When it comes to the topic of Agile development methodology, I bet you fit into one of these categories: (a) you’ve tried Agile and failed (b) a leader in your organization is mandating Agile, or (c) you’re just a geek and interested in it.
But why would you consider a new development methodology? The old ones have worked just fine, right? Agile development is likely being considered because it’s the new, hot thing for more rapid and iterative digital projects. And it’s touted as being able to save you time and money.
So, if this methodology provides for quick, flexible, and responsive software development – why haven’t you at least implemented it for projects where those tenets are a requirement?
Why Not Agile?
I can hear you out there – “We’ve been successful for decades and this fad too shall pass. We make plenty of money and have for decades. We. Don’t. Need. To. Change.”
There are plenty of excuses, or reasons, why Agile development practices might not be right for you. Here are the top three:
1) Agile Doesn’t Work in Highly Regulated Environments.
If you’re in a highly regulated, long standing company that’s been delivering services for decades, you likely think these practices won’t work in your environment. The regulators require too much certainty and predictability and Agile development doesn’t provide that.
My response: Bull! Highly regulated companies can use Agile methodologies to more completely meet the needs of an ever growing myriad of regulators. By breaking projects (and systems) into iterative chunks and features, these organizations are able to meet changing regulatory needs in a shorter time frame. By moving development, and the associated releases, from annual or quarterly events to more real time, the organization reduces overall system risk while increasing speed to delivery. This shortens compliance cycles and allows the organization to more quickly align with the necessary internal and external control needs.
2) Agile’s Lack of Documentation is a Show-Stopper.
Many people think Agile means no documentation and that regulators, auditors, and den mothers would never sign off on doing projects this way.
My response: That’s just flat out wrong. Lean and Agile methodologies call for weeding out unnecessary (I’ll repeat this loudly for those that missed the point) UNNECESSARY steps, be it documentation or otherwise. It’s actually possible (and not too onerous) to provide all necessary documentation, checklists, and notes from your mother as part of the Agile process while still allowing teams to complete work in shorter, iterative, and highly flexible project teams.
3) We Tried Before and Failed.
Many people say, “We tried this before with [fill in the blank] methodologies and they don’t work here.”
My response: Let me guess. An executive said you should implement X software methodology and expected everyone to run off and “just do it.” Your first project tanked and you thought, “See! This is why we always did things this way.”
Without knowing you or your organization – I have a few guesses as to why it failed:
-
- Did you think about why you were doing it and thoughtfully pick the right pilot initiative?
- Did you send everyone to training and hire coaches? (Coaching and training are great tools but won’t drive change alone.)
- Did you take a look at the broader organization and set up the initiatives and your people for success?
In order for a new method or practice to be successful, the organization has to give it a real chance. Providing training and coaching is a good start but isn’t enough by itself. The company needs to create a “cultural bubble” around the team and the initiative. The bubble creates a safe environment for the team to organize and try new methods or processes without being encumbered by legacy processes, reviews, and cultural norms. Often change (be it Agile or otherwise) fails because organizations don’t give it the time and space it needs to get started and evolve.
So, back to my original question—why not Agile? It’s not a cure all. But if you need rapid development in a changing environment and want to test applications and ideas quickly and often (“fail fast”), I would recommend trying it (again). It can make your development teams more nimble and innovative. Ultimately, you can respond to regulatory change more quickly, better adapt to changing customer demographics, and cut operational costs by doing these things.