To Deliver the Project at Hand, or Improved Project-delivering Capability for the Future?

To Deliver the Project at Hand, or Improved Project-delivering Capability for the Future?

[From the Archive: Originally posted at 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.

Amplifyd from
  • Dadi Ingolfssonblubberplinth @flowchainsensei I say, if a Scrum Master/Coach is part of a team he needs to commit to that team more than to an agile adoption


– Bob


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.


  1. This is inseparable for me. The local team is subject to the influences / constraints of the wider system (org) so in order to be effective the wider systemic issues need to be tackled.

    • Is it fair to extend Deming’s 95% rule to this situation? Is 95% of the productivity of a team dependent on the influences and constraints of the wider system, and therefore outside the team’s immediate control? If so, is it then fair to suggest that the team as a whole (or the coach or Scum Master, as proxy) should be spending 95% of its time on these wider issues?

      – Bob

      • No, I don’t think 95% of effort is required to solve 95% of problems. This is where I’ve found the Kanban method to be of particular use – but only when THE WHOLE system is visualised.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: