Skip to main content

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.

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica