TQ
dev.com
Blog about software development
22 Aug 2016 - by 'Maurits van der Schee'
Agile development is all about reducing "waste" (bureaucracy) and optimizing the percentage of development effort in the process. This makes sense, even for larger organizations to improve the effectiveness of their software development. Startups on the other hand need even less process as value creation is really all that matters. For these organizations Extreme Agile (or 'Developer Anarchy' as Fred George calls it) may be a good fit.
Larger organizations want to have process that ensures consistent quality and reduces risk of failure. Certifications like ISO 9001 and 27001 require that you have written down your process and that you follow this closely. They may not be helped with an Agile process that steers towards a flatter, more efficient organization where roles are combined to ensure minimal procedural overhead (hand-overs).
The higher the stakes, the more resistance you find against introducing Agile. This is understandable as you are breaking down the procedural safe guards that the organization has embraced to ensure quality. The choice for Agile to reduce development costs is on the other hand easily made when the current expensive quality assurance process is failing to deliver the promised quality or has led to an unacceptable time-to-market.
Can you have an equally good and described QA process while doing Agile? No, not unless you are doing test and delivery automation. Continuous Integration (CI) and Continuous Delivery (CD) are a requirement to achieve the best of both worlds. By writing functional tests for your functionality and automating regression tests and deployment you can have a well-described process that ensures high quality, without the red tape, simply because everybody writes code.
Automation allows for a shortened time-to-fix when problems occur. This should be taken into account as the problem impact can be calculated as the frequency (how often it occurs) times the damage (how much it costs when it is broken) times the time-to-fix (how long it is broken). This reduced time-to-fix is the factor that can allow you to win the QA comparison when switching to Agile (but only when you do CI/CD).
Fred George is an inspiring speaker about all things Agile. Here are some of his best videos from the GOTO conferences:
I could repeat his points, but why don't you just click the links above and hear the master speak? Enjoy!
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.
Subscribe