After XPDays 2015 in our session “Sharpen your story splitting skills”, we concluded that some additional framing was needed for our useful deck of cards with splitting patterns. 

This article is the successor of the “Splitting Backlog Items Part 1: When” post, and will handle about the people and aims to help you understand dysfunctions that make item splitting a pain and the reasons for good practices.

Background

Quite frequently we see that the splitting of backlog items is being taken up by experts.
Usually that is done by a PO, business analysts or achitects. 

One of the reasons why our organisations consist out of so many fragmented roles is that we often lack the skills to build an organisation.
And so we fall back to knowledge of our ancestors. 

That’s how our organisational formats are built around reductionistic thinking.
The belief that if you understand the particular pieces that form a larger system you automatically understand the larger system.  
That leads to organisational behaviour where we put the necessary skills together, and believe that this magically will work and produce good products.  
We miss out on the benefits of co-location for instance.  

Evidence of that can be found in the existence of specialist-departments.

Asking people in such an organisational setup to do a certain task (like splitting) leads almost automatically to the question: “Which department/specialist is responsible?” rather than “Who should we get together to get the job done?”

Rarely we see people questioning the organisational setup they are in.

Splitting

In order to understand what is so wrong about having a dedicated role for splitting, we need to go back and understand what splitting is exactly.

The most simple definition is breaking work down to consumable pieces.
This could go from a technical break down using architectural lines, all the way to functional break down.
Any kind can be considered as a split.

It’s true that certain ways of splitting make life easier, some make life worse. (I’ll talk about that later, promise) 
But one thing is sure: to maximise the splitting possibilities, we’d better not limit ourselves to splitting according to technical outlines like only architecture, or only crud operations, or even only functional outlines.

An experienced eye will recognise a pattern here;  “there is no silver bullet”.  
Also for splitting backlog items there is no “best” method.

That on itself argues for considering multiple ways to split, and pick the best for the given situation. Need inspiration?  Check out our splitting patterns cards. 
Multiple ways of splitting need different skills around the splitting table. 

Now here’s the thing: As we see splitting happening a lot by dedicated people like analysts, architects or even PO’s, we can conclude that the disadvantages that come along by doing so are underestimated or even unknown:

• The complexity of the backlog items at hand is high.
  It is hard to predict what the best split strategy should be.
  The underlying architecture, interests, team setup, skill set, … so many factors can influence a choice of split.
  Hence it’s not advised to split based on a single-person skill. 
  From complexity science we learn that increasing the diversity of the models in how to approach a complex situation, is the best chance to survive the day.
  In normal language: The best solutions to complex problems are found by different minds complementing each other.  
  Not doing so lowers the quality of the solution.
• As stated in the previous article, upfront splitting causes waste in the form of a hand-over: The dedicated person who did the upfront analysis (imaginary construction) needs to explain this all to the people that do the implementations (real constructing). This knowledge transfer costs time.
• Hand-overs also come with a risk. The risk of misunderstanding.
  So less hand-over, means less misunderstanding. Mistakes come with a cost too.
• Ever heard of the term: “learned helplessness”?  
  This behaviour can be found in teams that are not given the autonomy and means to take care of the end product they are working for. 
  Taking away the responsibility of splitting their backlog items in favour of some specialist is taking away their autonomy.

Who-o-who?

So who should be splitting then? 
As the above suggests: multiple skills together.  
Where do we find them?  Under the condition of being cross-functional, in the Team.

There’s another reason why you’d want the Team to do the splitting. (and nobody else)
They are supposed to carry the responsibility of the delivered quality.
Now, anyone can see we wouldn’t want someone splitting backlog items that hasn’t got the ownership on delivering quality, right?
Imagine someone splitting (e.g. solution-splitter-architect), but implementation like that is risky and hard.
Once done, he notifies the Team they can start typing their code.
How will the Team react, you think?  As managers we’d want our Teams to react on it.  Reality tells another story.

“But that’s stupid!”

“ALL these people?  In one room?  Endless discussing?  They will fight! They won’t agree!
We should avoid discussion at all costs! Discussing is a waste of time!”

WRONG!

Discussion is the process of shining the light on a problem from different angles in order to come to the best possible solution!
And if it IS the case an endless debate starts, think twice.
A team that wastes time on endless fights cannot be considered as taking responsibility of their timely delivery.  
Maybe it’s more important to be the winner of the fight. Maybe it’s something else.
If there is something more important than the delivery, there’s something else that needs to be taken care of.  
One thing is certain: avoiding the discussion is a symptomatic treatment. 

“But we do not have all the right skills in the Team!”

Well, better start building cross-functional teams, no?

Travelling is a good practise to sharpen skills without having an additional person in the team for covering that skill gap.  Check “Stop Managing Dependencies!” for a more in-dept explanation.
Allow teams to work on end-to-end problems by nurturing cross-functional teams. 

“But our architecture…”

“Our architecture is so complex that the skill count is too high”. “It ain’t no simple webshop!” 
Complexity high? This advocates to build solutions in a multidisciplinary way. 
High “complexity” could suggest a high degree of technical debt. Maybe this needs attention.
Leaving the situation at status quo only inflicts and maintains the resistance to splitting properly. 
High skill count?  Also here Travelling is a good practise to increase the skill count per person, and so reduce the need for big teams. 

In the next post of this series I’ll try to zoom in on the split strategies and factors that paralyse the skill of learning to split.