Agile Team Roles: De Jure and De Facto Distribution of Responsibility

It's totally uncool on any agile team to use the phrase "that's not in my job description."

Theoretically, the way to measure the effectiveness of an agile project is to look at how effectively the whole team is at working together.  Teams that work well together can often beat other teams composed of selfish individual achievers.  (Take for example the 1992 American "Dream Team" in basketball at the Barcelona Olympics, composed entirely of individual superstars such as Michael Jordan and Magic Johnson.  Oh, wait, no, never mind.)

At any rate, much digital ink has been spilt arguing over topics like:

• Do we need Business Analysts in Agile?
• What's the difference between User Experience Design and Business Analysis?
• If our Testers can't Automate, how soon can we fire them?
• Is there anything our Developers can't do?
• What's the difference between a Project Manager and an Iteration Manager?
• Is our Director a Pig or a Chicken?

and so on. I myself have squandered a few pixels on some of these topics.  But let's look at this in a new light.

As working individuals, we have de jure job titles which put us into play in a particular competitive economy, within our particular geographic region.  Before we ever get put onto any agile team, someone has to hire us.  It behooves us to get hired with a job title that will maximize our income.  So, for example, in Chicago, project managers get paid more than business analysts, at the same level.  When we're talking about de jure job titles, we're talking about what things we can put on our resume to get us hired at a certain rate.  These things are a reality at my house, and I bet they are at yours as well.

So let's say you ask questions like "is Business Analysis dead." At the de jure level, if I can't spin my resume to make me look like a developer or a project manager, yes, I'm going to get a tad emotional.  That cave-girl fight-or-flight reflex, involving protecting my young and whatnot is going to kick right in, and I'm not going to hear a word you have to say about "the business analyst just gets in the way when the developers try to talk to the customer, blah blah blah."

On the other hand, once we're actually in place on a specific agile team, we are constantly faced with the issue:  how can we best get the work done?  De facto, there are a bunch of different types of things that the team needs to do (which vary over time), and it would be best if we could optimize the way that we'll all chip in and get those things done.  In fact, this is true in any work environment, not just an agile one.

• An absentee power-vacuum-creating manager creates a de facto arrangement whereby the team works out its own priorities without her (like in Lord of the Flies!).
• A person appointed to her position for political reasons (whether "Friend of Bill Clinton" or "Niece of your boss") is going to need someone else to pick up her slack--she's not going anywhere and her work has to get done.
• More benignly, whenever we ask someone to train their own replacement and move into a different role, both trainer and trainee are going to be less effective during that transition than they will be a little later.

On an agile team, that means that it's helpful for everyone to have a shared mental model of all the roles that need to be in place in order for the team to succeed, and a shared agreement about who will play those roles de facto: that is, for the purpose of this team, and for this project.  For best results:

• It's helpful if everyone really wants to optimize the team's productivity.
• It's helpful if the team doesn't insist that roles must be aligned 1:1 with individuals holding specific job titles, or even having specific experiences in their past.
• It's helpful to cast a very wide net initially to look at all the things that need to be done, and the skills and inclinations of team members.
• It's helpful for at least one person, a de facto project manager, if not the named one, to be able to identify skills gaps and seek help from the de jure authorities to get additional needed skills onto the team.

Agile teams, like any work teams, always involve constant little adjustments on everyone's part to make for a shared, somewhat harmonious, existence.  Especially in considering "here's what my PO ought to be doing" type situations, you can lower your blood pressure a lot by changing your frame to "here's what needs to be done.  De jure, Sandy ought to be doing X, but de facto, here's a different way that need could be filled, utilizing Dennis's talents instead."

In case you were wondering, I was attracted to the image I included in this post because it kind of looked like a full-frontal rendering of a judge's gavel, and I was going to use a lot of Latin today.  But in fact, it's a plunger design which was discussed in a legal blog about an unfortunate decision whereby the person who designed the plunger didn't get to claim the design as unique intellectual property, because he had patented the functionality, not the appearance.  A sad, cautionary tale for all of us.