I often witness development teams arguing about what it means to “do” agile. These arguments between development team members often go something like this:
John: Everyone else on the team is working on a task, but there aren’t any tasks left on the iteration backlog. I need more things to work on – can I start working ahead on a story for the next iteration?
Bill: We’re not done with two out of the four stories we forecasted for this iteration. We should focus on getting those stories done before starting on something new.
John: That’s not agile! I won’t be fully utilized!
John and Bill usually continue to argue about how they should do agile without ever getting back to the basics and asking why they wanted to “do” agile in the first place. This leads to the developers debating for much longer than they should, and they rarely come to a good conclusion.
Agility is a state of being. The Merriam-Webster dictionary describes agile as being “marked by ready ability to move with quick easy grace.” In software development, being agile means being able to quickly and gracefully respond to varying business conditions. This is what the Agile Manifesto authors had in mind when they wrote the manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The authors of the manifesto listed those values because they used them to become agile. Adopting those values will help teams become agile, but without focusing on being agile, teams will miss the mark.
As an example, a lot of teams have incorrectly interpreted “working software over comprehensive documentation” as meaning that they do not need to write any documentation because they think it is always more valuable to have working software. This might help teams produce new features very quickly, but when those features need to be updated six months later, it will take developers a significant amount of time to figure out what in the world they were thinking when they wrote that code only six months ago. They will have forgotten a lot of the nuances of the code, and they will almost certainly update a piece of old code that will lead to a bug. This leads to development teams being slower when they respond to change because it will take them longer to become familiar with the codebase, and it will make teams less graceful because they will have more bugs when updating undocumented features.
The problem with John and Bill’s argument is that they focused on doing agile without taking a step back and asking what choice makes them more agile. Bill was correct in saying that they should not start working on another story until the stories they forecasted for the current iteration are done, but he will never be able to effectively change John’s mind without focusing on being agile. There are multiple reasons for finishing forecasted work over starting new stories which I will blog about later, but the most important reason is that the measure of progress on an agile team is working software because it helps a team be agile, so it would be more valuable for John to pair with other team members and focus on getting all of the stories for the current iteration done before the team considers starting on another story.
So what do people mean when they say they are “doing” agile? From what I have witnessed, it usually means they have implemented some of the practices that agile ‘methodologies’ recommend, like daily standups, iterations, and abandoning documentation (okay… I know good agile practitioners don’t recommend that last one, but that is often what teams end up doing). Unfortunately, when I hear people say they are doing agile, it usually means that they are focusing on the practices of a specific agile method more than being agile.
How do you be agile instead of doing it? Embrace the values and principles behind the Agile movement while keeping the end goal in mind: agility. Reading the Agile Manifesto and agile principles is a good place to start, but I recommend reading a book that digs into the values and principles of agile like Learning Agile.
So while there is value in “doing” agile by implementing practices, being agile is more valuable.