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.
The 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.
“The greatest obstacle to discovery is not ignorance – it is the illusion of knowledge.” – Daniel J. Boorstin
Here’s something your team should look to avoid – Cargo Cult Scrum.
Members of the John Frum cargo cult
Cargo Cult Scrum is what happens when you adopt the practices, vocabulary, and artifacts of scrum but you don’t understand why or how they work. Cargo Cult scrum is bad. It is accidental and is based on ignorance.
Here’s a tiny piece of what Wikipedia has to say about cargo cults:
“A cargo cult is a type of religious practice that may appear in tribal societies in the wake of interaction with technologically advanced, non-native cultures. The cults are focused on obtaining the material wealth of the advanced culture through magical thinking, religious rituals and practices…”
When we talk about cargo cult implementations of scrum we are talking about people who seize on the advanced ideas of scrum and expect magical, unexplainable benefit to come from them, not realizing that informed usage is required in the bargain.
Craig Larman and Bas Vodde talk briefly about Cargo Cult Scrum adoption in their excellent book “Scaling Lean & Agile Development” in a section titled Avoid…Fake ScrumMasters. Fake ScrumMasters are created by “…Changing the title of someone to ‘ScrumMaster’ while he acts like – and is encouraged by the organization to act like – a project manager.”
They go on to describe the ultimate cargo cult scrum implementation:
“We adopted Scrum. Our Sprint length is the length of our project. The Product Owner decides the items in the Sprint and the project manager acts as ScrumMaster. He makes the Sprint Backlog and assigns the tasks to people in the team.”
So what does Cargo Cult Scrum look like?
Here are some examples that I’ve seen in the field:
I recently attended a meeting at a company that considers itself to be agile. It was a regular meeting that occurred every two weeks. It was not attended by a scrum team, but instead by a bunch of people from two different groups. The three questions were not used. The meeting was scheduled for, and took, 30 minutes. Yet the meeting was called a scrum. Other meetings at this company are called scrums, so much so that ’scrum’ has become a synonym for ‘meeting’. This is a cargo cult. The true meaning of ‘daily scrum’ has been lost, if it was ever apprehended in the first place.
I’ve also seen organizations in which people call every item on the Product Backlog a User Story (which is not the same thing as every item on the Product Backlog actually being a user story).
Another example is this actual [paraphrased] conversation I had with a potential customer:
Customer: Oh yes, we’ve been doing agile for a while. Coach: That’s great! So you haven’t had any trouble getting the Product Owner to work closely with the team? Customer: Well, we…uh…don’t really have a Product Owner. Coach: Oh. Well, who keeps the Product Backlog in shape? Customer: Well, we…uh…don’t really have a Product Backlog, per se. Coach: Oh. So how do you plan your sprints? Customer: Well, we really don’t do that in a very formal way. But we do meet every morning. That’s what it’s all about, right?
And my all time favorite. I was once told by a manager of a supposedly Agile group: “We like things the way they are. We know it’s not perfect. We don’t want to change.” Yikes. So much for Continuous Improvement.
Though you shouldn’t do Cargo Cult Scrum for any reason, the reality is that any step down the road to scrum is usually better than whatever preceded it.
Don’t feel bad if your scrum implementation isn’t the same as what’s in the books. Feel bad if you are have stopped trying to make it better.
About the Author: Alan Atlasis a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
I am ever seeking to expand my Lean learning. This week I am attending and speaking at the Lean Kanban Conference in Miami, FL. I’m excited about the opportunity to engage in more Lean learning with some great people. Real conversations with the folks behind the books and on the forefront.
In my post on my Leaning Bookshelf about my Lean learning, I included Craig Larman and Bas Vodde’s wonderful book : Scaling Lean and Agile Development, based on their collective experiences in very large (and distributed) Agile software development.
I love this book. Given my interest in the book, and knowing both Bas and Craig a little, I invited them to tell us a few things about themselves and the book.
Q. [JET] I’m very interested in Systems Thinking and yet don’t find too many people in our software development field talk about it. So it was a wonderful surprise to see it as the opening topic in your book.
Tell me, why do you feel it is so fundamental to the work of scaling lean and agile development?
[Bas] I do think systems thinking is discussed in the software development field. Gerald Weinberg, of “Psychology of Computer Programming” fame, has written three books on the topic. Of all the topics Jerry talks about, I think this is probably the one he has written the most about. Also, Mary and TomPoppendieck wrote about the topic in their lean software development books. But perhaps you are right, it is still not covered enough.
In large-scale development everything tends to have an effect on everything else. It is easy and common to quickly respond to events or draw conclusions. For example, if there are many bugs in your system, it is easy to relate that to something you did recently and act based on that. When, after acting, the bugs increase or decrease, it is too easy to conclude that these two relate.
These mistakes in cause-effect thinking are especially common in large-scale development and therefore it is important to try to think of the system as a whole. System thinking helps thinking about the whole system and especially doing that together so that perspectives become aligned and a common understanding is created.
[Craig] The large-scale immediately (and usually, painfully) bumps us into the organizational structures and policies, and their impact to support or inhibit the flow of value. And large-scale development organizations have more formal policies and structures compared to the small-scale. The organizational design reflects the psychological and systems insight — or lack thereof — of the people in management.
Most business (and broader) problems have their root cause in mental and emotional limitations or weaknesses: command-and-control management and “Theory X” managers, not seeing the true nature of causal relationships, not grasping non-linear effects and delays in the workplace, lack of kindness and transparency, and so forth. And it extends to deeper issues: awareness of and healthy suspicion of our own mental models, double-loop learning, skillful listening and conversation, emotional intelligence … Great organizational designs reflect people in leadership with great personal mastery — and part of that mastery is people who can do systems thinking.
Q. [JET] Craig is a great guy. I’ve enjoyed the few times I’ve had to talk with him. As you were writing the book together, what would you describe as something in particular you were grateful that you learned from him?
[Bas] The book is a result of years long co-operations and discussions. So to limit what I learned from him to writing the book wouldn’t be fair.
Over the years, I mostly appreciated the countless discussions we had on large-scale development. I’m not always good at expressing my thoughts and Craig is a patient listener who really tries to understand different perspectives. Then, he is not shy on giving very direct feedback. I think it’s these discussions (and the ones we will have in the future) that I’m most grateful for.
Then, specifically to writing the book. I’m not a native English speaker and not an very experienced author. I don’t think I could have learned more about English language and writing in a shorter period.
Q. [JET] I love the “Try-Avoid” model you use throughout the book as well as inside the covers. It seems to walk a nice tight rope between prescription/non-prescription. What inspired you to come up with this approach?
[Bas] That is interesting. I wish I could take any credit for this, but I’m afraid Craig actually made that decision. I even argued against it since I felt that it would hurt the readability of some parts. Not all parts are easily put into this “experiment-format.” After many discussion on the format, I agreed with going forward and over time started to appreciate it.
What inspired the approach? I’ll let Craig answer this more thoroughly, but the main thing was the illusion of knowing the answer. Every situation, product, culture and company is different. Every product we go, we learn new things and experiment with new ideas.
So instead of giving “the solutions” we’d like people to think about their context and about the different experiments they could do. Learn from these and find themselves the best solution in their context.
[Craig] First, to reiterate what Bas said, kaizen in Toyota, and empirical process control in Scrum, emphasize a culture of structured experiments, rather than defined process or a cookbook of process recipes to follow, and I hoped to emphasize that notion.
Second, I become frustrated when reading a book and I have to dig around in the text to find specific actionable advice the author is offering. I want to respect my reader’s precious time, and make it as easy and immediate as possible for them to find that.
Q. [JET] Several years ago Bas, you and I roamed through Powell’s bookstore’s used computer books in Portland, Oregon together. That gave me a glimpse into your love of books; your bibliography for “Scaling Lean and Agile Development” is yet another indicator!
So here is a tough question for you: what were the top 5 books that inspired you in writing this book?
[Bas] Yeah, the visit to the bookstore was nice. :) I’ll change the question a bit. I’ll answer it with the top 5 books that inspired the content of the book… but weren’t mentioned in the book. There was no appropriate place to recommend them.
- Debugging the Development Process – Steve Maguire. Steve wrote two classics in 1995. One related to writing code “Writing Solid Code” and one related to the processes for writing code called “Debugging the Development Process” which describes how he managed software development groups within Microsoft. The book is full of insightful advice about software development and it is a book I always get back to and re-read parts of. Still today, most of Steve his writing is exceptionally relevant.
- Secrets of Consulting – Weinberg. Gerald Weinberg has contributed so much to the knowledge of software development. Not just his 40 books, but he has a group (Weinbergians) who he trained and is still in contact with. I know some of them and Weinberg’s influence is visible. Of all the books he wrote, this one was perhaps one of the most insightful ones. It is, like all his books, full of stories and small insights on working together with people and companies.
- Juran on Quality by Design – Juran. It is quite amazing that we did not have any place where we could recommend the work of Joseph Juran. Juran, next to other “quality gurus” such as Deming, Crosby, has been a huge influence on my personal thinking about organizations and developing quality products. I especially enjoyed this book of Juran and his insights related to quality planning and product development.
- The Gold Mine - Balle and Balle. We recommended a lot of lean books, but not this one. This lean book is written as a novel, which makes it hard to find a good place to recommend it. It is quite much like “The Goal” which is the well known business novel introducing Theory of Constraints. The Gold Mine, however, didn’t introduced any new concept, but it does a great job of clarifying lean in a form that is easy and engaging to read.
- The Peter Principle – Lawrence Peter. Some organizational behavior is so taboo that you shouldn’t be talking about it. But, of course, you can ridicule it. Thats exactly what the Peter Principle does. It shows that human society is rising in the animal hierarchy and has reached its level of incompetence. Books like this one give a great perspective to behavior in organizations and are very funny to read. Painful, but true :P
[Craig] In the same spirit of Bas, on relevant works that weren’t really emphasized:
various books by Ralph Stacey on the illusion of the belief of how much we can influence or control our complex non-linear social work systems (Stacey’s work is touched on in Beedle and Schwaber’s first Scrum book). There is a deep assumption in most people at work: we can control complex things. Once a great doubt arises about this core assumption, it opens a major can of worms that pulls the rug out from underneath many organizational design ideas.
Q. [JET] You mentioned to me that you and Craig discovered that in the writing of your book, you were uncovering “an embarrassment of riches”. This led you to decide to divide your work into two books.
What sort of preview can you give us to the material coming in the second book?
[Bas] Oh yeah. We kept saying “Oh that must be there.” Then we kept removing things to only leave the essentials. But soon it became clear that all the things we wanted to say would not fit in one book. Influenced by Don Reinertsen’s “The Design Factory,” we wanted to split the book in thinking and action tools. However, we had a group of ideas which didn’t fit well in either, so we came up with the “organizational tools.” Suddenly we had two logically consistent books and decided to do that.
The second book will be the “action tools.” The goal is to give concrete advise on how to do particular practices. How to do planning? How to do design? What do with with multi-site development? What to do with legacy code? All of these chapters will use the action and organizational tools from the first book. When people read the book, they ought to have concrete experiments for their current situation.
I’ve been thinking about leaning a lot lately, and not of the pressed-wood bookshelf nuisance variety. I talk about Lean with my colleague and President of Rally, Ryan Martens. So when I talk about a leaning bookshelf, I’m referring to my interest in Lean in all its forms. I am talking about the books I’ve been reading that pertain to Lean. And, more specifically, how can I turn my “Leaning bookshelf” into a continuous “learning bookshelf”? How can I think about my evolution of thought and practice with regard to Agile as influenced by Lean? What could be a good, rewarding goal?
And so, through discussions with Ryan and some of my own quiet thought, I came up with a goal of improving my notion of learning. Yes, for me, that seems to be what I am discovering more and more about Lean:
How to learn
How to teach others to learn
How to encourage organizational learning
How to avoid/eliminate re-learning
And so in this post, I thought I would share what I am reading, have read, or am about to read, and ask you for your comments and recommendations with regard to my leaning—>learning path. Some of the books may not look directly associated with Lean. I just know that they have been part of my lean learning journey.
Looking at my leaning bookshelf and thinking of my focus on learning, I realize I haven’t included any Senge books or others about organizational learning. That will have to wait for another post.
What books are important to you on your leaning/learning path?
RallyDev.com
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.
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.
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.
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.
In my post on my 
And so, through discussions with Ryan and some of my own quiet thought, I came up with a goal of improving my notion of learning. Yes, for me, that seems to be what I am discovering more and more about Lean:
