Even today, a whopping 15 years after the Manifesto of Agile Software Development was written, agile development remains shielded in confusion – particularly, by the question of who exactly is driving the ship?
In this article, we cover where project management (PM) fits into the agile process, and how this implicates change requests.
Wait – where’s the PM?
With agile development, the role of the PM is diffused among the team.
Traditional development projects put the project manager at the hub of the wheel, with each different stakeholder, team, or project element sitting on the rim around them.
But agile is different.
Instead of an all-seeing project manager, most agile development projects will have a scrum master.
This fulfils many of the jobs that the project manager would do.
The difference is that, instead of running the whole project, including:
- stakeholder wrangling and management
- procurement
- team organization
- project tracking
- budget tracking
- and change requests,
the scrum master is instead concerned with getting the best from the team.
For example, a scrum master might facilitate meetings, drive to the project milestones, and make sure that the team can work, keeping other things off their plates.
However, the scrum master is not responsible for the overall project delivery.
For example, there might be a question of time/quality trade off with an aspect of development. Normally, it would be the project manager who makes that call. However, a scrum master would leave that decision up to the relevant team.
The result is that the best qualified decision maker is the one who ends up making decisions, creating better results over time.
How agile handles change requests
Which, of course, brings us to change requests.
If there’s no PM, who do stakeholders get in touch with when the scope of the project changes?
The answer is that the agile process itself will absorb changes.
The objective of agile development is to present stakeholders and relevant contacts working software at every step of the process. This means that the team can elicit feedback from stakeholders as the project unfolds, and ensure that what’s produced fits the requirements.
Because of this iterative, adaptive process, change happens naturally.
For example, imagine a UX designer and a developer were working on changing the purchase flow for an airline website. You might develop a shell site and present it to stakeholders and to end users.
Now, imagine that people identified that the button to get from browsing to buying was hard to find. And imagine that the stakeholders were unhappy with how many steps it took.
Out of that feedback, the team has two change requests:
- Move the location of the ‘buy’ call to action
- Restructure the purchase flow so it’s spread across fewer steps
Because it’s so early in the process, these changes are easily dealt with before the next sprint and presentation to the client and end users.
Therefore, the changes happen naturally, without the need for a change request.
This idea of natural change, avoiding a formal change request and skirting the need for a formalized change management process beyond documentation, is the driving force of agile development.
The benefits are clear – ongoing change can occur without slowing the pace of development.
And because the relevant stakeholders and end users are consulted throughout the process, the final product more closely matches the needs of the organization – which is better for everyone.
Conclusion
How to manage change and adapt to new ideas is always a challenge for a project. Normally, it’s the project manager who gets squeezed, making decisions on what change is included and thus being saddled with the consequences of those changes.
But with agile development and its absorbed project management style, there is a quick and constant approach to change requests, and as a result, no saddling. The team works to deliver the best possible deliverable for the organization and the end user, and adapts to change as new and brilliant ideas come to light.
