Scrum: No Commitment Required!

A couple of years ago I first talked about applying the decoupling principle to Scrum. Since then I've turned a bunch of that material into a presentation called “Scrum and Kanban Like Chocolate and Peanut Butter.” I’ve made many updates to the presentation and presented it to a wide variety of audiences. One of the main points of the presentation is that all of the things in Scrum that are coupled to iterations can be defined in such a way that they are no longer coupled to iterations. I argue that once you have done that with everything, there is really no value left in an anchor point which anchors nothing. That is, there is no fundamental need for iterations in Scrum.

From time to time I’ve realized that I forgot to decouple something, figured it out, and added it to the presentation. For example, burndown charts, burnup charts, and per-story timeboxes. The per-story timeboxes were tricky to even notice because in Scrum we generally think of timeboxing at the iteration level, but in effect that also imposes a timebox on individual stories. If you remove iterations without taking this into account then you are also removing the per-story timeboxes.

But recently, buried among the many feedback forms from presenting at Agile 2011, I found three little words: “What about commitment?” Ouch. I had missed a big one! The Scrum team makes a commitment that is tied to an iteration. How could I have missed that?

As I thought about it more, I realized that I do actually address this point in an off-hand way when talking about decoupling story assignment from iterations. However, I am very grateful for the comment. It helped me realize that I had been effectively dismissing commitment as though breaking a promise with a shrug.

Scrum's Commitment

It turns out that Scrum's commitment is a bit too strict. Even the version of the Official Scrum Guide as revised by Ken Schwaber and Jeff Sutherland, the co-creators of Scrum acknowledges this. In the new version of the Scrum Guide, the commitment has been replaced with a forecast. The idea is that the forecast represents the combination of what the product owner wants and what the team believes it can deliver as the next shippable increment. This is a reasonable response, but I think something is lost in the change. Let's look at this another way.

Mutual Trust

The original idea behind Scrum's commitment is that the team commits to finishing what they have signed up for for the sprint and everybody else commits to leaving the team alone. It is really two commitments based on mutual trust. Without this mutual trust, both commitments break down. But both commitments are actually completely unreasonable and don't reflect reality. The goal is good, but the implementation is poor.

The problem is that the team is not prophetic. They can't possibly know how the work will turn out until they have actually attempted it. More often than not, their estimates will be wrong. Sometimes a little, sometimes a lot. Things happen. The product owner is not prophetic either. They can't possibly know what demands of the business will come up or how customer needs may change within the timeframe of a sprint. A set in stone commitment makes it difficult for both parties.

In practice, the most important ingredient is mutual trust between the team and the product owner. This rapport allows the team to go to the product owner when they discover they have made an unrealistic promise and ask to switch out a story. It also allows the product owner to come to the team with a new request that is more important than another unstarted story and ask to swap them.

Decoupling the Forecast

If Scrum now talks about a forecast, and we are comfortable with the transition of commitment to mutual trust, then the real question is how do we decouple the forecast from iterations? First of all, ask yourself if you need it. If you don't, then there's nothing left to do.

On the other hand, if you feel the need for a forecast then the same approach can be used as for decoupling other aspects of Scrum, you simply redefine the timeframe. By default, the forecast is tied to the timeframe of the iteration. If your iteration is currently 2 weeks long, then go ahead and provide a two week forecast. It is a subtle point, but by defining a forecast period on its own, it is no longer tied to your iteration length. For instance, you may be doing four week iterations and then move to two week iterations. But if you decouple the forecast from the iteration then you can keep your four week forecast. And once again, after you have decoupled everything in Scrum from iterations, what's the value of an anchor point that has nothing anchored to it?

You may also be interested in the follow-up to this post, "Sticking to Estimates"

Scrum and Kanban Like Chocolate and Peanut Butter Slides

For those of you that have attended one of my recent talks on "Scrum and Kanban Like Chocolate and Peanut Butter," here are the slides for the presentation. If you haven't already attended the session, be warned that there are no speaker notes and clicking through rapidly may result in vertigo due to the high degree of animation contained within.

Agile 2011 Highlights and Why Go to Agile 2012

For the third year running now I've produced a video of highlights from the Agile 20xx conference. The intention is to give a flavor of the conference and also to motivate folks to consider going to the next one. It is amazing how much value one can get out of the conference and my hope is that more people will experience that value.

The first year was a single take done during the "open jam" session at Agile 2009. The second year I used iMovie on the iPhone 4. This year I got slightly more sophisticated using iPhone 4 for video capture and iMovie on the MacBook Pro for editing. This year I've added photo overlays, voice overs, and audio normalizing to my bag of tricks!

This video has it all. A fight scene (!), comedy, acrobats on skis, interviews with attendees, clips from the sessions, and much more. Check out the short version on YouTube! An extended edition will be available soon.

Agile 2011 - Back to the Future!

Here are my thoughts on anticipating Agile 2011, filming Agile 2011, and reflecting back on the past 10 years of Agile.

Looking Forward to Agile 2011
I can't believe that Agile 2011 is upon us! A chaotic action-packed week mixed with being away from the family. And then after the event there is the week of withdrawal . No matter how wonderful and Agile your company may be, it can be jolting to move from "The Agile Future" back to whatever level of Agile you are currently at.

But I wouldn't miss it for anything. Every year there is a smorgasbord of sessions to choose from and this year is no different. Out of the literally hundreds of sessions, I've narrowed it down to 22. That includes the keynotes, and special events. If it is anything like last year, after I get over withdrawal I'll be drawing inspiration from those 22 sessions for months and hopefully it will fuel my Agile fires until "Agile and Beyond" and the Lean Conference in the Spring.

Filming Agile 2011 to Inspire Others
I strongly believe that everybody involved in software development should go to Agile 20xx every year. The ROI is just unbelievable. Of course, that will probably never happen. But my hope is that I can inspire at least a few more people to go and that it will make a difference. Towards that end, in 2009 and then again in 2010 I did a combination "Agile 20xx Highlights" and "Why You Should Go" movie completely filmed and for 2010 completely edited on my iPhone.

This year I'll be bringing along my iPad 2 which boasts an updated iMovie and will do it all again. Once again I'll be looking for people to interview about their experiences and to find out more about why they go. If you think you've got some good material for me, let me know. Also this year I'll be trying to do some video blogging for those of you back home to give you a visceral feel for what it is like and hopefully inspire you to come to Agile 2012!

I'm also open to suggestions for what to film. What questions would you like me to ask, what would you like to know about Agile 2011 that I can capture on video?

Looking Back on Ten Years of Agile
Actually, that's a misnomer. The Agile Manifesto was drafted in 2001 in Utah (thus the location for Agile 2011), but actually what they did in that meeting was to coin the word "Agile" and produce the manifesto to describe what the signatories felt was common about the various things they had already been doing for some time.

But anyway, what's the "big takeaway" of the past ten years of Agile? In my opinion, it is that there is now a struggle between Agile becoming fossilized and breaking out of the Branding Wars to reach its true potential. Let's face it, Agile was not handed down to us from a future where everything has been figured out and they have been doing it successfully for 100 years. No, a group of bright folks started talking about "Agile" 10 years ago and we've all been trying to figure out what to do with it since then. Along the way we've gotten "XP" and "Scrum" and "Kanban" and "TDD" and "Continuous Integration" and "User Stories" etc etc. It has been a true Renaissance of interpersonal and technical learning and growth.

But there is also the inevitable desire to have something definitive and unchanging and solid and secure. Scrum is currently that thing. What's wrong with that? Well Scrum is good, better than "waterfall," but it is far from perfect and it is only a subset of Agile, not the definition of Agile. Personally, I think there is much more value in the parts of Scrum than the sum of those parts. Things like product owners and backlogs are much more valuable in the long run than artificially binding them together in a particular way. More important is the process of  figuring out which pieces work best in your organization and having the knowledge and skills to do that process well.

Right now, it looks like Kanban may be just the thing to break the Scrum stranglehold. So let's all go out and learn how to do Kanban exactly right and by the book to do just that, ok? Oh wait... I've got a better idea, how about we think about how to combine Scrum and Kanban like Chocolate and Peanut Butter. And while we're at it, how about a little pair programming from XP to spice things up?