Theoretically Agile is quite simple - as long as the theory is Theory Y

When the whole agile movement started there was a huge amount of success-stories everywhere to be heard. But nowadays, as Agile has entered the mainstream at least partially things have changed. As Michael Sahota points out in his "...Agile Adoption and Transformation Survival Guide" the success rate of agile projects nowadays follows the bell curve pretty much like everything else.
When I run the team building simulation from the Hands-on lean and Agile practices course we very often find that the highest performing teams are in the realm of recreation – and it is my impression that there is a significance in that, that is worthwhile to explore.
Talking about motivation and people's engagement Theory X and Theory Y come to mind. In the 1960s Douglas McGregor developed Theory X and Theory Y at MIT. Two theories that have a considerable influence on how people and projects get managed – even though many managers are not aware of those theories. While Theory X assumes employees are unwilling to perform and have to be tightly controlled, Theory Y assumes the complete opposite - that people are highly motivated and just need to be supported.
I don't want to go into which theory is more valid - especially not without discussing Theory U which takes a completely different approach. But what strikes me ever so often is the similarity between the assumptions of Theory Y and the assumptions of most agile methods – and actually this is one of the reasons why the success/failure distribution for agile projects is developing the way it is. In the early days people were attracted to Agile projects by their enthusiasm and willingness to explore new ways of working. Actually the early "war-stories" from those agile teams fit perfectly into Theory Y wording. When – for example – a team hijacks a meeting room as a permanent collaboration space that's pretty much people wanting to excel and create their ideal working environment. But the more Agile is crossing the chasm to widespread adaption the more it gets pulled into the realm of Theory X – largely because most major companies are run based on Theory X. And thus we see a conceptual difference between the assumed environment for Agile (Theory Y environment) and the actual environment for many projects nowadays that run under an agile umbrella (Theory X environment).
This mismatch is – in my humble opinion – one of the main reasons why Agile has lost a lot of it's edge over "classical" management.

Till next time
   Michael

Uncharted Territory - exploration vs. guided tours

Yet another case for the use of adaptive methods in product development...

The good tour-guide...

... be it in a city or in the outdoors, has been to all the places he guides you to, has friends in every second venue, has intimate knowledge of the secluded spots so he can show you what the eye of the unknowing passer by would surely miss. That's the kind of tour guide I would want on a tour in well-known territory. But then again: what about the truly explorative excursions? Those places, I want to go to, to discover new things, unknown wonders or scarce resources - would I really want the same guide for this?

... may not be the best scout

If I go into uncharted territory my main focus is not to have a guide who knows all the places (that would somehow contradict the "uncharted" part, wouldn't it?), but someone who knows how to read the terrain, who knows how to work a compass, how to triangulate a position even when we haven't been moving in the intended direction for quite a while, someone who can figure out how to go about it if we need fresh supplies, and so on. Maybe the tour-guide from the previous paragraph also has those qualities – but the skillset is definitely quite different.

What's that got to do with software development?

Well - when Tom and I worked on our Hands on lean and Agile practices course I once again realized that, while traditional methods mostly took the tour-guide approach. Most of the tools in the Agile toolset really help you to be a better scout while the lean toolset seems to cover both aspects with a special emphasis on the transition. That way I like the Agile practices for allowing me to navigate in uncharted territory while the lean tools give me a way to quickly make this territory accessible for repeated tours.

How do they fit together? - Another Tale of Kanban and Agile Principles

Some say they are contradictory - I think that is the wrong word - complementary is more to the point.

What's the beef? Explicit lyrics ahem... policies

One of the Kanban Principles (the fourth to be exact) requires the team to "... Make Process Policies Explicit" while the probably best known statement from the agile manifesto invites us to value "Individuals and interactions over processes and tools."
Now when Tom and I prepared our hands on lean and agile practices course we both knew from experience that there is a lot of value in both approaches. But I still was baffled when a colleague from the Limited WIP Society Cologne pointed out the contradiction in these two statements and it took me while to come up with an answer.

Explicit is not a four letter word

Many people I know in the Agile community are sceptic towards explicit rules because they tend to be written in stone – especially if they come from the outside. But in an Agile environment (same as in a lean environment) that doesn't have to be the case. Not, if the team (or the cell if you use lean terminology or however the relevant unit is called in your context) owns the process policies - whether they are explicit or implicit. Making them explicit does not make the un-changeable.

"Explicit" makes it tangible

On the contrary - as long process policies are implicit it is hard to discuss them. Once they are written down – for example as an exit condition for a status or as a work in progress limit – it is easy to refer to them (the hard part is identifying them in the first place) and the team can change them explicitly whenever the need arises. Visible to everyone and without reliance on tacit knowledge. They might even start to track how often they change certain policies as those changes might point to some opportunity for improvement and the numbers could provide valuable input for the next operations review (or retrospective if your focus is Agile)

Explicit policies make it easier...

... to focus on "Individuals and interactions over processes and tools" because the important agreements between the individuals are out there in the open – tangible and negotiable.