Introducing Kanban Into an Existing Scrum Implementation

By far, the talk that I am most requested to do is "Scrum and Kanban Like Chocolate and Peanut Butter". I've given the talk all over the US and Europe, most recently in Kiev for Agile EE. Invariably, people come up after the talk and ask how to get started with Kanban. I've given book and coach suggestions, but they are primarily pointers to pure Kanban resources.

Scrum and Kanban Like Chocolate and Peanut Butter
There doesn't seem to be much material specifically geared towards introducing Kanban into an existing Scrum implementation as opposed to going from non-Agile to Kanban. So, I've decided to write a short and concise guide to folding Kanban practices and principles into an existing Scrum implementation called "Scrum and Kanban Like Chocolate and Peanut Butter." I will write the guide via a series of blog entries over the coming weeks. I hope you will follow along with me, asking questions and offering feedback.

Who is "Scrum and Kanban Like Chocolate and Peanut Butter" Intended For?
The first question is: when does it make sense to introduce Kanban where Scrum is already in use? It turns out that is a very complicated question. Rather than answer that question, I'm just going to gear my posts towards folks that match a certain set of circumstances. My material for introducing Kanban into an existing Scrum implementation is geared towards folks for which the following is true:

• You have already been doing Scrum for 6-9 months
• There is a general feeling that things are going better than before Scrum was introduced
• You are using user stories
• You have a definition for "done"
• Your user stories are relatively short with no stories that take longer than 1/2 of the iteration to get to done
• Most stories are "done" at the end of the iteration
• You have an iteration length of 4 weeks or less
• You have a cross-functional (though not necessarily self-managed or co-located) team
• If there is a "business unit" that previously served as "the customer" then you've integrated the business unit and software team at least to the point that there is a product owner on the team which talks to the customer of the business unit, and the business unit is no longer considered to be the customer for the software team.

If you do not have all of the above, you may want to consider getting to this point first prior to taking any of the steps that follow. Over time I'll come back and update some of the points above with links to resources for addressing these points if they are not already true. The first post will be available over the next few days. The guide will be based on my talk "Scrum and Kanban Like Chocolate and Peanut Butter". If you want to get a head start you can check out a recent video of the talk which is available on vimeo.

Agile Book Recommendations

The following books are the main books that I recommend as starting points for learning about the various aspects of Agile. While their is a fair amount of overlap each of them covers a specific topic. The one on leading self-directed teams is not strictly an "Agile" book, but it is one of the few books talking about self-managed/self-organized/self-directed teams that I have found. The Toyota way is also not an "Agile" book but does a great job of explaining the concepts of Lean which I believe are the foundation for Agile.

Click to enlarge.

Sticking to Estimates

I got a great comment from Kelly Waters on my recent post "Scrum: No commitment required" via his web site. After responding I realized that the response was a good basis for this follow-up to my original post.

In the original version of Scrum, the commitment of the team for the sprint is dependent on two things: a good work ethic and good estimates. If either one is an issue, then the work won't be done on time. The “no commitment required” title of my previous post was a bit tongue in cheek. Absolutely commitment is important, but I don’t think that making it part of “Scrum” will suddenly make team members with a poor work ethic suddenly have a good work ethic or team members with problems estimating better at estimating. Nor will having commitment part of Scrum automatically improve a bad team/PO dynamic. 

People with a good work ethic will work hard. If you have folks with a poor work ethic, I believe Agile will expose this more clearly and then you can use your management skills to address it one way or another. Hopefully, with a win-win solution.

Estimates are just that, estimates. They are a good-faith representation of what the team believes it will take with the information they have at hand. When something is discovered, then it is important for the team to communicate that to the PO, but I don’t think it means that they have to stick to the original estimate. Is that “letting them off the hook?” I don’t think so. Let’s face it, if they estimate 8 hours, but it turns out to take 24, the only way to do it in 8 is to do 8 hours “on the books” and 16 hours off. To have the team absorb those extra 16 hours means that they will have to take it out of their own time which is violating the idea of sustainable pace.

If you have a team that consistently misses their estimates, that’s something different. Missing estimates should be the exception rather than the rule. When it becomes the rule, the question is what’s going on? Is team morale low? Why?

When using story points combined with tracking velocity, there shouldn't be a problem with estimates because story points and velocity should make the issue of estimates a moot point. What I mean is that if all estimates are suddenly off by a factor, the result is simply that velocity goes down. If estimates have always been "off" then velocity will not be going up or down, it will just be fairly constant. Since story points and velocity are relative, estimates that are "off" by a factor aren't a real problem.

Instead, the “problem” may be manifesting itself more as a general feeling of “this team just doesn’t seem to be as productive as it could be.” But then you are back to “why not?” I don’t think an enforced framework of commitment will change anything if the team has, for instance, low morale.

On the other hand, if the problem is wildly varying velocity (perhaps due to wildly varying accuracy of estimating stories) then I would venture there is a good chance that the stories are just too big in general and a good remedy to consider is to aggressively split stories into smaller stories.

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?

Agile Training in Boston, New York City, and DC

AccuRev will be providing its amazing Scrum User Training which is also at an amazing price in Boston, NYC, and DC later this month. If you are considering getting Agile training, you should definitely take a look at this unique combination of content.