In this article, part of my series explaining better ROI from software development, I’d like to share my thoughts on Dependencies. This is the first of three articles in this mini-series.
Dependencies in any project are expensive. They are introducing a hidden tax on our projects.
Dependencies maybe due to inter-team communications.
Dependencies maybe due to complex inter-reliant systems.
In short, reducing those dependencies will reducing those hidden taxes.
These articles build on the concepts I’ve previously introduced when talking about Agile, Scrum and progressive companies such as Spotify and Facebook. You don’t need to have read those in advance, but I’ll include relevant links at the end of the dependencies mini-series.
For this mini-series, I wanted to take a different approach. I wanted to express this more as a story. The story of fictional company as it attempts to improve its return on investment by reducing expensive dependencies.
Let’s take the Acme Corporation. It’s a SME with a fairly generic set of systems:
Their development pipeline is what I’d consider fairly traditional;
The development pipeline follow an idea from concept to realisation. The idea will move from department to department – generally with supporting documentation.
The Ache Corporate is headed up by Ed (CEO)
Fiona is the CTO
They have recently had a management consultancy review their operation – the output of that review highlighted a number of opportunities:
Ed meets with Fiona to discuss the findings. He sees the opportunities as a great way to propel the Acme Corporation forward – but has concerns.
“How can these opportunities be realised while still getting the right thing and not putting the business at massive risk?”
Fiona commits to sit down with her team and come back with a proposal.
Fiona scheduled a number of workshops with her team and they soon identify that benefits could be gained from removing as many dependencies as possible.
They realised that the key was to reduce the number of times a conversation needs to go outside of a team.
The first thing they looked at was how the teams were structured.
Collectively, they arrive at the following team guidelines:
With the guidelines in place, they agree that the team should be responsible for not just the project delivery, but also the day-to-day support. They all agree that when a team supports a system, they are motivated to make sure that the system works really, really well.
They look at their current team structure:
And they agree on a squad based structure – focused around the products. The squads where to be designed to meet the guidelines they had agreed upon.
After further thought, Fiona wanted to provide a concrete example for Ed – an example that she’d want to trial.
So she sat down with the team again and asked their opinions on where to start with a trial.
It was agreed to start with a single squad. And to look for an important system that squad could own.
They didn’t want to use an unimportant system – there was little wow factor in that. And to make a meaningful change they knew they would need a wow factor.
They looked at the systems based on the volume of change, importance and how painful it was to get changes. They arrived at a simple matrix:
After review, they found that the website and CMS where pretty much always changed together, changed regularly, and where a fairly painful event every time they changed. If the end to end change process could be improved, it would represent a real game changer for Acme.
Having identified the systems and they turned to defining the squad what would be needed to manage it.
They look at the historical and planned changes for the systems to gauge what sorts of skills would be needed. After some analysis they arrived at their squad structure.
To provide the squad with focus they went further and defined some rules.
They collocated the squad in a separate office – in which they could work together easily, but also minimize distractions.
The squad would be expected to deliver change every two weeks into production. They would be responsible for the quality of the software they released.
They should be coached to focus on small, discrete changes – actively minimising dependencies.
The squad would be responsible for agreeing what could be accomplished within the two weeks, planning, developing, testing and implementing it. At all time the responsibility would be with the squad as a whole.
In their final workshop, Fiona and team went through concerns they had about the trial.
They felt that the biggest blocker to success was buy-in from all of the stakeholders. While the trial would have top level approval – without full organisation engagement, they could easily see the squad members being distracted by their old job.
They decided to prepare a town hall style meeting open to all.
In the next article, we’ll follow Fiona and team as they handle questions from the wider organisation.