A lack of defined engineering practices, standards and tooling is an often observed problem in software development, regardless of whether Scrum is used. It reflects the appalling lack of attention to technical excellence in our software development industry. In a context of Scrum, it is even more estranging. Scrum does not predefine any of such practices, but Scrum cannot be employed to its full extent if they are lacking.
Scrum implements empiricism, the process of frequent inspections and adaptations. Inspections happen against standards, agreements, goals and expectations. Inspections are done by those having skin in the game. When employing Scrum for software product development, a team can't operate effectively without well-defined development standards and practices.
At every event I visit I check for people's awareness and use of eXtreme Programming. Even if awareness is good, practical use is mostly poor. If any, the most implemented practices from eXtreme Programming are the more technical ones, like TDD or CI. The one that is often overlooked is Pair Programming. Unfortunate, as it's a very powerful practice.
Pair Programming is about quality in the first place. It’s certainly not about the opportunity to always work with one's best friend. And pair programming is also not about 2 people writing the same code. Much of the success of pair programming, in how we have experienced it, lies in the roles and the rotation of pairs.
Sprint Backlog is made up of forecasted functionality and its decomposition in development work. A good practice we use is to have team members take the ‘lead’ in seeing a Product Backlog item being created end-to-end. At the start of the day the pairs are formed, holding that the leads look for the right ‘partner’ to work with on the development work that lies right ahead. After lunch the pairs are rotated. The lead once again looks for the right ‘partner’ to work with during the second half of the day. This rotation offers team members the opportunity to get the best possible help for any given problem every half day.
Within the half day that a pair works together, they take up a second set of roles. The person holding the keyboard and mouse is called the ‘driver’. The second person is the ‘navigator’. The driver focuses on writing code, while the navigator minds respect for the overall direction and design. Within the half day that the pair works together, the roles of driver and navigator are switched frequently. The control over mouse and screen frequently goes from the one to the other, and back. It depends on the specific code being written, whether either of them has done this already before, whether someone has a great idea, etc.
The separation of driver and navigator assures that activities that a single programmer would do in a serquential way anyhow are performed in a parallel way (write code, compile, sit back and check, read again, verify coding standards, check naming conventions, consider the design). The person minding the road, writing code, gets immediate feedback, even while the writing is happening, by the navigator who is minding the overview, the overall direction.
And you might as well not complicate your way of working by having to decide when to or not to pair program, in what areas, on what type of work, etc. Just do it all the time. If simpler work pops up which is too easy for 2 people to collaborate over, let the ‘partner’ do something else. That may be some research, a little spike, a break.
Doing work in parallel that otherwise would be performed sequentially explains why pair programming has no higher cost than single programming. The driver and the navigator don't perform the same work. There is no additional overhead created neither. And the nasty (future) effort of rework is prevented. Waste is prevented.
A little example
Suppose a task estimated at 10 hours performed by a single programmer actually takes 10 hours (to the extent that this can be predicted). The same task performed by a pair takes 5 hours to get finished, but as this time is consumed by 2 people the total cost remains the same. Early studies on pair programming though indicated an increase of the cost with 10%, holding that in my example a task of 10 hours performed by a pair would take 11 hours. To be clear, it is not my experience. In none of my projects has pair programming proven to be more expensive.
Mind however simplistic thoughts over the time gains. It is not like a total volume of work is suddenly ready in half of the time. Obviously on a certain volume of work, the elapse time tends to be the same. If 4 tasks of 10 hours need to be performed by 4 single programmers it will lead to an elapse time of 10 hours, and a total cost of 40 hours. Get the same tasks done by 2 pairs (still 4 people) and they will take the same time, each pair performing 2 tasks. Elapse time is still 10 hours, and total budget is 40 hours.
Obviously, pair programming results in a lot of communication, makes the room look like a madhouse (when observed from the outside). This is good. This shows the high energy levels, it is not chaos.
As an organization, pair programming should be promoted for reasons of quality first. Early studies found a decrease in defects and rework with 60% and more. So, even if initial budget would be +10%, which I defy, the decrease of rework alone makes it more than worthwhile, from a total cost perspective.
Pairs also produce less lines of code to get the same functionality to work. They create lighter applications with lighter architectures that are easier to maintain. It lowers the TCO.
A great additional advantage of pair programming is knowledge sharing. By the pair-based collaboration people get insights in other skills, work on other layers of the application, different modules of the system. It allows not having to waste time on getting new team members up and running. They just join the pairs. We even encourage new team members to take the ‘lead’ over a story as soon as possible (and never longer than one week after joining the team). Because it is the best and fastest way to get introduced in all aspects of the software product and be assured of the assistance of the best placed partner, every half day.
In short, turn Pair Programming into a daily practice helps you turn quality into a habit.
Scrum implements empiricism, the process of frequent inspections and adaptations. Inspections happen against standards, agreements, goals and expectations. Inspections are done by those having skin in the game. When employing Scrum for software product development, a team can't operate effectively without well-defined development standards and practices.
At every event I visit I check for people's awareness and use of eXtreme Programming. Even if awareness is good, practical use is mostly poor. If any, the most implemented practices from eXtreme Programming are the more technical ones, like TDD or CI. The one that is often overlooked is Pair Programming. Unfortunate, as it's a very powerful practice.
Pair Programming is about quality in the first place. It’s certainly not about the opportunity to always work with one's best friend. And pair programming is also not about 2 people writing the same code. Much of the success of pair programming, in how we have experienced it, lies in the roles and the rotation of pairs.
Rotation and Roles
Sprint Backlog is made up of forecasted functionality and its decomposition in development work. A good practice we use is to have team members take the ‘lead’ in seeing a Product Backlog item being created end-to-end. At the start of the day the pairs are formed, holding that the leads look for the right ‘partner’ to work with on the development work that lies right ahead. After lunch the pairs are rotated. The lead once again looks for the right ‘partner’ to work with during the second half of the day. This rotation offers team members the opportunity to get the best possible help for any given problem every half day.
Within the half day that a pair works together, they take up a second set of roles. The person holding the keyboard and mouse is called the ‘driver’. The second person is the ‘navigator’. The driver focuses on writing code, while the navigator minds respect for the overall direction and design. Within the half day that the pair works together, the roles of driver and navigator are switched frequently. The control over mouse and screen frequently goes from the one to the other, and back. It depends on the specific code being written, whether either of them has done this already before, whether someone has a great idea, etc.
The separation of driver and navigator assures that activities that a single programmer would do in a serquential way anyhow are performed in a parallel way (write code, compile, sit back and check, read again, verify coding standards, check naming conventions, consider the design). The person minding the road, writing code, gets immediate feedback, even while the writing is happening, by the navigator who is minding the overview, the overall direction.
And you might as well not complicate your way of working by having to decide when to or not to pair program, in what areas, on what type of work, etc. Just do it all the time. If simpler work pops up which is too easy for 2 people to collaborate over, let the ‘partner’ do something else. That may be some research, a little spike, a break.
The cost of pair programming
Doing work in parallel that otherwise would be performed sequentially explains why pair programming has no higher cost than single programming. The driver and the navigator don't perform the same work. There is no additional overhead created neither. And the nasty (future) effort of rework is prevented. Waste is prevented.
A little example
Suppose a task estimated at 10 hours performed by a single programmer actually takes 10 hours (to the extent that this can be predicted). The same task performed by a pair takes 5 hours to get finished, but as this time is consumed by 2 people the total cost remains the same. Early studies on pair programming though indicated an increase of the cost with 10%, holding that in my example a task of 10 hours performed by a pair would take 11 hours. To be clear, it is not my experience. In none of my projects has pair programming proven to be more expensive.
Mind however simplistic thoughts over the time gains. It is not like a total volume of work is suddenly ready in half of the time. Obviously on a certain volume of work, the elapse time tends to be the same. If 4 tasks of 10 hours need to be performed by 4 single programmers it will lead to an elapse time of 10 hours, and a total cost of 40 hours. Get the same tasks done by 2 pairs (still 4 people) and they will take the same time, each pair performing 2 tasks. Elapse time is still 10 hours, and total budget is 40 hours.
Quality (and other effects)
Obviously, pair programming results in a lot of communication, makes the room look like a madhouse (when observed from the outside). This is good. This shows the high energy levels, it is not chaos.
As an organization, pair programming should be promoted for reasons of quality first. Early studies found a decrease in defects and rework with 60% and more. So, even if initial budget would be +10%, which I defy, the decrease of rework alone makes it more than worthwhile, from a total cost perspective.
Pairs also produce less lines of code to get the same functionality to work. They create lighter applications with lighter architectures that are easier to maintain. It lowers the TCO.
A great additional advantage of pair programming is knowledge sharing. By the pair-based collaboration people get insights in other skills, work on other layers of the application, different modules of the system. It allows not having to waste time on getting new team members up and running. They just join the pairs. We even encourage new team members to take the ‘lead’ over a story as soon as possible (and never longer than one week after joining the team). Because it is the best and fastest way to get introduced in all aspects of the software product and be assured of the assistance of the best placed partner, every half day.
In short, turn Pair Programming into a daily practice helps you turn quality into a habit.