At DigitalBridge, we’re always changing and responding to change. This time last year we were a service company, building a product to requirements defined by our biggest customer. Now we’re still supporting that customer - but we’re primarily a product company building our own product. To get here we’ve been on an Agile journey.
When I arrived last January, I found four separate teams each with a specific specialism (front-end, back-end and the like). They all had their own backlogs, predominantly made up of technical tasks, and we had another backlog too - full of stories from our customer. I was originally employed as a Scrum Master, but, like so many companies, we were doing something that looked a bit like Scrum but wasn’t really it. Unsurprisingly, we also had a lot of dependencies across the teams, and there was a real lack of communication and ownership.
Our first step was to mix everyone up - we created two new teams and made sure each one had at least one representative of each skill set. Taking lessons from LeSS, we combined all our backlogs into one, kept it prioritised, and had both teams take backlog items from it.
In every retro, the team enthused about improved communication and teamwork, and silos breaking down, which was great. But the tasks in the backlog were still technical and they were all being done by single people rather than as a team, so we weren’t actually working through the backlog in order - because if the top few items were front-end and the front-end devs were busy the next task to get done was obviously going to be a lower priority one.
And the fact that tasks were being done by individual people was, I thought, one of the reasons that our story point estimates weren’t very helpful. I shall resist (for this blog post at least) ranting on about why estimates are rubbish (#noestimates); suffice to say our velocity was pretty unstable and we simply weren’t able to forecast what we were actually going to get done in the upcoming sprint.
So we stopped using story points… and then we stopped doing a scrum-like process altogether and moved to Kanban. At the same time, as we started to move towards a more product mindset, our backlog began to become less overwhelmed with tech tasks, and a bit more story heavy.
As we started to work on stories, we found that our teams didn't actually have the people in them we needed to get the stories done, so we shuffled people round a little. James, our COO, had wanted us to move to feature teams for a while, and we realised that with the mix of skills our people have, we could probably work more effectively that way.
We’ve got two feature teams each with their own backlog and their own bit of wall to track work and we’re tracking cycle time, throughput and WIP. Our excellent new Product Owner Zoe has just joined us, and we’re just about to introduce a monthly vision, in which each team will collaboratively agree how we want our product to look in a month’s time.
Of course not. Agile is about continuous learning and continuous innovation. If we stayed as we are we just wouldn’t be agile. In six month’s time we might have a new feature team, or the existing teams may be doing different features. We might even be doing Scrum again. Whatever we’re doing, I know we’ll be doing it because it’s the right thing for us at that time. (We won’t be using story points though. Not if I have anything to do with it).