To Deliver the Project at Hand, or Improved Project-delivering Capability for the Future?
[From the Archive: Originally posted at Amplify.com Dec 30, 2010]
Dadi Ingolfsson (@blubberplinth) asks me to “please open” the “tricksy can of worms” (my comment) which his tweet (see below) raises.
Note: His tweet, amplified here, was in response to my own tweet:
“Should e.g. Scrum Masters, Agile coaches be more vested in success of “the project“, or in #agile adoption in the organisation?”
So, the core question – in my mind at least – is “Should folks focus on delivering the project at hand, or on delivering improved project-delivering capability for the organisation, for the future?”.
I can’t deny that to be an effective coach or Scrum Master within a specific project team, the coach must have the trust and confidence of that team. Such trust and confidence is rarely won easily, and this challenge is compounded when the coach has a different agenda (goals) from the team (irrespective of whether the team knows this explicitly).
Let’s remember that not every team is itself focussed on delivering the project as their highest priority. Setting aside the pathological cases – such as where the “team” is not actually a team (and therefore has no shared goal(s) as such), or where the team’s aspirations lie elsewhere than delivering the project (i.e. in CV enhancement, or in finding a new gig for the team) – the team may actually have valid priorities other than the delivery of the project itself. In particular, the team, directed by e.g. senior management, may already be working on improving their own – and the organisation’s – capabilities in the longer-term (i.e. post-project).
And of course, this is most often not an either/or situation (although rarely does capability improvement make it into the explicit objectives – a.k.a. requirements – of a project).
Capability improvement – i.e. getting better at delivering projects over the longer term – is central to some (but not many) agile adoptions. And most often in these cases, it’s the Agile coach or Scrum Master that is expected (e.g. by senior management) to be the locus of effort to this end. And they will be held accountable in such circumstances for any perceived shortfall in such improvement – whether agreed and articulated, or not.
Typically, then, when capability improvement in on the client’s agenda, the coach has little option but to include this within his or her remit. (Aside: I would suggest that it’s in everyone’s interest to make this agenda clear, unambiguous and explicit, with quantified (capability improvement) objectives as part of the project’s collection of non-functional requirements. Your project does have a set of actively-managed NFRs, doesn’t it?).
Asking a project team – who are likely already fully-committed to just delivering the project – to also deliver useful capability improvements back into the organisation (as an ‘extra’ or side-effect) is a recipe for grumbling and dissent, at best. Put another way, expecting a team to contribute capability improvements without allowing for the additional time and effort required is likely to cause friction, and if the coach or Scrum Master is seen as the person who is pushing the extra workload onto the team, all the worse. And we’ve all seen what happens to “lessons learned” exercises at the end of most projects, especially when the team is then disbanded (don’t get me started on those particular dysfunctions!).
My apologies if this post rambles rather more that usual, but I did start out by saying the subject was a “tricksy can of worms” :}
In summary, I agree that if a Scrum Master/Coach is to be a real, accepted, trusted member of a team, he/she needs to commit to that team more than to an agile adoption (a.k.a. improving capability). But actually, reality says that a delicate balancing act is the order of the day, because there are a number of stakeholding parties and constituencies involved, each possibly wearing several hats and having several (possibly conflicting) needs from the project, the team and the coach.
– Bob
Postscript
This situation (i.e. the existence of implicit and/or explicit requirements for improvements to organisational capability) is (yet) another reason why agile adoption is more tricky than it may superficially appear. And another reason why good/great coaches / Scrum Masters who understand this stuff can really earn their coin.
Think Different 