Too often, organizations try to rush agile change. It is usually because they want to see the business benefits of agile as quickly as possible. Unfortunately, change doesn’t work like that. Much like growing experience, you can’t rush it. In fact, trying to change too fast often results in no change at all.
Here are some examples of trying to rush change.
Asking everyone to change at the same time is a bad idea. Whether it’s a change in process or tools, some people are more adaptive than others. New concepts and tooling also often need to be fine-tuned before they work properly within a new organization.
The best way to make change is by running experiments, also known as pilots. Try out something new with a particular team first to work out the kinks. Ideally, this team is staffed with experienced personnel and those more adaptive than others to change. This will help the change be implemented successfully. Once this team has adopted a change, they can help other teams by providing demonstrations of the new capability, examples for how to use it successfully, training to those less adaptable, and acting as mentors or coaches for those that need more help.
Many organizations are intent on accelerating their software delivery process to the point where they can continuously deploy code into production as each change is made. While delivery speed provides benefits such as getting value to customers quicker and being able to rapidly correct critical production issues, no value is created if what is deployed doesn’t work. Continuous deployment without effective testing just gives you continuous bugs.
Make sure your testing practices are effective before moving to continuous deployment. Work to define quality gates at each stage of your delivery process to stop bad software from moving toward production.
When seeking to spread agile across a large enterprise, it is necessary to align teams so that products and product lines can be released in an orchestrated manner. However, focusing on how to scale agile before your teams have learned how to deliver working code on a regular basis is a waste of effort.
Instead, work on defining better definitions of done and the agile engineering practices necessary to design, build, and test software successfully each sprint. Only after you’ve gotten your teams to the point where they are repeatedly delivering business value every sprint should you worry about scaling.
In the DevOps world, automated testing is king. However, that doesn’t mean that all of your testing can—or should—be automated. Unfortunately, many organizations drive toward full test automation as quickly as possible and, in the meantime, probably reduce their quality.
Take time to design the tests you feel are necessary for meeting your quality objectives, and then look closely at which of these tests increase business value through automation. Over time you will determine the amount of automation that is optimal for increasing speed without decreasing quality.
