How to manage a failed sub team inside a scrum team

Question

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.

---

Answer 1

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.

Answer 2

Increase Your Collaboration with the Scrum Team

However in this particular case its not an option.

Not an option is generally business-speak for: "We want different results, but refuse to change any of the underlying factors." That isn't agile, and generally leads to finger-pointing and other non-constructive business anti-patterns.

Front-End team produces lot of bugs (defects) inside a sprint cycle.

Scrum is not a thin layer of buzzwords over command-and-control Product Management. You need a paradigm shift.

Defects and incomplete work are symptoms of process problems. Usually, this is because the Development Team is:

1. "Being held accountable" for work pushed into the Sprint, rather than pulled into the Sprint by the Development Team based on its own forecasts for capacity and level-of-effort.
2. Failing to collaborate on a Definition of Done that includes test-first development, or failing to bake in sufficient quality control measures when estimating and planning the work.
3. Not using adequate testing methodologies or continuous integration tools. This is slightly harder for front-end work than back-end work, but in your case the Scrum implementation is likely lacking it altogether.

You should partner with the Scrum Master and collaborate with the Development Team to address the underlying process problems. You can start by not assuming that they are "failing" or under-performing, and stop treating them like they are a "sub-team." In Scrum, there is only one Scrum Team, and you are all on that team together.

As a Product Owner, it's your job to find out what the Development Team needs to successfully collaborate with you on product development. It's also your job to capture the necessary prerequisites on the Product Backlog as work that the whole team can track. For example, setting up a continuous integration server that can render and test JavaScript is likely a prerequisite that isn't currently being tracked as a first-class Product Backlog Item. It's in your power to fix that, because you are the custodian of the Product Backlog, with the authority to prioritize the backlog items (and therefore allocate team resources) to facilitate the project's success!

Answer 3

I'm getting a lot of "us" vs "them" feelings from your question, which is a major red flag. As a PO, you're part of the team, there's only "we".

Others have touched on how it would be better to not have separate "sub-teams", but just one cross-skilled team, so I won't elaborate on that.

I think your main problem is that the team is getting pushed to deliver things, rather than them committing to a goal themselves.

The team should

1. Estimate how long it will take them to finish each story (in collaborative refinement sessions). Ideally you do this in storypoints.
2. Use data from previous sprints to decide how much work they can handle in one sprint. Look at the past 2 to 6 sprints, see how many stories you were able to close (no work is still remaining, so fully tested and all bugs solved) within the time-boxed sprint (no extensions!). This is your velocity.
3. Use that velocity to select a new set of stories to work on in the next sprint

This means that nobody from outside the development team is allowed to tell them what to work on, and how long it should take them to finish it. Not even you. You should tell them what the business priority of each of the stories is, and they should definitely take that into account when selecting stories. But if they have good reasons not to commit to a high prio item (for example: because it doesn't fit the next sprint, according to their velocity), that is totally fine.

If that means that they can't meet external deadlines, that means the deadlines are not realistic. You should push back on the deadlines, reduce the scope of the released product, or look for ways to improve the efficiency of the team or the capacity of the team. However, you're team is quite large already, so I would not expand it.

Answer 4

It is perfectly normal to have people of different skills and capabilities working in a scrum team. Therefore, it is normal to have Back-end, Front-end and QA roles separately in a team.

Success of the team depends on not treating a small group of people within the team as a sub-team. The concept of sub-team works against the concept of scrum team.

It is perfectly alright for each individual in the team to possess a specific skill and hence perform a specific role that matches the skill.

However, it is not a good practice to group the individuals with similar skills and call them a sub-team within the team.

Creation of sub-teams will lead to the scenario of one sub-team blaming the other.

Individuals usually do not blame the other individuals. However, sub-teams usually tend to blame the other sub-teams.

Sub-teams also invariably introduce a false sense of hierarchy and escalation process within the team, thereby reducing the overall efficiency of the team.

Avoiding sub-teams, allowing individuals to have good rapport with the other individuals of the team and eliminating the false sense of hierarchy will automatically make the team self-managed. This will definitely pave way for success.

Answer 5

I think that I would call for an "all-project stop and regroup." This team is obviously on a Death March, and that never works. You need to help the team – and, management – to understand what is driving the team to even attempt this.

Are the expectations realistic? Is the analysis process any good? Does the team – well – really know what they are supposed to be doing? Are they attempting to take on more work than they obviously are able to achieve, and if so, why?

You can't superimpose scrum, nor any other project management paradigm, "on top of" any death march. You've got to intervene to stop the march, first.

Answer 6

Yes, and I will "circle back and add another answer" to say that the root-cause problems here are very-obviously external to the team.

• If programmers have been told that they must kill themselves to produce the necessary software ... they are not(!) ... ever(!!) ... going to "produce the necessary software!"

Therefore – (putting on my hard-nosed consultant hat here ...) – "you cannot solve a problem until you confront what it actually is." And in this case, it very clearly involves someone, at a much-higher level within the corporate structure surrounding this team, who learned from "Cheaper By The Dozen" and not the actual software world.

"Software(!) workers" are not "line employees," merely responsible for watching a crank being turned. They're skilled workers who can easily have just as much "impact on your bottom line" ... if not more ... as can any overpaid lawyer. And – their daily work product is "utterly worthless" unless(!) "it is absolutely(!!)(!!)(!!) correct!"

So – this is why I said, "first, you must stop the Death March." You must stop subjecting this team of workers to unrealistic expectations. You must stop any management(!) expectations that "flogging" will do any good at all.

Because: precisely the opposite is true.

Simple Example: *"Tell our Corporate Lawyers that they must not only cut their billings by 50%, but also produce their counsel in half the time."

No. Software workers, exactly(!) like lawyers, earn their daily bread by their expertise. You can't simply count, say, "the number of pages [of source-code] [of legal briefings] that they produce." That is not the point.

Answer 7

Do yourself a favour and stray away from processes and tools (if you want to speak with Agile terms).

Gather everyone in a whiteboard exercise workshop, and find out how all of you together, can improve the status quo. You'll be surprised what you'll get out of it.