I just attended the Lean Kanban Conference in Miami. I have been going to conferences for 12 years. My mainstays of the last few years have been regional open conferences, SD West, SD Best, Agile Alliance, SQE’s Better Software, SQE’s Agile Development Practices and APLN regional conferences. I’ve had to redefine my 1-10 scale. What was formerly a 10 has to be moved down to 7 to make room for the new 10 this conference was. Truly amazing.
Here are some of the differences. First, the group was diverse, with different attitudes and experiences but were nonetheless completely open to any conversation. We also had quite a few big names there – amongst them David Anderson, Dean Leffingwell, Peter Middleton and James Sutton. My favorite talk, however, was by someone I had no familiarity with before – Sterling Mortensen who had helped with HP’s efforts. His early talk was a premonition of what was to come. The experience reports were amazing. None of the – “well we tried this, yadda yadda, and then we did this, yadda yadda, and then we had troubles with this, yadda yadda, …”. At the end of which you felt like you’d seen a bunch of old houses that you knew you’d never want to enter.
Virtually all of the experience reports (perhaps half the conference) were of the nature – here’s a problem we had, here’s our attitude about it, here’s how we solved it. Sometimes the problem was technical, just as often it was team/attitude/management related. The point was people were showing us problems they had encountered and how they analyzed them and solved them. Sometimes this was done with explicit knowledge of Lean or Kanban methods and sometimes they just naturally evolved to include those methods. But the practices used and the principles underneath them were typically very intertwined in the conversation. This enabled most everyone at the conference to be able to relate to the experience of the team(s) involved.
Sometimes it wasn’t clear as to why what happened happened. Then, it got even better. During the breaks people would have discussions about why a result occurred. For example, John Heintz asked me why I thought people were having less fear with Kanban approaches than what we’d seen on other agile teams. I had noticed this too and thought I had an answer – suggesting that in Kanban teams the focus is on the workflow and how to improve it while in many of the Scrum teams I have seen they ask themselves about what they (the team) is doing wrong. While not an inherent part of Scrum, this fear often happens because there is not an appreciation for the importance of systems thinking.
John was not particularly satisfied with this answer –believing there must be more. In a discussion immediately after the conference we continued the conversation. He suggested that Kanban had a focus on how to improve each step. It was like having a discovery conversation about how to do something better, not a conversation about what someone was doing wrong. This conversation was also about very concrete things (e.g., how many Kanban cards should be used). This enabled team conversations about very concrete problems - making team problem solving more frequent. This created trust between the team members. It became a “we” thing, aligned together instead of “who needs to improve”. We're always talking about building trust in the Agile community - here was an example of the process assisting in doing just that.
I’ll admit this conference was a real eye-opener. Making me realize how little I know about this exciting new method (even though we’ve been teaching it to some of our customers for a few months already). In the past, I’ve thought of where I should use Kanban instead of Scrum. For example, we had seen where Kanban was easier to implement in service organizations where an unpredictable stream of bug fixes and requests deluged teams. Another area we used Kanban was when there were highly specialized personnel and figuring out how to manage their resource during a sprint was difficult. On reflection I realize that a lot of places where Kanban avoids challenges that Scrum needs to resolve weren’t considered reasons to do Kanban because I knew how to solve or avoid the challenges with a context of Lean with Scrum (for example, working on two features at the same time – see below). One comment that particularly illustrates this was one from David Anderson. At the end of one of the experience reports, the presenter seemed a bit humbled by his results compared to some others. David commented - "do you realize you got your team doing continuous process improvement in 6 months? That's a high level of maturity."
On further reflection, I suppose this amazing result shouldn’t be too surprising. After all, I’ve been saying for years that doing Scrum within the context of Lean principles greatly increases the effectiveness of Scrum. In other words, you can remove many impediments that Scrum exposes. What I hadn’t recognized, however, was that using Lean principles to create your process in the first place with Kanban, solves many things before they even become impediments.
Here are a few that I observed during the presentations:
Multiple features being worked on in an iteration. When people create release plans based on stories, sometimes multiple features get into the same sprint. Scrum attempts to avoid this by telling people to focus on the “one big thing” of the release. When one Minimum Marketable Feature (MMF) is in the release, this is not a problem. But release planning often is not based about MMFs. Although many in the Scrum community are finally embracing MMFs the way they eventually embraced up-front-testing, it is taking quite some time for it to be considered to be part of Scrum when new features are involved. The batching of work is the essential cause of this problem. Kanban avoids it completely by not having batches. They start with the feature and break it down as necessary – but would not have two features being worked on simultaneously in the same team unless it was necessary (i..e, someone were blocked).
Having to plan out how to use specialized resources during a sprint. Scrum suggests that self-organizing teams magically will coalesce on finding the proper people at the right time for the work involved. Many people have interpreted this as meaning you have to have generalists on the team. I have worked with teams where some of the people on the team were PhD's with years of experience what they were doing. Cross-training was not going to be an answer here. Even on less extreme problems, I have seen many teams where certain people were the only ones who had necessary insights into the problem domain or legacy code. While these impediments could be improved (and possibly resolved over time) Scrum provides little in the way of managing these people’s time. Kanban’s use of Theory of Constraints and Kanban cards gives insights to solve this.
Moving focus from stories to features (MMFs). I have seen many many teams believe the driver of Scrum is the story. The introduction of the Epic often helps, but more often does not. When an epic is considered a mere collection of stories, teams typically still build software from the bottom up – a story at a time. Lean’s guideline of “optimizing the whole” creates a better perspective – write stories within the context of the Minimum Marketable Feature. While epics may be used this way, I don’t see it an awful lot. Kanban starts with the MMF being given to the Kanban team at the beginning and therefore creates the context needed.
Creating tension among product owners. Tension is a good thing if people are aligned to resolve it. All too often I have seen Agile teams working in isolation. Each product owner picks what is best for their team but a feature being built by one team is often not as important (to the business) as a feature on the backlog of another team. Sometimes specialized skills prevent doing this but often there is no reason to be working on the more important story except for lack of visibility.
In one of Corbis’ early implementations they had a “silver bullet” story. This was a story that a product manager could designate as having top priority over everything else. The team only allowed for one of these – but it was up to a product manager to say to use it. One day a product manager designated a story as “silver bullet” material. What was interesting was that the other product managers recognized that this story would slow everybody down so they said – “why is this so important?” Basically, the product managers self-organized to see the bigger picture to resolve the conflict between the product lines. Brilliant!
Creating a focus on the work and not on what people do. Deming’s understanding of systems is an integral part of Lean-Thinking. One advantage is that people can be more objective. Discussion of the work at hand means I can challenge the work being done without challenging the person doing it. I can ask – “why do we allow so much work in process, what can we do to improve that?” This is much less threatening that asking someone – “why are you starting so many tasks? That’s causing a problem.” Focusing on the work both creates a safer place as well as creating an understanding that how we work has an effect on our productivity.
Lowering the fear on the team. Some teams exhibit new fears when Scrum is introduced. The promises of getting stories done within a certain timeframe can be intimidating to highly motivated professionals who identify with their work. As a coach, I have spent a lot of time helping people overcome this. It is self-imposed most of the time. This fear ultimately stems from a lack of understanding what responsibility and promises are. A promise is not a “I’ll do this or I am a bad person.” It’s really a statement that says “I’ll do the best I can to get this done and if I can’t I will communicate to you at the first opportunity I have that I may not be able to accomplish what I said I would do.” Scrum would be a lot less intimidating if people understood this – but many don’t. Kanban focuses on the work, not on the promises made. Most people are motivated to do the best they can and to work in a timely manner so the motivation of the promise is not usually required. If it is, there is another problem.
Automatically eliminating the problem of too many stories being started. Most every team I know that has started Scrum has had too many stories opened at the same time in their first sprint or two. You can talk about how this hurts productivity but it is just too easy to start another story than it is to solve the problem causing the blockage. Anyway, blockage is often just the way it is. Typically, no one actually does an analysis to see how many stories should be in process so what harm does it do to start another one? Kanban explicitly says this is a question to address – how much WIP should a team have. A good conversation to have.
Enforcing the sequence of the steps the team has available. Once a team has decided its WIP level, Kanban cards are straightforward ways of enforcing the team’s decision. This decision, of course, is not set in stone. But it helps clarify the team’s best understanding of what will work best and gives a framework for changing team decisions. It also helps individuals follow the team’s decisions.
Encouraging people to work on what they are best at, but keeping them available to work on what they are capable of when needed. A team of generalists is ideal – but often virtually never present. Marcus Buckingham, in the One Thing You Should Know, makes a brilliant case that people are more effective working on what they are most skilled at than learning how to improve what they aren’t good at. While a team probably has members that are good at analysis, test specification, coding and testing, each member probably has a different level of ability in each of these tasks. While Scrum tells you to figure it out, Kanban gives you a nice mechanism on how to do this.
A note about this section. I am not, nor ever have, been trying to bash Scrum or say it shouldn’t be used. If you are using Scrum and either haven’t had these problems or have worked through them and are happy – more power to you. However, if you are experiencing these problems (and don’t feel bad, most teams we’ve started working with have) then perhaps you should consider trying Kanban or other Lean method. I believe you’ll find it much easier to improve your process with this model.
During the opening remarks I made a comment that I believed 5 years from now we'd look back on this conference and see it as a watershed event in the industry. Much of my comment was about the formation of the Lean Software and Systems Consortium as about the ascendance of Lean-Kanban. During David Anderson's closing remarks, he commented that at the start of the conference he thought my remarks were "hyperbole" but that at the end of the conference he could already see it happening. If you'd like to see other participants' comments, look for Israel Gat's Blog (The Agile Executive) on "Dean Leffingwell on the Lean & Kanban Conference 2009".
I am sure the future we will see many more Lean Kanban conferences. I suspect the UK one in September will sell out (I will definitely be there is some capacity). As they get bigger, I have no doubt they will also get better. Unfortunately, they will likely never be this intimate or surprising again. However, I believe the conference was summed up with two statements Jim Sutton made (co-author of Lean Software Strategies with Peter Middleton and Lean implementer extraordinaire at Lockheed Martin). On the first day he said his efforts in telling people about Lean were attempt to “save the middle class.” Jim is one of the few people who can say that humbly while at the same time let you know he means it. At the end of the conference, he said “I have found my tribe.” So have I. I invite you to join us.
CEO, Net Objectives
Achieving Enterprise and Team Agility