Cottmeyers 3 Things – some quick personal reflections

From my colleague Frank Olsen I received a link to Mike Cottmeyers Agile2015 presentation: http://www.slideshare.net/mcottmeyer/the-three-things-you-need-to-know-to-transform-any-size-organization-into-an-agile-enterprise – some quick reflections …

Instead of building up a 2×2 of convergence/emergence and predictability/adaptability I have been thinking about the obligation to assign winnable missions to teams – a prerequisite I believe if you want teams to be self-organized and engaged. I’ve only seen the slides and not heard the words, but I also believe that the nature of an assignment can change dynamically, so that you cannot rely on being firmly anchored in one quadrant or another – you must be able to handle all – and there’s no one size fits all 🙂

The three things are backlogs, teams and working, tested software.  With this we are still close to the team level. I believe that the challenge of transforming and with that also scaling is at the organizational level – not the team level.

Transforming and scaling is more about environment and conditions, than how the teams work.

I like how Mike connects to clarity, accountability and measurable progress – and to Pinks ideas of mastery, purpose and autonomy – enumerated as  purpose, autonomy and mastery to fit backlogs, teams and working, tested software. A nice way of coupling things.

backlogs – teams – working, tested software

clarity – accountability – measurable progress

purpose – autonomy – mastery

Mike then comments about how this look when scaling and adds:

governance – structure – metrics & tools

On slide 51 there is a great overview of what metrics applies in different levels. On the top level I miss a metric for ‘load on organization’ as well as financial metrics for agility – how much cash is tied up in unfinished deliveries – how much cash is required to complete unfinished deliveries in process – and also a financial measure for rework.

It’s mentioned that teams do SCRUM and Kanban is applied at program and portfolio level – without knowing the details I suspect this implies a classical misconception of what Kanban want’s to achieve.

Transformation is all about removing impediments for progress. A theory of transformation is formed (copied from Mike’s slides 70-72):

• Agile is about forming teams, building backlogs, and regularly producing increments of working tested software
• Agile at scale is about defining structure, establishing governance, and creating a metrics and tooling strategy that supports agility
• Anything that gets in the way of forming teams, building backlogs, and producing working tested software is an impediment to transformation

In summary, I believe there is a lot of similarity to how I have been thinking – first of all that agility at enterprise level is something very different from scaling scrum.

Great slides, thank you, Mike!