Stop Doing Agile
I mentioned some time back that where I work we do Agile software development. This phrase, though accurate in some sense, shows a certain misunderstanding of what Agile is. Sure, you might ‘do’ Scrum, or ‘practice’ XP or Kanban or Lean or whatever, but you don’t ‘do’ Agile. You adopt these processes as a starting point so you can be Agile, and being Agile is worlds more important than doing Agile.
Doing Agile implies the mechanical application of some set of practices with no understanding of or commitment to the principles and values underlying them. Frequently this comes about because the decision to do Agile is made from the top down rather than the bottom up. If it isn’t fully embraced by the team with energy and commitment then they’re just going through the motions. Yes, they’re doing something and in some ways it might work, but they aren’t being Agile.
The issue can be further complicated when ‘doing’ some Agile process is considered more important than ‘being’ Agile. I refer to this as ‘process attachment’ and it likely happens with Scrum more often than with XP or the other Agile variants (because Scrum has a broader adoption base and more of a project management focus). This attachment manifests as a viewpoint or environment where all other methodologies are disallowed and deviation from the One True Process is frowned upon. What those fixated on the rigid adherence to the letter of a certain process miss is that this attachment to methodology is precisely one of the reasons the Agile movement started in the first place. That’s why point one of the manifesto is “Individuals and interactions over processes and tools”. Process attachment runs counter to the core of Agile because the process is of minimal concern compared to the project and the team.
By all means, start with Scrum or XP or Kanban or Lean, but after a number of iterations there should be some drift. This is because fully agile teams will find a steady-state in a zone with maximum productivity and minimum process. Agile incorporates a feedback loop every iteration for this very purpose. Retrospectives are the crucible of change for how you operate. Iterations aren’t just about the project, they also apply to refining and improving the process.
“Hold on, Ben,” those with process attachment might say. “We need to standardize on one process so we can move resources around and everyone is on the same page about how things work.” No, no, no. These resources you speak of are people, and people can’t be abstracted down to cogs in a development process machine. People bring too many variables and different strengths, weaknesses and personalities. Different teams of people have different dynamics which yield different optimal environments. Good teams can succeed with almost any process, but they can deliver better and faster when they define how they work. Process for the sake of process at that point is (at best) waste and (at worst) counter-productive.
Agile methodologies are useful tools, but Agile itself is more of a philosophy. Find energetic teams of people that are committed to the principles and values and let them decide how they work best. If the organization requires certain metrics or data points, let them know and they’ll deliver. Beyond that, leave them alone and let them build the solutions. At the end, it may not be exactly Scrum or XP that they’re doing but they will be as efficient and effective as possible. All because they’re being Agile, not doing Agile.