Friday, October 10, 2014

A Rosetta Stone of Agile Maturity Models

The Rosetta Stone

Please note: I have massively expanded on this post in an article appearing in InfoQ:

Learn or Lose: Agile Coaching and Organizational Survival

Go there for my deeper, more considered treatment.

* * *

Here's my attempt to line up a range of models, most not explicitly or exclusively agile:

ModelStage 1Stage 2Stage 3Stage 4
Folk classificationCowboyWaterfallAgile (or Lean)-
Shu Ha Ri-Shu (learn)
Doing Agile
Ha (internalise)
Being Agile
Ri (transcend)
4 stages of competenceUnconscious incompetenceConscious incompetenceConscious competenceUnconscious competence
Marshall modelAd hocAnalyticSynergisticChaordic
Agile FluencyNon-fluentOne star
(focus on value)
Two / Three star
(deliver / optimize value)
Four star
(Optimize for systems)
Hofstede culture clustersContestPyramidNetwork-
Spiral dynamicsOrangeBlue, OrangeGreen, YellowTurquoise


Disclaimers
  1. In some Agile quarters "maturity model" is a bit of a dirty expression, in-so-far as it can be taken to imply a strict linear development, oblivious to context, so hopefully there will be some good debate!
  2. I don't claim that the models line up perfectly. Each has its strengths, so I'm using it to point towards useful parallels and prompt further discussion.
  3. Shu Ha Ri and Four stages of competence are usually taken to apply at a personal level, while the others apply at larger scales: to teams, organisations, and/or societies. I include both because I see the personal and cultural shifts as intertwined.

Commentary

It's early days in the paradigm-shift sweeping knowledge work and its coordination. Leading up to and following the signing of the Agile Manifesto in 2001 the early adoption of the Agile was all bottom-up, and came from software development groups.

Today we are seeing lots of top-down action, as well as the dissemination of Agile [and Lean] concepts and techniques well beyond software [and manufacturing] into most areas of knowledge-work. Executives are sponsoring Agile (and Lean) "implementations" in an attempt to cope with the challenges of an era of accelerating change and unrelenting competition.

But the shifts in mindset and culture needed to thrive in the "new normal" are vast. This applies to do-ers, to middle-managers, and to executives. [Those who think they can require change in their subordinates without going on the journey too, may well find themselves obsolete.] In my experience many welcome the change to a more humane and effective way of working, some adapt with a bit of effort, others misconstrue, bastardise and partly "get it", and a significant number are unwilling or unable to make the shift, at least on the first attempt.

When I first came across Agile methodologies in 2004 they were regarded as the province of elite, small-scale software development teams. I thought that there was no way large organizations would buy into the implicit challenge to command-and-control, and I had yet to realise that Agile ideas have so much to offer all areas of knowledge-work, not just programming, start-ups, and IT. By 2010, I saw that the shift was well under-way: the need for change now outweighed the blockers, but paradigm-shifts don't happen easily ... or overnight!

Today, as an Agile Coach, I find myself in the business of culture change, and I've gone hunting for models to quickly assess organisational culture in order to make clear, achievable recommendations for Agile intervention, implementation, transformation, or rescue. The aim is to make Agile coaching interventions faster and more effective.

After chatting with Matthew Hodgson of Zen Ex Machina about his brilliant application of Hofstede's culture clusters to diagnose organisational culture I wondered whether I could better target my own coaching efforts.

When I discussed applying the Hofstede/dgson with my then colleagues, a counter-proposal arose: what about Bob Marshall's model? This carried the day, and yielded helpful insights.

Some applications

The different mindsets that underly the different stages can give rise to interesting (and somewhat amusing) perceptual differences.

1. While recruiting in a fairly established corporate Agile environment (in which teams were operating reliably in late stage 2,  early stage 3) I would typically get one of two responses from job candidates who lacked previous Agile:
  1. People from Stage 1 (ad hoc) backgrounds such as digital agencies would take one look and comment on the "incredible bureaucracy" of our practices. How did we ever get anything done!?
  2. Those accustomed to stage 2 (waterfall variant) such as long-time bank employees would, by contrast, perceive our operation as a risky cowboy shop operating at break-neck pace!
In both cases it was necessary to gauge whether the individual would likely be able to make the transition. Generally, if they were attracted to our approach, for example if they felt that it addressed shortcomings in their previous work environments that they had found frustrating, there was potential.

2. As a coach, it's a very different proposition to work with an "ad hoc" group, typically confronted with organisational growing pains, compared to a more established organisation trying to transition out of command-and-control / traditional project management,  e.g. in order to become more responsive and/or creative.

In the first instance one needs to lead the client on a journey into discipline -- shu / doing agile -- before ha / becoming truly agile.

In the latter case, there is the tricky task of helping people unlearn the false lessons of command-and-control ("unplugging them from the Borg" in the evocative phrasing of the wonderful Stephanie BySouth) before nurturing the new mindset.

Which model is best?

Just as I love both my children equally, and I don't want to choose between different Agile methodologies -- but I *will* recommend one over the others in a given context -- I'm not picking winners here.  I wouldn't have included a model if I didn't think that it added substantively to the mix. However,  I will put in a vote for Bob Marshall's model as a good default starting place.

What do you think?

Monday, February 17, 2014

A compassionate reading of the Agile Manifesto


The four points of the Agile Manifesto read
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation 
  • Customer collaboration over contract negotiation 
  • Responding to change over following a plan
which Agilists are at pains to point out does not mean: "no process, tools, contracts or plans", but -- as the manifesto goes on to say -- "while there is value in the items on the right, we value the items on the left more".

Now Olaf Lewitz has written a wonderful articulation of why the items on the left are more highly valued than those on the right:
Now, when I read the four statements from a compassionate point of view, having worked with hundreds of organisations where people cling to documentation, plans, contracts, processes and roles, I have a more holistic perspective.  
All of the things on the right are commonly used for three purposes:  
  1. To hide lies, to avoid trust, 
  2. To cover somebody’s ass (make sure it’s not my fault), and 
  3. To defer acknowledgement of uncertainty. 
 The basic emotion behind all of these strategies is fear.
In other words: the items on the right give protect against negative outcomes and the related fears, while those on the left emphasise freedom and fruitfulness.

Depending on the situation one may need to play some defence, but the ideal is to move forward positively.

Wednesday, February 12, 2014

Scrum Master characteristics: From Good to Great

A fantastic blog post from Geoff Watts (inspectandadapt.com) enumerated desirable characteristics of good Scrum Masters, and how to take them to the next level in Towards a Definition of a Great Scrum Master. He used elements of the list in his book: Scrum Mastery: From Good to Great Servant-Leadership.

I've added categories and reformatted the original list for reference and readability:

Accountability
A good ScrumMaster will hold team members to account if needed.
A great ScrumMaster will hold the team to account for not holding team-mates to account.

Communication
A good ScrumMaster encourages people to talk to each other.
A great ScrumMaster encourages people to listen to each other.

A good ScrumMaster says what needs to be said.
A great ScrumMaster knows the power of silence.

Growth
A good ScrumMaster helps every member of the team grow. 
A great ScrumMaster encourages growth as a team. 

A good ScrumMaster notices areas for improvement in the team. 
A great ScrumMaster recognises & highlights strengths of the team for them to build on.

A good ScrumMaster will coach the team to succeed. 
A great ScrumMaster allows failure & encourages the team to learn from their mistakes (from Christina Ohanian).

A great ScrumMaster is chosen by the team and Product Owner. 
When she's done all she can, it's time for another great ScrumMaster (from Mike James).

Servant-Leadership
A good ScrumMaster serves the team. 
A great ScrumMaster fosters servant-leadership throughout the team. 

A good ScrumMaster  is wary of influencing the team with what they say & do. 
A great ScrumMaster can act normally and the team still make their own decisions.

A good ScrumMaster will be indispensable to a team. 
A great ScrumMaster will make themselves dispensable. And wanted.

A good ScrumMaster asks to understand so they can serve. 
A great ScrumMaster asks so the team understands and can serve itself.


Teamwork
A good ScrumMaster helps teams use "yes, but" effectively. 
A great ScrumMaster helps teams find more space for "yes, and".

A good ScrumMaster facilitates co-operation between people. 
A great ScrumMaster facilitates collaboration.

A good ScrumMaster listens to what is said in the daily scrum. 
A great ScrumMaster listens to what is not said in the daily scrum.

A good ScrumMaster will help maintain team harmony. 
A great ScrumMaster will guide a team through disharmony to reach a new level of teamwork.

Inspect and Adapt
A good ScrumMaster helps a team meet their definition of done at the end of a sprint. 
A great ScrumMaster helps a team extend their definition of done.

A good ScrumMaster will help teams optimise their process. 
A great ScrumMaster will help the team get past process.

A good ScrumMaster helps the team hold a balanced retrospective. 
A great ScrumMaster helps the team hold a focused retrospective.

Working with the Product Owner
A good ScrumMaster facilitates the Sprint Review so the team gets to demo to the Product Owner . 
A great ScrumMaster ensures that the PO is already aware so the demo can be for other stakeholders.

A good ScrumMaster will be a bridge between the Product Owner and the team. 
A great ScrumMaster will reduce the need for a bridge.

A good ScrumMaster helps write stories so team is ready for sprint planning. 
A great ScrumMaster helps the Product Owner  make time before and during the Sprint to write and talk to the team.

Relationship to the larger organization
A good ScrumMaster protects the team from distraction. 
A great ScrumMaster finds the root cause of those distractions and eliminates them.

A good ScrumMaster helps a Scrum team survive in an organisation's culture. 
A great ScrumMaster helps change the culture so Scrum teams can thrive.