With a growing team size, task breakdowns and sprint planning are taking longer and longer. To increase the likelihood of hitting the velocity target, a new approach is adopted: to put team members in pairs. Every pair is assigned to be focused on the user stories in a single epic only. Task breakdowns are carried out by the pair only. It seems more efficient and faster now. Is anyone aware of any long-term impacts of this approach?
Interesting approach. However, splitting a team into such small members will most likely have negative impacts. A few of my immediate concerns:
- Accuracy of estimations: A bigger team with more members estimating = more experience sitting around the table. When estimating the effort involved in completing a story, power comes with numbers. Discussions around the table about differing estimates gives a better picture of what needs to be done, and if some estimates are way out, a way for everyone to understand why that is and how to resolve them. Most of the effectiveness of this is lost with only two people
- Loss of problem solving solutions and ideas: Similar to above, only having two members decide on an approach to a story could have big impacts. They may decide their way is best, but it's possible another person in another isolated team could have an idea that halves the implementation time, or has a much simpler solution. You raise the risk of overcomplicating parts of the project by splitting team members up
- Dropping the bus factor: If two members work in an isolated environment, then they're effectively narrowing down the knowledge on that piece of work to just themselves, meaning that, should they move to another team or leave the company altogether, that knowledge leaves with them
- Learning: How do team members share knowledge and learnings on a grand scale if they only work in isolated environments? What point is a retrospective of 11+ people when people only interact in pairs?
- Etc. etc.
I could continue for a while, but all of these benefits you're potentially missing out on are repeated and repeated and repeated time and again where agile is concerned (have you done any reading on this?). My gut feeling is that you're trying to fix a methodology where it's not the methodology that is causing pain, it's the implementation. You say in your comment to Daniel that velocity has increased, and the team members are happy. How do you measure this? What about the quality of work, or the accuracy of your estimates? How long have you been measuring these KPIs using your new ideas, and did you measure these KPIs on your old implementation? Be careful that you're not just looking at short-term positive impacts to support your decision.
Scrum works successfully for a phenomenal number of teams, and I don't see anything out of the ordinary with your team that means it shouldn't work for you. My suggestion is to closely follow the fundamentals of agile and Scrum properly before hacking it to fit what you think it should be. For instance:
- Team sizes should be no bigger than nine. It says this everywhere, and for good reason. Break them into two teams. It's possible for one Scrum master to manage two teams, so try it out
- Isolating team members has a ton of negative side-effects that may not be noticeable now, but in the long term could be very damaging for the project
- Constantly review the impact of these decisions going forward, not just once, but continuously
There are probably a few things happening here. First, unless your teams are outrageously large, extremely long tasking sessions may be a sign of a different problem. I assume you are practicing scrum since you mentioned velocity. Scrum recommends a team of 5-9 people. I've never seen a good tasking session last longer than 30-60 minutes for a 2-week sprint. If you have more people than that, you may be pushing the limits of what a team can handle and might want to look at simple scaling methods with multiple teams (like Scrum-of-scrums for example).
I would caution against what you are describing. Ultimately, it is optimizing people's time to gain you maybe 20-minutes per week while sacrificing shared code ownership, knowledge transfer, team cohesion and performance, and can ultimately cost you far more than what you're saving. It also prevents you from being able to have teams "swarm" on epics to complete them and instead forces your team to bring many epics into progress and take longer to complete all of them.
Every pair is assigned to be focused on the user stories in a single epic only. Task breakdowns are carried out by the pair only.
Are you talking about estimation & task breakdown only, or also development?
Assuming the former, then if I was experimenting with this approach, I would add a required team review of the pair-produced task breakdowns & estimates. Nothing in great or gory detail, just an opportunity for everyone to read the board and put their finger on anything that didn't seem quite right, and revise before proceeding. This mitigates against the first two risks that @dKen identifies, and also allows for knowledge transfer.
If the latter, I would be more hesitant about that. Six teams of two is a lot harder to coordinate than 2 teams of six, in addition to having the longterm negative effects mentioned in other answers.