Short development cycles mean more frequent releases. On the other side of that coin, short development cycles can mean sloppier releases too. Kyle Cochran writes an article for EnterpriseTech about the threat of quality deterioration in agile, and three ways to balance speed and quality.
Flip the Coin
When bad agile is occurring, teams skip critical steps like documentation and testing. The bugs that make it into the release frustrate users, reduce faith in the development team, and are costly to remove. To maintain an agile velocity that is both swift and consistent in quality, Cochran recommends three things:
- Iterative goal setting
- Software management for agile
About the first point, Cochran writes:
Iterative goal-setting is critical to avoid a mismatch between what developers think is great and what users and business people actually want — which can be a moving target. Daily standup meetings are a useful form for iterative goal discussions. Beyond simple status updates, these regular meetings allow product owners, developers, and testers to discuss the status of current goals and update plans with any new goals. Instead of creating the big hairy audacious goal at the beginning of a software development project… development teams should set small goals in much smaller timeframes. This approach helps companies do Agile with far less risk.
Collaboration in this case goes beyond the standard “Let’s work together! Hurray!” to mean that it should be used to circumvent the need for rework. When developers provide ready updates to each other and to stakeholders, and stakeholders provide swift feedback on working demos, there are no unpleasant surprises later. No surprises means the project does not have a chance to shift off-track of business strategy.
Lastly, a proliferation of software for managing agile projects means that teams have a lot of resources available to them to facilitate processes. Pick and choose the individual software that work for each occasion and build your own customized system of how to keep agile.
You can read the original article here: http://www.enterprisetech.com/2015/08/03/why-agile-is-fragile/