Slice It Wrong And You're Doomed. Or How Feature Split Affects Scaling Scrum.

Author: Alexey Krivitsky

On one of my recent Certified Scrum Product Owner's trainings during a lunch break (this is usually when you can get into a real discussion about a real problem) one person approached me with rather a simple question:

Shall we add another Scrum team to a ongoing project that is due in 3 months from now?

Indeed, it was intended to be one of those yes/no questions a travelling Scrum-guru should have a ready answer for.

It took me the whole lunch break and then a good part of the next training day to get closer to the answer. And surprisingly the answer lied in what it would seem a complete different domain - forming a product backlog.

Yes, the way you slice your product may seriously impede your ability to scale software development. Let's see how that's possible.

Let's assume for the sake of an example that your company develops a web shop and it needs to be developed together by three Scrum teams in order to be released on-time (also on-budget and with expected quality).

Then your Scrum process might look something like this:

If you have been following the recent trends on scaling Agile and Scrum, then this picture should look familiar.

Indeed, it is a recommended (and the only possible) way of scaling Scrum according to the Large Scale Scrum framework. It has proven to work and described as a great method by dozens of fresh case studies. I'm also big proponent of this approach.

Note that all teams work inside a single sprint. 

Now for a small thought experiment forget about a scaled scenario and imagine 3 developers working on a single product, would they be sharing deployment environment, codebase, master branch, test suites, CI server, sprint planning and sprint review? Surely, they would.

And that's exactly why in the scaling scenario we want all the Scrum teams to share the same goodies. It maximizes team cohesion and help surfacing integration problems as early as possible. That's why the Scaled Scrum is nothing but Scrum scaled. 

But it all still go wrong, once you ignore the important rules of splitting up product backlog items...

Once we agreed on the basis and laid the foundation of scaling, let's deep dive into details that matter.

My hypothesis is that what you put inside the overall product backlog will really affect the overall scaling success.

I'm not talking about which features exactly you'd choose to release (that's none of my business). I'm talking about the way you slice your features for the backlog.

Let me prove this to you. 

So let's consider the following example: your next big feature (some people call it 'epic') is integrating payments to your web shop.

You are an Overall Product Owner (the source of ultimate power and glory) your development teams did their homework of backlog refinement (in scaling scenario you delegate as much of detailing work to the teams as possible) and now they're coming back to you with these high-level stories:

• Create database to store transactions
• Integrate with payment APIs
• Payment and transaction validation
• Develop UI for payment processing
  

They even went one step further and agreed who will be working on which stories.

Now, what would you say?

Well, being a trained seasoned Product Owner you probably know that features need to be split vertically, cutting through components and layers. And that the proposed product backlog items sound more like technical tasks... But why care? The teams did their job. They made an agreement. They can commit to deliver it to you. Why bother?

If you have seen such scenarios in real life you probably know that the chance the teams will actually deliver working software by the end of a sprint is significantly low. Having one team working across all layers would be a better choice guarantee. But you three teams and one feature....

Why is it so that the sprint is likely to be a disaster rather than a success? Didn't we say the teams are sharing the same codebase, deployment environment, tests, continuous integration... Yes they are (hopefully)... But the fact that each team is now working horizontally on a dedicated component (layer) comes with some costs.

Can you imagine preparing and running a sprint planning meeting for the teams? It's going to be rather technical as dependencies between the teams need to agreed on and discussed. So not much of business prioritization can happen - the sequence of tasks is pretty clear, straightforward and high-technical. This is how we're (1) losing ability to prioritize by business value. Have you seen a project role called a 'Technical Product Owner'? That's a common sign the backlog split is technical (as in our current case).

What happens when the teams deliver zero working software by the end of a sprint? Well, nothing. They just carry on the unfinished work on to the next sprint. Can a Product Owner make scoping decisions to fasten the release date? Not really. He is a hostage of the team. He is nothing but a monarch without any real decision-making power. A sad story for someone who is passionate about product management, UX and making customers happy.

During sprints the teams need to be kept aligned and synchronized or they will pull in different directions. This is how we're introducing (2) extra complexity (which now needs to be managed). The kind of complexity that is not inherent in software development, but rather added and self-imposed. We would not have had it, had we thought of splitting the backlog differently...

Now we need to make sure constantly that the teams are on the same page, don't block each other, work out all possible dependencies and integrate often to prove the feature works. 

Guess which team will be able now to manage this? Right, none. Because each team is focusing on implementing their own set of tasks for their own layer. No one sees the whole, no one cares for the whole.

So what happens when the stuff goes out of hands? When there is a failure on a sprint review? When a build fails?

It is always the "other team" who broke it. It is always the "other team" to fix it. There is always someone else to blame. See - we've created a society where it is very easy to avoid responsibility and nearly impossible to take it.. This is how we're introducing (3) lack of responsibility. Our old enemy that we thought should be dead when the sun of agile once rose...

But OK, the stuff still needs to be kicked out of the door, the features need to be shipped. What do we do now? How to we manage this?

Why don't we hire someone who is good at dealing with complexity, someone who can see the forest behind the trees. Someone who can commit (since no one else can). So we hire a manager. A delivery manager, development manager, engineering manager, project manager - he comes with different badges, but the principle is always the same - this person is supposed to collect the map from a puzzle and guide others by using it...

This is how we add a (4) potential command-and-controller to our system. And why is it so? Because simply he is the only person who seems to know where to go, so instead of explaining where we are and where we want to be, he would save everybody's time and simply start giving directions. One person thinking for all. One person making decisions for all. Quite a bad usage of collective brain power. And that sucks out responsibility from the teams even further.

Can you see where we've ended up?

(1) Inability to prioritize by business value

(2) Extra complexity and intransparency

(3) Lack of responsibility

(4) Command-and-control

Oh boy! We're back now to where we were when we started with Agile - we're back to waterfall. And by the way we're still formally doing Scrum...

Note the only main thing that got us here is the way we structured our product backlog by allowing the technical split of the feature. Sigh.

Did you experience similar situations? Interested in knowing alternatives?

Next blog post will start where this one ends.