Team members struggling to thin slice business value - how to help?

Question

I have been asked to join a new a team which is struggling with agile adoption within a large programme utilising fairly methodical Scrum. The aim of the product is to create a surface layer over the current legacy customer information systems (There are 4) which ties all of them together into one common interface and (eventually) replace the systems.

In the last few weeks we have embedded some of the key values, the necessary ceremonies and artefacts and begun to display real team cohesion and cross-skilling.

However the team is really failing in one key area.

They originally ordered their product vision as a full end to end process (no problem) then they boxed the various systems and sub-systems that a customer service representative must use to support a customer. They listed out the functionality that the customer service reps need (File Access, Information Update, Work Queues, Note Taking and 40+ others) and simply labelled these as epics.

Then they put the user journey on paper, dropped the epics onto the diagram like lego blocks over the user journey and start working through them. First part of the user journey, first epic, deliver that. Review. Next epic, deliver that.

For example

A user needs the ability to see a list of customers. Therefore we will recreate the pending customers as a queue of work. That is an Epic and will take a Sprint. That is our Sprint Goal. We did that.

A user needs to take notes. Therefore we will create note-taking functionality and call that an Epic. That will take a Sprint. That is our Sprint Goal. We did that.

Repeat for 40+ epics...

Understandably the stakeholders, well versed in Agile and Lean Product have intervened to say the team have not thin sliced the service. They have simply created a series of building blocks which are delivered in a spiral iteration...block after block and once all the blocks are in place the service will work end to end. Without the delivery of all blocks then the business cannot use the value...

A senior stakeholder asked the team just to demonstrate a message saying "Customer Name_EXAMPLE" could make it all the way through the system before adding in additional functionality.

The solution designer and the business analyst are struggling to understand thin slicing and have started resisting the change despite the Scrum Master and Product Owner being in agreement. They want each bit of the system laid like a paving slab before the next part is started.

What strategies and examples exist to coach individuals into effective thin slicing of business value?

Edit: If any clarity is required then I can edit but really looking for genuine guidance on this issue appears multi-faceted.

Answer 1

I do have a few questions...

If the work is rather straightforward and the way the UI is created and the integrations are solved are standardized, then a process framework optimized for complex work, may just add overhead. If the work is standardized it may just not be required to break down into smaller bits to learn along the way. The development team may be able to optimize by delivering complete funcionality.

A few questions...

When the team delivers an epic, is it what the stakeholders were expecting? Was it delivered fully (according to the Definition of Done)? And was true to their forecast? Was the whole solution valuable? If you answered yes to these questions, then maybe they don't need to break the functionality down any further.

A few nuances which may help with the discussion to break down further.

• Was there any functionality in other parts which were not built in the sprint, which were more valuable than some of the parts that were implemented? In that case the Product Owner should clearly point that out.
• Is there a Minimum Viable Product which the end-users can already use which is composed of a set of features from these larger building blocks? If so, that may be a logical way to split the epics and then reorder the backlog accordingly.

If you're trying to break down these stories into smaller parts, just to break them down, I can understand the reluctance of the development team.

If breaking down the stories into smaller parts will lead to the development of usable MVPs, the ability to validate which features are truly needed or ways to gain early feedback from users, then make sure that the development team understands what you're trying to achieve by breaking down further.

I generally direct people to the Story Splitting Patterns laid out in this blog post, it uses a list of possible ways to split larger stories into smaller ones.

It breaks down the work using a more "standardized" approach, which may resonate with your team. Have the product owner and stakeholders clearly vocalize which parts would be the most valuable for them if they could be broken out and delivered earlier.

Answer 2

Other answers about splitting stories are good, but I think there's a separate problem here. As I mentioned in the comments, the BA and designer jobs are traditionally defined by their ability to design complex systems. It may be a very large jump for them to not take this approach. (It certainly was for me when I transitioned to Agile)

Perhaps instead of asking them to break down the stories, the rest of the team should take on that task and then have them ask the BA and designer specific questions or only allow those members to ask guiding questions. For example, if a particular approach will prevent integration into a certain system later, they can ask "How will that affect integration into system X" rather than say "You have to do it like this so that it integrates with system X".

This isn't to devalue their input, but rather to break the existing paradigm where the BA and designer come up with the plan and the team follows it.

You do need those other answers about splitting stories though. Changing the team model alone or splitting stories alone will probably not work. Both together should get you over that hump though.

Answer 3

I hope you can coach them by presenting the problem in a different light, so they can come to the solution themselves.

One idea. Can you present the problem to them as very high level user stories, or perhaps personas?

Ie

1. As a customer service representative I need to do X, Y and Z to do my job
2. As an admistrator I need to do A, B and C to do my job.
3. And so on...

Show them this, and say that until one of these is complete we can't really release anything to the clients. But, once one of these use cases is solved we can ask clients to move people matching that persona onto the new software. Hopefully this will allow them to map their epics to match these larger groupings and start working towards that. Possibly this may even allow them to pull some of the work out of the epics where it was part of one before but not really required for the larger groupings you've outlined.

There may well be a long gap before the first users can get in but hopefully the team will better understand where the key milestones are and management can get a better picture of when things will get done.