Agile Project Management Myth Busting

Myths About Agile Project Management

There are a lot of preconceptions as to what an Agile project is or is not. So let’s explore some of the myths that surround the concept of Agile projects.

Agile Makes Teams Go Faster And Helps Deliver To Market Sooner

Agile encourages teams to work in smaller increments. As progress is made through the project, teams may realize that not all planned features are actually necessary. In addition, project teams that are new to Agile may in fact see an initial drop in their speed and productivity.

Agile And Scrum Are The Same Thing

Agile is an overarching approach to development and project delivery. Scrum on the other hand is one specific framework that implements the ideas in the Agile Manifesto. The scrum framework is well-suited to teams new to an Agile approach. It is also well-suited to high risk projects where teams can change direction quickly.

Agile Processes Are Lightweight

Each Agile approach is only lightweight in certain facets of its implementation. Scrum lends itself to being lightweight in documentation and artifacts. But Scrum is very heavy in ceremony comparatively, meaning it has a large number of meetings.

Agile Is Only For IT Projects

Agile began life as an approach to software development, and the principle remains strongly associated with the tech sector in the minds of many. But Agile has come a long way, and the values and principles that underpin it are now being applied successfully in many business environments. From marketing teams to organizational transformation, and even senior leadership looking to responsively manage their teams. If you have a project with a high degree of uniqueness and complexity it is well suited to Agile.

Agile Has No Governance

Because Agile projects tend to be of a fast-paced nature, there is a perception that no governance is involved at all. For some organizations coming from Waterfall, the absence of familiar governance structures like stage-gates, committee meetings or forums can feel like a lack of governance.

However, Agile methodologies do have similar governance structures in place, but simply approach them differently. Instead of having committee meetings, Agile teams might get all those involved in those traditional meetings to be involved in the sprint planning and sprint review meetings to highlight what is going to be worked on, and then what was actually delivered. If any decisions or questions need to be raised or points require clarification, then they can be done then and there, without the need for creating additional material or additional meetings for team members.

Agile typically decentralizes some aspects of governance, ensuring decisions are made by those with the best information. But the Agile principle of transparency of information ensures that stakeholders and sponsors can exercise oversight to whatever degree they want, whenever they wish to do so.

There Is No Documentation In Agile

Documentation within Agile is not just more responsive, but more objective. Measures like Sprint Cadence, Sprint Velocity and Sprint Burndown are underpinned by real and tangible data and complemented by value drivers derived directly from end user validation and engagement. Additionally, feedback ensures the team understands whether what they are delivering is adding value, is the right thing or is a worthwhile spend of money and time on. Real-time, in-situ documentation is arguably one of Agiles greatest strengths.

Agile Doesn’t Do Planning

While Agile projects may be somewhat less pre-determined than Waterfall projects, the total amount of time spent on planning is similar. The only difference is that planning is done more frequently and focuses on smaller horizons. If your project is operating in sprints, at the beginning of each time boxed period, there is a planning session involving the whole team in order to understand priorities for that upcoming sprint, and ensuring what they want to get delivered, can actually be delivered by the team on the ground.

In addition to this, teams will usually go through backlog refinement or backlog grooming sessions. This is planning in advance of the planning, but it is used to ensure that what is in the backlog or in scope for subsequent sprints is still relevant, makes sense to those involved, and has been prioritised to ensure the items at the top of the backlog are most important to achieve the product vision.

In Summary

I hope this has helped clear up some of the misconceptions around the Agile methodology. Every Agile project is different. And the Agile methodologies are more robust and flexible than the traditional waterfall approach.

Myths and criticisms about Agile software development are abundant. Agile is not a fad. Regardless of your proficiency with Agile, it is important to be mindful of these common myths and criticisms because Agile requires organizational buy-in. You can be successful with Agile and realize the business benefits of Agile, such as faster time-to-market, higher quality software, lower costs and a greater ability to adapt to changing priorities.