Pink Rose, Beijing: Martin Harris.

I have been reading chapter 12 of Succeeding with agile by Mike Cohn.  The chapter title is Leading a Self-Organising Team. I have been reading it in the following context:

Strive for technical excellence and Improving technical practices is not optional.

Why is it that improving technical excellence is sometimes neglected on a project?  Why do developers think its ok to check in classes with warnings, leave essential and easily written tests out or add to messy code.  You must of heard the phrase “nobody cares about a building with broken windows.”  One more broken window will not matter. The same applies to software. Often you will find developers harboring some kind of guilt for not fixing things.

Once possible reason for this that I offer, is these teams although self directed are not being managed correctly. Draw a cause and effect diagram for your team, and include pressure or influence from management. Is there pressure to deliver at the expense of quality improvements?  Have you got managers using downward pressure to influence teams? There are other reasons but it seems to me that its more than just the scrum and agile practices, the team needs to engender a culture of self improvement and continuous change.  Conceivably a non scrum team with the right culture would work out its own scrum and agile systems if they had the right mindset.

I am of the view that building a team with a positive drive to deliver quality and meet deadlines is extremely difficult. Its hard to build up the right attitude and one short word, or foolish reaction from someone with influence can destroy that process.

So what is the alternative?  Unfortunately the alternative requires a great degree of skill and thought to pull off.  Its much harder than dragging a team into a room and attempting to bully them into submission.

Just to recap to improve technical excellence you need a team that actively engages in engineering practices.  Its easy to list them off: TDD, Refactoring, Collective Ownership, Continuous integration, Pair Programming.   Its quite another thing for a team to actively pursue the improvement of these processes and have the collective view that “Improving Technical Practices is not optional“.

Chapter 12 has the best write-up I have seen so far on how this might be done.  It suggests more subtle ways to influence your team to enable them to do this.   If anyone knows of similar works let me know as I want to build on this.

The following is just a list, read around and practice them to fully understand the processes.  Never be tempted to take the pressure your under and just apply it raw to the team.  This will have the opposite effect to the one you require often causing morale problems and damaging the team interactions.   This ultimately leads to reduced quality, higher defect rates and slower delivery and change.   All of these techniques require a deep understanding of how the team works.  Spend time working with your team to understand how its working or not as the case may be.

Once you have a handle on what is working and what is missing there are a series of alterations that can be made to change the balance.  The team will react to this and if you get it right adapt and improve from inside.

So these are the high level things I am looking at currently.  Check out the book for more detail.

Adjusting containers: Teams have boundaries and members.   This effects the way the team self organises.  Adjusting these changes the personality dynamics and can alter the skills balance in the team.
Example: Perhaps one member is too strong reducing discussion.  Another counter strong member might stimulate dialog and stand up to them.

Amplifying or Dampening Differences: The idea is to draw out those differences.
Example: Stimulate dialog by asking the team some hard questions about architecture or process that is not currently working.

Altering exchanges: Changing the way the team communicates with itself or other entities within the organisation.
Example: One team keeps impacting and rubbing up against another. Introduce a practice where individuals attend each others scrums. Mix it up, make it different individuals each day and get them to report back.

Apologies for the shallow list each of the above can be achieved in many ways, and a certain amount of creativity is required to make it work.  There will be failures but its important to keep experimenting and changing the equilibrium.  In summary its techniques like this that address the fundamental issue for me, how to get teams to fully take collective ownership and evolve towards continuous improvement.

                          

Goa State, India, Lifting the load: Martin Harris

Project Management Offices really serve no purpose in scrum. You are either a product owner, (not a manager), scrum master (not a manager either) or your in the team, (no technical leaders here either). So what about all that useful controlling and reporting stuff they used to do?

• Program management functions should be moved into the team.
• Team support comes from Agile coaches, or scrum masters.  They are not managers, they guide and do not tell the team what to do.
• Responsibilities of release, budget, tracking reporting etc, are the Product Owners domain, once again the Product Owner is not a manager.

Its a bad idea to keep the PMO and attempt to re-brand it under Scrum.  Keeping the unit and asking people to be scrum masters is a recipe for disaster.  Its hard to change team culture over to scrum.  Teams find it a big challenge to throw off the old and become self directed.  If you have your old manager coming to your team the roles stay right where they were.  So if you want to keep members of the PMO and they are technical, make them part of the team or remove them from the process.

Educate the Fake Scrum Master

Along similar lines, have you met a Fake Scrum Master? Its common for an organisation to take existing managers and ask them to be scrum masters.  Often with little or no training, rarely assigning mentors.  Its a very difficult thing to do, to change within your own organisation.  Michael Watkins exposes this as a potential area of failure for new leaders in his book the first 90 days.  A manager is typecast by his existing interactions within an organisation, so being promoted within his existing unit to a more strategic role is possibly one of the hardest things for a manager to do.  So moving from the role of manager to one of coach, mentor and guide with the same people is nigh on impossible.  People just put you back where you were despite your best efforts.  Its a big ask turning a team self directed, its tempting as a manager to tell the team how to do it.  So you see the paradox.

To help you spot a Fake Scrum Master, think Cargo Cult Programming but with a process slant.  These are typical behavior characteristics.

• Produces the Sprint Backlog on their own.
• Decides how long the tasks will take.
• Assigns tasks to people.
• Chases around the team (outside the scrum) requesting status updates.
• Takes on the role of co-ordination with other teams where dependencies lie.
• Takes the heat when the pressure is on.  What a hero!

All these things the team should do.  Those tasks teach, pressure and form the team into an efficient unit.

Things you can do with project managers to help them transition

Get external help.  Find good, skilled facilitators who can come in and pair with the new scrum master.  They should help with the new meeting formats, show how to guide instead of manage, and jump on any of the fake symptoms.  Its not always the scrum masters fault but a facilitator will be able to spot when the relationship is reverting to type and break it up.  If you recruit facilitators to the organisation you can often share them amongst projects.  Let them move around the teams from week to week and be on hand if anyone wants “emergency support”.  Sometimes its important to get something resolved before it develops into a habit.  Remember, support not control.

Other signs that your project managing

• Sprint lengths are project lengths.
• Teams are broken up people moved around frequently.  Teams need to change but give them time to settle and grow.  Only change individuals infrequently, keep the team.
• You have a matrix structure in software development.  It was an idea to reduce load on managers, no longer needed if the team shares the work.
• Scrum managers are shared.  How could a genuine scrum manager have the time.

So save some cash and spend it on facilitation and budget for development.  Disband the PMO, give people support and new scrum roles.

                          

Beware all yea who let the stand-up slip into longer formats, your wasting company money and time.  Possibly you could end up on this new social site Meet or Die!

I have been in scrums with established teams, where extraneous dialog started to creep in.  My scrum master introduced a speaking ball.  The ball is passed around.  You can only speak if you have the ball.  Anyone speaking out of turn is marked on a board.  When you gather enough marks you have to buy food for the team.

Sounds silly, but it did make the meeting fun…chucking the ball around, and kept it short.

                          

Cambodia, Phnom Penn, the water festival: Martin Harris

Probably one of the most common mistakes in Software Development is to allow Estimates to become Commitments.  I am sure you know the following scenario all too well.  The development team is called into a meeting room and asked the following question.  We (the management team) have had a look at the estimates, and your tasks on average are taking longer. The insinuation is that the development team is, stupid or perhaps lazy.  Worse still, an individual is called in because the stats show their work is “Behind Schedule” as judged by the estimates.  The problem is none of this though, the problem is believing that estimates are anything other than an educated guess.

The most likely outcome of this is a dissatisfied manager requesting for more hours to be worked.  This pressure normally results in dissatisfied team members and a drop in morale.  Its likely outcome a drop in productivity.  Extreme cases result in high turnover of staff as they leave in search of more enlightened projects.  In addition developers drop quality to meet the deadline.  This code is unmaintainable in the future as corners have been cut just to get it working.  So the initial surge in productivity results in slower progress ongoing.  Watch the defect rates, your teams will spend more time fixing than producing new work.

In actual fact what does the business require of our Software Development services that has lead to the belief in estimates?  We need to know when something will be delivered.  In some cases we demand that at all cost something will be delivered.  The book Peopleware by DeMarco and Lister describes this as The Phony Deadline.  Poor delivery is the result of picking a phony deadline.  Yes you got something, but it might not work quite as expected.

I still want that delivery date, what can be done?

Have it you shall, but not straight away.  Now I have spent the last few paragraphs showing how estimates poison the team and reduce product quality.  In the next section lets look at the relationship between our team and the sponsors.

A collection of estimates can be used to provide the paying customer with an inaccurate delivery date.  So given that the average customer has problems with the definition lets re-brand estimates as guesses, educated or otherwise.  There are two important things that a software development team needs to provide the business.

1. The contents of a delivery.
2. A delivery date.

There are only three variables in delivery, time, cost and scope.  Cost is most often set in stone at this stage, scope can be negotiated and time has an awful habit of not sticking to the rules.  The trick is to use our guesses to address the content of the delivery instead of the go live date.  For delivery date we will record story velocity over the first few tasks and use that to extrapolate the delivery date.  We will carry on tracking velocity and the cone of uncertanty will get tighter, leading in turn to a more accurate date.  Commitments can be made on that date once you move into the cone and the variance diminishes.  This can be problematic to the business at first because the date is non existent at the start, and as you begin to track reports will vary.  This will settle down, especially if you try to keep other variables consistent.  So stop mucking about with the team makeup and the iteration size, concentrate on tracking the work accurately.  Once you have a few releases over, you will find that velocity is a much better way to work out delivery dates.

The business I currently work in uses techniques like this in many financial metrics.  Take a look at how interest rates are set for a year.  Obviously its impossible to know what will happen to interest rates over the course of a year.  We might start at 2% and rise to 2.5% or perhaps not.  News on the economy gives some indication in the short term as to what might happen to the rates.  These news clips cause the market to react and the closer we get to the end of the year, the more likely we are to be able to guess the final rate across the year.

So what is so bad about using story velocity metrics to gain more accurate estimates of how many stories a team can complete in a delivery cycle?  To further improve things we might also consider smaller delivery cycles and standardizing story and task sizes as much as possible.

Estimates guesses still have value don’t they?

So where do the guesses come in?  Lets use a relative estimation system instead of a time based one.  In scrum these are known as story points.  Please do read that link it is probably the best description I have ever come across.  Many thanks to the authors.   The idea behind point-based estimation is to agree that at the beginning we have much uncertainty and ambiguity.  Even if we spent extra time on analysis of the problem, we would still be uncertain and much ambiguity would remain.  Points are relative to each other and are all about size of stories over time.  This is much easier to deal with as a developer.  People are comparators, we do that all the time.  This makes us much better at saying if one task is bigger than another.  Especially if we have done similar stories before.  So points are a weighted system to grade stories into a set of different sises.

Now we need some kind of system to help us standardize the size of the boxes.  In scrum a technique knows as planning poker helps with this.  Planning poker gives us a set of cards representing the relative weight of a story.  Normally 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.  When estimating your thinking goes something like,

Mmm well I have done something a bit like this before, that was a 20 but this is a bit more complex, now is it a 40 well that’s double…and this feels a bit bigger but not double.  So I will plump for a 20.

So as you see the numbers are important as the weighting is designed to help grade the story into standard size boxes.  The other important thing is the whole team takes part in the planning so you get a graded average.  This has a side effect, the team members start to appreciate the effort involved across the full spectrum of work.

So then, that delivery date?

If your able to try and run an iteration or two before giving a delivery date.  Track how many stories you can complete in an iteration and use that to project forward and arrive at a date.  Explain to the business that you will review this date with them on a regular basis and that it will get more accurate as velocity settles down.  A little like the speculation over the next interest rate announcement.  One problem is the initial project stories are often very different from latter ones.  Usually due to building and setting up initial architecture and development environment.

Another idea at the initial stage is to break out a random selection of stories into tasks and estimate / guess those.  Calculate an estimated velocity and explain to the business that you can’t commit to this date and once more accurate statistics come in you will review the new date with them.

So finally your left with no fixed date.  The honest thing to do is to explain how consistent velociy will ultimatly give a better reporting picture This is going to be a sticking point I assure you.  In the past it might have been easy to just give a date to the business.  Chuck in some contingency for good measure.  This is a very bad practice indeed.  If you do miss that deadline you loose the customers confidence.  If you manage the politics better by de-scoping your just going to erode that confidence slower.  At first explaining your system will give them a date that gets more accurate the nearer you get might not go down that well.  I can assure you though that once you get more accurate velocity and that date moves around less the business will gain a profound confidence in the system.  After all soon your dates will be the best ones they have ever had.

                          

Craig Larman in Agile & Iterative Development, A managers guide describes it thus:

Sprint Review: At the end of each iteration, there is a review meeting. (maximum of four hours) hosted by the Scrum Master.  The team, Product Owner, and other stakeholders attend. There is a demo of the product.  Goals include informing stakeholders of the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots.

Feedback and brainstorming on future directions is encouraged, but no commitments are made during the meeting.  Later at the next Sprint Planning meeting, stakeholders and the team make commitments.

“Power Point” presentations are forbidden.  Preparation emphasis is on showing the product.

What is a Demo anyway?  What should we Demo?

Demo of a Balinese fire dance, Bali, Indonesia: Martin Harris

A demo has to be fully working software.  Although the team considers it ready for production and has fully tested it, its acceptable that the demo environment is scaled down in terms of moving parts and data sets.  Often there are manual test stages that follow user acceptance and such, but during this meeting we expect to get business agreement and sign-off so the environment has to be good enough to inspire confidence in the product.

Get the product owner to drive the software.  No cheating The product owner will get a better feel for it if they drive.  I have seen situations were very good software refuses to behave only when the product owner takes control!  Make sure that your demo room has a spare PC just in cases someone from the team needs to login, check logs, or re-start a service etc.  Its important not to stall on something trivial or unrelated to the demo.

Record any issues or problems.  These have two outcomes.  Either they are bad enough that the product owner will not accept the stories as finished, or if trivial the product owner may sign off a story if they are fixed in the next iteration.  The ideal is obviously to sail into the next iteration with no hangover whatsoever.  Don’t let issues slow the meeting down.  The product owner should make a decision and move on.  The scrum master documents any such issues and the outcome.  Note that the teams testers are incredibly useful in a demo, often providing usability and product usage advice.

If possible everything in an iteration should be included in the software demonstration.  If you get it right it should be possible to demonstrate every story.  If the team is in the habit of producing a definition of done for all tasks and done includes things like, documented, fully tested, deployable then preparation for the demonstration should just be a matter of updating the demonstration environment.

What a demo is not?

A demo is always actual running software, never mocked aside from test or development data.  If you can get production data then all well and good.  The product owner is always present, demonstrating to the development teams has little value.  This is a key opportunity for developers and the business to come together and feel part of the same team.  The product owner is the only person who can sign off a story.  If they are unavailable postpone.

How much does a demo cost?

Very little when measured against the return.  In an ideal project the demo environment is created off the back of a successful build possibly automated.  Its not just used for the demo, but provides a place to test.  In an integration situation its often useful to have somewhere that is guaranteed to be stable.  Its possible to share the environment over several teams as long as its stable during the demo.

What are the Benefits?

The main benefit is the team is able to demonstrate that a set of stories for an iteration is finished.  The burn down is complete.  The product owner is able to report that a key section is complete.  In some projects release to production follows soon after.  You are able to see exactly where you are after updating the backlog.

This process like no other Builds Confidence.  The confidence the team has in itself and the confidence the business has in the team to deliver.  It can not be overstated how important this is.

Sometimes this is the first time that the Team members see the product working end to end, when your working on the small parts is easy to forget where your heading.  The demo brings it all together.

Team becomes more focused on delivery.  I will paint you a picture.  Its Thursday morning, the demo is tomorrow, there is still quite a bit to do before the demo.  Nobody on the team wants to be the one, who’s key piece meant something was not ready for the demo.  By the afternoon you can feel the tension as the team readies the environment and tests everything one last time.  Teams with no demo do not have such focus.  A key part of scrum is something called cadence.  Iterations are always the same length, people get used to that, and they are marked by events.  I would say Sprint Review is the full stop marking the end of a sprint.

Its very addictive to the business.  The product owner will really start to get involved when at the end of each sprint demo after demo builds more working product.  Its a very important part of forging the teams relationship with the business.

Problems you may have with demonstrations.

Problem: We find that at the end of a sprint we have nothing that can be demonstrated!
Experiment with: Longer iterations.  Find ways to make it possible to demonstrate, look for blocks, missing environment and work hard to plug the gaps.  Its vital to demo never de-prioritize this.

Problem: We have difficulty getting the product owner to attend.
Experiment with: Shorter iterations.  Less to demo should mean shorter meetings that are easier to schedule.  Always do the demo at the same time and day.  This is also easier to plan for.

Problem: The team has no time to do demonstrations, they are busy building new functionality.
Experiment with: Plan less and schedule less stories.  Its vital to know you have actually finished an iteration.  A common scenario for teams who do not demo, is one where the project is just collecting more and more partially finished stories because of one block or another.  This can even be hidden as with no demo you have not the assurance that what you build is correct.  So you only think your complete.  There will be a price to pay later in re-work during test or worse after go-live.

Problem: We tried sprint reviews but they broke down after several chaotic attempts.
Experiment with: Create a story for Demo preparation. Have it in mind that your telling a story. Lead the product owner through the stories in a logical order that builds. See links below for more on how a review should be conducted.

Conclusion

Always hold a Sprint review with a demo.  It has hidden benefits and builds confidence in the team.  Don’t underestimate its power to motivate.  Business confidence and reporting accuracy will also improve.  Greater understanding of the product and business are other side effects.  So plan to demo now and enjoy, it can be the best part of the sprint.

Further Reading

Simple Scrum Sprint Review Note the amount of time allocated to demo in this example!

Successful Sprint Reviews Excellent work on how to make them work.

                          

Groundswell shows a way to tool up your Product Owner?

One of the most important scrum principles is to assign a Product Owner.

Tool me up, Temple, Ho Chi Minh City, Vietnam: Martin Harris

This person should have a very good understanding of the business.  At first glance is seems like a good idea for that person to be an active part of the business.  For a single dealer platform it looks like a good idea to recruit someone who actively deals or for a legal application a senior member of the law staff.  The problem with this is a dealer is likely to be too busy looking after money, and the Lawyer is in and out of court.  Active members of the business have better things to do, so we have to look elsewhere for our product owners.

Some links if your interested in the problems a product owner deals with and how to find a suitable candidate:

Being an effective product owner

Product owner – Choosing the right person for the job

So instead another option is to appoint a business proxi.  Perhaps a Business Analyst or a traditional Project Manager.  There is nothing fundamentally wrong with this and I have seen it work well but at the end of the day this person needs to tune into their sponsors and customers.  This is where the book Groundswell comes in.  Groundswell has several documented cases where Social Technologies have been used to garner information from communities, check out this blog post for some idea of the mechanics.  Some such cases have been in areas where it would normally be very difficult to get any feedback from the community i.e. a pharmaceutical company setting up support communities for cancer patients.

There is one great example of Credit Mutuel a French retail bank who asked of their customers “If I were a banker” and collected responses on what the customers thought the bank should be doing.  A huge wave of Groundswell resulted in the bank making changes and in Credit Mutuel benefiting from increased competitive advantage.  They were able to respond to customers quickly and make the changes they deemed sensible.  The customers loved it.  There is a caveat to this though.  You have to be able to turn around changes quickly, and now we are back to scrum.  A development system that done well can implement software changes quickly in reaction to a clients demands.  What I am suggesting is that correct use of Groundswell could make the product owners job easier.

In particular within organisations who have trouble getting the right kind of requirements from the users of the applications we write.  I have worked in several industries where getting access to your users is a real problem.  Lawyers and Traders who are just phenomenally busy and expensive, highly dispersed users of global applications where the logistics of visiting them all is impossible.

In the book there are several documented cases where companies like Communispace or Passenger setup and manage systems to recruit and manage a comunity focused around a product or idea.  I think it would be great to try out ideas like this to gather information about an important software product from its internal and external users.  The end game, is to gather the best ideas, then put them back to the community for voting and prioritisation.  Yes, you get a ready made backlog off the back of this.  How incredibly handy is that!  Take a look at this, its pretty much a community fed backlog used by Salesforce.com: http://sites.force.com/ideaexchange/. Here is another that Dell use based on the same Crispy News system: http://www.ideastorm.com/

I think that doing something like this has these benefits possibly more:

• It helps the product owner get a more representative view of what the customers think is important.  What requirements they put at the top.
• The customers feel more involved in the evolution of the product.
• Your scrum team is likely to find out some things that all the experts and analysis have missed.

Its powerful, but as with any power tool be careful!

• You will have to show both the good and bad feedback.  Are you ready for the honesty required?  Make sure all your sponsors are prepared.
• The scrum team should be ready and established, if you can’t turn around the best ideas quickly the mood will quickly turn sour.
• It takes a great deal of skill and a degree of humility to make this work, but the closer alignment with your customer will soon show results.

So why not give it a try?

                          

Pushing the cart, Matheran, India: Martin Harris

I went along to the London Scrum User Group yesterday evening.  For a change it was a quiet night.  Christmas is around the corner so we had less attendees.  Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum.  After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack.  So we stopped there and got on with eating the snacks and drinking the beer.  The night was sponsored by Rally Software, cheers for the food guys.  So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment?

The London Scrum Groups 6 Good Scrum Tips

• Love your product owner. The group agreed that the product owner should be part of the team. Include them in the meetings and get them involved. Its possibly the most important thing you can do for success in scrum. A fully integrated product owner will spot early on if the stories do not match their expectations. They negotiate the definition of done for a story. They are on hand to answer questions during the iteration removing waste and improving understanding of the stories. The product owner decides if the team has finished stories at the demo. Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as they get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
• Run Retrospectives. Its very important to take actions away from a retrospective.  Be realistic though, your never going to solve them all, so ask the team to priorities them.  If your doing the retrospective right your product owner will be there to help with prioritisation.  If you find something very big lands at the top, split it down into stories.  Otherwise pick one or two that the team feel strongly about and turn them into stories.  Make sure these stories are included in the next game planning sessions and make it into the iterations.  If you have adjustments to the process you can implement these straight away, but experiment with it, and try to measure the impact of changes, you might not get the process right first time.  Commit to doing them and then deliver.
• Ask your team to Pair Code. The XP technique of two programmers working on the same task.  It was agreed that there are different kinds of pair coding and that they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput.  Don’t be dogmatic, let the team decide how much work should be pair coded.
• Setup Self Directed teams. Self directed teams have been proven to be more efficient.  We discussed the role of a scrum master in a self directed team.  Its very important that the scrum master does not tell the team how to work, or how to go about completing the tasks.  The scrum master does not plan or allocate tasks.  The empowered team needs to work out what the tasks are and find out how to finish the stories.  The scrum master should spend his efforts removing blocks for the team, checking quality.  Its important for the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues if truly self directed.  We also decided that to be empowered you need to make the team multi discipline.  Include testers, user interface designers etc to remove hand off waste and increase team knowledge.  With role diversity comes better decision making.
• Deliver what you commit to. Another gem, it sounds obvious but is so often ignored.  Delivering builds trust in the team and the process.  Classic ways to miss delivery include: Failing to produce a strong definition of done.  The definition should include the programming, integration, testing and setup tasks.  In fact everything required to get that task ready for delivery.  Another way to miss delivers is to fail to demonstrate at the end of the iteration.  You may think your done, but when the product owner sees the work for the first time they may request refinement.  If you have kept your product owner close then the demo is likely to be painless.  No power-point slides please, only real working software in the demo!  So commit and then deliver what you commit to.
• Co-locate your team. The group defined co-location quite tightly.  Co-location is not putting everyone in the same office.  Its putting the team members next to each other in the same space.  Intra team communication does not happen with the team scattered around an office.  You should be able to turn around and join the stand up meeting.  This closeness, speeds up the myriad of tiny important messages that pass around the team.  Some of which is non verbal.

After this rich discussion we gave up on the 15 tips idea.  If your doing these, then your doing very well indeed, and are likely to get better over time.

So another excellent meeting, a few more beers and I headed home enlightenend, well fed and slighlty merry.  Why not come along to the next one, we could use your input.

                          

Pair of farmers working the rice, Ubud, Bali, Indonesia: Martin Harris

I have done quite a bit of XP and Agile.  One of XP’ engineering practices is pair coding, At first I just did not understand pair coding.  My initial introduction was within a self directed team practicing Scrum and Agile.  I have come to realise that without self-directed teams, you don’t have scrum. You can scrum without pair coding but without these, you have thrown away two very effective techniques.  What is left just turns into inefficient micro management.  For some reason, these two techniques get resisted hardest.  Yet they are the key and the dynamo behind the success.

My definition of Pair Programming: A technique to increase development throughput by maximizing review coverage, reduction in faults leading to increased software quality and less effort in downstream processes such as manual testing and product maintenance.

Pair coding viewed from the outside is often seen as a waste.  Its important to understand the process before eliminating it.  Two guys working at the same desk!  What a waste of effort! I find this a little odd.  In programming circles its quite difficult to be a team, when most of the time is spent isolated at a development console.  There are points in the scrum process when the team comes together for a group activity, but its a small part of the overall process.  After an iteration planning session the team returns to their islands to work.  Quite peculiar if you think about it in the context of other professions.  I would say that there are plenty of examples where people work alone but in software development the best work is done by teams, and a pair is the optimal small unit within a larger team.

Good though it is pair coding should not be mandatory, the team should decide which aspects of the work require the higher pitch of pair coding, and which bits can be left to individuals. There are many tasks that are not actually writing code, some of these can be done individually.  Saying that though, a good scrum master knows pair coding is hard, and most people will revert and poor quality code will result, so it should be encouraged. Make it a natural part of your work and attempt to write all the code this way.

I have found there is a temptation, to reduce the levels of pair coding when the team is under pressure, this is the wrong approach. Actually you need more pair coding if you want to go faster. In addition the increase in quality will reduce the number of defects and lower the number of production support issues.

Pair programming distilled

As I said before initially I was skeptical.  This is what I now believe.  These points can also be found in greater detail in the linked pages below.

• Pair coding is a review process. While one developer concentrates on the mechanics of writing the code and getting the confounded IDE to do what he requires, the other is thinking quality and strategy.  You will often see pairs break to discuss a point of quality make a decision and move on.  If you reviewed someones code at a later stage, and made the same decision.  i.e. all this has to come out and be replaced by better patterns and its going to cost you.  Also later never happens so the code remains poor.  It takes nerves of steel and many people pushing to get bad code changed.
• When you have an equal pair looking over your shoulder you try much harder. Naturally you do, as if you don’t they pick you up on points of quality and that is irritating.  I strive all the time for quality in a pair or out, but I know I perform at a pitch higher in a pair.
• Equal pairs are better than unequal. Mentoring a junior is fine, but that is not the best way to get quality code.  Although beneficial and necessary to educate team members the equal pair smoothly moves to excellence.  Whilst mentoring, the tutor reduces his pace, and is unchecked.  You will find statistics on the wikipedia ref that shows an improvement in correctness of around 15% and 20 to 40% decrease in time, but between a 15 and 60% increase in effort. Williams et al. 2000 also cites an earlier study (Nosek 1998) which also had a 40% decrease in time for a 60% increase in effort.  I know what this feels like, and to me it feels about right.
• A secondary effect is a closer knit team, focused on delivery and quality.  The team really understands and enjoys the work they are doing.  They know where they are going.  Nobody is sitting to one side, struggling with something.  Brilliant software development is hard, and hard things are easier if there is someone with you.
• The scrum stand-up seems to go better. People know each other and are comfortable.  They are more likely to come forward in the meeting to highlight an issue.
• The team does less context switching. Pairing means working on less parallel tasks. Parallel working is hugely overrated and a massive waste. Pairing will help keep context switching down.
• Its very hard work.  In fact its exhausting. Working this way is much harder, I don’t get to read my email, surf the web, call home.  Give me a break. 

So that’s my take on it.  Its worth it and it works but its hard work.

See the collection of links below for other views academic studies etc.

Definitions, studies and papers

http://en.wikipedia.org/wiki/Pair_programming
http://www2.umassd.edu/swpi/xp/pairprogramming.html

Other peoples perspectives

http://blog.obiefernandez.com/content/2009/09/10-reasons-pair-programming-is-not-for-the-masses.html
http://blog.jayfields.com/2009/01/cost-of-net-negative-producing.html
http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/

How to start Pairing

http://www.developer.com/lang/article.php/3652636/Pair-Programming-Dos-and-Donts
http://www.extremeprogramming.org/rules/pair.html