Roles and Responsibilities


Me – “The team is responsible for Quality!”

Dev Mgr – “Yeah, I hear that, but what will help is to go one level deeper – let’s realistically identify what can and should be done by “developer” and “tester” resources.”

Lots of managers and their employees (and HR) struggle with this concept of team responsibility.

Clearly there will sometimes be tasks on stories that involve a level of coding skill that can only be done by someone with the title of Developer. There also will be some tasks that would be much more efficiently done by someone with years of testing experience. This doesn’t change the fact that when you commit to stories in a sprint, you’re expected to get those stories done. It doesn’t matter who is actually available to do the work.

Let me explain.

In the beginning of each sprint, the delivery team takes “Ready” stories from the backlog and works through them and creates tasks and estimates them. The team should know what their capacity is for that period of time. This means you should have an idea of how much time it will take to code and test and otherwise produce that work. All of it, not just the coding. If people are unavailable that sprint, clearly you should take on less work. If some of the test-related tasks don’t fit within the capacity of the testers you have on your team, you have a choice: either remove some work from the sprint and use the extra time for the programmers to do training and/or help with other projects outside of the team OR have other members of the team take on the remaining testing tasks.
If testing, or any other specialization on the team, is causing a bottleneck, the answer isn’t to shove more work into the bottle! What you do is work together to keep the flow going. If that means programmers doing more testing, fine. If that means testers doing more tasks that traditionally fall to programmers, fine. If that means analysts doing the same, or any other permutation, fine.

If something doesn’t get coded – that’s not a single programmer’s fault. The team should have known about it. If something doesn’t get tested, that’s not a tester’s fault! It’s the team’s fault for not making sure it got done. Blaming isn’t a productive method of getting things done. We succeed as a team and we fail as a team. And when we succeed, we reinforce and build upon the things we’re doing right. When we fail, we recognize the reasons for the failure and work to improve for the next sprint.

Let’s go back to the discussion – assume I said all that stuff above.

Dev Mgr – “Alright – so we come up with tasks together and then assign them to people – that will lock them down and we’ll be able to tell Project Management what resources we have free, or what resources we need to get the work done in this sprint.”

Me – /sigh

Note that making sure you have the capacity isn’t the same thing as assigning tasks to people. Tasks, optimally, should be pulled by people capable of the work only at the point in time that they can start working on them. It isn’t efficient to have a task assigned to someone who’s working on something else while another person could be doing that task. Now you may *know* simply because of the nature of the task that a particular individual has to do it. That’s fine. But be aware that’s risk you’re taking on. If nobody else is capable of that work, then you have to be very sure that particular individual has the capacity in that sprint to do that work. If you have a lot of work like that, it would be advisable to pair that person with someone to work on the tasks together. After a time, then you’ll have two people capable of doing that kind of work and you’ve lessened your risk!

Me – “So you’ve got it now, right? You’ve got a cross-functional team that self-organizes. You don’t need to assign tasks to anyone or wrangle with Project Management over time estimates and the availability of people.”

Dev Mgr – “Resources.”

Me – /sigh

  1. #1 by PM Hut on October 24, 2011 - 9:12 am

    Quality was always an issue in the last company I was working for. I believed that it is the developer’s responsibility to ensure that his tasks are very well done, and not to write poorly written or poorly tested code and wait for the tester to unveil the bugs. Others (especially the developers), believed that the opposite is true: why should they spend time testing their code when someone else was doing this for them.

  2. #2 by Eric Jacobson on October 27, 2011 - 12:33 am

    Great post. So much easier said than done. I think the programmers took the job in the first place to write code that ships, not test code. And the testers are too stubborn to let the programmers test. People prefer to stay in their comfort zone. Your post is about convincing the manager. How can we convince the Do’ers?

    • #3 by Alex Kell on October 27, 2011 - 3:12 am

      So why is it such a big deal? As long as stuff gets done eventually, it’s fine. Right?
      We all have to honor our commitments. If we don’t, what does that say about our respect for our coworkers or customers? And what about ourselves? I know I don’t want to be the guy that never delivers on what he says he’s going to do. Nor would I want to be on a team that doesn’t.
      But that’s just the integrity aspect. Establishing a stable velocity is a major key in a successful agile implementation. Being able to count on commitments lets the business know what they’ll be getting (or not getting) for their money. If we can’t, it sounds a lot like traditional SDLC. If we don’t have that promise of predictability, what’s the point in changing?

      So yeah, how can we convince the do’ers? Tell them that they should do what they say they’re going to do. We form teams and self-organize and decide on what we can do, for ourselves, and then we do it. I’ve given what I think is one of the best ways to accomplish this. If meeting commitments isn’t important to the team…well, there you are.

  3. #4 by Victor on November 2, 2013 - 3:41 am

    In the end, a working, good looking product, so if that means developers doing more testing, or testers building packages, or modifying databases, it’s all for the team’s benefit, so it shouldn’t be a problem for anyone.
    I’m a tester, and I’m never too stubborn to let programmers test. It makes my job easier, makes the development process move faster and it results in a better, overall release.

Leave a Reply

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

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

Facebook photo

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

Connecting to %s

%d bloggers like this: