Unraveling the Developer Bias in Agile Development Practices

There is a contradiction that shows up in many books and articles on agile software development.  .  And I’m going to rant a little on one of them: the “developer” bias in Agile software practices.

Before I begin my rant, I’d like to tell you where it comes from.  I am an Enterprise Architect.  I am also an agilest.  I am a certified Scrummaster (for many years) and have been on many agile projects.  I’ve seen success, and I’ve seen failure.  I know that agile is good, but not good enough to overcome people who are determined to undermine change. 

I am currently engaged on a project to help an organization rewire their business processes.  All of their core processes.  Some of them are in software development… and that is where agile comes in, but some are in other areas (sales, account management, customer service, etc).  I see it all, not just the software engineering bits.

To make this work, we created a set of principles that we use to drive the conversation around transforming the company.  We train people on the principles.  We connect change to the principles.  The principles are developed from the agile mindset but are not the same as the ones traditionally tied to the agile manifesto. 

One is focused heavily on the notion of an empowered team.  As the trainer, I’ve embedded these principles into my head.  Kinda hard not to.  So when I’m reading a book on agile practices, and the author says something that violates one of these principles, it stands out.  Big time.

And hence the rant.  I was reading Mike Cohn’s book on agile stories and I came across a passage that reflects a kind of mindset that does NOT build empowered teams.  And I went off.  The rest of this post is my rant.

---

On one hand, there is a basic expectation that we should empower the team to solve their problems using their skills and training.  On the other hand, there is a bias towards having developers involved in every part of a business process, from sales through requirements to project management and out to delivery and customer service.  The net result: we are empowering developers to perform every role.  No one else is empowered.  They are, in fact, not trusted at all.

At some level, agile practices like XP and Scrum are written, and promoted, by software developers, so it is understandable that these authors believe that software developers are a necessary part of every process.

But they are not. 

So what’s the problem

Organizations intentionally create specific roles and groups of people.  Those roles are defined to take the most advantage of the intrinsic motivations of people when performing their duties.  The things that motivate a person to become a project manager, for example, are rarely the same things that motivate a person to become a software engineer.  Motivation matters. If you are not motivated to excellence, you will not perform with excellence.

While it is fine for an individual person to be able to perform well in a couple of roles, it is absurd to build a system or business process that expects all people in one role to be able to perform another role well.  In specific, it is absurd to build processes where a technologist is required to develop requirements, or manage a project, or plan the delivery of systems.  Those processes can be performed just fine with motivated people who are trained and experienced in those activities.  However, to empower a team, people in these roles must be respected as well. 

Agile software, that so values people over processes and tools, demonstrates an utter lack of respect for the individuals who choose to excel in non-technical roles by asserting the need for developers to be involved in every step of their process.

For example, in XP (and sometimes in Scrum), user stories are described as being developed by a “customer team” that includes developers.  In the book “User Stories Applied,” Mike Cohn describes a process where a series of user roles are developed.  From those roles, the stories will be drawn.  The following is a quote from the book:

To identify user roles, the customer and as many of the developers as possible meet in a room with either a large table or a wall to which they can tape or pin cards.  It’s always ideal to include the whole team for the user role modeling that initiates a project, but not necessary.  As long as a reasonable representation of the developers is present along with the customer, you can have a successful session. -- “User Stories Applied” by Mike Cohn

I’m an agilest, and this statement takes my breath away.  Why?  Because the SKILL of developing user roles is a good skill to have, but not a necessary skill for all developers to have.  Yet the author (whom I respect) assumes that the activity cannot be performed successfully without developers in the room!   At the same time, the text assumes that the task can be performed by developers exclusively (no one else is necessary at all).

The time that we spend training developers to be good at creating user stories is time that we are NOT spending training them on concurrent processing, idempotent messaging, and query optimization.  We don’t train business analysts or engagement managers on C# design patterns, so why should we train developers on user role modeling and requirements analysis?  It’s a total lack of understanding of the value of roles, and it is a bias that works against success.

What’s the solution: respect

 

Roles are not boundaries.  In any team, there are roles.  More importantly, as a member of a team, I have to trust my team members to fulfill their roles well.  If they need help, I TRUST THEM TO ASK FOR HELP.  When they do, I am happy to “cross roles” and provide help.  When I provide help, I am doing so from the perspective of a less-skilled resource, and under the supervision of the accountable role.  (e.g. if I “help” a tester, but don’t document a defect according to team standards, how much “help” am I actually providing?)

Roles are empowering.  If my team member does not ask for help, I trust each one to perform his or her role with excellence.  If I don’t trust them, how can they develop the excellence that the company expects?  How can they be recognized and rewarded for excellence if our processes and methods show a lack of trust in their roles to perform well without a developer present? 

Roles demonstrate respect.   As an agilest, I value people over processes.  That means I value the contribution of individual experts on my team to do their work with excellence, and I will show them respect for the work that they do, and the unique value that they contribute.  I will do so by allowing them to do their work without the “supervision and assistance” of a developer.

If they need me, they will ask for me.  Until then, I will get to doing what I do best.  I have a job to do, after all… and it is mine to do well.

Why this matters

Agile software development solves a problem.  The problem is that we are including waste in our processes, and that waste is causing software to be delivered late or with poor quality. 

If we optimize our processes, we can reduce waste. If we include developers in every process, we are not optimizing our processes.  We are, in fact, replacing one kind of waste with another.

Comments

• Anonymous
  April 16, 2013
  I think you are conflating two different uses of the term "developer".  In the classic sense, developer means the person that is typing code into a compiler.  In the agile (or at least Scrum) sense, "developer" is anyone who is not the Scrum Master or the Product Owner.  This is made pretty clear in the Scrum Guide.   So I interpret Mike Cohn's statement to be saying that a reasonable amount of the team members (not just the Product Owner) need to be present when clarifying requirements with the customer.  There is nothing wrong with this position.  Obviously, if any members of the "developers" group has skills that relate to requirements gathering, you'd prefer to have them in the session over someone that has more of a classic developers' skillset.

• Anonymous
  April 16, 2013
  Hi Justin, I love this phrase, "in the agile (or at least Scrum) sense".  To take the scrum "sense," you accept the scrum assumptions which include the assertion that developers (erm... 'pigs') are the only role that knows how to "get things done."  Massively disrespectful to the honest, hard working people who are not coders and testers.  After all, according to Cohn, you need developers in the room to "model user roles" (not even collect requirements... this is at the step of "understanding the roles that a user can play"... requirements or stories come LATER). And a business analyst (product owner) can't model user roles?   If I trust my product owner to do an excellent job, why do developers need to be there at all? If I don't trust my product owner, why would adding a developer solve the problem?  Why not add a product owner who DOES know how to do user role modeling? Is user role modeling such a difficult skill that a good business analyst can't do it?  If so, why would a developer do it any better?  If not, what am I saying by requiring a developer to be present?  I'm saying that I trust developers, only.   You are CORRECT that Mike, in saying "developers" probably meant to include testers.  But he probably did not intend to include PMP Project Managers, or business analysts, or deployment technicians, or account managers.  He meant technologists. And why would technologists be any better at that task than an account manager, or a deployment technician, or a project manager, or (G-d forbid) a well trained business analyst?  They wouldn't.  

• Anonymous
  April 17, 2013
  I think linking developer involvement with their involvement in creating user stories is missing the point. Developers should be involved in the creation of stories not to empower them, but to make sure that the stories are understood by them, to ensure that they are feasible, etc. it's not about empowerment, it's about doing what you can to ease delivery, which is what everyone wants. If you hire a builder or engineer to extend your house, you need to involve them in defining the requirements so they can say "that will take weeks", ask questions, etc- not to make them 'empowered'. Likewise, it wouldn't be a good idea as the house owner to don a hard hat and start swinging a sledgehammer. It's about sharing knowledge, increasing communication, and ensuring delivery is smooth and aligned with requirements.

• Anonymous
  April 17, 2013
  Sorry, first "involvement" should read "empowerment".

• Anonymous
  April 19, 2013
  The comment has been removed

• Anonymous
  April 22, 2013
  Hi Mark, The specific example is interesting.  At this point in the process, there are no user stories yet.  There is a customer.  There are developers.  While I utterly respect Mike Cohn, he doesn't mention the product owner role at all.  There is no other role described. It is clear from the text that, if there were another role, it would not be respected.  He doesn't ask for two developers.  He asks for "enough" developers.  Any reasonable person would assume that to mean "all the smart ones" or "a majority of the team."   So what are these people actually doing? are they collecting requirements? nope. They are creating a list of user roles and/or personas to FRAME the requirements. That is a very specific skill.  Not a terribly difficult one, but very specific.  It is NOT useful in software development.  Just as learning how to write code that reads an XML file into a DOM object is a very specific skill.  Not useful unless you are a developer.   This skill is not a developer skill.  It is a requirements - gathering skill, often the job of a business analyst, sometimes the job of a project manager, occasionally the job of a lead developer (singular), rarely the job of a sales professional.  Nearly never the job of a programmer. But, according to Cohn, it won't be successful unless a programmer is in the room.  Cohn says nothing about "knowledge transfer." And, no, I DON'T invite the brick layer into my conversation with the architect or master builder when deciding what my renovations will look like.  (although I don't usually select construction metaphors when discussing agile development, since it's tough to "refactor" a concrete foundation). Waiting until the majority of the development team is available to have a conversation with the customer about the various roles that will interact with the software is bizarre and naïve.  An ideal agile requirements session would have an analyst to gather requirements, possibly a senior technologist who understands what is feasible to help guide the expression of requirements, possibly a salesperson who is in the process of handing off the relationship to the development staff, and of course, as many customer stakeholders as you can get.  It can be a single meeting or a series of interviews, depending on the situation.  (Read the IIBA's BABOK).  The only two people that are actually necessary: the analyst and the customer.   The technologist is option.  Even when present, he or she is RARELY the developer of this system.   If my home were being renovated, I would NOT want a conversation with the bricklayer, the carpenter, the electrician, the plumber, the roofer, the landscaper, AND the architect, all at once, where I talk about the desire to "open up my living room" and to give me another bedroom on an upper floor. With respect, --- Nick