No Risk - no Gain?

"If a project has no risks don't do it" - that's what Tom DeMarco and Timothy Lister state on the very first page of chapter one of "Waltzing with Bears", one of the better books written on risk management.

Initially this statement may seem counterintuitive but actually most techniques applied in Agile software development and its management are about controlling risk. Timeboxing? Reduce the risk of overengineering or overanalyzing. Test Driven Design/Development? Reduce the risk of untestable, tangled, unstructured software. Pair Programming? Reduce the risk of poor code quality and lost focus. Daily Standups? Reduce the risk of uncoordinated (or duplicated) work. And so on. On the other hand a different kind of risk is seldom mentioned: the risk of not reaching the project's goals!
If no one – not even the owner of the project – sees "not reaching the project goal" as a quantifiable risk, what does that mean? Primarily two ideas come to mind: either the project is not really important and nothing bad is going to happen if it doesn't succeed or no one even considers the possibility that the project might fail due to yet unknown reasons. Neither of these scenarios seems particularly appealing to me.

So the message from Tom DeMarco and Timothy Lister is twofold in my perception:

1. Don't take on a project that doesn't matter to anyone. (i.e. where there is no risk in failure)
2. Don't take on a project where there is no intention to address common risks (i.e. a project where good practices – like those from lean and agile software development are not even aspired)

Untill next time
  Michael Mahlberg

P.S.: And yes, this is also a recommendation for the book "Waltzing with Bears: Managing Risk on Software Projects"

The Spice Girls on requirements engineering and root cause analysis

Just the other week I came across an interesting thread on the "kanbandev" mailing-list. It was all about "have you asked the Spice Girls question?" which seems somewhat odd, if you consider that this mailing-list is about managing Software development projects...
turns out it is only about the second verse of "wannabe" : "So, tell me what you want, what you really, really want" [you can (and should) ignore the rest of the song for the purpose of this post].
That one sentence actually captures remarkably well what differentiates a shallow requirements or root cause analysis from a thorough one: Asking beyond the obvious to find out the need that fuels the obvious.
according to Jabe Bloom Steven Bungay formulated the question a bit more formally:

[...] This should be encapsulated succinctly in the form... We should do What in order that Why.
For example... We should implement Continuous Delivery in order to minimize Lead time.

But "Tell me [...] what you really, really want" seems to stick a lot better than just "why".
So thanks, Jabe Bloom, for raining this!

The best way to do hardening sprints

What's the problem with hardening sprints?

Hardening sprints are often considered a sign of mis-interpreted Agile and a process smell. But then I read in answer to Ron Jeffries, who pointed out that hardening sprints simply mean that you where not "Done" the first time around.
In that answer I read that should be almost always due to overcommitment.
Really? Well - I've never seen this.
If I see hardening sprints at all I usually see teams putting the hard part last and then ending up with a huge number of 98% done stories that will be "fixed right before the release" - of course this accumulates and the transaction cost of the release become higher and higher until you end up with a whole Sprint to fix the small things that now form a huge, interconnected blob.

The solution

Get to "DONE" early. Not as in "code complete" or "checked into source control" or "automated tests did run" or even "accepted by client" but as in "There is nothing left that has to be done for this story" Just don't do hardening sprints!

Additional comment: When the requirements conform to INVEST so should the implementation

The (well know?) INVEST formula for story-design put independet as the top property of a good user-story.
But what good is an independent requirement if the implementation is strongly coupled with other stories? Of course there is a limit to the independence, especially if you have a newer story relying of an already "done" story. But an older story should never be dependent on a later story (Really bad: "it will work once we've got the implemented, so let's just consider it 'done' for now") and the stories of one iteration should be as independent as possible.

Post-mortems are for dead projects - what to do with the living?

"He's dead, Jim" – the famous quote from "Bones" McCoy in the original Star Trek may be one of the shortest post-mortems one can think of, but it's not necessarily what you want in an Agile retrospective. What you might want instead is the attitude of Star Trek: the Next Generation's captain Picard - "Make it so".

From post-mortem to retrospective

But then again: the history of retrospectives is a history of misunderstandings...
One – plausible – version I have heard goes like this:
When the idea of project retrospectives came up in the context of early space missions, the idea was in fact to learn for the next iteration. But "the next iteration" would have been the next iteration of a rocket design, and the previous iteration would now have been reduced to a lump of metal shreds after it's successful test flight. Under these conditions it must have seemed quite fitting to borrow the term post-mortem – after all there wasn't much left moving at the "landing site". Developing safe ways of landing was not quite as high on the list of priorities as getting off the ground in the first place.
Gradually the scope of post-mortems expanded and soon the term was used to describe the process for all kinds of projects and was even adopted as a general term in commercial software development.
In 2001 Norman L. Kerth wrote a book titled Project Retrospectives: A Handbook for Team Reviews in which he made a strong case against the use of the, then accepted, term post-mortem. Before Esther Derby Diana Larsen's Book Agile Retrospectives came out, this was the definitive guide on retrospectives for me (now both books share that place) and I always tried to follow his emphasis of the fact that we don't do retrospectives for the past but for the future.

So let's use the term "Retrospective"?

At least there is a somewhat common understanding of the term.
When Tom and I laid out the structure for the Hands-on lean and Agile practices course we decided to go with the term "retrospective" – partially because that term is more widely recognized and people would have a clearer picture of what we talk about in that part, and partially because "retrospective" is the term commonly used in descriptions of the mechanics of such a review which makes it a good search candidate when looking for additional information.

How about "operations reviews"?

Nowadays I'm contemplating to suggest naming this section of the course "operations review" – a term used in the lean and Kanban literature. Although there are many very tight definitions of that term pointing out that an operations review is not at all comparable to a retrospective, these "clear" definitions are contradictory and some (a lot) actually suggest a certain similarity between operations review and (healthy) retrospectives.

Now what's it with this nitpicking with words?

Is it really important how we call this activity in our daily work? If we start with the intention in mind – looking forward, wanting to influence the future – won't the rest follow?
Well, modern brain science has it's own take on this.
As humans, our expectations and actions are influenced by the language used. In one very well known experiment people where told that they where tested on word-understanding while in reality their physical behavior was the subject of the experiment. One group had to work through a series of words with connotation of old age while the other group worked with words implying agility and youth. Sure enough the "old word" group was measurably slower on their way out from the testing facility. Even though this specific experiment on `priming´ has been disputed lately, the effects of priming also are one of the things the whole advertisement industry thrives upon. One last argument I would like to quote for this influence of words are the Implicit Association Tests from the harvard university. In these tests unconscious beliefs can be discovered by measuring the time it takes to identified words after the brain has been 'primed' with simple but powerful concepts like 'good' and 'bad'.
I don't know about you, but if I have the chance to 'prime' the whole team conducting the activity, I would rather like prime them with a concept that directs our attention to the future than setting them up for looking at a project that's still running with the mindset of a retro-spective, "looking back from a distance". Although much closer to "being in the present" than the mindset of a post-mortem, it still sets us apart from the things we want to influence. For my ears an "operations review" sounds much more like a thing I would undertake to influence what I'm doing right now.
I'm open for suggestions, but whenever possible I propose that we use words like "operations review" instead of "retrospective" or "post mortem" – at least until we find an even better way to put it.