Sunday, September 20, 2015

Effective daily scrums – and how to achieve them

In this case my advice is contrary to what I usually say. This time my advice is not to go by the book!

Remember the purpose of the daily scrum

The purpose of the daily scrum is to plan ahead for the next 24 hours. It is not about reporting progress. Of course it is an important part of the planning to know the current situation, but the focus should be on the things you are about to do.

"What did I do in the last 24 hours", "What will I do in the next 24 hours", "What hinders me in achieving the sprint goal?" – those (paraphrased) questions from the scrum guide, are there to facilitate a purpose as my esteemed friend and colleague Tom Breur points out. The purpose being constantly navigating the best way to achieve the business goal for the day.

It is like action planning for firemen

The daily scrum is more like firemen planning on how to tackle a burning house they are about to enter.

They don't talk about how they clung to the seats when the fire truck skewed around the corners – it is all about the future.
"I'll go to the left with hose", "I'll break the door open, so that someone can use the powder extinguisher" "As soon as you've broken up the door, I'll use the powder extinguisher to quench the flames in the hallway" etc.

Nobody want's to know how they quenched the last fire – it's the future that counts here. (I really love this example, courtesy of another esteemed friend and colleague, David)

Turn it around

The least you can do, to make the daily scrum more efficient and effective is to turn the questions around. Start with the future, mention any impediments you actually have and then talk a little bit about what you did. If there is anything left that the others don't know from the last daily meeting or the events in between.

It is not for 24 hours!

And what's more: You don't have to talk about your plans for the next 24 hours – all you have to do is to talk about your working time, and in most places this would amount to roughly 8 hours.

Talk about the future

If you have to tell your colleagues what you did in the last 24... sorry, 8 working ours, you probably didn't tell them what you planned to do in the last daily meeting. Or you had to diverge from your plans. If you had to diverge I very much hope you didn't wait till the deadline. After all the daily meeting is a deadline for the things you planned at the last daily meeting. You told your colleagues what you had planned to do between then and the following daily scrum. Usually it is a good idea to let everybody on the team know what has changed just as soon as you find out. It just might happen to interfere with the work of your colleagues as well. After all you would like to know if a co-worker changes his mind if your work depends on their result. Even – or especially – if they have a good reason for changing their plans.

So if you talk about the last 24 8 working hours you'll only end up telling people what they already know. Either from the last daily scrum or from observations and information during the last 8 working hours.

Instead, think of the firemen planning to extinguish the fire in a burning house – or the A-Team planning a mission.

till next time
  Michael Mahlberg

Sunday, September 06, 2015

Iterations! “Done” does not mean "never to be changed again!"

One of the hardest things to understand in agile software development seems to be the concept of “iterative“ development.

Especially in conjunction with the concepts of done-done and definition of done.

In my experience people – developers and customers alike – tend to be confused by the opposing forces of “embracing change” and getting the current iteration of the product to a “done” state in “production quality.”

Although there are several very good explanations on the web, like the one from Alistair Cockburn, it seems very hard to express the basic concepts concisely.

The default example nowadays seems to circle around the different ways to paint the Mona Lisa, so let's start with that one:

  • Incremental:
    • (could be similar to waterfall with milestones)
      • partition the canvas into an arbitrary number of rectangles
      • Start painting at the top left rectangle
    • This approach has the added benefit that you could dispatch a subteam to paint the bottom right rectangle and thus ‘scale’ the project. 1
  • Iterative:
    • (closer to the standard approach in agile projects)
      • Do a rough sketch of the whole picture in pencil
      • Get customer feedback on the sketch
      • Erase some lines and areas
      • Get customer feedback on the sketch
      • Do broad fills with colors
      • Get customer feedback on the intermediate
    • In this approach you might even have one iteration where the Mona Lisa was blonde

While this model does a fine job in explaining the difference between iterative and incremental, it does not really address the topics of ‘done’ or shipping.

Partially that is due to the fundamental difference between Software and pictures – it is easy to keep on working on software after shipping, because we ship something that is mechanically created from the stuff we write. (No matter whether it is compiled and linked, compiled and put in a jar, packaged or anything else – we still don't have to let go of the stuff we created to ship to customers). There is a huge difference between paintings and software, so for me this is where the analogy stops.

In painting we get value from the customer feedback. In software products we oftentimes can get much more value from real-world use of the product we’re building. Or to be exact: from using the current state of the product that we are building with real customers.

Now to be able to do this, we have to do both – we have to build an increment of our product that is fully functional. And we have to iterate over parts that we already had ‘done’ the last time around.

Let’s look at a simple example – a sign up dialog.

We might want to offer some high-tech login integration via facebook, google and twitter later on, but since we’re just a tiny startup and haven’t yet gotten around to deciphering all the fine details of the OAuth2.0 protocol, for the time being we only want to enable registration via e-mail for the first launch.

So our first iteration of the login dialog only includes e-mail. But what about the design? Since we already know that we also want Google and others integrated, we could already do a real nice UI-design for all the options, couldn't we?
Well – we could. But we shouldn't. We would have to deal with a whole bunch of decisions about things that we only have vague ideas about. And would have to maintain those decisions for quite a while. One agile way of addressing this in an iterative, incremental way, would be to build an increment that is of production quality and make sure that it is easy to re-iterate over this part easily by employing techniques from good software craftsmanship.

So the first increment would contain a finished part of the product (with all the colors, to stick with the Mona Lisa metaphor) to make it really usable, but we would be willing and take precautions to change it later on (paint it over) to iteratively add new functionality.

So long for now
  Michael Mahlberg

Footnote: Scaling and iterations
Actually this also shows that this kind of work-breakdown and scaling is manageable if the expected result to be is known beforehand. We can now easily(?) put nine illustrators on nine pieces of a gigantic billboard that is to feature the Mona Lisa as long as each illustrator knows which part they are responsible for. But that would not have worked for creating (developing) the Mona Lisa in the first place.