By Elena Moldavskaya,
Ultimately, flexibility is at the basis of a truly Agile development methodology, though sometimes it may be difficult to implement. Going Agile doesn’t mean that the team refuses to stick to plans, deadlines, and budgets or something else. It means that the team can choose various ways to fulfill the objective.
Though flexibility sounds like a simple thing, the wrong understanding of this term may trigger various issues along the development process and the project workflow. A case like this occurred on one of my recent projects.
“You are agile, so be flexible”
The agile development team entered the project focused on the automation of the business process including three global stages – the contract agreement, project execution, and project maintenance. The client stakeholders wanted the process to be applicable to any type of the project carried out on various terms. Every stakeholder was responsible for the automation of a certain part of the process and had own requirements.
The project started smoothly. The stakeholders composed the requirements, the list was huge. After the backlog creation and tasks’ prioritization, we knew one release is not enough to fulfill all of that. However, we expected that.
The team launched the process activities and the development process started rolling.
The first pitfall was awaiting us after the first sprint demo. The team received a bunch of new requirements along with the recommendation to re-prioritize the backlog. “You are agile, so be flexible,” they were saying.
After the numerous attempts to re-prioritize the backlog, multiple explanatory meetings, and settling the final release plan, the project owner came up with a workable solution – a roadmap.
The Roadmap. How to use it efficiently.
In fact, the roadmap is considered as one of the essential artifacts in the product development. Although, development teams often neglected it, just as we did it. We’ll turn to the reasons later.
The roadmap is a detailed action plan describing how a product, project or solution will evolve over time. It helps a project manager to outline the list of features and the date of their release. It also allows stakeholders to keep track of the project milestones, assists with the coordination and communication.
In our case, creating the Roadmap helped the development team to approve the project backlog and release plans with the stakeholders. However, the success depended not only on the roadmap but also on sharing it with everyone involved in the project. Another important thing is that the team referred to every day, and, we reviewed it continuously.
A good product roadmap can improve the team’s efficiency immensely.
There are countless ways to create a roadmap and adapt it to the company product and services. Whatever approach the project owner chooses to the roadmap development, it is important to remember that is a hands-on tool for everyday use.
Despite all the apparent advantages the roadmap offers, numerous project managers do the same common mistakes, like:
- Refuse a roadmap.
- Create a roadmap only for presenting the project steps in the beginning.
- Change the roadmap too often or never do it.
- Consider the backlog as a roadmap.
The team in the case above did two of the four of these mistakes. The project manager created a static PowerPoint document providing an overview of the project steps and showed it to the company stakeholders only once. After that, the document was forgotten and left at the backyard, which obviously brought negative results.
The bottom line is that to be flexible the team does not necessarily need to use the latest project management inventions. Sometimes it is enough to have a detailed plan (a roadmap), update it on time and reconsider the approaches to completing the objectives. In some cases, simple though appropriate actions can significantly improve the end results.