Archives for Mar,2015

You are browsing the site archives by date.

Paired Programming Does Have an Impact

Nothing strikes fear into management more than the suggestion of Paired Programming.  They start envisioning multiple people sitting around one computer.  One person is working while the other is eating popcorn and reading magazines.  To be honest, I was once a ‘Pair Programmer denier’.

During a retrospective, a team brought up the idea of Pairing.  They even brought a video: www.mobprogramming.com

As a good Scrum Master I had no choice but to allow the team to at least try pairing for several hours a day.  I had every expectation that it would fail.  After one iteration the experiment was not a complete failure, and the team requested another iteration to work out the kinks.

After the second iteration, we were hooked.  Not only did pairing not fail, but our velocity began to increase, quality begin to improve, and the team started to spend even more time in pairs.

This blog post is a list of statistics that have I found that prove paired programming works, and my top 3 quick wins I received once I put paired programming into practice.

 

paired programming stats

 

Paired Programming Benefit #1: Communication

This benefit seems simple: ‘The team starts to work closer together, and communication goes up”.  However, the effects are more far reaching than that.  The team learned how to talk to many different personalities and skill sets.  They started to put our Emergenetics profiles into practice.  The team began to look beyond the ‘title’ of each team member and they began to utilize each team member’s vast talents and experience.  Our meetings per iteration decreased and our Retrospective and Demos became super-charged.

paired programming stats

Paired Programming Benefit #2: Quality Improvements

Quality on many levels began to increase. The team’s documentation quality increased while the number of pages per document decreased.  The number of bugs reported in production took a dramatic decrease while the amount of time needed for regression testing and hardening also decreased.  Job satisfaction increased as team members began to learn new skills by working closely together.

paired programming stats

Paired Programming Benefit #3: Self Organization

Planning sessions started to revolve around who would pair on stories.  The team started to self-organize in ways that I had not seen before.  The team started to ask questions like: “Who needs to learn this feature?”, “Who has experience…?”,”Who can assist with…?”.  As the team began to understand the ‘big picture’ they began to provide input on release planning and backlog grooming.  Their suggestions offered insight, innovation, and efficiency where there was none before.

What kind of experiences have you had with pairing? Positive or Negative? 

Talk to Us Today

 

paired programming benefits

Sources:

mobprogramming.com

http://c2.com/cgi/wiki?PairProgrammingCostsBenefits

Scrum Events – The too many meetings problem

Nearly every team that I have introduced Scrum into a new company someone has complained at some point about the duration of meetings in Scrum. I get comments like:

“Scrum has far too many meetings”
“What? A four hour planning meeting for a two week sprint!”
“We have so many meetings here, and now you are killing us with more meetings”
“I cannot have my team in spending so many hours in meetings”
“I am too busy”
“&(#* off, this is &$%# @

Here are the events in Scrum and the hours for each event:

Time-Spent-on-Events-Graph1

A novice team may see these numbers as big and a lot of time put into each event, however if you follow the principle of inspection and actually take a deeper look into the timing; you may be a little surprised with some of the numbers.

For math purposes, I will be assuming an average 9AM to 5PM job with an 8 hour workday. I will also assume a Monday to Friday job as this is common in just about all the teams I work with.

Here is the breakdown of time spent on each event in a Sprint:

Scrum-Events1

2% Retrospection

Teams should spend time inspecting their processes and practices and seek opportunity to do things better and faster. Without this inspection and spirit to adaptation is completely lost and the essence of agility non-existent.

2.5% Review and Feedback

At the end of the sprint it is important for the team to speak to stakeholders and seek their feedback on the work they have just completed. This risk management strategy helps correct misaligned objectives early by allowing the team show what they have built and the stakeholders to agree or to correct it. Not spending time doing this feedback will simply result in the wrong product been delivered to stakeholders and not to their expectations. This supports the entire belief in incremental and iterative development with regular feedback.

Next is reviewing upcoming work and allowing the Product Owner to demonstrate the health of the pipeline of work to both the team and the stakeholders. It is facilitates transparent communication to the health of the product, project and upcoming work.

2.5% Co-ordinating daily effort

Each day the team simply have a 15 minute event to plan who is doing what for the next 24 hours until the next Daily Scrum.

5% Planning and Design

The largest Scrum event is to Plan the next sprint and to do high level designs on how the work will be approached. Traditional development teams spent way more effort on planning and design and Scrum team have totally reduced this. Yet this event is the most controversial event where teams feel it is still to long.

One must agree with Winston Churchill “Failing to plan is simply planning to fail”. I personally do not think ask any team for 5% of their time to plan and design upcoming work is a big ask. Surely a professional should be able to recognize the importance to plan.

88% Available to do work

That’s a lot of time to get stuff done. I do consider refining as work.

Here are some more facts

1 hour per day (average) in meetings

If you look at it as only having a single one hour meeting per day on average, this is actually not much at all in the grand scheme of things.

It’s a time-box

A time-box is the Maximum time for an event, this means that if you can do it quicker whilst delivering the same quality; then please do it quicker.

If you are doing more meetings than the ones in Scrum, then you are doing it wrong and the organization has dysfunction that needs to be addressed.

Here is the math for the skeptics:

Event-Times-for-Sprint1

Author Brett Maytom is a Professional Scrum Trainer.

where is your time going