Developer Owns a Story – Good Idea or Bad?

One aspect of the transition to Agile is the switch to truly team-based work. Like all aspects of significant change, it can be difficult to get it to take hold. One of the anti-patterns that coaches see from time to time is when a single developer takes over the development of a user story and works on it alone. This is a pattern that shows up in more traditional environments and it is a shadow of the more extreme “cowboy coder” phenomenon. No matter the details, it is the opposite of the kind of swarming, tightly knit team approach that we depend on in scrum to give us some extra oomph.

I have seen this “developer owns a feature” a lot. What does it lead to? If “dev owns…” then they typically work alone on the feature. So then end up coding and then handing off to QA. In other words, they’re back to where we started with serial phased waterfall development. You will also see, miraculously, the same number of stories as developers. Each developer will take one, and none of the stories will complete until the end of the sprint, when some of them will complete and some won’t. So you lose the benefit of swarming and you also lose the benefit of moving testing forward in the development process.

(My current company uses Pivotal Tracker, which is one of the online tools that actually have a field called “Owner” for each story. Rally has one, too, as do other Scrum tools. I have no idea why that field is there or called that, but it is one of those cases where a tool encourages bad behavior. )

Let’s think about this. If a developer owned a feature, or a set of stories, and other developers and testers worked on those stories, too, then would there be a problem? Not so much, IMHO. In fact, there are some nice side effects of such a model. Being the owner of the story or theme or feature or set of stories becomes a kind of scrum-oriented technical leadership position. The position lasts as long as the story or the feature is being developed. This person can be the domain expert and can “lead” the design of the feature, and they can also mentor the others working on it. Using this approach I have found to be helpful when trying to map scrum into existing performance review and promotion models. I mention this because the thing that is so poisonous is not “developer owns a feature” but “developer owns a feature and works alone on it until coding is done.”
So how do we get from “developer owns a feature” to “team owns a feature”? As a coach, I think it’s important to find a way to evolve there rather than try to just legislate it. Just saying “no more dev owns a feature” sounds like you’re taking something away from people. People will resist. Can we find a stepwise way to evolve this? I think this is the coaching challenge here.

One thing I tried that was not perfect but it helped, was to emphasize the risk management approach. Obviously, it’s nice to have an expert who can work within a domain faster than anybody else, but if you only have one guy per domain, you run the risk of not being able to do any work in that domain if your guy goes sick or leaves. Then you are way behind the eightball. (I used to try to convince people that it wasn’t necessarily true that the most experienced guy in the domain goes the fastest and writes the best code, but that one is a tough sell. There’s even that cute story about the teams that chose to work only on things they didn’t know about and it actually increased their velocity, but people don’t believe it.)

So, back to risk management. Even the most feature-hungry, speed-freak executive should fear having zero people who can work on a problem. Having just one is the same as having a single-source supply chain. It’s a disaster waiting to happen. It is Management 101 to work to mitigate risks like this, and the way you mitigate risks like this in Scrum is you spread knowledge. In scrum you spread knowledge by allowing or encouraging people to work on new tasks. People working on a new task use the experts on the team to help them learn enough to complete the task. I would argue that the manager of a scrum team that doesn’t do this is guilty of bad management, from the company’s point of view. That manager is not doing risk management. So you work to get the idea of knowledge distribution to be a part of what the team is expected to do and it starts to break the “developer owns a feature alone” pattern.

Here’s another evolutionary approach: mentoring. In most large companies, experienced engineers are called upon to help younger engineers learn. In many companies, it is considered a part of the senior job descriptions and they are often graded on their mentoring activities at review time. In the old, “wasterfall” days the way people would learn new things was their manager would say “Sure. Go ahead but don’t spend more than 10% of your time on it.” That was because we had no other way back then to cleanly allocate a small amount of somebody’s time and energy to a specific thing like learning a new domain. In scrum we can do better. Why not let an experienced person mentor an inexperienced person in the scrum way…by helping the inexperienced one work on a task with which she is unfamiliar?
What happens when we let somebody take a task on an unfamiliar story and plan to ask the ‘lead’ any questions? Well, you then have two engineers working on that story! One is the experienced one and one is the newbie who is learning. Two engineers on the same story? Why, it almost sounds like scrum!

The point of the preceding two ideas is that they are a way to start to get more than one person involved on a project without having to win an argument.

Once you can get tasks to move around, the rest will follow without having to coerce people. That is my experience, anyway. The thing I like about this evolutionary approach is you don’t have to have a big fight or debate with anybody up front. You don’t have to make people do large change. All you have to do is find one person who is willing to take on one task for the pure joy of learning. And it’s usually easy to find some engineers who want to learn new things. If you can’t find one of those in your organization, you have other issues.

About these ads

One thought on “Developer Owns a Story – Good Idea or Bad?

  1. I always thought that the “owner” field for a story in these tools was to indicate the product owner with authority to accept it — in cases where there is a product council or someone who is responsible for making sure there is business value in the story. I don’t see developers owning the stories too often in Scrum, but all the time in Kanban.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s