1

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?

2
  • 1
    There's a lot going on in your question. Firstly "velocity target" raises the question, what side effects are there of targeting velocity? It's meant as a descriptor for planning, not a target. How big is the team? What exactly did you change about the team structure and planning agenda that made things different? – yitznewton Aug 17 '17 at 13:23
  • Scrum In Name Only The Scrum Guide See self-organizing, forecast, Scrum Master, Development Team Size. – Alan Larimer Oct 3 '17 at 18:20
4

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
6
  • yes, thanks for the insights. Re-grouping the pairs every two sprints can mitigate the impact? – Hammer Aug 17 '17 at 6:55
  • What you're doing is creating sub-teams which in turn will affect negatively your whole team. It seems that you're just trying to work on too many things at once. Try to cut down the amount of epics that you're working on and/or prioritise things so that the whole team can work on any epic. Also accept the fact that more people and/or epics you have the more overhead you have as well. And that's not a bad thing as long as knowledge is being shared. – vvmann Aug 17 '17 at 13:18
  • @Hammer it seems like you're reading what we're saying, but you're not listening. Apologies, but I will be blunt: there's no reason (and no sign you know enough) to improve on the given agile methodologies. They are designed, tested and approved by the world's best. So, stop trying to one-up them by doing your own thing, and start reading books on agile and Scrum so you understand how it is supposed to work. Your team is relying on you to know this and get it right, not to make up your own mixmash and force it on them. Get off SE, open a book, and read. – dKen Aug 22 '17 at 4:53
  • @dKen, thanks for the reply and surprised to see your reaction. Calm down and let's come back to the topic? I am not saying which is better, but just throw it out for a discussion. Personally speaking, I do not think we should follow any methodology blindly or take it as a bible. Actually, A good methodology should always be adaptive to your own needs. Or the practitioner should tailor it based on his/her organization needs. Should not we?:-) – Hammer Aug 22 '17 at 6:32
  • @Hammer Nobody said "take a methodology and blindly implement it"; I strongly suggest the opposite. What I'm saying is that you've not shown any evidence of understanding agile or Scrum, no measurements for your assumptions on the impact on your team, & no reason to deviate from the tried and true. Long story short, from what I've read, you're ill-prepared to make sweeping changes to agile based on your apparent understanding. I'm recommending you start strictly with a proven methodology, and then measure impact & change it subtly as you progress. Ultimately, it's your team, do what you like. – dKen Aug 22 '17 at 7:20
2

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.

1
  • our team size is 11+. I had the similar concerns that this might create some long term side effect. However, under some timeline pressure, we are trying it out now. It does look things are moving faster. Velocity increases significantly... Team members seem OK. I hope such short-term stimulants wont destroy the chemistry in the long run. – Hammer Aug 14 '17 at 15:42
1

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.

1
  • Estimation is still at the team level (all team members), but the breakdown is at the pair level. On top of it, how many user stories to commit is also at the pair level, which we usually do at the team level previously – Hammer Aug 17 '17 at 6:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.