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.

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …