It’s March Madness for college basketball here in the US. And if you know me, you know I am a nut about college hoops. Hence my metaphor for David Anderson’s recent book, “Kanban”. It is a true dream team of material and I am a true fan. 
I had been flipping through David’s book, a bit here, a bit there. And then one day, found myself completely absorbed. I am so struck by David’s expanse of knowledge, his well-founded observations, and his breadth of very accessible experience. What strikes me most though is the clarity of voice in which David offers us his depth of guidance on Kanban.
I first remember hearing David’s passion around Kanban at the Agile 2007 conference in Washington. Just a few feet away from where I was putting final touches on my systems thinking talk, here was David. In the Open Space of the conference, he collected anyone interested to listen to his passion about Kanban. I watched the small group of people grow to a larger group. For me, that was the moment I started to see David and Kanban become synonymous.
Since that 2007 conference, Kanban has become a much sought after topic by organizations looking for visualization, transparency, and continuous improvement in their processes. David’s book is a wonderful place in which to begin your Kanban immersion. Through David’s book, we learn why we should care about Kanban; how principles of flow guide our perspectives on Kanban; and what the Kanban practices are that specifically help us continuously deliver value in the larger context of our organizations.
Now, to admit my particular biases about why David’s “Kanban” is a top seed in my brackets:
- I love the “Takeaways” at the end of each chapter. Each snippet is spot on.
- I already mentioned it but the clarity of voice. It is key in how David brings us Kanban in such an accessible way.
- Everything about WIP limits. David has a “cool your jets” approach to how to set WIP limits and then watch how they help or hinder the value stream.
- “Dragos and the 25 Days.” Sound like a children’s book? Too bad. You are going to have to read David’s book to find out why Dragos and his 25 days, for me, is like an incredible 3-point fadeaway shot, all net, with one second on the clock!
I am fortunate to be in an organization that is embracing Kanban. I am fortunate to experience Kanban day-to-day as well as to bring my experiences to others. I am so fortunate I have other colleagues here at Rally passionate about Kanban. I’m very fortunate to be involved in the upcoming Lean SSC conference in Long Beach where many of us will be coming to talk about Lean and Kanban. And, I am so fortunate to have been there in 2007 for David’s talk about Kanban and to now have David’s “Kanban” book in my toolbox of Kanban goodness.
Read this book and embrace David’s advice. It will not only put you and your organization at the top of your bracket; it will keep you there.
Jean Tabaka is a March Madness college hoops freak, a crash skier, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka
Here’s something obvious I’ve learned the hard way: delivering “potentially shippable product increments” each and every Sprint isn’t easy. Essentially you’re trying to take all the disparate activities that occur throughout the waterfall process, focus them on just the little product increment’s functionality and then jam them into a teensy little Sprint. Hard to do and definitely pretty unlikely to get accomplished right out of the chute. The authors of “Practices for Scaling Lean & Agile Development”, Craig Larman and Bas Vodde, forgive you in advance for not getting this done straight away. In fact they suggest that this is more a goal the team will approach over time than a rule they put in place on day one.
The authors propose something very simple but very insightful:
- Sketch out all the things you need to do to get your product out the door.
- Define “done” as that subset of those the team is currently capable of performing every Sprint.
- Use your retrospectives to challenge the team to bring more and more of the “undone” work into each Sprint.
This has already changed the way I think about retrospectives. For other nuggets from Larman and Vodde’s book, read on.
Overall a Must-Read for Agile Development Leaders
I was blown away by “Scaling Lean & Agile Development”, as you can see from my bullish review on O’Reilly. Some time has passed since then but I still feel that it’s one of the most important development books I’ve read. That book alluded to the companion volume, “Practices for Scaling Lean & Agile Development”, and as you can imagine I awaited its publication eagerly. It came out in February – I’ve worked my way through it now. It’s most definitely a worthy successor.
The first book presents theoretical and philosophical underpinnings for agile and lean development. The second book presents a survey of practices relevant to all aspects of the process of developing software at scale, presented by two guys who bring a wealth of knowledge and experience to the table.
Continual Investment in Requirements
Larman and Vodde present practices relevant to a continual investment in requirements throughout the product development process. This is done both up-front, in seeding the product backlog, and iteratively, in refining requirements to support upcoming Sprints.
I love the emphasis they place on whole-team involvement in the initial Product Backlog development effort – even for projects with large teams. Too often I’ve seen this be the provenance of Product Owners, working in near isolation, which does little to get the project off on a good footing. The first the team sees of the requirements is the Product Backlog itself, having been involved in none of the discussions and thought that went into it.
The notion of requirements areas, which was introduced in the first book, is leveraged here to help parallelize the initial requirements development work. Concurrent sizing and value estimation workshops keep the requirements work rooted in reality. They spend some time on the problem of bootstrapping a consistent sizing process in a large scale team. The use of cross-team estimation sessions result in the development of a canonical set of sized stories used as a basis for subsequent sizing at the team level.
In Favor of Forward-Looking Requirements Refinement
The discussion of forward-looking requirements refinement really resonated with me. I’ve found in my own practice that peeking ahead at the Product Backlog items upcoming in the next Sprint and then spending time together working through them to understand what they really mean – before we get into the Sprint planning session – goes a long way towards supporting a predictable iterative process.
It also puts the requirements elaboration just barely outside the Sprint that the work is planned for. This separates coming to an understanding about what we want from the stress of figuring out how to fit it into a Sprint, which makes for more open and enjoyable requirements development. The authors suggest the use of examples and Acceptance Test Driven Development (ATTD) to more precisely capture the intended behaviors of the stories in a way that realizes both conversation and confirmation of the “three Cs” . Smart.
T
he authors show how traditional approaches to project scoping and commitment (where separate product management and development organizations act essentially as competitors) are very much analogous to the contract negotiation that the Agile Manifesto cautions us against. I’m surprised to admit this never occurred to me – I always read that part of the manifesto pretty literally. But it’s inarguably true that the wrangling between these two groups over project scope and timelines that happens in many organizations is a form of contract negotiation, and the waste it drives can be startling.
The arm wrestling of the product management “market ask” captured in a Market Requirements Document followed by the team’s “development response” carefully defined in a Product Requirements Document is a case in point. Weeks and months can go by during this ritual. What are the development teams doing during this time? Not at lot, in my experience. Does development really “win” if they manage to push out the end date or reduce scope? Does product management really “win” if they manage to squeeze in extra features or pull in the release date? I’ve seen how the empowerment of the Product Owner and the establishment of the Product Backlog as the single high-level requirements and release scoping artifact helped to prevent some of these painful dysfunctions but I’ve never thought of them in terms of an imbalance of contract negotiation over customer collaboration.
Creating “Desire Lines” in Design
Larman and Vodde strongly advocate wikis as the preferred basis for the technical documentation the team develops. They suggest a page for the overall product and pages for each Sprint. That worked for my teams as well, although there was always a certain (healthy) tension regarding what was appropriate for Sprint documentation and what should be living documentation at the product level.
They present the compelling idea of “desire lines”, which, in landscaping, refer to paths that develop naturally, as people use a given space. Rather than guessing how people would use the area, they are observed using it and then the landscaping is designed around their actual usage. Similarly in design, rather than trying to guess what the needs are, let them emerge and then refactor to support the emerging design tensions. A lovely analogy, I thought, and one that will stay with me.
They suggest both a priori design in collaborative design workshops and design after the fact in System Architecture Documentation (SAD) workshops. I like the acceptance that both approaches are going to be useful. The former stresses the need for team contribution to the design as the Product Backlog items are being developed, while the latter recognizes that team needs for technical documentation will emerge over time and so setting time aside to fine tune design documentation is both warranted and healthy.
The authors also address the question of whether and when to rewrite code – like Joel Spolsky, I personally favor refactoring to improve legacy code rather then re-engineering. The authors present a compelling and complementary argument for refactoring and incremental improvement based on the value of instilling a notion of continual (rather than punctuated) improvement in the development teams. They stress that the real problem isn’t the legacy code you’ve got but rather the legacy code you continue to write. Encouraging the team to have a mindset of each check-in leaving the code base better than it was before – fixing the broken windows and taking out the trash – is a better solution to the problem of poor code quality than is carving off large sections of time for exclusively improvement-oriented work.
Acceptance Test Driven Development
The book’s worth it just for this material alone. Larman and Vodde present a wonderful analysis of ATDD and characterize its place in the context of Scrum, including tying it into iterative requirements refinement, the Definition of Done and the Sprint Review. I’d seen teams go in this direction driven largely by the desire to better engage testers in their teams throughout the Sprint and avoid “scrummerfall.” The authors take this further to show how ATDD, in which acceptance tests are defined and automated in advance of the development of the code that will pass those tests, does for teams in an iteration what Test Driven Development (TDD) does for individual developers in ten minutes.
They stress the need for the test automation to be a distributed responsibility shared by the whole team rather than one assigned to a specialist team. I couldn’t agree more. I’ve seen many attempts to establish test automation through the creation of a group apart from development and I can’t say that I’d call any of them particularly successful – at least not in the broad and encompassing sense that Larman and Vodde are envisioning in this book.
Continuous Integration at Scale
I was particularly glad to see treatment of Continuous Integration (CI) at scale. I’ve seen groups start with vanilla CI as it is described in the Extreme Programming literature and do well with it initially but then fail as their groups grew larger.
Essentially, Larman and Vodde propose a nested set of continuous integration builds, each larger one subsuming sets of smaller ones within it and each build defined for a particular concern. Examples of these concerns include the verification of specific components and subsystems but also particular kinds of testing – including things like performance and stability testing. One key aspect of this approach is that, at each level, you’re trading off the immediacy of feedback to the developer against the likelihood of the developer’s submission affecting quality at that level and the expense of the tests.
The Elusive Definition of Done
As noted earlier, Larman and Vodde, suggest defining “done” as that subset of the work needed to release the product the team is currently capable of performing each and every Sprint – then use your retrospectives to challenge the team to bring more and more of the “undone” work into each Sprint. The authors point out that there are really only two ways to extend the Definition of Done: increase the cross-functionality of the team or increase the degree of automation the team uses.
In the meantime, however, while the Definition of Done leaves some work undone, Larman and Vodde suggest meeting that problem honestly, by doing things like defining an undone work team and pushing undone work onto the Product Backlog. By being explicit about where the team currently stands against the goal of delivering potentially shippable product increments, this undone work can be better managed and the team’s insights can be directed to the problem of expanding that definition of done to get them closer to the goal.
For the Bookshelf of any Agile Team Member
The book isn’t without its faults. It’s certainly long enough and some sections can be tedious (there’s a fifteen or so page section where different scenarios for story splitting are laboriously addressed – I get that this common complaint about stories needs to be put to rest but this feels like killing me with kindness :)). The book’s organization lends itself more to use as a reference than as something you’d read cover to cover. There are many repetitive sections that allow each chapter to stand on its own but are a bit hard to get through when you read it straight through. But these are really just quibbles. In all, “Practices for Scaling Lean & Agile Development” is, just as its companion volume before it was, a tremendous book that belongs on the bookshelf of any agile coach, manager or team member.
I’d like to thank Anne Greenhaw and Selaine Henriksen for their help in developing this post. Thanks also to Ryan Martens for inviting me to post here.
About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer. He is currently a developer in the telecommunications industry.
RallyDev.com
