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 Scrum Master will hold team members to account if needed.
A great Scrum Master will hold the team to account for not holding team-mates to account.

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

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

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

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

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

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

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

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

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

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


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

A good Scrum Master facilitates co-operation between people. 
A great Scrum Master facilitates collaboration.

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

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

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

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

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

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

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

A good Scrum Master helps write stories so that the team is ready for sprint planning. 
A great Scrum Master 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 Scrum Master protects the team from distraction. 
A great Scrum Master finds the root cause of those distractions and eliminates them.

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

Tuesday, September 17, 2013

Good prioritizers; bad prioritizers

Even though there are many excellent techniques to prioritize a project or a backlog of work -- e.g. Story Mapping and MoSCoW -- it doesn't mean that it's easy.

In the various Agile approaches we usually split high-level prioritization and estimation between different roles: the stakeholder representative / customer or proxy / product owner (in Scrum) prioritizes the over-arching product backlog, while those who will do the work (typically a development or delivery team) estimate the cost.

Good prioritizers
  • seek bang-for-buck
  • own the project vision (or at least thoroughly understand the intent)
  • strive to get the "must haves" down to around 20% of the backlog
  • are great listeners who distil insights from a range of stakeholders
  • expect to learn a lot along the way
  • are privy to high enough level information to order the relative value of different pieces of work (quantification, e.g. cost-of-delay, would be even better!)
Bad prioritizers
  • try to please everyone, and may be punished for "poor customer service"
  • negotiate for as many "must haves" to be around 80% of the backlog
  • think they know pretty much what's needed up-front
  • struggle to synthesise a coherent picture from multiple stakeholders
  • bargain with or push the delivery team
  • may be exposed to too much detailed information
Entrepreneurs, especially those who are spending their own cash seem to have an advantage in terms of setting priorities because they are crafting their vision (although they may struggle with new information that challenges their pre-conceptions) and typically have both significant financial and emotional investment.

In an organizational context these advantages can be easily lost in the org chart.  We need to deliberately set up or carve out favourable conditions for our prioritizers to do a good job.  Then our Agile techniques can work wonderfully well.

Friday, September 6, 2013

My Talk on Design by Contract, Functional Contracts, Automated Testing and Static Typing

Last night I gave a well-received ;-) talk on Design by Contract at the Melbourne Functional (Programming) User Group.

Here are the slides:


For clojurists: James Sofra said afterwards that my talk reminded hime of this recent talk: Beyond Contracts.

Wednesday, August 21, 2013

Taiichi Ohno on Kaizen: Don't be a Fool!

According to the Kaizen Institute's blog, gemba panta rei, Taiichi Ohno once scolded a subordinate for following his instructions too closely:
You are a fool if you do just as I say. You are a greater fool if you don't do as I say. You should think for yourself and come up with better ideas than mine.

Friday, August 16, 2013

Some Reflections on Values

Here's a short quiz: Match the company to its corporate values:
  • Companies: IBM, Toyota, Enron
  • Values:
    • A. Communication, Respect, Integrity, Excellence
    • B. Challenge, Continuous Improvement, Go and See, Respect, Teamwork
    • C. Client success, Meaningful Innovation, Trust and personal responsibility
[Answers are at the bottom of the post.]

At first blush they all sound pretty good.  After all, who doesn't love a manifesto, motherhood statements, and apple pie?

Systems of Values

In exploring examples of systems of values one might also examine
  • Religious creeds: the 10 commandments, the Golden Rule, etc.
  • Practical philosophies: the Agile manifesto, Scrum values, XP values
  • Insights: e.g. Seligman on Happiness
  • Your child's school's values
  • Your personal values
It seems to me that value statements present us with at least three challenges:
  1. Explicit values vs tacit values
  2. The sheer quantity of possible values
  3. What to do in the presence of conflicting values

1. Explicit vs tacit values

The war between appearance and substance, perception and reality is ongoing.  At their best explicit values can capture and promote positive ends by conserving what is good and guiding aspirations to do better.  At their worst explicit values devolve to propaganda, or as we say nowadays "spin".

Actions speak louder than words: An interesting exercise is matching actions to explicit values and taking the leftovers and framing tacit values that they match.

2. So many values ...

Consider needs:

In the face of so many possible and overlapping values consider starting with a lists of needs and selecting a small number that are personally relevant and reasonably independent.  The aforementioned needs have the following headings: connection, physical well-being, honesty, play, peace, autonomy, meaning.  The journey from a need to an espoused value is from necessity or desire to intended action.

Maslow's hierarchy of needs -- in ascending order: physiological, safety, love and belonging, esteem, self-actualization -- is another categorization worth examining.

Self-Determination Theory identifies Competence, Relatedness and Autonomy as key.  Dan Pink subs in Purpose for Relatedness and rebrands Competence to claim Autonomy, Mastery and Purpose as the keys to intrinsic motivation.

Some other interesting examples:

Tim Gallwey and co. explore the relationships between Performance, Learning and Enjoyment -- the vertices of the "PLE triangle" -- in The Inner Game of Stress. Organizations typically obsess over Performance (the obvious, outward objective) over the other two (internal, enabling objectives).  If performance is poor (or feels empty), try focussing on learning and/or enjoyment for a while. Performance may well improve as a consequence.

At Kaizen camp Melbourne 2013 Ian MacDonald's System Leadership Theory was touched on.  In MacDonald's schema: trust, fairness, honesty, dignity, courage, and love are identified as core values that manifest in different ways depending on the work culture of an organization.

Mix and match
I've identified some categories that I find useful for comparing systems of values:
  • Ethics: Without ethics, who are we?
  • Purpose: What am I trying to achieve?  Why does the organization exist?  What distinguishes it? 
  • Performance: How am I /we doing?  Can we survive?  Can we excel?
  • Learning: How do we improve and get better, especially in the face of threat and/or competition?
  • Safety and enjoyment: Without safety, enjoyment, connection and fulfilment it will be difficult to thrive and survive long-term. [Oft-stated, sadly oft-ignored.] 
If an organization doesn't value all of these in some shape or form, that's going to leave a significant weakness.

3. Values Conflicts

Values Conflicts were the main subject of discussion in the values session at Kaizen Camp.  Discussion of examples suggested that values-conflicts may be over-diagnosed and clashes of competing self-interest under-diagnosed.

Nevertheless, the following commandments ;-) were suggested as guides to dealing with values conflicts:
  1. Thou shalt not prostitute your values.
  2. Thou shalt not retreat into learned helplessness.
  3. Thou shalt understand alternative points of view.
  4. Thou shalt understand operational imperatives.
  5. In a difficult situation, thou shalt look for ways to achieve the deeper aim, while honouring your values.
  6. Thou shalt not set up systems that reinforce bad behaviour.
The first five commandments boil down to understanding and sticking to your own values, while striving to understand other perspectives and systemic factors, and employing creativity to find win-wins. The last item is preventative.

The Value of Values

Your beliefs become your thoughts,
Your thoughts become your words,
Your words become your actions,
Your actions become your habits,
Your habits become your values,
Your values become your destiny.

― Gandhi
Quiz answer key: A = Enron, B = Toyota, C = IBM