My interest was immediately peaked when the opening question was “Ask the four or five people around you what are some of the key causes for an Agile Implementation to fail”.
What we were met with was two elements of failure – 1) at a team layer and 2) at an organisation or enterprise layer. An element of distinction between these two was not really made so I am left to assume most of the twelve failure modes are directed at an enterprise layer.
On the first failure mode I felt a little shaky. It was called ‘Checkbook commitment’ and was pitching failure where the Agile Champion is just a Sugar Daddy (my words) – all money but no heart. I don’t disagree with this as a failure mode but feel it goes much further. To have a Champion in the first place is a good thing. One failure mode would be that one doesn’t exist; another would be that their expectations are unrealistic and they pull the plug too early in the piece to reap the reward, or one that doesn’t stand up for the framework and lets governance bog it down with unnecessary requirements. The failure is in several layers of the Champion not necessarily that they are only a checkbook.
Then failure mode two hit: Your organisation does not support change. My faith was getting weaker with immediate thoughts as to whether this was a cop out statement. What organisation DOES support change? If an organisation was supportive on change then surely Agile Implementation would be a no brainer. This is why cultural change takes an average of seven years and without a doubt Agile is a significant cultural shift for most organisations.
Now in fairness Jean had incredible jet lag and sleep deprivation so maybe the words didn’t come out right. When the closing slide was done I looked at it curiously – failure mode two was renamed to “Your organisation does not support learning” – was the initial slide a typo or the recap was the typo or did I just fail at paying attention probably and mis read it? If the point was supporting learning then maybe I could see that as a failure mode, but this is probably the only point in the whole presentation I wasn’t sold on.
There were further comments that occasionally peaked my interest. There was a reference to ‘insight’ and I felt that this had synergy with Alistair Cockburn’s recent post of reflective improvement frameworks.
Another point was made about servant leadership and this one really made me think hard. If we are trying to achieve a servant leadership environment – is the Scrum Master/Iteration Manager role counter-intuitive to this? Is the role we seek more really an Agile Coach rather than a Master/Manager role. Perhaps just the titles are bad, but all too often I have seen teams not take on collective ownership of the story wall, not take ownership of helping to facilitate retrospectives. I have heard many SM/IMs call the role an almost ‘administration’ role rather than a coaching or mentoring role. Maybe we are doing ourselves a dis-service in the furtherment of Agile by continuing with the Scrum Master/Iteration Manager terms?
On the recent topic of PMOs Jean talked about how a PMO isn’t there to enforce practices. I think I am still in two minds about this. I have re-organised a PMO so that its key function was to ensure that prior to senior executive approval of major projects the right IT people (and by right IT people I mean the real workers) were engaged with the right business people (end users or those that truly knew the business benefits and drive) met together and both agreed that they got just enough detail that they needed to proceed to the next step and that the value was worth the effort. In essence, they were there to ensure that effective collaboration was done. Prior to implementing that change executives would approve projects with no IT input to estimates or timeframes or estimates were changed (read dramatically cut) from what the IT group provided.
Take the presentation as a whole – 12 failure modes. What if a PMO’s function was to ensure that those 12 failure modes did not occur; I wonder if that would be considered worthwhile.
I loved the idea of walking into a retrospective and asking for a confessional (sorry Jean I took this idea a little further). Imagine asking a team that hadn’t performed a retrospective for a while and asking them to start their brainstorm with ‘Hi I’m Renee. It’s been five weeks since my last retrospective”.
I loved the concept of Servant Leadership as “I raise IQ’s for a living”.
I loved the point that performance bonuses are not beneficial to Agile (I’ll probably tackle this on my next blog as it has been mulling around in my head for a few months now and I will be presenting my vision on this when I present next week at Agile Australia).
I can’t recall anything mentioned about Definition of Done on the testing related failure modes but it was on the recap slide (maybe a typo again?).
All in all I got probably 5 takeaways that really made me ponder so A++ to Jean for the presentation, for making me think, and doing it whilst incredibly jet lagged!