Tag Archives: agile

Agile project management

It is interesting – and somewhat telling – that I have sometimes been asked by business representatives “But what does a project manager actually do?”

Of course in a traditional waterfall project this is well understood. The PM is the key person responsible for planning and delivery to the plan, managing communication, risks, changes and issues along the way.

But what about an Agile project? Surely an Agile project team is self-managing, and the business end is handled by the Product Owner?

Well perhaps. But in practice most companies who have used Agile for more than just small, discrete projects have found, unsurprisingly, that there is a need for a project management role also.

The best analogy I have seen here is from Steven Thomas

“The role of the Project Manager is subtly different when using an Agile approach. From my fairly biased view an Agile PM is more a shepherd (or sheep dog) and less a military officer. There is lots of rushing around the edges of the development team but relatively little direct control of what the team does. If you merge together a description of the Project Manager, Scrum Master, Coach, and Tracker from XP, DSDM, Crystal Orange and Scrum you get:

Gather information from all stakeholders and integrate into workable plan; log estimates; advise programmers on their estimates using historical figures; log task assignments; sustain high rate of progress; make decisions; remove impediments; build and sustain team culture; ensure team sticks to process; liaise between management and team; manage customer relationships; fend off “feature creep” and other project hazards; get agreement on the prioritisation of requirements and detailed content of timeboxes; track progress against the timebox goals/plan; collect information without disturbing the process; update plans; communicate progress; ensure that the lessons are learnt; log defects; stay calm.

Things like “remove impediments” and “build and sustain team culture” aren’t normally seen in traditional PM role descriptions. Then there are the softly, softly items like “collect information without disturbing the process” and “get agreement on …”; and notice we “log task assignments” we don’t “assign tasks”. However, when the crunch comes we must still “make decisions”.”

In their paper “Agile project management” Maven make a similar point

“Whilst the role of Project Manager and Team Leader exist as they do in PRINCE2 , the emphasis on the responsibilities is very different and this can cause some adjustment for those project managers coming to Agile from a waterfall background.

The project team is empowered to plan their work in detail and to address issues as they arise with whoever is best placed to solve them. This means that not all communication comes through the Project Manager. [He is] not formally managing the project team, but must be on hand to guide them and to help remove any obstacles that will impede their progress. At the same time, [the PM needs] to be fully aware of the progress that the project team is making so that he or she can relay this to the stakeholders and ensure they have enough information to assure themselves that the project is on track and will deliver what they need.

For project managers used to planning every aspect of their project and conveying this information to team members via detailed work packages, this lack of control over the day to day work can appear threatening. This is why trust and honesty between the team and the Project Manager is vital, as is knowing when to stand back and let the team get on with their work.”

So there you have it. More guidance, less direction. Less a military officer, more a sheepdog.

Roles in an agile programme

One of the common criticisms made of agile is the inability to scale to large systems and programmes. It seems worthwhile, therefore, to think about the differences in agile structure between a programme and a project.

Just as in waterfall many programme roles relate directly to those in a project. However the programme level is fundamentally about business outcomes rather than project outputs and therefore focusses on business change implementation and benefit realisation, functions not normally found in projects. At development level though, the responsibility is larger and coordination greater but the roles are basically the same. The Programme Manager, Product Owner and Technical Architect roles are like this, corresponding to Agile Project Manager, Product Owner and Technical Lead.

In addition a programme needs some roles that don’t appear at all in a project, notably Programme Director and Business Change Manager. Again these roles are a result of the increased scope and communication necessary in a programme and also because of the focus on organisational change.

Programme Organisation Chart

Lets look at a typical agile programme organisation.

agileorg

The people in the technical teams (product development, integration, infrastructure) have Agile project roles. The Agile programme roles are in the Programme Board (Agile Programme Manager, Programme Director, Programme Product Owner, Technical Architect) and Change Implementation workstream (Business Change Manager).

Programme Director

The Programme Director is a senior manager responsible for the overall success of the programme. He/she is the final point of responsibility at the programme level.

The Programme Director is the key manager in ensuring the programme remains aligned to corporate strategy.

Typically the Programme Director is the business sponsor for subordinate projects. They might also be the Programme Product Owner and could be the Product Owner for the Technical workstreams.

MSP actually expects a Senior Responsible Owner (SRO) at the head of a programme although it accepts that some organisations have a Programme Director instead.

Programme Product Owner

The Programme Product Owner is responsible for the entire product being delivered by the programme team. Normally the Programme Product Owner is a different role to the Programme Director but the two roles can be held by the same person. As the size of the programme grows the Programme Director will definitely have to delegate increasing amounts of product responsibility to other people. At some point the two roles split.

MSP doesn’t have the concept of a Programme Product Owner as many programmes are not about building something (although our interest is software development).

Agile Programme Manager

A Programme Manager is responsible for the programme from programme setup (including governance), through the delivery of the capabilities and benefit realisation, to programme closure. A Programme Manager has to do all the normal project tasks (Planning, Monitoring and Control, Change Management, Risk Management) but at the programme level.

In addition the Programme manager must shape the programme team including subordinate projects. They need to form the various teams, manage the interdependencies beween them and ensure the projects deliver as tasked.

Technical Architect

The senior technical person on the programme is usually a Technical Architect. They have overall responsibility for technical quality of the product including how it is structured, organised, and implemented.

Business Change Manager

The Business Change Manager (BCM) is an MSP role. It doesn’t appear in a project (Agile or not). That is because a programme is about business change and a project is about delivery of outputs.

The BCM’s role is to manage the organisation through transformation. The programme might create capability but it is up to the BCM to ensure the organisation adopts the products and whether the organisation achieves the desired benefits.

The nature of the role, including close stakeholder contact, means a BCM is usually from the business. The role can be full or part time, long term or short and are often local champions recruited to support roll out in their area.