Skip to main content

Multifunctional Learning & the reusable Sprint Backlog

September 20, 2015

Have you ever seen a Sprint Backlog that can be reused across Sprints? I have!

A reusable Sprint Backlog contains obvious tasks, like for example ’write code’, ‘make test scripts’ , ‘execute test cases’, 'investigate' and so on. These tasks are too trivial to be useful and undermine one of the fundamentals of Scrum. Let me try to explain why.

A fundamental of Scrum is multifunctional-learning as described in the 1986 Harvard Business Review paper ‘The New New Product Development Game’ by I. Nonaka and H. Takeuchi. Multifunctional-learning happens when people with different specialities together develop one product and there is no division of labour. That is, all people in the team have to do whatever is needed to get the job done and share the same goal of delivering working product.

 

Why is multifunctional-learning important in Scrum?

Multifunctional-learning is important because you want a Scrum Team to always be able to make progress in case a team member is absent for some reason. You do not want the team sitting around waiting for the team member to get back. You also do not want to work on low value work while high value work is being postponed. And this often means the people do work that is outside their main speciality, hence multi skills are needed.

 

Why is there no test role in Scrum?

Have you ever wondered why there is for example no test role, programmer role or analyst role defined in Scrum? Yes, that’s right… all of the above are everybody’s responsibility. Unfortunately in many companies people work to job title and feel only responsible for the tasks that are within their job description. So, a tester does testing, a analyst does analysis and so on.

Having specialised job titles in a team encourages local optimisation. For example, a person with the title of programmer will tend to locally optimise on his speciality of programming.  Therefore she will tend to work on programming tasks of lower value Sprint Backlog Items (SBI) over woking on analysis or testing tasks of higher value SBIs.

I’ve seen lot's of teams not deliver working product at the end of a Sprint because testing tasks were not done. When I asked them what’s going on they responded along the lines of

“...the tester will pick up these testing tasks once he is back. He has been on leave a couple of days…”.

The thinking is that the others wait for the tester because the tester can do testing work better and faster. A local optimisation decision and as a result the team is slower.

 

How to encourage multifunctional-learning?

Pairing on work is excellent for multifunctional learning for obvious reasons.

Another way is having a Sprint Backlog (SBL) that is not reusable. A detailed SBL with small clear tasks makes it easier for team members to pick up tasks outside of their main expertise and help each other. So, instead of a reusable task called 'do analysis, or ’do coding’ you could be very specific about which class, interface, design issues and so on you need to work on. For testing tasks you can be very specific about which test data you need, the test cases to be developed, risks you want to address and so on.

Multifunctional-Learning is further encouraged by doing all events together. Design sessions, refinement sessions, planning sessions and so on. When people pick up a task outside their speciality themselves they are consciously choosing to learn. The specialist can take on a teaching role and guide people in their learning by coaching, teaching and pairing.

I am very interested if and how you encourage multifunctional-learning in the teams you work with?

 


What did you think about this post?

Comments (1)


Daniel Flöijer
05:32 am September 25, 2015

I both agree and disagree. I think it's very important with a Sprint Goal and that the whole team helps out to reach that goal and the high priority backlog items. However, I do not believe that everyone should do everything all the time. The tasks done in development teams is too complex for everyone to be able to do everything as well as anyone. Even sub-skills like testing or programming can be divided into specialty areas. Different languages, front-end or back-end programming, and even many different areas within each of these. Or performance testing, test automation, exploratory testing etc. That doesn't mean a programmer should never do testing, but most of the time they will not do it on their own. What they should do however is work TOGETHER with the tester to help them do better and more efficient testing. And in the same way the testers can work together with the programmers, or requirement analysts to help them do their work better.

I believe there's a danger in believing that everyone can do everything in a team, because that is a simplification of the complexity of software development.