Monday, June 18, 2018

Yesterday’s weather – it’s only an approximation!

Very recently (yesterday to be precise) I published one of my shortest blogposts ever.

What happened? I used an estimation technique from the days of eXtreme Programming called “yesterdays weather.”

The basic idea is that it is rather probable – though not certain – that the future will resemble the past. I started writing regularly for this blog in 2013 and published a post every two weeks except for a time last year when I explicitly decided to let it rest for a while.
So it was a sound expectation that I would continue to publish every two weeks. On Sunday afternoons (European time).
Or so I thought. To add insult to injury I did not only violate agile principles (adjust the plan when the circumstances change), I also violated lean principles.
How so? Well, Of course I don't write all my pieces on Sunday afternoons, but instead on the days in between Sundays and set the the publishing date to Sunday afternoon. And fiddling with the publishing date in blogger (my blogging platform of choice - for now) is quite tedious. So I decided to increase the batch-size and create some inventory of already scheduled blogposts that I would ’only‘ have fill with the contents from my local drive.

Except that it didn't work out like that. I did not create the content in time, and all of the sudden the inventory became a liability. Since I didn't respond to the changed situation and the plan got carried out by bloggers scheduler, this actually went out to the market. Luckily it was only a “lorem ipsum” type of blogpost and not a vital product feature marked “to be defined before production” that went live...

Well, this blogpost from yesterday definitely reminded me, that the lean avoidance of overproduction (one of the seven wastes in Muda#Over-production)) really is a virtue... and that even though past experience is a strong indicator for tomorrows events, we still need to check the current circumstances on a regular basis.

till next time
  Michael Mahlberg

P.S.: To quote George Bernhard Shaw:
“The only man I know who behaves sensibly is my tailor; he takes my measurements anew each time he sees me. The rest go on with their old measurements and expect me to fit them.”

Sunday, June 03, 2018

How technical is lean and agile?

A huge amount of discussions around lean and agile today is about management methods, personal interaction, coaching approaches, team interactions and so on.

And while I completely agree with the notion that “soft skills are the really hard skills” and are absolutely necessary, I still think that some technical excellence is crucial (remember the second page of the agile manifesto, principle 9?).

Many of the things that are present in successful agile teams and that people nowadays try to ‘inject’ into not-yet-quite-as-agile teams could be either cause or effect.

Let’s take the value of trust for example – perhaps people in highly skilled teams trust each other more because each of the team members brings some technical excellence to the table. Or perhaps people show their degree of excellence (including it's boundaries) because of the high level of trust. It could be either way around. Neither of that might be the case if the team is not self selected but made up out of “those who currently don’t have any other project”. Or let's look at sustainable pace – perhaps people in highly skilled teams are able to work with a sustainable pace because the know there limits and know that if the work beyond those limits the quality of their work suffers. And so on.

But back to the question of the technical aspect. Nowadays I often see teams where refactoring is looked upon as a separate activity (In XP-Times it was Red-Green-Refactor every couple of minutes), where people are neither free to choose their own IDE (e.g. because of company standards) nor willing (e.g. because they don't know any other IDEs) and where the command line is considered dangerous.

That’s not how the game was played when the term agile was coined - If you want to be able to quickly react to changes you need technical expertise. And technical excellence. Invest in it. Without technical excellence all the agile management practices might bring some improvement, but in the end those improved situation will be brittle unless serious attention is paid to technical excellence.

Just my two cents for today...

till next time
  Michael Mahlberg