Agile is not about iterative development. It’s not about cross-functional teams, user research, test driven development. It’s not a bunch of practices on a checklist. Agility won’t be found in stand-up meetings or burn charts, and it won’t be found in open workspaces – or in cubicles. It’s not written on task cards or hidden in your backlog. The key to successfully applying Agile is not any of those things.
Rather, Agile is an attitude. It is about supporting your people, seeking out ways to improve, and looking critically at your both your failures and your successes.
If you are working at a company that tried Agile and it didn’t work, most likely it’s not because you forgot to do one of the practices in the Extreme Programming catalog, or because you didn’t hire a certified ScrumMaster – and it isn’t because you did hire one, either. Agile has a hard time working if your company does not have a healthy attitude supported by culture, transparency, and honesty.
One of the things so many people like about the idea of “waterfall” is that it supports signoffs. Armored by signatures from upper management, the boss can strut around the office with confidence that any failures will be someone else’s fault. Such a culture won’t ever produce good software: if everyone involved is too busy shifting blame, then efforts to introduce new practices, measurements, tools, or technologies will be stonewalled at every turn.
Even if you can look at your experiences and measure your teams successes and failures, you can run into trouble. You can’t grow without this introspection, but at the same time, such measurement is a double edged sword, as demonstrated by Dilbert. Joel Spolsky gives us “more serious look at this same concept.”:http://www.joelonsoftware.com/articles/fog0000000070.html
It’s absolutely critical to successful operation that you can measure things and improve, but if your culture, management practices, and incentives are such that people will resent or fear new metrics then you are bound to fail. Agile both depends on and can help provide a significant level of transparency. If this visibility threatens your people, only two results are possible: Either you’ll measure everything and read all lies because everyone is afraid to be honest, or you’ll anger your team and they’ll work against you.
If your team has moved beyond scapegoating and your team is eager to measure their successes and failures then mature software development practices can succeed. Only then will they be successful, and not one minute beforehand. It is easy to see why this is true: Software development is hard. It takes time to learn to write code and to manage projects.
Here are a few examples:
* Learning how to do TDD effectively and efficiently is hard. Experimenting with mock object tools and test frameworks takes time, and if your company won’t support this growth, they are shooting themselves in the foot. Test automation is incredibly valuable – but it takes time and effort to learn to use the necessary tools effectively.
* Effective estimation is hard. It takes time to learn to estimate and you must be able to compare your costs to your original estimates if you expect to improve. This can never happen with a culture that will penalize you for missing your milestones.
* The industry changes faster than any human can keep up with. If your company won’t at least support learning and keeping up by purchasing books and sponsoring conference trips, they will be forever constrained to use obsolete technologies poorly.
* Tools are expensive. If you can’t measure improvement, estimate ROI, and purchase the right IDEs, hardware, and facilities to do development well, you will be constrained to do it poorly.
If you no longer look for reasons to fire people, if you measure your successes and failures to inform your improvements, if you help nurture your developers, designers, and managers and accept that they don’t know everything, if you can discuss your mistakes and have whole-team buy-in to fix them – if all those things are true, odds are you’re doing Agile already. If you’re there and you’re not Agile yet – you’re ready for it.
For everyone else, I encourage you to work on improving your company’s dysfunctional culture. If you don’t, no capital-M Methodology is going to save you.