How does it look like when a Scrum team does not
understand the techniques, or even the value of splitting large chunks of work
into smaller, working software chunks? What is the risk in not dealing with
this issue fast enough? What can we do about it besides simply teaching the techniques?
and why?
100% of the times when we are engaged in an Agile
implementation inside an organization, we hear developers say -- and mostly this
comes from team leaders, that it's impossible to divide big chunks of work into
smaller ones (it may be dealing with large user stories or the technical aspect
of splitting user stories to tasks, or other variations of the same slogan:
"we can’t divide it to smaller portion”). Not only that, it is often
assumed that large technical assignments cannot be divided into smaller ones.
It’s a ”one hundred percent thing” - At the early stages of the implementation
the thought that this is actually impossible is very common.
The absence of this skill, the mindset or understanding
of the value in splitting large chunks of work into smaller working chunks is
one of the painful issues that encourage and build resistance inside Scrum teams.
We need to deal with it. Because resistance, if left untreated, can get out of
hand.
It come in a lot of shapes, colors and forms, For example:
"The sprint should be one month since we will not be
able to see anything working sooner, it’s plain impossible"
"Splitting to small chunks may work for existing code,
but not for new features"
"Splitting to small chunks may work for new features
but not for existing code"
"It is irrelevant when it comes to bugs"
"You can't do it for a research assignment"
"Our server side is more complicated than the GUI side,
which is why they can do it. We just can't even if we would want
to"
"Our GUI side is more complicated than the server side,
which is why they can do it. We just can't even if we want
to"
"UX is different. You can never do it"
"I have nothing to say on the daily anyhow – it's too
big a stop"
"Experienced
developers can and should have a backlog of large issues instead of wasting our
time with small user stories."
"Its too much testing
anyway, it’s a waste of time."
"Technically it cannot be split… whatever the merits,
the business side will not be interested anyway."
"The Sprint was delayed because we can't split these stories,
it's not doable"
"There is nothing to demo this sprint"
"Of course one could always split them into several so
called "technical stories", but they are, with the exception of
refactoring spikes, a big no-no in Agile, aren't they? "
It may even look like an active, strong emotional resistance
toward the coach or toward technical managers in the organization. I found
that team leaders who possess less technical skills, or who are less confident about
their skills, or are less experienced as managers, often provided very dramatic
or deterministic examples of these types of statements, to the point of
ridiculousness. This behavior itself is very dangerous to an implementation and
to the team mindset we wish to acquire.
I think the problem lies with these team leaders’ inability
to immediately understand how to divide big chunks of work. This threatens
their core professional image as software developers and poses a real threat to
their confidence regarding their abilities as skilled developers. The resistance can be very strong, and as a
coach you know that you have to face these issues and you need to get those
developers from the theory the practice as fast as you can.
We all know that learning to divide into smaller user
stories, and from user stories to tasks, takes time. It's not an easy thing to
learn or to get used to. It truly is hard for them. They need to both learn the
skill and to understand the value. We need to provide all the technical and
theoretical assistance needed and do it fast.
While this issue can definitely be hotly debated, the fact
of the matter is that there are lots of ways to deal with large stories. Field
experts have written extensively about it already.
So what can we do about it in terms of mindset and
resistance?
1.
First, identify and
acknowledge the smell. "we have an issue with dividing big chunks of work
into smaller ones"
Don’t ignore it and don’t assume team
leaders and/or developers will overcome it by themselves or just by reading an
article. After all it’s a craft they need to learn and it takes time and requires
the proper support.
2.
Assign a technical
mentor – someone who could get his hands dirty and help figure out patterns
of splitting. Someone that can be available for a long period of time and
trained for the craft or knows how to do it already. It may be a technical lead,
CTO, Component Owner, whoever the team respects enough on a professional level
to allow him or her to "step into their territory" without feeling
threatened, instead feeling safe enough to cooperate.
3.
Teach the
techniques.
Explain the value of dividing big chunks
into smaller ones: early feedback, higher quality work, delivering business
value, etc.
Teach both the business side and the
technical side, explain the value and the specific techniques out there.
It's better to do so using a real
backlog example.
Here are some links for further reading on techniques
of splitting big work into smaller chunks.
4.
Invest in the product discovery
and planning sessions so that developers will have more small "ready"
stories to generate in the first place.
Make sure that during the ongoing
discussions, as part of a discovery process or planning session there are people
there who have the skill and those who lack it. The team discussion will expose
those less skilled to the craft we would like them to acquire. There is nothing
like ongoing real exposure to practice that is relevant to what you are going
to work on next. It much better than a big chunk of training.
5.
Engage other
developers, who have experience in breaking large chunks of work into smaller
ones, in group discussions.
6.
Have a hackathon.
Yes! A hackathon can have an amazing impact on this issue. It is fun, goals-oriented
and requires presenting working software in a very short period of time. I will
write a separate post on this matter, but suffice to say that having attended
several hackathons in the course of my career has made me realize what a
powerful tool this is for delivering this value precisely.
