Winning The Backing of Stakeholders for Agile Delivery at Companies House
Ben Lidgey is head of development at Companies House, a UK government agency that maintains registrations and official records of limited companies. He spoke at the Agile Delivery 2017 conference about how he had obtained stakeholder buy-in for a more agile approach to software delivery…
Ben wanted to introduce more agile ways of working into the organisation, including a DevOps approach to delivery — but he realised that he needed to avoid jargon and
Often saying DevOps is better doesn’t really cut it with the business, Ben says. They might have heard the word but they don’t really understand it.
DevOps is often defined using the CALMS acronym:
To Ben, culture is first in the acronym for a reason. Get that right and the rest should follow.
So he decided he needed to spend time considering the culture of the organisation and stakeholders in order to get buy in for an agile DevOps approach.
So he thought through:
- Who are the audiences?
- What do they know/understand? What don’t they know/understand?
- How will I show them the results?
- Is there commitment from them? This is crucial
He then considered what value a DevOps approach could bring the organisation:
- rapid releases (bringing customer benefits more often)
- staff morale, engagement
So Ben went to stakeholders and pitched quality and reliable delivery. They have legislative requirements to meet, and it has to be right. This appealed to them.
To the dev team he pitched it as a chance to use new tools, to learn, to improve their skills and deliver good stuff more often.
To the project management team he pitched it as more certainty about delivery timelines.
But it was still too much to try to implement at once. So he decided to try to bite off one chunk at first — introducing test automation. Typically with their legacy platforms they had a long delivery time, and then a long testing period at the end. It was waterfall, risky.
The work for the development teams was relentless, working on project after project after project. There was no slack in the system. Tech debt was increasing. The code smell was increasing. But they didn’t have time to deal with any of it.
So Ben went to stakeholders, saying look at these things happening — we need test automation on the next project. They understood, but said we have all these project delivery dates, we don’t have time to do anything new!
So Ben needed to think about the culture again, in order to refine his approach.
He used the DESC method:
- Describe what happened
- Explain how this made you feel
- Share what you’d like to happen in a new way
- Compromise by stating what you will do as a result of this newer way
This meant that he:
- Described what happened in the previous projects with difficult test phases
- Explained the impact on delivery, delayed by two weeks
- Shared the changes to the ways of working you’d like to introduce by setting out how the automated testing would work
- collaborated by offering to start with automated testing just for key user journeys, and bringing in specialists to do this, out of his own budget, rather than asking existing teams to do extra work or spend more money.
Additionally he offered to demo the work afterwards to make the benefits clear, and to make the testing very visible.
So as they began introducing automated testing, they introduced dashboards, on the wall in the office, showing visual representations of test scenarios passed and failed.
Ben says they had to give stakeholders enough context that they didn’t panic when there was any red, so they understand the ongoing development and will later see green. Stakeholders can then understand that they are problems that have been caught now rather than later.
The test cycle went from two weeks to 1 day, and the actual automated tests take 2 mins to run. Stakeholders could immediately see benefits of faster, more reliable testing.
Companies House now have 10 scrum teams, and automated testing has been rolled out to all of them to varying degrees as it’s harder to apply to legacy platforms. They have the basics in place.
The next challenge is to get buy in from the business to get time and money to do agile delivery with DevOps properly. Those discussions are going well, though, as it should be with the DESC principle, there are compromises.