Ways to play Scrum

Scrum.org-Logo-CirclesIn our Professional Scrum classes we also talk about the topics of User Stories, Planning Poker and (Daily) Stand-up meetings. Some attendants have never heard of it. Some have never practiced it. Some are convinced, or have been instructed, that Scrum says these are mandatory to do.

I have grown my own little pattern to work with a class whenever we run into one of these topics during my classes.

  1. I start by asking what Scrum actually says on the practice. In general, people don’t know or are not sure, and conclude that Scrum says nothing about it.
  2. I ask where the practice then does come from, if it’s not Scrum. Few people know that it is eXtreme Programming.
  3. I end up by saying that, despite the XP origins, we do support them in many cases as they represent good ways to play Scrum, they are good practices to chose from. And that this is the reason why we cover them in the course; to inspire people with different options to play Scrum.

But, they are not mandatory from the Scrum framework described in the Scrum Guide:

  • Extreme Programming Explained: Embrace C16614_fUser Stories, written on story cards, are the practice in Extreme Programming to hold and describe requirements from a user perspective. Bill Wake, author of ‘eXtreme Programming Explored’, suggested the ‘INVEST’ acronym as a simple way to remember and assess whether or not a User Story is well formed.
    A Scrum Product Backlog though serves to provide transparency to all work that a Scrum Team needs to do, which might be more than only functional requirements. The obligation, from Scrum, to use the User Story-format would endanger forgetting other important work to be undertaken, or it might force teams spending more time and energy on using the ‘right’ format, thus creating waste. However, for functional items on the Product Backlog, User Stories may be very good.
  • Planning Poker was invented by James Grenning during an eXtreme Programming project where he suffered from having to spend much, much time on producing estimates.
    In Scrum, estimates are to be created by the Development Team and, although not mandatory, Planning Poker is a good technique to do that. It leads to more honest estimates from a complete team. But don’t forget that the intention is to invoke an honest conversation over the estimates. Because that results in a good understanding of the work attached to implementing the discussed item.
  • Daily Stand-up are described in Extreme Programming, which recommended participants stand up to encourage keeping the meeting short.
    Scrum describes this meeting as the Daily Scrum, but doesn’t oblige to do it standing up. However, it is a good idea to do, especially to keep the time-box of 15 minutes.

That is often a relief to students, knowing that it is not mandatory. And I am glad I can help people. I am glad they see more opportunities to discover their own best way to play Scrum respecting the intentions and design of Scrum. They see better how Scrum can help teams and organizations emerge their own process. These ways to play Scrum in teams’ specific contexts turn the selected good practice into best practices.

Scrum, after all, can be called a ‘process’, but it’s a servant process, not a commanding process.

10 years, or so. Piece of a career. Rückblick.

It’s been 10 years since the world was shocked by the brutal airplane attacks on the US. It’s a terrible birthday, but it also reminded me of the fact that it’s been only 10 years of working in IT consultancy for me. But, boy, what a path it has been.

On 9/11 of 2001 I was guiding a junior analyst of a customer of the consultancy company I started working for not too long before. After having heard of some crazy attack, but not even knowing what the twin towers really were, I drove off to an interview with another customer for an analysis assignment. They approved of me, and I started… analyzing. Having no formal background, except a 3-day UML course (hmm, don’t have the attached diploma anymore, I fear), I tried to be pragmatic. Mixing plain text descriptions with Visio drawn screen drafts and flow charts and other diagrams. Whatever seemed most appropriate to get the message across. I later on estimated the project upon a model built by a senior colleague, upon listing screens, field and data types, and expected difficulty. And my management strongly insisted on communicating less days to the developers than estimated. You can’t trust ’em, ya know. But I didn’t, as I didn’t hide the included contingency. Did create a predictive plan. A giant MS Project something matching the expected elapse time.

Having no formal background in project management, I managed to get my team in the same room and do intermediate sessions with the customer. Project room however was organized in a traditional class style (rows) and I was regularly disappointed because my extremely good contacts with customer staff didn’t prevent them from abusing my intermediate sessions for adding scope and changing their mind. Still, we had a fine time, and the project ended (for my employer) in a break-even, which made it even a fantastic fixed price project.

After this project I was asked to start up a new, critical project in very difficult circumstances, i.e. the project hadn’t started yet and was already nearly over time. It only took 2 smart software architects 15 minutes to talk me into eXtreme Programming. Because I saw how XP made explicit, structural and inescapable what I intuitively had tried to do in my traditional project: communication (pair programming, face-to-face) and consistent, clear iterations. Project wen extremely well, ended in time and with profit. Quite extraordinary for a fixed price project. Big-time success!

When scaling up for that same project in a next phase, I was pointed to this thing called Scrum. I read the 2 books by Ken Schwaber available at that time. I went to a CSM course by Ken, where I learned formally not so much, but was excited about the collaboration with Ken and the other participants. We then replaced our organizational practices from XP with Scrum. We kept on applying XP engineering practices though and this felt really natural.

Today I am reading “The Black Swan” (Dutch translation though). On unpredictable, high-impact events. Like 9/11. And I just officially became Professional Scrum trainer from Scrum.org and… Ken Schwaber (Professional Scrum Master and Professional Scrum Product Owner class). You can’t even imagine how proud and happy I am about this. It seems such a long road. Yet, the seeds were sown not more than 10 years ago. And no terrorist or traditional manager is going to ruin my pride.

Respecting Scrum by doing more

;-) Confession
I did eXtreme Programming before I did Scrum. Although this may seem trivial, it has positively affected my further Agile career.

Let’s go back in time…
In September 2003 my management (consultancy company) assigned me on a project that they hadn’t hoped to win and that was allotted far too late. Result: our company was facing a development effort of 700 days and delivery in December. Two software architects, literally in 15 minutes, convinced me of applying eXtreme Programming. Because I recognized what I had been trying to do in previous projects, but was now sort of ‘hard coded’ in the approach, i.e. iterations and communication.

In only a couple of days we created User Stories, replaced the MS Project phasing by 3 iterations of 3 weeks and convinced the external customer to intermediately attend demo sessions. Our roles included the Team, a project manager/Big Boss (me), a Coach and a proxy Customer. As we soon discovered that our proxy Customer was fully occupied in functional guidance to the Team, we included a Tester to assist her. The Tester incrementally wrote hands-on functional test scenario’s for the User Stories being developed. We added 2 days of slack before the stakeholder demo; to fix small issues, prepare the next User Stories and do spikes.

In 2004 we had to scale and the same fellows (now Coaches) directed me to Scrum. I read the 2 books by Ken Schwaber and registered for his CSM course in May 2004 in Brussels. It was a great experience and as from then we used Scrum for our organizational practices (Sprints, roles, meetings, artefacts) but we kept using eXtreme Programming as implementation for the general Scrum demand of Engineering Standards (PP+TDD, CI+Refactoring). From those engineering standards the use of User Stories emerged, as well as the roles of Coach and Agile Tester.

We always delivered fixed price projects as an external supplier. So we had to translate the customer’s Vision (mostly an RFP) into a Product Backlog, more READY than you would expect in pure Scrum. But we put a maximum length of 1 Sprint on the effort (but usually did it in less time). Our Sprints delivered DONE and potentially shippable work, but we added a final hand-over Sprint (no development!) to close the project. Oh yeah, our ‘slack’ turned into Product Backlog Grooming sessions.

A framework was born.
I went through lots of yo-yo movements over the next years. Even quitting for a while, tired of the slow local adoption (supplier ànd customer side). But… relaunched my ideas as My.Fragility to re-enter the market. And at my current employer we renamed the framework to ScrumPlus, because it does respect Scrum completely, but just extends the base pattern of Scrum to the particular use for delivery of fixed price-negotiable scope projects.

Back to the future
In February 2011, my management decided to apply only Scrum and ScrumPlus in some major Service Lines, abandoning RUP or other traditional approaches.

So I have set up a training program while I will be coaching people in the field. From the training people will get a deep understanding of the base mechanics, principles and emergent Scrum. Project practitioners will get a good understanding of ScrumPlus as instance of Scrum, its base Philosophy of Done, its Agile Project Life Cycle and the 2 Excel tools.

And as you have understood this is largely rooted in my early eXtreme Programming experience.

Managing Risk & Quality with Scrum

It’s a strange, yet wonderful, world, our world of Software Development. Where success is often considered a coincidence, a lucky shot and too anecdotal to believe. Although I have a proven track record of successful projects with Scrum (figures and data included) I still try to present various angles to my results. Here’s my perspective on Risk & Quality

Risk

In a traditional project, a number of phases and activities are typically performed separately and sequentially, upon the belief that extensive descriptions, signatures, sign-offs and hand-overs assure a good result. However, as practice shows, users and customers don’t realize what they’ve asked, described and signed until they get their hands on it. In the absence of that, risk just piles up. And when the usable application finally becomes available, all additional work, rework, tasks or activities will immediately force the project out of time and out of budget.

In our Scrum projects we slice the work in timeboxed iterations (Sprints). We re-organize the typical IT activities drastically because we perform them daily, in parallel and in every Sprint. We build and demonstrate working software at the end of each Sprint. Feedback and change is processed in the next Sprint, keeping us at all time in line with (changing) expectations. But, it’s true, we do not spend countless effort and time on upfront work. Risk therefore seems high at the start, but upon delivered results it will quickly decrease and keep steadily decreasing:

Quality

The ultimate evidence of quality is in working software. As we deliver that frequently, functional quality can be easily determined (and quickly improved). Business Value therefore continuously accumulates where in a traditional approach it is more delivered as a big (disruptive) burst.
The underlying technical quality of the software is assured by the daily, integrated testing and the application of good ‘engineering standards’. We implement these standards with our (daily performed) “Quality Loops”:

Here’s a movie

When creating a presentation on the above, I started a little experiment with the recording option of PowerPoint (version 2010) and succeeded in creating a movie of my presentation. And however improvised and somewhat rudimentary it may be, I’m just gonna leave it like that…

Stay tuned to My.Fragility

My.Fragility is my framework of Agile practices for flexible delivery of software development projects.

  • It started in 2003 with eXtreme Programming
  • In 2004 I started using Scrum and certified as a ScrumMaster
  • I’ve always applied personal practices for fixed timeframe projects
  • To prepare projects I use a Product Backlog Estimation model
  • I track development with my Product Backlog Tracking model

I have started distributing my documentation on it, beginning with my overall presentation: My.Fragility – The Essential Scrum and beyond (handouts) (4 MB).

It includes:

  • an introduction on the general position, maturity and adoption of Agile as a software development method
  • a focus on the process of Scrum
  • the specific elements (and additions) of My.Fragility
  • addenda on eXtreme Programming, references and the roots of Agile

Find all my notes on my framework under the tag my.fragility.

Or stay really tuned via RSS http://en.wordpress.com/tag/my-fragility/feed/

The sizing of User Stories

My My.Fragility framework adds my insights for fixed price (-negotiable scope) projects to XP and Scrum.

I included a Product Backlog Estimation model to calculate a total price using my Definition Of Agile Planning. And on top of User Stories and Story Points the Sizing of User Stories is to be considered:

The right size of a User Story is 0,5-5 ideal days (di) (ideal time = Story Points). For development. To be invEST. To comfortably fit a Sprint.

  • Epic Stories can be 5-15 di. A size not suited for development but acceptable for estimating. To be split into User Stories.
  • Cosmic Stories are >15 di. They can serve only as a beginning to understand a Product, not for estimation or development.
  • Tiny Stories are < 0,5 di. To be combined into User Stories.

Note: ‘Minimal Marketable Features’ (MMF) from Kanban can be a set of User Stories. Possibly an Epic Story.

The best base to estimate is experience. When experience is limited, use relative estimates (complexity scaling). I use a 1-2-5 scale:

  • Size is set upon complexity to 1-2-5-10-20-50-100-… Always use the higher value if you end up in between two points.
  • Find some reference points in your experience to compare.
  • Refine until you end up with real estimates (Story Points).

note: Ideal time is development time without breaks, questions, problems or any interrupts. It is multiplied with Velocity to get Planning days.

Definition of… Story Points

I have combined personal insights for fixed price (-negotiable scope) projects with practices from eXtreme Programming and Scrum in my My.Fragility framework.

The main estimation steps from the framework’s Product Backlog Estimation model were highlighted in my Definition Of Agile Planning. But the model also implies at least an understanding of some definitions.

After my definition for User Stories here’s how I use Story Points:

  • Story Points equal ideal time (“ti”). But using ‘Story Points’ might prevent people from confusing it with realistic time. The eXtreme Programming notion of Gummy Bears (“Bg”) might be a bit too abstract, although it’s fun to use.
  • Ideal time is the development time for a User Story without breaks, questions, problems or interrupts of whatever nature. Spending every minute of every working day on productive coding.
  • Ideal time is mulitplied with Velocity (“v”) to estimate Planning time (“tp”). In my experience, an overall velocity of 2,5-3 results in a realistic number of planning days.

planning time (“tp”) = ideal time (“ti”) * Velocity (“v”)

  • An alternative definition of Story Points is the number of productive coding hours per day. This is generally accepted as maximum 5-6. Velocity is then expected to be around 1,33.

Note I generally apply an overall Velocity to all User Stories, although my model allows a specific Velocity per User Story, e.g. depending on the expected complexity.