A couple of decades ago, agile project management became the go-to approach for teams everywhere. It all kicked off with the Agile Manifesto, published in 2001 by a group of software developers who were frustrated with traditional project management methods. They wanted something more flexible and responsive to change—something that could keep up with the fast-paced nature of software development. And they did succeed! They revolutionized the way teams deliver value, fostering collaboration, flexibility, and continuous improvement.
However, if you talk about agile now, you can hear different opinions. Here are a few collected by Medium:
“Agile? It seems more headless than streamlined.”
“All this talk of flexibility and quick adaptation to changes just seems like an excuse for not planning properly.”
“Scrum? Kanban? They’re just labels, ways to sell consulting and training without guaranteeing tangible results.”
So, what’s gone wrong with Agile, which, on the one hand, allows teams to respond to change, such as a new feature request or a shift in market demand, and helps teams to deliver working products more frequently, and, on the other, is said to overrely on team dynamics and provoke scope creep?
The proponents of the approach claim that the incredible 84% Agile failure rate is caused by the misunderstanding and misinterpretation of the concept.
We asked Mike Cohn, a well-respected figure in the Agile community and the author of several influential books on Agile and Scrum, including “Succeeding with Agile,” who has spent decades helping organizations adopt Agile practices and has firsthand experience with both its triumphs and challenges, to shed some light on the common Agile misconceptions and help us have them debunked.
Mastering Agile With Mike Cohn
What are the most common misconceptions about agile project management that can lead to pitfalls?
Mike Cohn:
One common misconception is that there is no role for managers in agile. This comes from the idea of a team being self-organizing or self-managing. Some managers learn this and think their job is just to buy the pizza and get out of the way. That’s not the case. Managers can still play a very important role in agile.
Another misconception is that agile is something only the team does. This universally results in failed agile improvement efforts because the agile mindset needs to extend beyond the development team.
What specific challenges arise when transitioning from a traditional project management approach to agile?
Mike Cohn:
(Somewhat answered with #1)
One challenge is that organizations often try to be “just a little agile.” They want to keep most of what they’re doing and sprinkle in some agility.
There are some agile practices you can add a little of and be better off. Doing more test automation, for example, is something that can be added incrementally.
But other aspects of agility, such as self-managing, cross-functional, empowered teams, are all or nothing. A manager can’t tell a team they’re self-managing until they do something the manager disagrees with.
So while it’s ok to dip a toe into an agile transition, there are some parts of agile that need to be all or nothing.
In what ways can team dynamics affect the success of an agile project?
Mike Cohn:
Team dynamics affect agile projects just as they affect traditionally managed projects. However, because of the faster pace and increased collaboration on agile projects, problems are revealed more quickly.
Exposing problems sooner is a good thing, as it lets an astute manager or agile coach address the problems rather than letting them fester.
How can scope creep occur in agile projects, and what strategies can mitigate this risk?
Mike Cohn:
Scope creep occurs on any project, agile or not. But the short iterations and desire for feedback in agile can make it worse. If we ask our customers and users every few weeks what they think of the new functionality and what ideas they inspire, scope is prone to increase.
However, this may not be a bad thing. The term “scope creep” definitely implies it’s bad. But if we view it instead as progressively understanding users’ needs and incrementally building the most valuable product, new requirements can be viewed in a different light.
How can teams balance flexibility with the need for structure in agile projects?
Mike Cohn:
Teams absolutely need to balance structure and flexibility. In agile, this can be done by keeping a team’s options open as long as possible in as many ways as possible.
Certain architectural decisions need to be made early, so go ahead and make them. But, when possible, avoid architecting or designing up front a part of the system that can be left vague or less precise for a while.
This is known as *progressive refinement*. It can be applied to all aspects of a project. A team starts with a loose understanding of what users need. They then progressively refine that understanding by developing, showing, and getting feedback.
A team can progressively refine a system’s architecture or design. Design what’s needed to start, see how it works, and then move onto the next piece. The design or architecture of a system emerges by the act of building the product but is always guided by the intent of the senior technical people.
What are some signs that an agile project is veering off track, and how can teams address these issues?
Mike Cohn:
An iteration or sprint review can reveal if a project is veering off track. There’s the obvious and extreme case of a team being told that. More subtly, however, we can tell if a project is in trouble by considering attendance and engagement in these reviews.
If stakeholders and users are excited about what is being built, they willingly participate in reviews and offer suggestions. A poorly attended sprint review or one with no enthusiasm is often a first sign that the project may not deliver the outcomes expected.
Doing Agile Right
Anyway, a core principle of an agile mindset is recognizing that some elements are beyond our control and inherently unpredictable. And in the pursuit of excellence, we tend to introduce more and more new methods designed to ‘enhance’ our processes. These involve refining estimation techniques, obsessively reviewing story points, endlessly tweaking metrics, or even overhauling strategies and development principles.
But here’s a thought: instead of continuously searching for improvements through new methods, what if we took a moment to evaluate our current practices? Are we genuinely adhering to Agile principles, or are we simply going through the motions?
To assist you in this evaluation, we’ve created an engaging Agile project management quiz! It’s a quick and fun way to assess whether your approach aligns with Agile practices or if there are areas that might need adjustment.
And while we’re on the topic of tools that can enhance your Agile journey, have you checked out actiTIME? It’s an excellent solution that aids teams in managing projects more effectively. With features designed for better time tracking and project oversight, actiTIME allows you to concentrate on delivering value rather than getting bogged down in metrics.
- Enjoy flexibility. Log hours, gather data, and optimize routine tasks to suit your needs. Here are some key advantages it offers:
- Introduce automation. Use automatic timers and simplify routine tasks such as billing, invoicing, and approving time-off requests.
- Leverage integrations. Integrate with popular tools via Zapier or log hours directly from various online platforms using the Chrome extension.
- Track from anywhere. Use the mobile app to log time online and offline.
- Use the Kanban board. Manage workloads using a customizable Kanban board, allowing you to set your own task progress statuses and easily see which tasks are in progress or completed daily.
Remember, it’s not always about adopting the latest trends but rather about understanding and improving your existing practices!
