All About Agile | Agile Development Made Easy!
Pair Programming
One of the agile practices I've never tried is pair programming. I can see the arguments for higher quality and more focused team members, but I can't get my head round the idea that output won't be significant less. I'm also concerned about how we would sell the idea of pair programming to the business, given the loss - or at least perceived loss - of productivity. When I budget for projects, I just can't imagine having to double the number of developers for everything. I would be grateful for any comments and advice, for or against...
James.
James.
Views: 88
Replies to This Discussion
-
Permalink Reply by Stavros Pitoglou on -
The basic idea behind pair programming is that programming / writing code is -above all- intellectual work. So two brains working together through a specific task perform better (maybe not always faster but always with greater quality). And in our profession, quality means speed and resources (in the mid-term). Think that with pair programming you reduce dramatically (if not eliminate) the need for code review. Also, in most cases, you effectively reduce the bugs and you keep your 'technical debt' as low as possible.
Of course it's not a 'panacea'. It has (in the most cases) long adoption time, even with highly qualified and dedicated teams.
And, most important, it depends highly on the individuals and their potential to develop good co-working 'chemistry'. Finally, all the team members involved have to be convinced that this methodology is worth the try. Pair programming can work only with 'true believers' or else you will find yourself in a situation with more problems than those you were trying to solve...
-
Permalink Reply by Robert Sfeir on -
To add to the first response, I would also argue that programmers are not 100% efficient when working on new code. Therefore your programmer is already spending his/her time trying to figure out what to do with the code and how to change it. Adding pair programming, and pairing that person up with the engineer that wrote the code, would allow the person with the new task to learn the code faster and finish the task more quickly.
I view pair programming as a learning tool, a way for programmers to mentor each other. It is not a direct way to increase productivity in the short term, rather it is a way to increase knowledge sharing in the short term, thereby increasing productivity and the team's overall skill level in the long term.
Budgetting by number of developers has its own issues as well, but I guess that's for another discussion.
R
-
Permalink Reply by Kelly Waters on -
Hi Robert. I'm curious. What do you mean about budgeting by number of developers? Don't you have to know how many people to budget for?
Kelly.
-
Permalink Reply by Robert Sfeir on
-
What I do is look at the number of user stories we have, how many points those user stories cost. Depending on how fast we want to go, I know how many developers I assign to the sprint and go from there. If I don't have enough developers, then the client simply knows that there will be multiple sprints to accomplish what s/he wants.
The team I run is a team of contractors, so adding folks is not an option. Further, we also are in an environment where we manage 8 different products. While they're all inter-related, they're all managed separately, each with its own sprints. So I have to look at what needs to be done, what is already in progress, and who is available to do the work. If I have 2 developers available then I work with those developers to figure out how many sprints it will take to get x number of user stories done over a 3-4 week sprint cycle. I have to adapt what I have, not the other way.
The result for us is a set level of expectations, known and stable quantity for the velocity, and a very efficient team that is able to adapt to greatly changing conditions and requirements. Of those 8 products we typically have 3 sprints going at the same time, for a team of 6 engineers, who know how to work on all the products.
Everyone's going to be different.
R
-
Permalink Reply by Endre Dingsor on -
..and to add to the two first replies: "how we would sell the idea of pair programming to the business". In a case of in-house programming it would probably be a case of trying, and let the results speak for itself. When it comes to sell the idea of "pair-programming" to customers in competition with other companies I've presented pair programming as a method of training in-house developers. It works well to transfer knowledge fast if the client wants to be able to support the system themselves after the project is completed.
And about double the amount of developers.. Pair programming can be used on particular parts of a project as well - great risks, new material, new developers etc. In some of these cases I've seen the team produce more - with greater quality - than what they did on their own.
-
Permalink Reply by Kevin Johnston on -
One thing to remember about great agile teams is they should be able to self organise so if pairing works for them they should be able to do it...the velocity of the team over a period of time will enable you to assess the capability of the team..ask the team if they will try pairing for a couple of sprints then try without pairing might be interesting to see the impact on velocity..in my experience we end up with much less rework as we have a much greater chance of achieving a state of Done Done...
-
Permalink Reply by Ilja Preuß on -
Our management was very sceptical about pair programming, at first. They allowed us to give it a try on a difficult feature and where surprised that it didn't take any longer than originally planned, at all. Since then, we are absolutely free on when to pair program.
And regarding less output, take a look at http://www.netobjectives.com/ap/download/pairing.pdf
-
Permalink Reply by John Reber on -
From a practical QA perspective pair programming gives testers (and other project members) greater and easier access to developers time. If I need to discuss anything around a story that a pair have just completed, be it automated tests, details of implementation etc at least one of the pair programmers can spare me some time whilst the other continues to code.
Over a period of time the shared knowledge garnered from pair programming means I'm rarely relying on a single developer for the information I need. Also the increase in communication within the project is greaty improved.
On the downside - it's clear that some people do not enjoy pairing with each other. But this is a project management issue which can be managed by the use of practices such as pair stairs.
-
Permalink Reply by Katie McCroskey on -
Convincing management of the benefits of pair programming can be a challenge if the concept is not properly understood. I often see the question "I'm paying two people to do the same work - is the task they are working on going to be done twice as fast or twice the quality, or a mixture? " Do people think this way about pilots and co-pilots?
Recently a similar question was asked on www.AgileShout.com and the community came up with some great supporting information. Hope this helps!
-
Permalink Reply by Urs Enzler on -
If you want to start then it's probably best to start on selected parts of the code. For example code that has to be reviewed anyway. This way you can get experience without added cost.
Afterwards, let the team decide how much pair-programming is benefitial.
-
Permalink Reply by Gertjan Assies on
-
A human brain has two sides or modes, the left side is the logical, functional mode, the right side is the creative one.
The person at the keyboard will be working with his left side, writing the lines of code focusing on the details, the one sitting next to him will be working with his right side, more thinking about the big picture how it fits with the rest of the program. my experience is that is this working together that improves quality and productivity. besides that it is in my opinion the best method to get knowledge into new/junior developers. I'm not saying to do it all the time, but at least for the more complex parts of the system. but like someone here already says, you have to leave it up to the teams themselves
© 2012 Created by Kelly Waters.
