Friday, July 04, 2014

How to get to the value(s)?

Values! That's what the Agile Manifesto – and hence the whole agile software development movement – is all about! Or is it?


Do you know how Waterfall first came into life? There are many stories, but a lot of them start with an article by Dr. Winston W. Royce, presented at the 1970 WESCON.

There the classical waterfall approach is lined out on the first few sentences and pictures.

And for many a reader that was enough!

And so they missed, that he continued by stating, that while he believed in the principal idea [of doing analysis and design prior to programming] he thought the implementation to be „risky and inviting failure“. He used the remainder of the paper to line out a more iterative approach, which he recommended to his readers. If only they had read thus far...

So the straw man, that Royce set up just to knock him down, has become the foundation for the waterfall model as we know it, because (some? most?) people didn't bother reading far enough.

Same in agile

The funny thing I see nowadays is that the same starts to happen with the agile manifesto.

In a lot of conversations the agile manifesto seems to have been reduced to the underlying values. Which are handily presented on the first page of the manifesto. It is funny how the room falls silent very often when I start to ask about the second page of the manifesto with the principles...

Seems like a lot of people don't look further than the first page.

How to get the values across

To me, the fact that there is (way) more to agile than only the four value statements has always been a relief – after all, up until now, nobody has found a way to install values into someones brain directly. At least not to my knowledge.

From what I understood from the behavioral psychologists, with whom I talked about the matter, the accepted way to transport values is to let the target audience experience the values through practices.

Children learn about values from the way other people act – not by what others say is right. (Claiming “Chocolate is bad for you” while munching away on a mousse au chocolat usually doesn't work to well with children.)

And – as Uncle Bob pointed out – we also infer the values a culture holds high from the behavior we can observe in that culture.

A culture in this case can be as local as a single software development team.

Thus, when everybody on the team claims “We believe in high quality software” but they cut corners every time they have to deliver, one might infer that they don't really see value in high quality software. (Which would be a pity, since – in my opinion – Quick and Dirty is very non-Agile!)

Or, when the whole team claims to love tests but none get ever written, one might infer that "testing" is in fact not really in their value set.

The opposite is not quite as simple – if we observe a team that consistently writes test we would probably infer that they hold testing high, while in fact they might just be scared by their QA department.

Nonetheless, as long as there is no way to ‘inject’ values directly, just following the practices for a while still seems to be a very good way to get at least closer to the values.

While I have seen many a project fail where every member could quote all the values from the Agile Manifesto I have not yet seen a project that adhered to all the principles and still failed.

Although I have to admit that it is a lot harder to actually follow the concrete principles than to quote the values.

Try giving the second page of the Agile Manifesto a chance – it might be worth it!

‘til next time
Michael Mahlberg


Steven M Smith said...

Am I catching your meaning correctly that it's impossible to inject values but possible to coerce behavior? If you could inject agile values, what behavioral change would you expect? Some? None? If you could coerce agile behavior, what change in values would you expect? Some? None?

Anonymous said...

Thanks Michael, for this nice blog post. I like the idea that following practices (voluntarily, based on positive experiences) is more useful than talking about values. Once you developed your set of values, it might be helpful to share it with others, who developed their own set of values. But before, consciously choosing practices should be enough.

With respect to the misreading of Royce, I recently became quite stunned, how weak the basis for other commonly accepted statements (exponential growth change cost, cone of uncertainty) actually is. Laurent Bossavit in "The Leprechauns of Software Engineering" presents quite some disillusioning research in this respect. You might want to check it out.


Michael Mahlberg said...

Hello Steve,

"coercing" behavior sounds a bit strong.
I do believe that it is easier to agree on specific behaviors and to live up to those agreement, than it is to "agree" on having a specific mindset and, just by agreeing on the intention of having that mindset altering ones believes.

But no, I don't believe in coercing people – but I can invite them to do an experiment (different behavior) that might /convince/ them to alter their values.

Thank you very much much for the comment - made me think a lot!