How to manage a failed sub team inside a scrum team



  • Our scrum squad consist with three teams (Back-End, Front-End, QA). Each team expertised in their own set of technological stack and of their own code bases (repositories).

    I'm aware that cohesive skilled team is a key to achieve most out of scrum team. However in this particular case its not an option.

    As usual, squad burns down assigned user stories inside a sprint and most of the time, Front-End team produces lot of bugs (defects) inside a sprint cycle.

    Even they spend overtime, all nights, double shifts, they only can resolve 90% of the bugs within a given sprint period.

    The remaining 10% is mostly the complex bugs. Even we provide few extra days or in some cases an extra week, they fails to deliver. Most of the time the only option is go back and change the already committed code base to a new development plan. Which seems like a whole new sprint.

    I'm continuously seeing this issue after I joined the team as a product manager.

    What does this particular team miss here? What resources I should provide them? What's the project management workflow to handle this? What would be the company's management workflow to handle this? As a product owner, should I be responsible for this unskilled team?

    Edit: Added few notes to clarify few doubts on comments and original answers

    Why "its not an option" to have a cohesive skilled team

    • We really need to stick with sub teams for now. API is legacy, and needed lot of training and years of experience to maintain it. We are fortunate if we could find fullstack developer with knowledge of this early 2000's code-base and with modern browser UI framework. Reality we are less fortunate and really "Its not an option".
    • And I'm a personal believer of a separate QA team, who are specialized in the field. Who does full day testing and who does have spare time tp break the system with loads of regression tests.

    How sub teams operate as a scrum team

    • Sprint planning usually happens collaboratively with all the team members. And most of the acceptance criteria comes from me and team comes up with more edge level acceptance criteria cases.
    • Each user story gets assigned by one person from each team. As an example, one from UI, one from API and one from QA team.

    What happens in retrospectives

    • We are in a loop of pointing out the issues -> Team records it -> on next sprint, same issues -> Retrospective

    Why still slavery exists in our team?

    • This isn't something SM, PO or someone came up with. We strongly discourage of doing overtime, all-nighters. We do discussions, send notices to the team members. However it's something each developer or tester committing. Sometimes, even when not at office. I believe its a matter of the cycle which individual producing less quality work, then that person fear of nearing deadlines or feels guilty, and they work more to cover.

    Work load

    • Our scrum team consists of 9 people including me.
    • Usually we have 2 weeks sprints (10 working days)
    • I table a priority list of stories.
    • Its the team who (exclude me) picks the stories for the sprint duration.
    • Its the team who (exclude me) of scoring the stories.



  • You asked in terms of scrum, so that is how I'll answer. However, there are a number of red flags in your question that lead me to believe you aren't actually doing scrum (and I am far from a scrum purist).

    The scrum answer would be:

    • as PO, you are responsible for the product backlog and priorities, not for process improvement. If you see an issue, you might bring it up in the retro, or (what I would recommend given the persistent nature of the problem) talk to the SM and get their advice on whether you should bring it up in the retro, or whether they would prefer to bring up the subject.

    • the SM is responsible for bringing up any observed process problems they see, and coaching the team towards process improvement. This is typically done in the retro.

    • be clear about the problem. The problem as you describe it is not "they can't release code without any bugs". That's an unattainable ideal that we should all aim for, but it is not actually achievable. The actual problem you describe sounds like "complex bugs are discovered late, and can't be fixed within the sprint."

    • the first step in any question of the form "why is this happening" is to bring it to the team: ask them why this is happening. (Again, this is properly in the SM's sphere to do, not the PO's.) The SM may need to coach past the first answer.

    • in this discussion, think broadly and creatively: maybe the problem is further upstream, in requirements and acceptance specification. Maybe it's in backlog refinement (and if it is, that part is in your sphere as PO). Maybe you really need to invest in some automated testing. Maybe you need to fail early. Maybe you need to do some spikes to reduce uncertainty and clarify requirements. I'm sure there are more possibilities.

    • also, think incrementally: brainstorm a bunch of possibilities, then the team selects one item to try, to see if it makes an incremental difference. It is highly unlikely you'll find one big silver bullet.

    • Finally, good grief, stop making them work overtime and nights and double shifts! Scrum is supposed to be a sustainable pace.. and regardless of what methodology you're using, this is utterly counterproductive. It exhausts your team and expects them to solve complicated problems while they're exhausted.

    Edit: Responded to an additional edit above

    What happens in retrospectives

    We are in a loop of pointing out the issues -> Team records it -> on next sprint, same issues -> Retrospective

    This is the place to start, then. Don't stop at simply recording the issue. The retro is not only about identifying process issues; it is about brainstorming causes/factors and corresponding possible solutions to try, and committing to try at least one of them in the next sprint.

    Also, if "we" who point out the issues are not the same as "Team" who records it... that's another problem.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2