For Part 3 of our Being Agile in Practice series, we will be looking at delivering value often.
The ultimate goal of any development team, whether that’s a software team, product team or other, is to deliver value to their customers. With that in mind, what’s stopping so many teams from being able to do so?
We are sure that many of you have experienced or worked with teams on large projects that don’t “Go Live” until the end with catastrophic results. Some of the results usually manifest as bugs, time consuming workarounds, unhappy customers and end users, demotivated staff, reputational damage and impact on a company’s bottom line.
What’s Stopping You From Delivering Value?
The response that we see to this is that organisations move to make releases less frequent and with more thorough governance. This unintentionally has the inverse effect – it makes releases riskier and more error prone.
Some more potential negative consequences include:
- Larger releases introduce more risk through complexity
- More governance slows down our ability to respond to changes
- Governance is sometimes provided through a Change Approval Board (CAB) who are too far removed from the work
- Releases become something to be afraid of – teams do not have the opportunity to regularly practice the skills and tools required to make releases smoother
- Increases the feedback cycle, losing the ability to respond to changing market demands
Tips to Deliver More Often
Here are our practical agile coaching tips that we’ve used to help solve customer problems in the past and to enable their teams to deliver often:
Make Your Releases Smaller
Large releases are risky as we previously discussed. Smaller releases can be:
- Less risky
- Easier to manage
- Easier to communicate (if needed)
- Easier to debug (in the event of bugs)
- An opportunity for teams to practice, experiment and refine their release process
Invest in Automation
Automation will enable you to reduce risk, increase quality and speed up your deployments by cutting out repetitive tasks. To automate, you’ll need to review and standardise your deployment process. Standardising the process alone will make releases more robust, but by investing in automation tools, you’ll be able truly reap the benefits of a reduced time to market.
Build a Culture of Testing
In agile, testing is a first-class citizen, not some afterthought to be squeezed in at the end. Adopt a “test first “mentality in everything that you do – if you can’t write the test, you can’t write the code.
Don’t Constrain Your Releases by Sprints
It is often good practice to have a predictable release frequency. Lots of organisations choose to aim for the end of a sprint. However, if your sprint is 2 weeks, can your customers wait that long? There is no reason why releases must be constrained to your sprint cycle – your customers, competitors and market probably don’t care at all about your sprints!
Once you’ve implemented a culture of testing, invested in automation and planned smaller releases, you’ll be able to release on demand – when your product will deliver the most value.
Empower Your Teams
Finally, don’t forget about your teams! Give your teams the skills, knowledge, time and ownership to improve their release process and to decide when they can release.
This has been a challenge in some organisations that we’ve worked with where there has been so much red tape to get through to release. Teams present their changes to a Change Approval Board where it waits in a queue for days, then is rejected for having spelling mistakes in the release notes (Yes, really!!).
The book Accelerate by Forsgen, Humble and Kim highlights some interesting research about CABs, from the 2014 – 2017 State of DevOps Reports, they concluded:
“External approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate. In short, approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems, measured by the time to restore service and change fail rate. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.”
You might be working in a heavily regulated industry and a response to compliance with the regulations is the CAB. Consider what impact automation and a culture of testing would have on the regulations.
What’s Next?
Our approach to delivering more often is not founded on theory, but in experience. We’re experienced transformation engineers, dedicated to helping our clients achieve business agility through agile training, coaching, and consulting.
Our next blog post in the Being Agile in Practice series is around a practical approach to technical excellence, something our software development side of our business prides itself on.
Previous posts in this series focused on healthy backlogs and stable teams. Make sure you go back and read those if you missed them.
