I am a huge fan of Agile. Back in the 1980s, when I was a mad German scientist building products and managing development efforts, the Agile concept didn’t yet exist. I used to call the process “development by prototype” or “iterative development.”
I listened to the user community, went back to my cave and cobbled something together that fulfilled at least 60 to 80 percent of the users’ needs. Then I sat down with the users and refined the product until it matched their needs exactly.
Here at CA Technologies, I followed the same process when developing a reporting system for CA Services that has been used for close to 10 years. Colleagues use my reporting system not because they have to, but because they want to.
Now Agile is sweeping the IT industry. That’s very good for end users and project teams. We just need to make sure we understand seven key facts about Agile so that we get maximum benefits from it:
- Agile is not a methodology: It’s a mindset. Several methodologies are based on the Agile manifesto; two of the most widely known are Scrum and SAFe.
- Agile methodologies are not designed for projects: One key part of the definition of a project is that it has defined start and end dates. Agile methodologies work best when you establish a cadence of iterations released over a longer period of time, as with long-term application development. However, your typical project is completed long before you have a chance to settle into a cadence.
- A project isn’t Agile just because you use Agile terminology: I’ve seen projects advertised as Agile when in reality they simply divide the usual waterfall steps into multiple iterations. The projects are still defined in terms of requirements, design, configuration, testing and production release—and that isn’t Agile. Agile produces completed products at each iteration, not just at the very end. And in Agile, you build the requirements and design as you go along.
- The cost factor: The Agile process is less prone to errors and rework because stakeholders are continuously involved. Errors are caught much earlier, long before they result in extensive and expensive rework. However, Agile requires more time commitment from SMEs and stakeholders—not just the product owner. Everyone needs to review work and provide input and feedback during the whole process.
- Don’t force a project to be Agile just because it’s the “in” thing to do: No matter how hard you try, some projects simply can’t be fit into an Agile setup. (Think data center moves and replacing an existing product with another.) If your project must follow a rigid sequence of requirements, design, etc., it isn’t suitable for Agile.
- Some projects lend themselves to an Agile/waterfall hybrid: The key is to divide the project into two parts—one that’s waterfall and another that’s Agile. This would work well when you use waterfall to establish the infrastructure for deploying a new solution, then turn to Agile for the configurations. This approach ensures a solid base design while giving users the input and feedback mechanisms to make sure the solution has the look and feel they require.
- All projects can benefit from an Agile mindset: Even though all of the above points are truisms, just about every project can benefit from Agile thinking. I will write more about that in a future blog.
I hope you and your organization take full advantage of what Agile has to offer. Just be sure you don’t go through the motions simply to satisfy management. To meet with real success, embrace the Agile mindset.
I’d love to hear your thoughts and experiences with Agile and hybrid approaches, so please comment below.