Skip to main content

Splitting your team reduces planning time

June 24, 2020

Splitting your team reduces planning time

Dark, small, crowded room in a corporate office. All windows shut closed with worldproof blinds. The only source of light is a projector splitting the room in two uneven halves.

7 people around the table struggle to keep their eyes open, even though 6 of them have coffee mugs full of the ever-awake potion. One man with blind stare types something on the keyboard. One sits to the back and observes from under half-shut eyelids. Someone looks at the phone to read the time: 10:12 - still 108 minutes to go ...

Sounds familiar?

In one of the companies over 10 years ago we called them Coffee Plannings that later became Coffin Plannings. An excruciatingly boring and time-wasting activity, where the whole team sits in one room, looking at one screen trying to plan a two-week Sprint. Usually only two people are engaged, the rest is asleep. We tried battling it using Core Protocols (BTW, a great set of tools). Later on we tried working on dynamics by introducing gadgets - balloons, crayons etc. It worked a little. 

We were stuck in believing that a team is a team and it has to work TOGHETHER!

This is one of the most common Scrum misconceptions. Scrum does not allow sub-teams, that means everything has to be done together. That's why we plan together, refine Product Backlog together, review work toghether, achieve goals together. Everyone at once. 

Of course I'm not advocating creating sturdy sub-teams. Working together in pairs or bigger groups (even the whole team at once using swarming) allows for knowledge diffusion and collective learning. So those sub-groups should be flexible and interchanging as much as possible. Too much division can be as bad as too big group working together - it will stop team from forming and learning and it is a common problem. I am advocating time-restrained sub-group working to maximize output and minimize time invested.

If we look at software development, the most effective way of using your team time is not one person coding, and others looking and commenting. The most effective teams work in pairs or small groups, sometimes individually and INTEGRATE their work OFTEN - even every few minutes. Same applies to planning.

 

How can I integrate planning often?

I know three ways - all of them reduce planning time by at least half the time: 

  • Central board - you can have a central planning board, where all Product Backlog Items are placed. When a sub-group takes one to work on it, nobody else can, so work is not duplicated. After it has been planned, the item is returned to the board, arranged accordingly and another one is taken to be planned.

  • Iterative integration - you integrate your work every (for example) 15 minutes. You organize what you have done until now, and proceed planning in sub-groups for another 15 minutes.

  • 1-2-4-all - divide work to be planned among everybody individually. Then plan individually. Merge people into pairs and merge their work. Then merge pairs into fours and finally merge everybody's work.

 

Do you know any others? Share them in the comments below!

 

You can also join me and other PSTs - Peter Gfader, David Sabine and Joshua Partogi on a tag-me discussion on Linkedin [link]. You also can be tagged to provide your opinion on the next #daretochange  - just let me know!


What did you think about this post?

Comments (8)


David Sabine
02:23 pm June 24, 2020

There are plenty good reasons to temporarily, intermittently, or permanently split a team. Thanks, Kate, for initiating this discussion.

Throughout a Sprint, for example, Scrum team members morph into pairs or mobs as they conduct the work of the Sprint Backlog. In self-organizing cross-functional teams, it occurs ad-hoc and informally as people combine their attention and effort to solve problems together. With respect to planning, each ad-hoc collective plans and executes their tasks — they do so without having to gather the entire team to plan every implementation; yet, they do so with respect to the team's design patterns, architectural vision, and quality goals.

Scrum teams may split up during the Sprint events too. For example, I worked with a team who was responsible for developing and maintaining an app on multiple platforms (Android, iOS, and web). During Sprint Reviews, they found it very effective to set up *stations* — each station would feature many devices (e.g. Samsung, LG, Apple phones and tablets; e.g. multiple computers preloaded with various browsers (e.g. Safari, IE, Chrome, Firefox). Stakeholders would split up, visit each station (think Science fair or museum) and the team members at each station would capture feedback. Then, everyone would gather for the latter half of the Sprint Review to compile the feedback and inspect/adapt the Product Backlog together.

Also, perhaps obvious, splitting a team may make good sense if the team grows too large. (What is "too large"?) The Scrum Guide suggests a team of roughly 9 will struggle to maintain cohesion — significant effort is required to communicate effectively and people will tend to split up naturally. Rather than fight that tendency, it may be important to have deliberate discussion during Retrospective how best to split the group into smaller, distinct and independent teams.

Thanks for posting, Kate! You've got me thinking.


Erwin de Gier
09:02 pm June 24, 2020

Wouldn’t it be way better to skip the planning all together? Just pick up the top story from the backlog and right there with the complete team discuss and build it. Then move on to the next. Estimates are lies anyway #noestimates


aljjxw .
07:13 pm June 25, 2020

You misunderstood sprint planning. The long meeting you described has nothing to do with scrum or agile practices. It is just waste. Also, sounds as micromanagement, it's the team that will decide to split or not in order to achieve the sprint goal. You are trying to solve the wrong problems. Finally you understanding of pairing/mob programming is disturbing.


Kate Hobler (Terlecka)
07:29 pm June 25, 2020

That was over 10 years ago and yes, we didn't understand planning back then, that was learning for the whole organization. The problem is that this schema persists in organizations I am working with - as a recommended internal practice (teams are forbidden to split on planning), because someone misunderstood teamwork.
I'm curious what do you find disturbing in my description of group working with code. Can you elaborate?


Kate Hobler (Terlecka)
07:34 pm June 25, 2020

That depends greatly on circumstance. If you have complex problem or technical debt or dependenies to manage, you are going to be greatly inefficient if you didn't plan. There are well-written products created by teams with strong refinement practices - and they barely need planning.
Notice that I wrote nothing about estimating - this is something very different than planning and planning may contain it or may not. And I'm a fan of #noestimates myself 😉


Maura Assam
02:05 pm July 2, 2020

I would like to know how best to do this with remote teams. Anyone?


David Sabine
02:20 pm July 2, 2020

Hello Maura,

Can you share with us if the team (or teams) you're talking about have ever worked in-person together?

What I mean is: if they used to work in-person and are now working-from-home, then I'd expect the team members to adapt their in-person habits. If they used to pair up on tasks, I'd expect they'd naturally continue that pattern.

If they have always worked remotely, and if they do not yet have the habits of pairing, then it will be unnatural for them to begin those patterns. For example: I don't have the habit of exercising regularly; so to develop that habit would require [1] the will; [2] that I try it a few times; [3] that I experience benefit; [4] more will; [5] that I keep trying it … until eventually I would have incorporated the habit fully and *not* exercising would therefore be odd and undesirable.

That's much easier to say than do, of course.

What have you tried to date?


Kate Hobler (Terlecka)
07:04 pm July 2, 2020

Hi Maura! Just like David said - remote setting does not vary much from the in-person.
Toolwise you might need an online whiteboard (Mural, Miro, AWWW board, Google docs or functions in Big Blue Button or MS Teams) and then some rooms or ways of dividing people - Zoom breakout rooms, MS Teams channels/meeting rooms or Google Meet meeting links. Then go ahead and use what you have used before or experiment with something new 😊
Most importantly - inspect and adapt having fun along the way!