Is Agile Software Development a Cul-de-sac for a PM's Career?

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.