BigVisible Blog

It is sometimes attractive to impose processes. The reasons that it is attractive make sense: We know what works based on our experience. Those of us who study process have a lot of anecdotal evidence that some things are better than other things, and why not share our wisdom with those who lack our wear?

However, this only makes sense if we don’t value learning. If we don’t value learning then we can assert that we who know, know. We know because we have learned, and we can share what we know with those less fortunate than us. They should be grateful to have benefited from our wisdom and to have been spared the many trials that we have endured.

If we value learning then we value systems that can learn, but that implies that we must let go. We must let go of the idea that what we have learned is what others should learn. Their experiences are necessarily different than ours. If they succeed it is their success. If they fail it is not our failure.

The quality of a good coach/teacher/parent, is to provide everything that is needed to succeed, to motivate, to encourage, to endure, and to get the hell out of the way.

There has been a storm of blog posts, tweets, and other noises lately about why Agile is this or that, why it is good or bad, why it works or doesn’t work, etc. None of it actually matters.

There are two things we ought to be talking about: 1) How do we change our organizations to optimize the delivery of value? 2) How do we make the lives of people involved in software development better?

XP, Scrum, Lean, Kanban, Agile, and whatever else are collections of ideas and practices each united by strong principles and all designed to help us figure out how to solve some of these problems. Each is limited by its point of view. None is a panacea. None will fit your situation “out-of-the-box” without considerable thought and adaptation.

So, use these ideas and these practices. Do so thoroughly and unapologetically. But, I don’t care what you think Agile is or is not, whether you think it is good or bad, whether you think it works or doesn’t work, whether you think I am doing it right or doing it wrong. It doesn’t matter.

[In a private email discussion with the other BigVisible coaches I came up with the following metaphor. I thought it might be of general interest, so I'm reproducing it here with a few small edits.]

An Agile team is like an engine. An engine needs four basic things to work well:

1. Feed it lots of fuel and air at the right moment.
2. Ignite the fuel and air at the right moment to generate power.
3. Transfer power to the drive line to do some useful work.
4. Remove waste gasses at the right moment to maintain volumetric efficiency on the next stroke.

Agile teams need similar things:

1. Feed them valuable ideas to implement at the right moment.
2. Implement high-quality software at the right moment to realize value.
3. Transfer that value out to the customer so that they can do their work.
4. Receive feedback at the right moment to maintain the delivery of value on the next iteration.

Extending the metaphor:

• Scrum is a bigger engine. It is theoretically capable of generating higher output, if you give it all of the things above.
• XP (or “technical practices” if you prefer) is a well tuned ignition system. You need it to maximize efficiency and clean power output.
• Kanban says, “Find the bottleneck and eliminate it.” That is great advice (For engines too) but maybe not specific enough to tell us how to make a Civic beat a Ferrari. [Note: I deliberately diminished the importance of finding and eliminating bottlenecks here. To be clear, I think it is one of the most important skills a coach (or engine builder) can have.]
• Effective product ownership and related business practices are your intake plenum. The fastest way to sap an engine’s power is to starve it here (That’s why they call it the “throttle.”)
• Your direct line to your customer is like your exhaust system. The tighter and twistier and more packed with crap it is the less power you will get.

To go fast you need all of these parts to work together. So, start with a bigger engine. Sure, why not? Start with more efficient spark. Sure, why not? If you want to get faster you’ve got to understand the whole system, and it more or less doesn’t matter where you start.

Jerry Weinberg commented on my last post regarding the Definition of Done saying that we aren’t really done until we have stopped. When pressed further he said that even delivering to production was insufficient, because we might get it wrong, and if we get it wrong we aren’t really “done.”

Of course, he’s absolutely right, and it leads nicely to one of my favorite topics that I’ve been wanting to blog about:

Agile software development is about learning. We work from a premise that the final solution is not known (or knowable) until we have delivered it, and that, therefore, we must collaborate with customers to build and define a working solution incrementally. Along the way we learn about the problem space that we are exploring and we incorporate that knowledge and our own expertise to drive towards a heuristic solution.

That may seem obvious, but it has an interesting implication. All software development processes/methodologies tend to obsess over the question of how much we can get done per unit time. However, if we know that we are engaged in learning, and we understand that learning means sometimes getting it wrong in order to adjust and get it right, then how much we can do is the wrong question. The right question is how long does it take before we can find out that we are wrong. In other words, what is the delay before our next opportunity to learn?

Scrum’s notion of “Done” is not really about being done, but about getting to the point where we can get real feedback to learn from. The same is true for the Lean notion of “Cycle Time.” Each cycle is an opportunity to learn. If there is any chance that we will get it wrong then we need at least two cycles. In fact, the likelihood that we will ever get it right is directly related to the number of opportunities we have to learn before we stop. I’ll let you chew on that for a while.

[Note: the assertion in the last paragraph originally said that the likelihood of getting it right within some period of time was inversely related to the length of our learning cycles. Hopefully, the way I wrote it above is somewhat clearer. The notion of keeping learning cycles small is a natural and important consequence of the above. You will hear more from me about that at some point.]

One slightly peculiar question that comes up over and over again with new Scrum teams is: what is the definition of done? And, how do we determine what our team definition of done is?

It is a peculiar question, because if we weren’t practicing Scrum the answer would be obvious. In fact, the Lean and Extreme Programming communities more or less agree on what “done” means without any real discussion: Done == deployed in production, in the hands of real customers.

When Scrum folks talk about the “Definition of Done,” however, they mean something slightly different. There is an important assumption here: software can reach an intermediate state called “done” where it is not yet “released,” but is “potentially shippable.”

Potentially shippable is an equally peculiar idea. In theory it ought to mean that to release or not to release is purely a business decision at this point. The software is complete, accepted, and tested, but it is not released. In practice it often means that the main development activities have been completed but there is some amount of intangible work to be done that may or may not fit inside of a Sprint (e.g. QA testing, deployment to various environments, formal release process, etc.) This is a poor, but common, way to address the “Definition of Done.”

Potentially shippable software is actually a useful idea. From a technical excellence point of view the goal should be continuous delivery, but from a business perspective continuous delivery might not be feasible. In fact, in some domains big-bang delivery actually has inherent value (e.g. any COTS, especially commercial games, and various forms of online media.) [actually, even in those environments continuous delivery is useful, but only after the initial release hits its date...] What we want is for continuous delivery to be attainable, so that it becomes a business decision not to do it. Thus, XP has long had the concept of always releasable software.

So, how do Scrum teams define done? I suppose the real answer is, however they want to, but I suggest the following: Start with everything that it would take to release the software to production. Then, to the extent that it is infeasible to do all that stuff, scale back to something that can be accomplished within a Sprint. Then, continuously improve (i.e. inspect and adapt) until the definition is once again everything that it would take to release the software to production.