In the piece Jim discusses the definitions and merits of Scrum and Kanban.
This is a subject about which I too have some feelings. Not feeling as talkative as Jim, I will summarize them. This will allow greater room for mis-interpretation, and therefore for greater learning. (smile)
1. Let's get more results. I am getting to the point where I don't care if we use Scrum, XP, Kanban, scotch tape, or Granma Berthe's Bible. What we use or what we call it means less and less to me.
Show me the smiling faces. Show me how it helped you or your team or your customers. In real life. The results are what matter. The gods who spoke to Jeff and Ken and the scrum community knew this well.
I better add: I still think Scrum is the place to start, and I don't believe in Scrum-But. But this subject is another 10 blog posts.
2. Lean bias. I look at Scrum and Kanban as parts of Lean. And I like them all.
3. Scrum. I think it is an excellent start. About as much as one team can change in a short period of time. And, yes, while it is simple, it takes years to become a master.
But Scrum is only a framework, and while the team should not subtract from Scrum, stuff must be added to Scrum. Actually quite a lot of stuff, in my opinion.
Scrum's 'incompleteness' is not a defect but a virtue.
4. Kanban. The cards in Lean were stolen from Piggly Wiggly (the grocery store). Which pleases me, since I have been to some of their stores, I like them, and my kids have "I'm Big on the Pig" t-shirts from Piggly Wiggley.
Kanban is one of several tools in Lean. Kanban may be classed with several Lean practices or tools under a group called "Visual Management."
Kanban in Lean first refers to the sign-cards stolen from Piggly Wiggly. And of course to all the 'usage' around that. Kanban has many purposes in Lean manufacturing. Reduce and manage inventory. Set up a pull system. Enable flow. Enable single-piece flow. Provide some indicator of stoppages in flow.
It is important to note that Lean uses many other things in addition to the Kanban cards to attain all the goals mentioned above.
5. "Kanban". This is becoming an alternative software development 'framework'.
It has various definitions. And there are of course now many implementations. Many of which would no doubt be called "Kanban-but..." by some of the "Kanban" people.
Many good and smart people like the idea, and so no doubt it does some good.
In Lean manufacturing, the Kanban cards represent things of the same 'size'. In "Kanban", the cards represent User Stories, but so far as I can tell, there is not a strong discipline yet to keep the User Stories of the same size. To me, this is a meaningful problem. (Long discussion as to why.)
Related to the size problem, "Kanban" has no metrics. Thus, it is hard to demonstrate this way that it is successful. (Yes, it is true that measuring success is difficult in almost every case.)
So, how much benefit "Kanban" provides compared to and separate from Scrum is hard to say. Objectively.
5. Engagement with Business/Management. It seems pretty clear to me that Kanban tends to be used when engagement with the business side and/or management is not wanted or not possible.
Clearly, to me at least, this lack of engagement is not a good thing. However, if it is not possible (for now), then perhaps it....is not possible for now.
Still, we tend to believe that Scrum, with for example the Sprint Planning Meeting and the Sprint Review (demo), and with Release Planning and Release Plan Refactoring (technically not a part of the core of Scrum)...Scrum with these things tends to build trust between the Business side and the Technology side. Admittedly, often they start in a state of mutual distrust. Sometimes severe. But these practices, if done well, smooth out the distrust and build trust.
6. Our recommendation: Scrum first, then add Kanban.
Some will note that this is similar to ScrumBan.
We think that Scrum is plenty to implement on Day 1. And the Scrum Board, which comes 'out of the box' with Scrum, is already a very basic Kanban board.
We recommend that later, after the have Scrum working decently, the team use the ideas from "Kanban" and Lean to modify the Scrum Board into a specific Kanban board that reflects their work. To us, the focus should include:
- Minimize WIP (work in process)
- Do not over-stress the system (a basic principle that deserves 15 blog posts)
- Single-piece flow
- Aggressively identify and remove impediments (eg, stoppages in flow)
Kanban and flow should not become a fetish. (Nor should Scrum purity be a fetish, for that matter.) There are good reasons to "stop" and do a Sprint Planning Meeting and a Sprint Review (demo), for example. And to do a Daily Scrum.
If developers (coders and testers) still evince a preference for "Kanban" after these issues are discussed and explained, management needs to consider carefully the root causes. Humans (developers and managers) are of course complex, and many things could be at play. But our first guess is that management is not aware enough how important it is for the team to have more fun when playing Scrum.
Fun is actually quite key to more creativity. Which, in our kind of work, is key to higher productivity.
6 comments:
Thanks, Joe, on your thoughts on Scrum, Kanban, and Lean. Too often people forget that Scrum and Kanban both are founded in Lean and that none of them is complete in itself. It's really important to understand the underlying Lean principles - only then people can improve their processes to make them more successful.
Hi Matthias,
I agree. I guess I will add this. To me, Scrum's 'incompleteness' is a virtue. While, if by Kanban one means the cards and some small usage around that, then Kanban's in completeness is a problem.
I think/hope most decent Kanban implementations avoid the problems I am concerned about to a fair degree.
I hope I explained those two comments in the post well enough.
Anyway, completely agree with what you said.
Thanks!
Joe
Joe,
Ahh..you can almost feel the learning in the air, can't you? (smile). It must be that time of year.
I couldn't agree more with most of what you've shared above; either the tools we're using help our teams and customers or they're not. Sometimes it's a problem of fitting the tool to the context, and sometimes it's a problem of learning and maturity.
Re. mastering Scrum before attempting Kanban; generally, I've found that teams unable to curtail their carryover lack the skills to limit WIP in activity queues. This is patently obvious when you realize that, from one point of view, a Sprint is essentially Kanban with a single time based queue (i.e. where the WIP cap = estimated capacity of the team for the duration of the Sprint)
Regarding those smiling faces, on the teams in which we've implemented 'Scrumban', I've observed the opposite phenomena you describe; business has been ecstatic about the increase in flexibility and reduction in cycle times. They're more engaged, not less (and in a healthy way). The teams seem happier too. Maybe it's just a difference in contexts or execution?
Regarding metrics, I'd be interested in hearing what problems you've encountered with 'cycle time per story point'. It seems to provide fairly useful feedback for evaluating the outcome of tweaks to the way the team manages flow (nothing's perfect of course). It's also a pretty handy way to spot deficiencies in the team's ability to estimate effort relatively (the yucky graphs just jump out at you).
I'm looking forward to reading about your thoughts and/or experience on the discipline of story decomposition (size) to improve flow. Regardless of methods of visualization, it seems a vexing (and sometimes fruitless) pursuit for some categories of problems. In lieu of that, I've seen some pretty good results limiting WIP in activity queues based on story points rather than story counts. Oh... wait... that's what we do with Sprints in Scrum. Never mind. Old news. (smile)
Extremely thoughtful post,
Thanks!
J.
Hi Jay,
Glad to hear that Kanban has gotten MORE customer/business engagement. As you suggest, anything is possible depending on the specific people involved.
I have observed (although not proven to myself) that the business can want too much flexibility, ie, they become 'whimsical' not because real life is changing, but because of their political dysfunction. I do hope that is not the case for you. I can imagine it not being the case, too.
My next concern about 'pure' "Kanban" is that we lose the demo. And the right attendance at the demo. To me, we want people there who will tell us: "Well, it's pretty much what we said, but now that I look at it, it's not what I want." At most of my clients, we can only get a bunch of those guys to show up about once every 2 weeks. Now, if you can get them to show up daily (and I have been in a few places where you can...well, every day that 'their' story is being worked), then it's a different problem.
My last concern is the tendency of me and others to be lost in the weeds. We need a cycle (every 2 weeks?) of looking up and saying "now, where were we actually trying to get to?" Or, to put it a different way: what do we think the minimum marketable feature set is today? Again, most of the kinds of firms I work with need this. I have also seen firms where this issue is very different.
One more thing you point out... we do not do Scrum or Kanban or whatever without thinking about the principles that the related practices are attempting to put in play. Only when we are in sync with the music do the dance steps become wonderful. I think many of us are dancing the steps, but no longer hear any music. It is a wonderful thing for a man to see a beautiful girl realizing the music in her dancing. Much the same applies, by metaphor, to our work. It can be wonderful.
Thanks!
Joe
Joe,
Thanks for the response.
Any mode of development that increases intimacy with business or extends decision event horizons brings with it the risk of gratuitous vacillation in choice. Coping with that very real threat is one of the reasons why the "Individuals and Interactions" side of the Agile equation get's the bold letter treatment. Mastering when (and when not) to change design decisions requires discipline and the acquisition of that discipline is heavily influenced by corporate culture (what isn't?).
I find that with a little creative coaching, seismic swings in direction can usually be nulled out without abandoning an otherwise helpful approach to creating products.
My "Warning Will Robinson" ring tone goes off whenever I hear words like "pure" and "true" used in close proximity to any process or tool in a sentence. Process purity should always take a backseat to team effectiveness. Most Scrumban teams I've seen continue to realize value from doing demos and maintaining a planning / review cadence so.. why change? That's really up to the team. What's cool is that with iterative approval by product owners, there's a LOT fewer surprises when you get to those mile marker ceremonies. As mentioned, you do have to keep an eye on the thrash.
I LOVE the music / dancing metaphor!! Grace and elegance emerge when the fundamentals become second nature; the trick is getting them to stop staring at their shoes, lift their heads, and find that harmony of flow (...quickly ducks before the metaphor police come by to clobber him with their night sticks...)
Cheers!
J.
Post a Comment