Marcato

As Brian H pointed out in a recent comment, one of the more difficult challenges for introducing or operating scrum is getting team members wholly committed to one team.  Rather than comment back, I though I would dedicate more time to the topic – this is an important one to get right.

My experience has been that effective, high functioning teams only form when team membership is stable and team members are dedicated to one team.  While the transition is hard to accomplish, the steps are relatively straightforward:

• Reorganize to separate reactive, maintenance work from feature development
• Create balanced feature teams that receive and process work assignments from a variety of projects

I cover the first step in detail in another post (see Customer Response Team), but I realized there is more to say about the second step.  We’ve all had experience with matrix organizations – the notion here is that you have project managers that draw together a collection of people that have an HR report to a functional manager.  The functional manager is responsible for making sure that everyone is fully allocated and is usually responsible for creating and sustaining the process definition, where the project manager is responsible for the outcome of a particular project and accomplishing it with the resources assigned to them.

The matrix system works, but it doesn’t serve the needs of software development very well.  First, it tends to group people by function, and since the manager of your function performs your review, it tends to emphasize role over project outcomes.  These dividing lines become entrenched, and functional managers end up overly involved in business of the team as they seek to expand their own influence and protect their team members.  There are, simply put, too many cooks in the kitchen.

Water Tower - Harmony, MN

What happens if you turn this inside out – make the cross functional feature team the primary unit of organization?  Role specialization still exists, but the team is self-directing in figuring out the best way to get the assigned work done.  Functional managers still exist, but only to advocate and evangelize the spread of good practices throughout the organization.  They still generate reviews, but the reviews are based largely on peer review from fellow team members and on the outcome of their projects.  Project managers still exist, but they are embedded in the team as scrummaster and they continue to represent the state of the project to the outside world, but they share accountability for the outcome equally with everyone on the team.

Projects are broken down into pieces (features) that can be assigned to an already constituted team.  Teams are expected to have enough diversity in skills that they can be assigned any kind of work yet still be capable of accomplishing the goal.  Work can be reassigned to a different team if progress is insufficient, but you don’t change team membership between iterations.

Of course, this only works well by having the buy-in of the manager responsible for how the teams are organized – in most organizations it is the VP of Product Development or IT that would have sufficient purview to create the structure.  As I mentioned earlier, that person also has to shunt work that requires immediate attention away to be handled by another team and process – you can’t mix dramatically different time tolerances together and get an acceptable result.

I have seen the end result of not doing this too many times – people with multiple project assignments shuffle weekly or daily between status meetings reporting that they have made little progress on their assignments for this team because they are too busy with other priorities.  Everybody looks busy, but macro level output suggests otherwise.  This is definitely a “smell” – a clear indication that something is rotten in the state of Denmark.  It’s unsatisfying for you as an individual because you feel that you have let one of your teams down, and it’s inefficient for the organization as the more cycles that are spent context switching and updating, the less that is actually being done.

I’ve seen this in my own consulting work as well – it’s difficult to manage the transitions and overlaps between multiple clients because you can have all the best intentions in the world yet still find it difficult to always be there when your client needs you.  This is what it is like in a high functioning team – everyone chips in, everyone works really hard, and everyone shares in the success knowing that they carried their fair share of the load.

What to do about it?  I think each individual needs to be accountable for their career and this decision.  You can’t blame your leaders for asking if you have the capacity to work on more things (OK, you can – they need to knock it off, too), but only you can say “Let me finish this first, and then I’ll start working on that”.  You may think this will put you in jeopardy with your leaders, but I can tell you the opposite is true.  I would much rather have someone that regularly completes what they start than someone that takes on too much and never finishes anything.  I don’t like excuses.

I think people are confused on this point – at an individual level, they think that success will come from showing a long list of projects as accomplishments, but a savvy leader will see right through that and recognize that being a “chicken” in many projects means being a “pig” in none. “Chickens” flap their wings and make a lot of noise; “pigs” ship stuff.  As for me, I’ll take bacon any day.

Mmm, bacon…