The Problem With Agile

In today’s world, everyone claims to be agile. Being agile is no longer just for tech and IT people. Many companies and teams proudly proclaim their agility. This bears the question of what exactly agile means and why I prefer to avoid this term.

The process of moving from initial business needs to delivered production software has always been a huge challenge in IT. Software projects are notorious for risks like delivery delays, exploding costs, misunderstood requirements and critical bugs. Due to the complex nature of software development, several processes, frameworks and methodologies have emerged over the years in order to get a handle on these typical problems.

Seasoned developers still remember some of the more classic and rigid development processes, based on ideas like the waterfall or V model. By now, most companies know about the weaknesses of these methodologies and lean towards agile practices like Scrum, Kanban or mixed forms. Agile processes address many problems from traditional, more rigid methodologies, mainly by being adaptable to changes (requirements, priorities, efforts etc.).

What is the problem with being agile? Agile has become an empty phrase, in my opinion. It does not tell me anything about how a company gets work done.

Sure, you could go one step further and tell me you are doing Scrum, Kanban or something else. While this is a bit more specific, it is still lacking meaningful information. Although much theory exists about these processes, their actual adoption and implementation differs a lot in practice. Hence, what one company refers to as their Scrum process, could be very different from the processes of another company that also claims to work with Scrum.

Here are some examples of what people could have in mind when talking about agile:

• Having small, self-organizing teams, each with its own responsibilities.
• Working iteratively in fixed time intervals, like sprints of X weeks.
• Estimating tasks with story points or T-shirt sizes instead of time units.
• Working in cross-functional teams that include stakeholders, product owners and scrum masters.
• Having regular meetings like standups, sprint plannings, backlog groomings or retrospectives.
• Practicing continuous integration and continuous delivery.
• Validating a business idea as fast as possible.
• Doing lots of pair programming.

In practice, none of these aspects is consistently present across companies who call themselves agile. Even if it was, there is still a lot of room for interpretation and customizing. And that is totally fine since teams should do what works best for them. Processes are just a means to an end.

Don’t get me wrong. Depending on context, I consider most of these practices useful when chosen deliberately. However, I would really like to see development processes being discussed on a deeper level with more specifics instead of just calling it agile and assuming common understanding.

#SoftwareEngineering #Agile #Scrum #Kanban #DevelopmentProcesses