Scaling Scrum – Team Ownership

I’ve been practicing the Product Owner role at a large fortune 100 company, on a program that has massive potential.  One effect at a large fortune 100 company at least, is that bodies get thrown at it.  In the course of not even a year, we’ve gone from 3 Scrum teams to 11 Scrum teams, 5 Scrum teams not in the same building, plus a customer support team, a massive dev-ops team and an operations center.  Wheh.  Plenty to discuss here in future blog posts.  Let me know if scaling scrum issues are of interest to you.

Today I’ll keep it focused at the team level.  Take this situation: Team A works on a specific feature for a few sprints.  Something new pops to the top f the backlog which Team A is uniquely qualified for, and they suggest going for it next sprint.  They talk with Team B and product ownership and everyone agrees that Team B will pick up the remaining work on Team A’s feature and make a few enhancements and add a few new features. I would suspect this is a common occurrence in large programs.  Probably sometimes in command-and-control ways (listen up people, we’re going to re-org these teams to work on different things….)  But even in a good self organizing system, this can create issues.

What responsibilities does Team A have to Team B while Team B is working on the codebase Team A originally created?

The perfect world answer is that Team A is responsible for knowledge-share, a few Q&A sessions, and nothing more.  Team A has left their codebase in good shape, with low technical debt, and plenty of artifacts that explain what’s going on and how to get work to done in this particular codebase.  They’ve showed their working software every few weeks and been transparent about what’s done and what’s not.  Team B has all the necessary skills needed to turn backlog items related to this feature into done software.  Team B does all the design, coding, testing, etc, etc, etc needed to produce done increments.  They rely on Team A only for the occasional question and explanation.  In the perfect world, both Team A and Team B can make progress simultaneously.

In the real world, this probably isn’t the case.  There is likely going to be significant drag on both teams for quite a long time.  Mangers like to call this a “transition period.”  Developers and teams like to call this “hell.”  The teams will fight over the state of the codebase “you’re handing this crap over to me?!!?!” and quarrel over getting help “can’t you just spend a few days [doing our work for us]?!?”

Scrum will make this very, very apparent (this is a good thing!)  It will not fix this for you.  (what’d you expect?)

As a manager, you want the team to own their work, even if they didn’t create it from the get-go.  A team that is whole-owner of their work is a team that learns.  They are a team that is solely responsible for quality.  They are a team that has all the power to create great products.  You want this.  Don’t get sucked into the short-term tactic of having “all teams help each other” and having alot of cross-team dependencies and other teams to parts of features or parts of development, etc.  It’s a short term tactic that optimizes the struggling team at the expense of all teams.

It’s not an easy choice.  It takes courage and vision to wait while a team struggles for a bit to find its way.  But it will.  It will learn and organize and grow and come out the other side all the better for it.

Advertisements