Let’s get this out of the way — agile software development is tough — hard, difficult, complex. (Pick your favorite adjective.)
This applies to Kanban, Scrum, Lean, XP or whatever agile approach you like. Is it tougher than those legacy waterfall approaches? Your guess is as good as mine. Agile development is simpler in some respects. For example, there is less rigor and tension at the beginning of the project. It is also more difficult in some respects. For example, good team communication is essential and we all know that communication issues are rampant in almost every organization.
So, if your organization is looking for a quick and simple fix for its software development problems, I have very bad news. There is none. Maybe you should consider a career change?
If changing careers is not an option, here are a few things to consider.
Agile development really works … if you let it.
Agile software development is not a one-size-fits-all solution. Consider that no two legacy waterfall implementations are identical. Every company adapts waterfall to it’s needs and culture. Sometimes the adaptations improve the process and sometimes they don’t. (It seems that more often than not the adaptations make waterfall worse.)
Similarly, no two agile implementations are identical either. That’s why we have Scrum-fall, water-Scrum-fall, Scrum-ban, Lean-ban — you get the idea. Everyone is trying to make agile development better — or so they believe.
Agile development approaches are meant to be tailored to the team and the environment as long as you preserve the core principles. Neither Kanban, Scrum, Lean, nor XP are prescriptive. While they all have fairly rigorous ideologies, none offer a precise formula for success — as in do this, don’t do that, and your software will be delivered on time, on budget and without major defects.
Here’s the core issue. In attempting to optimize Agile development for the organization, managers usually change the agile ideology to make it fit the company culture. That’s doing it wrong. In fact, the opposite is the optimal approach — change the culture to make it more agile.
Here’s an example. Let’s say the executive management team meets every Monday — a common scenario. And, on many Monday afternoons, the development team receives a new directive in the form of let’s stop doing that or let’s try this. Agile teams know that such ideas should be included in retrospectives and openly discussed. Applying the latest management hypothesis every Monday is not agile!
But changing culture is hard to do and that’s why many agile development implementations struggle.
Changing culture is the most difficult challenge.
What’s the solution? Start by implementing simple, agile concepts that fit the organization. Gently but firmly resist efforts to corrupt those concepts. Demonstrate success by keeping commitments reasonable and meeting them. Add more agile concepts to the process through retrospectives as the team matures. Review the Agile Manifesto regularly and adhere to it.
Agile development is tough. That’s why it works when we do it right! You can deliver better software in less time but it won’t happen overnight. Plan on using an agile approach for at least a year before drawing any conclusions.