At face-value, agile methodologies are one of the best and most efficient ways to approach software development. When done correctly it delivers quicker results, the client is more involved in the development process, and the end product is of higher quality and more in line with market trends.
But models aren’t foolproof, and agile approaches are not the exception. Iterative development comes with its own share of challenges, and both novice and veteran teams can be faced with situations that require them to adapt and to think outside the box.
What is Agile?
Agile is a set of practices, beliefs, and principles in software development that aim for early delivery, continuous development, flexibility, adaptation, cross-functional teams, self-organizing, and working hand-in-hand with the product owner.
Agile was born out of the frustration of software developers who came to see the traditional approach to project management as a straightjacket. Waterfall methods were seen as document-driven, heavyweight, linear, rigid, and crippling in many ways.
The alternative was an almost zen-like approach to software development that can be summarized in its four core values:
- Individuals and interactions over processes and tools: The development team and the product owner come first, software development is a human endeavor that benefits from technology, not the other way around.
- Working software over comprehensive documentation: The end goal of software development is to create intuitive software, so that should be at the forefront of the project. Documentation shouldn’t be a dictionary for understanding the software.
- Customer collaboration over contract negotiation: The customer is an active part of the development process, the project owner is constantly giving feedback, testing the product, creating new goals, and giving input.
- Responding to change over following a plan: Making software isn’t a straight line, things can change dramatically from one moment to another, and the development team has to adapt, which may mean going back to previous stages of the project to change something or redo it completely.
Within Agile there are dozens of frameworks, each with its own set of tools and practices. A team working with Scrum will have a very different approach to reaching their goal than a team using Kanban or Crystal Clear, but they all share the same underlying philosophy.
Does it work? Yes, when done correctly Agile frameworks have shown to increase productivity in software development, as well as improving morale and satisfaction in software development teams.
So, what are the challenges of agile development?
Getting people on board
Clients and developers who are used to waterfall methodologies often see agile as confusing and chaotic, with some even going as far as to think that the team is making it up as they go. One of the most common criticisms raised against Agile frameworks is that they lack a solid methodology.
In truth, it’s actually quite the opposite. What Agile proponents aim to achieve is to create a methodology that meets the demands of software development. In fact, Agile frameworks can be quite strict, with clearly delineated roles and structures – it’s just that those structures have been built with flexibility in mind.
The best way to approach this challenge is to share success stories with apprehensive team members. People who have worked with agile in the past can explain the iterative process to their teams. There are literally millions of testimonies online of people who have successfully applied agile project management in their businesses.
Feature creep
When I first learned about agile, my coach used to call feature creep the “and then syndrome.” To understand that, picture a kid with an overactive imagination that just ate a box of chocolates. If we ask that kid to tell us a story, it will start small, and exponentially grow as they get excited, just adding more and more elements to the story “and then they beat the enemy army and then the dragons attacked…”
Most projects start small, but as the client tests the early builds and gives feedback they start thinking about how to improve the project. This is how the project grows in scope, and more functionalities are added on top of the original scope.
Developers will accommodate and adapt as the project scales, but, if they are not careful, they can end up with a project that requires more personal, more time, or more investment. To compensate software developers may leave things for later, accumulating technical debt. And if that gets out of control, they end up with a disaster in their hands.
So, what’s the solution? Scaling is a great thing, and adding features as you go is one of the core strengths of Agile frameworks. The trick here is to have a very clear understanding of the team resources, and not to overpromise.
As for technical debt, using management software so that both the team and the client can keep track of it will help everyone understand where the project is at. And maybe that cool new feature can wait until the debt is paid in full.
Lack of documentation
Yes, one of the core strengths of Agile frameworks, not being anchored by documentation, can also be a challenge. Many critics falsely call out Agile for lacking a blueprint that you can go to when things go off track.
In truth, Agile doesn’t reject documentation, it just places building the software at the front and center of the project. Waterfalls methodologies tend to cover their bases by overproducing documentation, which in turn leads to a whole different problem: having too much documentation.
For Agile, documentation shouldn’t be too long nor too short, just enough. But that comes with its own set of challenges, specifically, what is enough? And for whom?
Each person involved in the project needs to have different information. What an end-user needs is very different from what an IT expert needs. Thus, being mindful about covering all the bases without overwhelming with information is an art unto itself.
On the other hand, the fact that very little documentation is done in the first few stages of the project means that a newcomer may find themselves lost when they are added to the team.
The first problem is easily solved with practice and feedback. Developers get better at writing documentation as they go along, and the experience allows them to learn to anticipate what the client will need in the future. On the other hand, showing early drafts and asking for feedback helps the person in charge of documentation assess what needs to be added or removed.
For the second problem, having a coach from the team take newcomers under their wing as they join the projects will help the new developer acclimate better. Also, they will have a person to go to as they get used to the project.
Should you go with Agile?
As I’ve said before, there is a ton of evidence that supports the claims of Agile’s proponents, and while there are challenges to face, Agile experts have been engineering solutions for over 20 years.
Agile teams perform better, feel better and create better products. So, there are no excuses for you to at least try it and see how it works for you.
