My starting premise is that in order to grow in a successful
career as a project manager you need to acquire and practice a core range of competencies. A good example would be those
described in the Association for Project Management’s (APM) Competence
Framework, which do not differ greatly from the competencies laid down by any
other professional body for project managers.
With that starting point, the answer to my question must be
“Yes, agile software development is a cul-de-sac for a PM’s career.” I do not believe that, within an agile team,
there is the scope for a PM to acquire and practice many of the competencies
necessary to be regarded as a fully rounded PM, let alone to be able to attain
Registered Project Professional (RPP) status. Ambitious Project Managers must
find a wider remit if they are to grow and advance their careers.
Moving away from the theoretical to the empirical, I have
yet to have first hand experience of any
organisation engaged in agile software development where the PM is doing
anything like the full range of activities I – and the APM – would associate
with professional project management.
In almost all cases I have seen the PM is little more than
an extremely competent administrator, usually reporting to a development
manager. At best, the PM takes the role of Scrum Master, which I believe is a
career path of its own, and a more appropriate role in agile teams.
Let’s look at some of the competencies and see if they can
be practised within an agile setting. I think they fall into four groups.
First, those where it is possible to create an argument that
they are used irrespective of the technique being used to deliver any piece of
work:
Professionalism &
Ethics. Few if any would dispute that one can behave professionally and
ethically whatever the role.
Teamwork. Again,
the very essence of agile is teamwork so it would be difficult to argue that
the PM is not using this competence.
Behavioural
characteristics. Similar to professionalism, maintaining the right
behaviours would seem to be a universal requirement.
Health, safety and
environmental management is another example of a universal competence, with
more significance for some than others.
Second, those competencies that are demonstrably practised
by Project Managers in an agile team and in my view should be the province of
Scrum Masters:
Communication and
Information management and reporting. Certainly. The PM is usually
responsible for communicating progress, burn-down charts, user requirements and
so on.
Stakeholder
Management. Undoubtedly; the PM is often seen as the primary point of
contact by stakeholders, and, given agile’s emphasis on people, relationships
and communication over process and rules this is a competency that the PM
probably exercises every working day.
Scheduling. Sort
of. In a “self-managing team” prioritisation and scope for each sprint is a
team effort, but the PM might be responsible for managing the backlog in
consultation with stakeholders (although I would want to argue that this is, or
should be, the role for the Product Owner, and the PM is little more than the
scribe for the Product Owner).
Budgeting and cost
management. Maybe, although I have to say at best my experience is that PMs
in agile teams do nothing more than keep track of man-days required to deliver,
e.g. a MVP compared to the original forecast, which is hardly the way the
Competence Framework defines this competence or the way most people would
understand the term.
Risk and Issue
management. Probably, when they are practised at all in agile teams. The PM
will keep RAID Logs but it’s a fairly solitary activity and I’m willing to bet
that few developers in an agile team really feel the Log is relevant to them,
unlike in a waterfall team where a clear correlation between risks and
deadlines might be made.
Third, things that fall into a grey area where sophists
might tie themselves in knots arguing a PM does them in an agile environment:
Conflict management. In
the very loosest sense of the term we all manage some conflict as part of
office life, but in a stricter interpretation of the competency, the PM might be responsible for gaining
agreement between stakeholders
But would be unlikely to resolve conflict within the team –
that task would probably fall to the Development Manager.
Project success and
benefits management. In the sense of this competence as outlined in the APM
Framework I haven’t seen PMs undertake this in an agile environment. By its
very nature the environment is iterative and collaborative and it is
effectively business as usual for developers to demonstrate prototypes and gain
sign-off along the route. It could be argued that once the MVP is implemented
PMs monitor the benefits against those anticipated in the Business Case, and
for any subsequent enhancements of the product, which is why I have listed it
in my third category, but it has never been my experience.
So the first three sections cover 13 of the 29 core
competencies required of an RPP. The final list explains my justification for
the claim that agile is a career-killer for project managers.
Leadership
In an agile software development team the PM is completely
pushed out of any formal leadership. Development Managers are responsible for creating
an environment to encourage high performance, gaining commitment, addressing
development needs and motivating the team. The best a PM can do is to set a
good example of professionalism and positivity.
PMP. Or PID if
you prefer your flavour of project management to be PRINCE 2. If you really
wanted to, I suppose you could argue that the PM documents why the work is being done, but in my experience this is covered
off in a business case created before the PM is involved. Similarly, the PM
could be said to document what is
being done in maintaining the backlog, but that, more strictly is the Product
Owner’s responsibility. I cannot think of a single convincing argument that the
PM documents the how and when for agile software development in a
self-managing team, and talk of schedules, milestones and critical path ring
pretty hollow even if you do produce a Gantt chart of fortnightly sprint dates.
Change control. There
is no formal change control in the sense that the Framework means it in an
agile team. Talk of signing off scope then subjecting it to configuration
management makes sense in the context of waterfall development but in an agile
world responding to change with minimal fuss is the inevitable inference from
the Agile Manifesto.
Scheduling. In
conjunction with the Product Owner the PM might agree the priority of items on
the backlog but when it comes to scheduling that’s the domain of the self-managing team at the sprint
planning meeting.
Quality management. Again,
the competence against which PMs are judged assumes a formal document stating
quality expectations and approach. In agile methodology the emphasis is on
people, not processes and documentation. Quality is established by prototyping
and continuous, incremental improvement and this is done by collaboration
between team members and stakeholders and the “Quality Log” is not “maintained”,
it is implicit in each subsequent code release.
Resource management. The
Development Manager, not the PM, will normally identify what resources are
needed and scheduling, smoothing and levelling are meaningless for an agile
team. Talk of a schedule and resource allocation plan is similarly meaningless,
as is the notion of controlling resources with respect to scope changes.
Project life cycles. The
life cycle model is, by definition, agile, and evaluation and approval points
are inherent in the sprint process, so there is nothing meaningful for the PM
to do against this competency.
Organisational roles.
You might well ask “What OBS?”. It’s a self-managing small team, with the
emphasis on collaboration, not documentation.
Governance of project
management. Any adherence to the organisation’s processes, standards and
guidelines is self-governing in a high-performing agile team, and in a lesser
performing one is enforced by the Development Manager. In any event it is more
likely to be technical than governance in nature.
Project reviews. Most
of this competency is business as usual for an agile team, holding scrums/daily
stand-ups and demonstrating prototypes. At best, a PM might organise a
Post-Project Evaluation and create a Lessons Learned Log.
Scope management. Product
Breakdown Structure? Change Control Process? I think not. Requirements and objectives
are determined by the business, usually documented by the Product Owner and
held in a backlog to be added to sprints as the team sees fit.
Requirements
management. See “Scope management” and “Project reviews” above. Why would
you need a PM to document requirements when you have a Product Owner,
Development Manager and team of developers all talking to each other and collaborating?
Estimating. In an
agile team this activity is reduced to calculating the team velocity, easily
and quickly done by the Development Manager in agreement with the Product Owner.
As a side note, this produces far better estimates than the methods used for a
waterfall project where, despite a wealth of experience to the contrary,
stakeholders demand and PMs strive for delivery certainty.
Business case. This
is an activity that falls squarely on the shoulders of the Product Owner, who
should be a subject-matter expert on the business trends and benefits of what
the team is developing.
Organisation
structure. Typically, Development Managers will agree amongst themselves
when resources need to move from one team to another for a given piece of work.
That’s an inevitable (healthy) cultural consequence of self-governing,
collaborative teams.
Negotiation. Let’s
be honest. Negotiation for a PM on an agile team might involve agreeing
different priorities for the backlog with a Product Owner but there is likely
to be little else. There would certainly be no opportunity to negotiate
contracts and the like, creating a negotiation strategy as envisaged by the
competency.
So I started out by asserting that Project Managers,
embedded in purely agile software development teams are damaging their careers
because they can never be fully engaged, if at all, in many of the activities
regarded as core to professional project management bodies. Of the APM’s 29
core competencies, four are done by just about everybody, seven are done by PMs
in agile teams (I’ve conjoined some) and I think they would be more
appropriately given to a scrum master, two you might be able to make a case for
but possibly not whilst keeping a straight face, and sixteen are not done in
any meaningful way by PMs in agile teams.
I’ve no doubt that people making a living selling books and
training courses on “Project Management in an Agile World” or similar will leap
to tell me I’m wrong, and I’ll do my utmost to keep an open mind as I read what
they say, but the whiff of vested interest will make it hard for me to suppress
my cynicism.
Similarly, there might be Project Managers out there doing a
great job in agile teams who take issue with my assessment. I would suggest
that they complete the APM RPP Portfolio of Evidence and see if they have
convinced themselves. If you have, I’d love to see it. If you haven’t, I
suggest you either decide to go down the Scrum Master route or consider a
change of job for the benefit of your project management career.
Steve Syder is a Registered Project Professional, a Fellow
of the APM and an RPP Assessor. He has in his time implemented Programme and
Project Management practices for organisations as diverse as the UK
Hydrographic Office, EDS and Orange amongst others. Until recently he was
Director of Project Management at OpenBet, and he has now turned his attention
to governance of the BI function at Tyche Consulting, where he encourages an
agile approach.
