11

I'm on a team that is currently using Scrum, and we're considering adding pair programming to help improve the cross-functional skills of the team, as well as help reduce defects with a "two heads are better than one" philosophy.

On our team, each team member typically signs up for a full workload during sprint planning (with "full" being a number that is less than 40 hours a week, allowing for meetings, collaboration, etc.), with a single dedicated owner for each task. I believe this is fairly common on Scrum teams but may not necessarily be by the book.

In particular, I'm looking to avoid a situation where team members are hesitant to pair because they have their own tasks to work on, which I'm afraid is likely to happen if the team simply self-organizes without time set aside for pairing.

Given this, what is the best way to account for effort/hours/story points in a pairing scenario, to make sure we have appropriately allotted time for pairing?

Some options considered are:

  1. Allow two people to sign up for each task and (roughly) double the number of estimated hours
  2. Only the "hands on keyboard" team member signs up for each task, which is estimated based on that person's estimated hours. Anyone on the team who will be supporting pairing will sign up for fewer tasks in the sprint to allow time to support pairing.
0

4 Answers 4

4

The most common option I have seen when pair programming is employed within scrum is to double up the development estimates.

That is, if the task is estimated to take 3 hours for one person, the time allocated would be 6 hours for the pair.

Substitute hours for points if that makes you feel more clean ;)

1
  • Thanks Oded. This answer most concisely answered my specific question. However, a big thanks to DXM who helped to identify the root cause, which is more people related than process. I wish I could accept more than one answer.
    – Cliff
    Dec 30, 2011 at 22:25
15

I think others already provided good answers but I'll add mine only because I think your team just transitioned to Scrum and now you guys are in a very similar position we were when we started.

First off, our introduction to Agile and more specifically Scrum wasn't very smooth. Basically management came down and said, from this day forth you shall do Scrum and this is a process you will all follow. So much for People over Process.

The process we originally followed (blindly, I might add) ended up very similar to how you described. People get assigned tasks, everyone gets booked and we all go back to our desks and plug away. Then we have a boring stand-up meeting every day.

The key to realize is that Agile, and Scrum included, is actually about people. When the team goes into iteration planning, don't let your Scrum master (who is probably your manager) to assign you hours, stories and tasks. It is completely UP TO THE TEAM. I think for a lot of people this is a very hard concept to get through because for years before that they'd come to work and they would have a boss (manager, technical lead...) who would simply assign work. They dive into Scrum but everyone (including scrum master himself) continues to operation in the same mode.

One day, you'll get sick of this, so you'll start reading books, blogs and keep asking questions like this on stack exchange. The realization that you will get is that you as the developer and your teammates should be the driving force behind committing to stories and assigning tasks. If you guys feel you will benefit from pair programming, by all means create a 2 tasks for each of the engineers and assign both of them hours. The only thing scrum master should be doing is measuring velocity against completed stories that you delivered AS A TEAM in the previous iteration.

Also another thing that bugs the crap out of me is how people are told that their capacity IS ALWAYS 75% of total hours, so that's what they commit to and then for the entire duration of the iteration they complain that a) they can't help you or b) they can't do the right thing because they've been assigned too many hours. People should not be told how many hours to commit and they certainly should push back if scrum master is attempting to pull something like this! Everyone should commit to exactly what they are comfortable with. For example, I'm a team lead and frequently I'd end up in a random unplanned design discussion, or helping someone with code, or with troubleshooting weird stuff, so my capacity is never above 50%.

It took our team 4 release cycles to learn not to do the things I just mentioned and even though we've definitely improved, if you ask the experts we are not even half agile. So still a lot of learning to do.

Update 1: Response to Cliff's comment Well you offered your ears so here it is...

You are right, cultural shift is key, but this shift doesn't need to happen at the executive level. Your own group manager can change the culture within your team and isolate you guys from corporate BS that he has to deal with. What you are describing was EXACTLY us about from 2007 to 2010. Our team (and other teams as well) flopped release after release. In one of the releases using management's "process for being agile" we manage to have 9 people produce the work that would usually be done by a single person and it took us double the time. I had so much free time, that I even updated my resume.

Then, I had a conversation with my boss and explained all these things to him how agile is about people and that if you want us to care about the product, let us make decisions that affect how we work on and deliver the product. I think he decided to make it an experiment out of it, he made every single change we... well, mostly myself, but I talk with the rest of the team a lot, hence 50% capacity :) ... proposed. It's possible that he figured that if he makes all the changes we are asking for and we still fail, he'll come back with a victorious "I told you so".

So in the last 12 months, we've eliminated so much "stupid" it's not even funny. Our stand-up meetings actually make sense now because we work together, not in isolation. We still have ownership (at least for now) of specific parts of the product, but we also cross very frequently into each others' code. We constantly do code reviews so that not only team members learn other code, but they also learn better coding and design techniques. We've broken monolithic, giant "agile" team into 3 different teams so planning and other meetings are much shorter and people actually care about them because they don't sit around and listen about things they don't care about. I've seen nights when 4 out of 5 of our guys (one of the teams) would be online at 11pm at night and nobody actually told us we have to work hard or ever pressured us to work over 40 hours. People who couldn't care less half a year ago, all of a sudden are engaged and excited about the work they are doing. And all it took was for our manager to do was say, "you guys decide what is right and do what you need to do and I'll keep corporate BS out of the team as much as I can."

It started as experiment (my suspicion, he never told me that), but now our group is kicking butt compared to other development groups in the department and we even have other developers who are now trying to come over and join us.

The biggest hurdle for us ever since this change happened (and still a problem today) was the fact that engineers in normal corporate environment are like experimental mice in a cage. Even when your manager decides to go truly "agile" and removes the cage, everyone has been in that cage for so long, they don't even realize they are free. So even with all the freedom, they continue acting as if they are still constrained. I think what would help is to have at least few people on the team (such as yourself), who go outside the boundaries of the group and seek out better ways of doing things. Then come back into that group and stir it up a little.

In your case, maybe paired programming isn't a solution if you are looking for another external force to come down onto the team and tell them how to work. Instead, throw the rules out, sit down with them, without management, and ask them what they want to do? What will make them happy? Productive? Identify the biggest problems and then ask THE TEAM what they think solution should be.

5
  • I totally agree. Part of the problem is that the Agile philosophy isn't well ingrained in the development culture, and we are trying to fix this with process, where ideally it should be fixed via a cultural shift. Without task sign-ups, team members either took a "not my job" attitude toward tasks (for one thing, the team is not really cross-functional, which is one of the reasons we are looking to implement pairing), or they became easily distracted. The result was an imbalance in workload among the team. I'm all ears to suggestions on how we can solve these issues with less process.
    – Cliff
    Dec 23, 2011 at 4:55
  • Thanks for updating. Management has actually been very supportive and hands off in allowing the team free reign to define the "how". But I think part of the core problem is that the team lacks a cross-functional mindset. For example, the team has created imaginary walls of un/accountability based on individual skill sets. On one hand, team members feel very empowered and take ownership for portions of features that are in their self-defined functional areas, but on the other hand they don't feel accountable for portions of features that are not in their functional area ("not my job").
    – Cliff
    Dec 23, 2011 at 5:59
  • Sounds like already took several steps in positive direction. So now that you identified major area for improvement, have you presented this to the team and ask them to propose solutions? If yes, did they come back with paired programming? If yes, then by all means, assign whoever wants to work together to the same story, create multiple tasks and put coding hours next to each person. If no, have you asked them why they are so hesitant to cross a functional boundary? In the end if they think they'd be more effective without crossing, maybe real solution is somewhere else.
    – DXM
    Dec 23, 2011 at 6:46
  • "Not my job" means "I don't care" and it is your biggest problem. Agile is for developers who care and who are able to take responsibility. Team has responsibility for the product. There is no "I have responsibility for one part" = team member must care about whole product. Why do you have functional areas? Is it because your product is so big? Dec 23, 2011 at 9:25
  • @LadislavMrnka: Although there might be some people on the team who simply don't care, and I think that's ok. Those people will become work mules for bugs and crap work because major decisions, product direction, architecture and design will go right past them. But you still need someone to deal with tech support :). I think most of us do care about what we do. And if the whole team has "not my job" attitude, I think the root cause is some other external factor which needs to be singled out and eliminated. Without doing that, it'll be impossible to mandate to the team "you must care".
    – DXM
    Dec 23, 2011 at 9:42
2

Scrum does not mandate that tasks be assigned to individuals--far from it. The responsibility for tasks to be completed fall on the Team as a whole. If the team wants to do pair programming, where each pair picks up a task, they most certainly should do so.

From the Scrum Guide:

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product increment. Work may be of varying size, or estimated effort. However, enough work is planned during the Sprint Planning meeting for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or less by the end of this meeting. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint.

3
  • 1
    Interesting. I have the March 2009 Scrum Guide and they actually changed that quote. It used to be: "The Team self-organizes to assign and undertake the work in the Sprint Backlog, either during the Sprint Planning meeting or just-in-time during the Sprint."
    – Cliff
    Dec 22, 2011 at 22:12
  • Our interpretation has been to always create an initial set of estimated tasks for each backlog item and assign them to individual team members during sprint planning. A couple of the benefits are that it helps us to effectively balance the workload among team members during planning, and with an assigned owner for each task, it makes it easier to make sure we're not missing anything. It also helps with capturing metrics.
    – Cliff
    Dec 22, 2011 at 22:12
  • @Cliff - If that's the way you want to do it, it's fine. All I am saying is that Scrum doesn't say you have to do it that way. If you'd rather assign items in pairs (which we generally do as hit-by-a-bus insurance), that's fine too, and you could easily work out metrics based on pairs. Dec 22, 2011 at 23:00
0

Assigning tasks on planning meeting is exactly what goes against just it time decisions and empowering the team. It also goes against sprint agility because since day one in a sprint every developer has exactly aligned what he should do. It also means that every task must be very correctly estimated which is almost never the case.

Imho estimating tasks is redundant. You have committed to set of stories and planning meeting 2 is just enough time to split those stories into tasks and create cards for those tasks (or fill them to some system). There is not enough time to estimate each task and these estimation should not consume time for real development.

Why? Estimation is a garbage. How it can be a garbage? Because doing more estimation will not bring more business value = it is garbage and should be reduced to necessary minimum. The minimum is estimating / sizing stories which helps you to do commitment. Once you did a commitment you don't need any other estimation. You just know that you have fixed date to deliver something you have committed. You will either be able to deliver committed stories or not. Estimating tasks will not help you in that delivery.

Skipping task estimation will in no way affect visibility into sprint progress because the only real measurement of the progress is number of completed stories (story points) and that can be still showed in sprint burn down chart.

Just to make it clear. Commitment means = We will do it. Not we will try to do it or anything other. Yes, you can fail to deliver what you have committed but your commitment should be based on your belief that with your current knowledge you will deliver selected stories. If you have this belief you don't need another estimation.

I always used Scrum in the way where developer choose a new task once he completes his last one. Developers usually say which one they are going to choose on stand-up meeting. Generally there are no rules which task he should choose. It is up to team self-organization and discussion between team members (outside of stand-up meeting). That is postponing decision to the latest possible point where you can react on some changes and problems without affecting your imaginary plan. The task itself can even change the owner if somebody has some problems to complete it - alternatively such task can be developed in pair.

How can pair programming be involved in this? Easily. Team does commitment and team must make it in the way to make space for all development techniques needed to deliver the working increment of the product. Do you estimate a task or task development and task testing? The latter approach is completely wrong. The testing is part of development and in the same way the code review or pairing is part of development if needed.

Doing pair programming should result into completing task faster with smaller amount of bugs and better code quality. It will not be twice as fast so there will be still some overhead but the real impact on commitment caused by occasional pairing should be very small. This is not a case for mentoring or teaching. If you have such developer which needs to be mentored or taught you should not plan his capacity at all for sprints where he learns the product's code base or some technology.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.