Sunday, November 25, 2018

A very simple risk-mitigation approach to tackle the truck-factor

If you have heard of the Truck-Factor you might assume that it is a good idea to have everyone on the team capable to do everything equally well. There are just a couple of issues with this idea. For one thing, you can't have the world’s best goal keeper in such a team. And –especially when the goal is to build something that hasn’t been built before– training and educating all people in all areas of expertise equally well takes a lot of time.
Furthermore, since it’s desirable to run a lot of safe to fail experiments some of the options we explore will be discarded and thus spreading the (in depth) knowledge about them through the whole team could be considered waste.

I personally like the approach of the three ”bricks” as a rule of thumb for the distribution of knowledge about “special” areas of expertise:

    /------\          \
    |      |           | 
    |  1   |           |
    |      |           |
    \______/            \  Capacity between
/------\/------\        /  0,5 and 2 "expert equivalents"
|      ||      |       |
| 0,5  ||  0,5 |       |
|      ||      |       |
\------/\------/      /

\______  ______/
       \/
 Risk-mitigation
    3 people

Where the numbers in the ‘bricks’ indicate a subjective competence that has to be negotiated on a per case basis.

This is by no means all you need to do a full capacity planning or full fledged risk management, but the “three bricks approach” is a very handy way think about managing expertise on new technologies, tools or techniques.

till next time
  Michael Mahlberg

P.S.: If you want to do in depth capacity planning you might want to look at Troy Magennis’ Excel sheet for portfolio planning for that and when it comes to risk management the classic Waltzing With Bears provides a great introduction.

Sunday, November 11, 2018

What’s up with all these Manifestos?

We all know the Manifesto for Agile Software Development, right?
Well, all generalizations are dangerous. And the idea that the Agile manifesto is well known doesn’t hold much substance as soon as we talk to people who are not part of the Agile movement. The word “Agile” in itself seems to be well known by now - the Agile Manifesto not so much.

Not only are a lot of people unaware that there actually is a second part of the Manifesto, containing the twelve principles of Agile Software Development. Many people I speak to haven't even actually read the first page, containing the value assumptions of the Manifesto for Agile Software Development.

What happens if “Agile” as a concept spreads so widely, while only few have actually read the original manifesto?
For one thing, there are a lot of different interpretations out there. I guess that would be the case even if everyone in a so-called Agile project actually did read the full Manifesto, but the fact they didn't, doesn't exactly make it better. Probably related to this, there is a phenomenon I have observed within the Agile community: a growing frustration with bad implementations of Agile and the whole "Agile Industrial Complex."

What about the Manifestos?

Some people took it upon themselves to point out some of the worst interpretations of Agile by creating manifestos that highlight specific anti-patterns.

The “Dark Manifesto for Agile Software Development

The dark manifesto highlights an anti-pattern that I would call “superficial Agile.” It manifests itself in just focusing on the left-hand side of the first page of the manifesto –the things valued more by the creators of the Agile manifesto than those on the right hand side– without looking at the right side or even going into the depth of the principles.

The “Manifesto for Half-Arsed Agile Software Development

This manifesto focuses on the problem that organizations, that grew big by applying a non-Agile mindset, probably (often, in my experience) have a hard time really embracing an Agile mindset.

The “Agile Quitters Manifesto

The Agile quitters manifesto is a very glum or even bitter statement about many things that derail Agile intentions nowadays. Basically I translate its message as “If you want the benefits of Agile, get out of the Agile Industry.”

Unfortunately, these ironic and sometimes even sarcastic manifestos only speak to people who share the mindset and experience of those who wrote them. To others –especially without explanation– they often look like people whining without making any suggestions on how to improve the current state of affairs.

Serious critique by Uncle Bob

In his 2014 critique on the corruption of Agile Robert C. Martin (one of the original authors of the Agile Manifesto) already pointed out that there is a real danger in focusing either on the cultural aspect of Agile or the practices aspect of it.
His conclusion:

“Agile is a culture expressed through a set of practices

is something we should try to keep in mind.

Suggestions and a call to action by Martin Fowler

In his keynote at Agile Australia 2018 Martin Fowler, another original author of the Agile Manifesto, took a more positive stand without ignoring the fact that a lot has gone wrong with the current way Agile is spreading. But he also encourages all of us not to go the way of the Agile quitters but instead carry the Agile movement forward.

So now what?

Let's not get frustrated by these Manifestos, but instead let's take them as a warning sign and try to bring reason and meaning back into Agile. Let's put more emphasis on “starting where you are now” and “evolutionary change”, as Kanban-Lingo would have it. Evolution in this sense means selection of the best fit. The best fit for the current situation at this point in time. And what constitutes “the best fitting solution” is certain to change over time. As Keaynes allegedly said “When my information changes, I change my mind. What do you do?” – so stop imposing one-size-fits-all-solutions on people and perhaps try an alternative path to agility. Don’t focus on “scaling Agile” (which is kind of an oxymoron in itself), but instead try to be Agile in your teams. And maybe have a look at evolutionary models to build Business Agility.

till next time
  Michael Mahlberg