Means to an end

Introduction

I have had the opportunity to observe many teams at close quarters trying/doing/being agile. Apart from the obsessiveness with velocity, one other area of obsession is to be able to break down work into smaller units and refer to them as "sprints". Most teams that I have experience with used the terms agile and scrum interchangeably, which is not a surprise given that more than 2/3rd claim to be using Scrum or one of its variants/combinations (see infographic - courtesy 13th Annual State of Agile). There is nothing fundamentally wrong in the concept of "chunking", just as there is nothing wrong in the concept of improving velocity to reduce time-to-market. However, teams forget that creating blocks of work is not the main objective, it is a consequence. Since they only look as splitting the work as the main objective, they end up worshiping the wrong God.

The heart of the matter

One of the twelve principles in the agile manifesto prescribes:

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale”.

Teams moving from waterfall, amend this principle for themselves to something like: “Deliver frequently, every (couple of) month”. Once formalized, the project manager then takes their year-long plan and creates 12 sprints of 1 month each and ends up with two design sprints, four-five development sprints, two testing sprints etc. He then renames project status meeting as scrum and the monthly steerco meeting as sprint review - victory is declared “We are agile – we follow scrum”.

You must be joking, right?

Everybody is surprised why none of the anticipated benefits are realized, blames the consultants and the market fads and moves on. It is like ripping the heart out (i.e. working software) of a living creature (principles of agile development) and then wondering why it is dead.

"Insanity is doing the same thing over and over and expecting different results." - Albert Einstein

Yet, that has happened many times, in many contexts. (And sometimes still does).

Chocolate is always a good idea

Isn't it? Anyway, imagine you have baked a (chocolate) cake and want your loved ones to taste it. How to cut a slice? That depends very much on the cake - but let's say it looks something like this:

A couple of things to note here - how big was the slice? Enough for them to enjoy your cake and give you feedback. How was it sliced? Across all layers, so that you can taste the chocolate sponge, the chocolate cream, the fondant, all in a spoon.

Think about software development like making the cake, but you are having to make and serve one slice at a time. How big is the slice is - that will be your sprint length/capacity. It should be big enough for you to produce something for which you can get meaningful feedback and it will also make one serving for your customer. Imagine also that all the layers have to be there so that the slice is representative of the cake - not horizontal slices which only gives you either the fondant or the cream or the sponge but not everything together.

So what's the point again?

When thinking about the sprint length, think about the longest period that you could go with no structured feedback on the work and still be comfortable about it. If you can (and you should always try to) get continuous feedback without interference on the execution, nothing like it. Generally it is a balance between feedback coming too little or too late (more prevalent) vs feedback interfering with the execution (less likely, but possible). It is not about what is easy or comfortable - it is about what makes sense. This is why different teams will work with different sprint lengths and still be equally successful. This is also why some teams do not need sprints (but focus on smooth flow) and can still be successful.

OK - but we have automated code review

Aha - good for you! Now that you understand feedback cycle is the main point of a sprint, imagine what kind of feedback you are looking for while building software. It is not about the technical quality report – remember that you need “Continuous attention to technical excellence”, not once per sprint, so that's not what I am talking about.

The feedback we are (or should be) looking for is the impact that our work is having on the beneficiaries of the software. ("Did the chocolate cake taste nice - would you like coffee with it?", not "Did you know the chocolate is Belgian and the cocoa powder is from Brazil and cream is from Holland?"). While both questions may be important from different perspectives, if the cake did not taste good, it will not matter where the ingredients originated. If the cake did taste good, then it may matter to some where the ingredients originated from.

Enough with the cake - back to software please

How can you expect feedback on the benefits of a software (during sprint review) unless you have a working software. This is why “Working software is the primary measure of success” and taking out the criteria of delivering working software is like ripping the heart out of agile software development. Grouping work in sprints is a way of ensuring moments were structured feedback can be received from external sources. Unstructured or continuous feedback may be difficult to handle particularly when the work (i.e. software development) and the feedback (i.e. benefit of the software) is in different perspective.

As experts in technology, we are always looking at tools to give us continuous feedback if we are “building the things right”. We have architecture review, design review, code quality review, security review and so on. We are trying to automate as much as possible. We are generally quite good at it - Scrum or not.

What we tend to forget is that it is more important to find out if we are “building the right things”. This comes from the market feedback and the product owner is best placed to distill the insights from the data. This is why Scrum enforces a structured review. In the review what we have built is only one side of the coin – an equally important, but often neglected element is to understand the impact of what we have already built and draw conclusions on what should be built next. This is why stakeholder involvement is of great importance. Remember ...

"There is nothing so useless as doing efficiently something that should not be done at all" - Peter Drucker

I will leave you with another gastronomic analogy to ponder over ...

Case for working software: the cocktail analogy

The recipe for a popular cocktail (Margarita) goes something like this: Chill the glass. Run a lime wedge on the rim and roll it in salt. Mix 1 part tequila, 0.5 part triple sec, 0.5 part lime juice and some ice cubes. Shake well in a shaker. Strain into the glass and serve chilled.

Scenario 1: Imagine me serving you, every 30 minutes the following and asking for feedback.

• 4 chilled glass with rims frosted. Feedback: Glasses are chilled.
• Lime slices, salt. Feedback: Salt is salty, lime slices are thin.
• 120 ml tequila, enough for 4 servings. Feedback: Tequila tastes good.
• 60 ml triple sec, for 4 servings. Feedback: Triple Sec tastes sweet.
• 60 ml lime juice, for 4 servings. Feedback: Lime juice is sour.
• Some ice cubes – shake at your convenience. Feedback: "Where's the shaker - these ice blocks are too cold for my fingers".

In spite of regular delivery and feedback, I do not know if it was a good margarita - in fact there was no margarita!

Scenario 2: Now I prepare one glass of margarita for you every 30 minutes and ask for feedback.

• I follow the recipe and serve you one portion of margarita. Feedback: “Mmm, good – but I don’t taste the lime enough”.
• I try it again with a few more drops of lime juice. Feedback: “Wow – that’s got a kick but why did you rush – it wasn’t chilled enough”.
• I try again. Feedback: “This is perfect, can I have another”.
• I serve the 4th glass. Feedback: "This is life baby ... yeah".

Moral of the story

You see the difference feedback can make when you share something as a logical functional unit rather than bits and pieces, which individually do not have the value. It is difficult to do, until it becomes a habit. I hope you take this to heart and have a rewarding agile journey.

Enjoy summer with a chilled margarita. Cheers!