Overcoming Practical Challenges in Agile Projects
Agile is all the rage, and many organizations are tempted to
implement Agile in their projects without fully understanding what types of
projects work best, what the Agile methodology can support, and how to ensure
There are many resources that detail Agile’s benefits, but
very few provide information on the practical challenges that teams face, or
why Agile projects sometimes fail to deliver the quality required.
In this post, I will share some lessons from one project
where Agile failed completely and required a switch back to the Waterfall model
to deliver the project.
The practical challenges we faced were:
In Agile, the team is encouraged to create lightweight documents, such as requirements, design, and test plan. In our case, the documents were created in a major rush in order to accommodate a 2-week sprint. Unfortunately, some critical information was left out, which led to incorrect delivery.
Complete project tracking was very difficult since the team was working on multiple small tasks during every sprint. In smaller projects, if a task slips, it simply can be moved to the next sprint. However, these delays can have a ripple effect as they affect dependencies and new tasks planned for future sprints that suddenly need to be tracked separately.
For a large, complex project with multiple sprints and many small tasks, tracking can quickly become very confusing and time-consuming, and the chances of missing important functionality increase dramatically.
Agile demands more time and energy from everyone, because developers, testers, business analysts and clients must constantly interact with each other. When projects are large and sprint durations are short, any employee taking time off creates a huge issue, as finding backup for their particular skillset can be very difficult.
In the absence of a clear end state, projects can become everlasting. In our case, the scope changed frequently and new or updated requirements were constantly being added to the planned sprints. As a result, the team was not able to take a clear stand for requirement freeze.
For some software deliverables, developers cannot quantify the full extent of required efforts in advance. This is especially true at the beginning of the development lifecycle for large products. Teams new to the Agile methodology fear these unknowns, which can create frustration, sloppy work, and poor decisions. In contrast, more regimented methodologies like Waterfall make it easier to quantify the effort, time, and cost of delivering the final product.
When a product’s design is fragmented, it gets passed down to the user journey, the project plan, and even the code itself. Large features must be broken into small pieces, but this process can be botched without a holistic view of the entire project. As work progresses, the resulting lack of cohesion results in disjointed, poorly-functioning software.
With short sprints, there is no time for teams to learn new skills or bring trained resources on-board. You must ensure that the right team with the right skills is in place from the beginning, or you may encounter major setbacks mid-way through a sprint.
Agile is not a
“one-size-fits-all” methodology. It is well suited to particular types of work,
namely smaller projects with well-defined scopes, clear goals and thorough
documentation. In our case, the problems
were recognized early enough to change course and successfully deliver the
My suggestion is to carefully evaluate whether your project
is a good candidate for Agile before jumping in. Don’t choose Agile simply because it’s the
flavor of the month — especially when you have time-tested, proven ways to
deliver successful projects like the Waterfall and “V” models at your disposal.