The Agile Values and Principles for Everyone
May 28, 2018
What Is the Difference between an Agile Coach and a ScrumMaster
October 25, 2018
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? “
“In fact, the last 6 months, I’ve been working on a project where the entire point is for customers to notice no difference (platform migration)”. https://pm.stackexchange.com/questions/2316/how-to-handle-user-stories-that-cannot-be-split-and-do-not-fit-even-a-30-days-lo)
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?
- 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.
- 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.
- 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.
https://www.roojoom.com/r/1757#/trek?page=1
https://www.roojoom.com/r/375#/trek?page=5
- 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.
- Engage other developers, who have experience in breaking large chunks of work into smaller ones, in group discussions.
- 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.
