Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

The Ever-Expanding Agile and Lean Software Terminology

Sunday, July 8th, 2012
A Acceptance Criteria/Test, Automation, A/B Testing, Adaptive Planning, Appreciative inquiry
B Backlog, Business Value, Burndown, Big Visible Charts, Behavior Driven Development, Bugs, Build Monkey, Big Design Up Front (BDUF)
C Continuous Integration, Continuous Deployment, Continuous Improvement, Celebration, Capacity Planning, Code Smells, Customer Development, Customer Collaboration, Code Coverage, Cyclomatic Complexity, Cycle Time, Collective Ownership, Cross functional Team, C3 (Complexity, Coverage and Churn), Critical Chain
D Definition of Done (DoD)/Doneness Criteria, Done Done, Daily Scrum, Deliverables, Dojos, Drum Buffer Rope
E Epic, Evolutionary Design, Energized Work, Exploratory Testing
F Flow, Fail-Fast, Feature Teams, Five Whys
G Grooming (Backlog) Meeting, Gemba
H Hungover Story
I Impediment, Iteration, Inspect and Adapt, Informative Workspace, Information radiator, Immunization test, IKIWISI (I’ll Know It When I See It)
J Just-in-time
K Kanban, Kaizen, Knowledge Workers
L Last responsible moment, Lead time, Lean Thinking
M Minimum Viable Product (MVP), Minimum Marketable Features, Mock Objects, Mistake Proofing, MOSCOW Priority, Mindfulness, Muda
N Non-functional Requirements, Non-value add
O Onsite customer, Opportunity Backlog, Organizational Transformation, Osmotic Communication
P Pivot, Product Discovery, Product Owner, Pair Programming, Planning Game, Potentially shippable product, Pull-based-planning, Predictability Paradox
Q Quality First, Queuing theory
R Refactoring, Retrospective, Reviews, Release Roadmap, Risk log, Root cause analysis
S Simplicity, Sprint, Story Points, Standup Meeting, Scrum Master, Sprint Backlog, Self-Organized Teams, Story Map, Sashimi, Sustainable pace, Set-based development, Service time, Spike, Stakeholder, Stop-the-line, Sprint Termination, Single Click Deploy, Systems Thinking, Single Minute Setup, Safe Fail Experimentation
T Technical Debt, Test Driven Development, Ten minute build, Theme, Tracer bullet, Task Board, Theory of Constraints, Throughput, Timeboxing, Testing Pyramid, Three-Sixty Review
U User Story, Unit Tests, Ubiquitous Language, User Centered Design
V Velocity, Value Stream Mapping, Vision Statement, Vanity metrics, Voice of the Customer, Visual controls
W Work in Progress (WIP), Whole Team, Working Software, War Room, Waste Elimination
X xUnit
Y YAGNI (You Aren’t Gonna Need It)
Z Zero Downtime Deployment, Zen Mind

Agile is Counter Intuitive

Friday, November 26th, 2010

I hear many people claim Agile is just common sense. When I hear that, I feel, these guys are way smarter than me or they don’t really understand Agile or they are plain lying.

When I first read about test-first programming, I fell off the chair laughing, I thought it was some kind of a joke. “How the heck can I write automated tests, even without knowing what my code would look like”. You think TDD is common sense?

From traditional methods, when I first moved to monthly iterations/sprints, we were struggling to finish what we signed up for in a month. Its but natural to consider extending the time. Also you realize half day of planning is not sufficient, there are lot of changes that come mid-sprint. The logical way to address this problem is to extend the iteration/sprint duration, add more people and to spend more time planning to make sure you’ve considered all scenarios. But to nobody’s surprise but your’s spending more time does not help (in fact makes things worse). In the moments of desperation, you propose to reduce the sprint duration to half, may be even 1/4. Surprisingly this works way better. Logical right?

And what did you think of Pair Programming? Its obvious right, that 2 developers working together on the same machine will produce better quality software faster?

What about continuous integration? Integrating once a week/month is such a nightmare, that you want us to go through that many times a day? But of course its common sense that it would be better.

How about showing working software demos weekly/monthly somehow magically improving collaboration and trust. Intuitive? And also shipping small increments of software frequently to avoid rework and get fast feedback?

One after another we can list each practice (esp.the most powerful ones) and you’ll see why Agile is counter-intuitive (at least to me in early 2000 when I stumbled upon it).

Pair Programming: Public Demo

Sunday, June 13th, 2010

At the end of the Programming With the Stars @ the Agile Mumbai 2010 conference, based on public demand, J. B. Rainsberger and yours truly did a 6 min public demo of Pair Programming. We started with an Ugly Pairing session, trying to show-case some pairing anti-patterns.

Followed by a normal pairing session:

Enjoii madi…

Remote Pair Programming

Tuesday, April 13th, 2010

Since I’ve started working for Industrial Logic, I’ve spent a decent amount of time pair programming with folks in the US. Yes, we do Remote Pair Programming.

Quite a few people have asked me:

  • What special editor or tool we use for remote pairing?
  • How effective is the pairing?
  • How much time is spent in setup each time?
  • How long does it take for one to get used to remote pairing?

Here is my answer:

The most important part of pairing is free flow of ideas between the 2 individuals. Its about the brains of the 2 individuals being at the same wavelength so communication can truly take place. Tools can certainly disrupt or get in the way of this flow. But IMHO the individuals contribute 80% towards the success of the pairing experience, tools contribute 20%. Skype with Video Sharing lets us achieve 80%. Better tools might improve that. We’ve experimented with some Eclipse based plugins, all of them have their trade-offs. There is no clear winner. Also on our team since we’re all used to Skype for conference calls, the threshold to get started is very low. So my recommendation is to get started with simple tools, something that you are already familiar with. When starting anything new, focus on the crux and not on the peripheral stuff.

For a more introductory material on pair programming refer to Pairing FAQs.

Want to Pair Program and Concerned about Productivity?

Monday, October 26th, 2009

Often I find developers and managers who claim they understand the advantages of Pair Programming and are bought into the concept, but they are really concerned about loss of productivity.

This morning when I watched the following video, I thought, we could use this as an excellent example of what pairing can help you achieve.

My premise:

We are in the business of building software and this process requires craft and skill, rather than a series of manual steps. Programming requires lot of thinking, creating abstractions, figuring out the logic and trying out things. Its an evolutionary, iterative and collaborative process. Its a lot more than just typing code using the keyboard (or even worse, using the mouse).

If you resonate with the philosophy stated above, then you should be able to understand how pair programming can make it easier or more feasible to create master pieces that could be extremely difficult or rare for one individual to single-handedly create.

An introductory slide deck on Pair Programming:

Ultra-light Development and Deployment Example

Monday, October 26th, 2009

Over the last year, I’ve been helping (part-time) Freeset build their ecommerce website. David Hussman introduced me to folks from Freeset.

Following is a list of random topics (most of them are Agile/XP practices) about this project:

  • Project Inception: We started off with a couple of meetings with folks from Freeset to understand their needs. David quickly created an initial vision document with User Personas and their use cases (about 2 page long on Google Docs). Naomi and John from Freeset, quickly created some screen mock-ups in Photoshop to show user interaction. I don’t think we spent more than a week on all of this. This helped us get started.
  • Technology Choice: When we started we had to decide what platform are we going to use to build the site. We had to choose between customer site using Rails v/s using CMS. I think David was leaning towards RoR. I talked to folks at Directi (Sandeep, Jinesh, Latesh, etc) and we thought instead of building a custom website from scratch, we should use a CMS. After a bit of research, we settled on CMS Made Simple, for the following reasons
    • We needed different templates for different pages on the site.
    • PHP: Easiest to set up a PHP site with MySQL on any Shared Host Service Provider
  • Planning: We started off with an hour long, bi-weekly planning meetings (conf calls on Skype) on every Saturday morning (India time). We had a massively distributed team. John was in New Zealand. David and Deborah (from BestBuy) were in US. Kerry was in UK for a short while. Naomi, Kelsea and other were in Kolkatta and I was based out of Mumbai. Because of the time zone difference and because we’re all working on this part time, the whole bi-weekly planning meeting felt awkward and heavy weight. So after about 3 such meetings we abandoned it. We created a spreadsheet on Google Docs, added all the items that had high priority and started signing up for tasks. Whenever anyone updated an item on the sheet, everyone would be notified about the change.
  • User Stories: We started off with User Persona and Stories, but soon we just fell back to simple tasks on a shared spreadsheet. We had quite a few user related tasks, but just one liner in the spread sheet was more than sufficient. We used this spreadsheet as a sudo-backlog. (by no means we had the rigor to try and build a proper backlog).
  • Short Releases: We (were) only working on production environment. Every change made by a developer was immediately live. Only recently we created a development environment (replica of production), on which we do all our development. (I asked John from Freeset, if this change helped him, he had mixed feelings. Recently he did a large website restructuring (added some new section and moved some pages around), and he found the development environment useful for that. But for other things, when he wants to make some small changes, he finds it an over kill to make changes to dev and then sync it up with production. There are also things like news, which makes sense to do on the production server. Now he has to do in both places). So I’m thinking may be, we move back to just production environment and then create a prod on demand if we are plan to make big changes.
  • Testing: Original we had plans of at least recording or scripting some Selenium tests to make sure the site is behaving the way we expected it to. This kind of took a back seat and never really became an issue. Recently we had a slight set back when we moved a whole bunch of pages around and their link from other parts of the site were broken. Other than that, so far, its just been fine.
  • Evolutionary Design: Always believed in and continue to believe in “Do the Simplest, Dumbest, thing that could Possibly work“. Since we started, the project had taken interesting turns, we used quite a lot of different JavaScript libraries, hacked a bit of PHP code here and there. All of this is evolving and is working fine.
  • Usability: We still have lots of usability and optimization issues on our site. Since we don’t have an expert with us and we can’t afford one, we are doing the best we can with what we have on hand. We are hoping we’ll find a volunteer some day soon to help us on this front.
  • Versioning: We explored various options for versioning, but as of today we don’t have any repository under which we version our site (content and code). This is a drawback of using an online CMS. Having said that so far (been over a year), we did not really find the need for versioning. As of now we have 4 people working on this site and it just seems to work fine. Reminds me of YAGNI. (May be in future when we have more collaborators, we might need this).
  • Continuous Integration: With out Versioning and Testing, CI is out of question.
  • Automated Deployment: Until recently we only had one server (production) so there was no need for deployment. Since now we have a dev and a prod environment, Devdas and I quickly hacked a simple shell scrip (with mysqldump & rsync) that does automated deployment. It can’t get simpler than this.
  • Hosting: We talked about hosting the site on its own slice v/s using an existing shared host account. We could always move the site to another location when our existing, cheap hosting option will not suit our needs. So as of today, I’m hosting the site under one of my shared host account.
  • Rich Media Content: We questioned serving & hosting rich media content like videos from our site or using YouTube to host them. We went with YouTube for the following reasons
    • We wanted to redirect any possible traffic to other sites which are more tuned to catering high bandwidth content
    • We wanted to use YouTube’s existing customer base to attract traffic to our site
    • Since we knew we’ll be moving to another hosting service, we did not want to keep all those videos on the server which then will have to be moved to the new server
  • Customer Feedback: So far we have received great feedback from users of this site. We’ve also seen a huge growth in traffic to our site. Currently hovering around 1500 hits per day. Other than getting feedback from users. We also look at Google Analytics to see how users are responding to changes we’ve made and so on.
  • We don’t really have/need a System Metaphor and we are not paying as much attention to refactoring. We have some light conventions but we don’t really have any coding standards. Nor do we have the luxury to pair program.
  • Distributed/Virtual Team: Since all of us are distributed and traveling, we don’t really have the concept of site. Forget on-site customer or product owner.
  • Since all of this is voluntary work, Sustainable pace takes a very different meaning. Sometimes what we do is not sustainable, but that’s the need of the hour. However all of us really like and want to work on this project. We have a sense of ownership. (collective ownership)
  • We’ve never really sat down and done a retrospective. May be once in a while we ask a couple of questions regarding how something were going.

Overall, I’ve been extremely happy with the choices we’ve made. I’m not suggesting every project should be run this way. I’m trying to highlight an example of what being agile really means.

Who needs a separate QA Team?

Wednesday, January 14th, 2009

Have you come across developers who think that having a separate Quality Assurance (QA) team, who could test (manually or auto-magically) their code/software at the end of an iteration/release, will really help them? Personally I think this style of software development is not just dangerous but also harmful to the developers’ growth.

Having a QA Team that tests (inspects) the software after it’s built, gives me an impression that you can slap inspection at the end of any process and improve the quality of your product. Unfortunately things don’t work this way. What you want to do is build quality into the process rather than inspecting (checking) at the end of your process to assure quality.

Let me give you an example of what I mean by “building quality into the process“.

Back in the good old days, it was typical for a cloth manufacturer to have 10-15 power looms. They would set up these looms at the beginning of the day and let them run for the day. At the end of the day, they would take all the cloth produced by the looms and hand it over to another team (separate QA team) who would check each cloth for defect.

There were multiple sources of defects. At times one of the threads would break creating a defect in the cloth. At times insects would sit on the thread and would also get woven into the cloth creating a defect. And so on. Checking the cloth at the end of the day was turning out to be very expensive for the cloth manufactures. Basically they were trying to create quality products by inspecting the cloth at the end of the process. This is similar to the QA process in a waterfall project.

Since this was not working out, they hired a lot of people to watch each loom. Best case, there would be one person per loom watching for defects. As soon as a thread would break, they would stop the loom, fix the thread and continue. This certainly helped to reduce the defects, but was not an optimal solution for several reasons:

  • It was turning out to be quite expensive to have one person per loom
  • People at the looms would take breaks during the day and they would either stop the loom during their break (production hit) or would take the risk of letting some defects slip.
  • It become very dependent on how closely these folks watched the loom. In other words, the quality of the cloth was very dependent on the capability of the person (good eyesight and keen attention) inspecting the loom.
  • and so on

As you can see, what we are trying to do here is move the quality assurance process upstream. Trying to build quality into the manufacturing process. This is similar to the traditional Agile process where you have a couple of dedicated QAs on each team, who check for defects during or at the end of the iteration.

The next step which really helped fix this issue, to a great extent, was a ground breaking innovation by Toyoda Looms. As early as 1885 Sakichi Toyoda worked on improving looms.

Toyoda Loom

One of his initial innovation was to introduce a small lever on each thread. As soon as the thread would break, the lever would go and jam the loom. They went on to introduce noteworthy inventions such as automatic thread replenishment without any drop in the weaving speed, non-stop shuttle change motion, etc. Now a days, you can find looms with sensors which detect insect or other dirt on the threads and so on.

Basically what happened in the loom industry is they introduced various small mechanisms to be part of the loom which prevents the defect from being introduced in the first place. In other words, as and when they found issues with the process, they mistake proofed it by stopping it at source. They built quality into the process by shifting their focus from Quality Assurance to Quality Control. This is what you see in some really good product companies where they don’t really have a separate QA team. They focus on how can we eliminate/reduce the chances of introduction of defects rather than how can we detect defects (which is wasteful).

Hence its important that we focus on Quality Control rather than Quality Assurance. The terms “quality assurance” and “quality control” are often used interchangeably to refer to ways of ensuring the quality of a service or product. The terms, however, have different meanings.

Assurance: The act of giving confidence, the state of being certain or the act of making certain.

Quality assurance: The planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled.

Control: An evaluation to indicate needed corrective responses; the act of guiding a process in which variability is attributable to a constant system of chance causes.

Quality control: The observation techniques and activities used to fulfill requirements for quality.

So think about it, do you really need a separate QA team? What are you doing on the lines of Quality Control?

IMHO, in the late 90’s eXtreme Programming really pushed the envelope on this front. With wonderful practices like Automated Acceptance Testing, Test Driven Development, Pair Programming and Continuous Integration, I finally think we are getting closer. Having continuous/frequent working sessions with your customers/users is another great way of building quality into the process.

Lean Startup practices like Continuous Deployment and A/B Testing take this one step further and are really effective in tightening the feedback cycle for measuring user behavior in real context.

As more and more companies are embracing these methods, its becoming clear that we can do away with the concept of a separate QA team or an independent testing team.

Richard Sharpe made a great interview of Jean Tabaka and Bob Martin on the lean concept of “ceasing inspections”. In this 7 minute video, Jean and Bob support the idea of preventing defects upfront rather than at the end. Quality Assurance vs Quality Control

Pairing FAQs

Friday, January 12th, 2007

Yeah, Yet Another Blog on Pairing and Pair Programming.

Question. What are the disadvantages of Pairing?

My experience with pairing has been good so far. I‘m not too sure if I can really point out disadvantages. But here are some things to be aware of.

  1. One thing that does bother me a little is, it can get into the way of your creative thought process sometimes. But most of the times, I‘m happy with the end results.
  2. Some people also complain about the trashing of ideas that goes on when people pair. It might feel like the pair is wasting a lot of time just abstracting arguing about the approach or their understanding of the problem at hand. Again, this is not really a disadvantage of pairing. Any time you have more than one person, there will be differences in their perception and approach. According to me, it better to clarify them sooner than later. Usually if the pair cannot converge on one approach, one of them drives [implements] her/his approach. If it works, they move on, else the other person drives her/his approach. Lot of times they come up with a 3rd solution which is better than both individual approach.
  3. There might be other interpersonal issues that could arise while pairing. But its better to resolve them rather than ignoring them. And it‘s not unique to pairing. Any team activity would have the same issues. A good example that comes to my mind is ego clashes between people. It‘s better to resolve it rather than letting it grow.

Couple of things one should remember:

  1. Pair programming is not about typing code. If you have watched a really good pair programming session, there is very little typing and more of communication/discussion. Designing good systems is not about typing code, it needs a lot of brainstorming. No I‘m not suggesting big upfront brainstorming sessions. You need Just-In-Time brainstorming. Closer to the time of implementation. Also people often under-value the feedback they get from code. Everyday I learn from my code and from other people on my team.
  2. Pairing is not just limited to programming. We do a lot of cross-functional pairing. Developer pairing with the Business Analyst to write automated acceptance tests. Developers pairing with QA to recreate bugs. QA pairing with BA to do exploratory testing and so forth.

Question. Some people do not want to pair program, they are lone contributors and pairing slows them down, they just stop thinking, they feel less productivity. How do you deal with this? Can we possibly reduce pair programming hours? May be ask people to work separately for 2 hours and sit for 30 minutes to pair program.

Like any skill/habit, people take time to learn it.

When I was in University, the natural thing to do for me was to work with others [Profs and students]. I learned programming by working with other students [pairs]. Once I joined a software company, I was given a sound-proof cubical. I drifted on my own and after a while I got used to working on your own. Changing this habit back to working with another person took some time [a week or two]. But the people I was pairing with were really good and there was a motivation to pair with them. After that I don‘t see “the pair slowing me down“ thing happening much.

Every single time I‘ve worked with a team, “lower productivity” comes up as the first argument against pairing. Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs. Since testing and debugging are often many times more costly than initial programming, this is an impressive result. There have been a lot of other studies, which prove that lower productivity due to pairing is a myth.

While we are on the topic of productivity, let me back up a bit. How do you define productivity? Amount of work done in an hour or day or sprint/iteration? This looks short-sighted. We are talking about software project which has a life span bigger than hours or days or sprints/iterations. Shouldn’t one consider, UAT bugs, production bugs, support calls, ramp up time for new team members, maintaining all kinds of crazy documents, etc?

Faster learning, better communication, collective code ownership, shared understanding, evolutionary design, better estimates, continuous code review, etc all go hand in hand with Pair programming.

So I would strongly discourage people working separately for 2 hrs and pairing for 30 mins as a regular practice. I would reverse the time.

Often on teams, people want time to check their emails, answer some calls, go to meetings, etc. These things do come in the way of pairing 8 hrs a day. So what we do on most teams is to have core-pairing hours.

For Ex:

  • 08:50 : 09:00 – We have our stand up meeting
  • 09:30 : 12:30 – We have the first core pairing session.
  • 12:30 : 02:00 – People are free to do other stuff and lunch.
  • 02:00 : 03:00 – Any team meetings if required.
  • 03:00 : 05:30 – We have another pairing session.

Sometimes we have another stand up at 5:30.

So in an 8 hr day, we at least have 5.5 hrs of pairing. Remember pairing can be very intense and it could drain you out. So its usually not recommended to pair for more than 8 hrs everyday.

There is always going to be resistance to pairing. The biggest reason I have found so far in 10 years is, fear of exposing how much one knows to others. My theory is, usually junior people are much open to pairing, coz everyone expects that they don‘t know much and they don‘t really have any fear of exposure. Also they feel they can learn much faster that way. On the other hand, people who want to hide in their cubical will always resist it with irrational/unacceptable reasons.

The best thing to do is have an open team discussion on this topic. Challenge people in front of the whole team. Ask for facts.

IMHO, Pair programming is not effective in the following cases:

  1. If you don‘t have a team room and team members are not sitting at a common table. If people go back to their cubical and try to pair, it is usually not effective. Most cubicles are built for one person to sit in. Trying to fit 2 people in there, mean one person is always going to look over the shoulder of the person driving.
  2. If your are not following Promiscuous pair programming. If your pairs are not swapping frequently [at least once a day], then you are going back to old ways of programming. Instead of one person now you have 2 people. So what? You need more pair of eyes. You need collective code ownership and not pair code ownership. Please note Promiscuous means “making relatively unselective, casual and indiscriminate choices.”  Pod cast and Slides.
  3. If developers are not involved in estimation and planning. If there is no collective ownership and self-organization.
  4. If you already have spend more than 30% of your project budget on BIG UPFRONT DESIGN. And if you have architects on the team who don‘t want to pair but just want to create fancy documents and throw it over the wall.
  5. If your manager assigns tasks to the pairs

Question. Some people want to pair program, but they do not pair well, i.e. though they are looking at the same computer but they are actually planning a vacation, i know this may sound ridiculous but it happens. How do you deal with this?

Talk to them. Very very important. Understanding their issues is most important. You cannot afford any communication gap.

Encourage them to try ping-pong pair programming.

Question. Where can we find a demo of good and bad pair programing?

At the end of the Programming With the Stars @ the Agile Mumbai 2010 conference, based on public demand, J. B. Rainsberger and yours truly did a 6 min public demo of Pair Programming. We started with an Ugly Pairing session, trying to show-case some pairing anti-patterns.

Followed by a normal pairing session:

Question. What does a really good pair programming experience feel like?

When each programmer has an implementation/design in mind, but in the process of pairing we end up with a 3rd, much better solution. The collaborative attitude and mutual respect amongst the pairs is very important.

Question. What does a really *bad* pair programming experience feel like?

When wavelengths don’t match and each programmer just wants to prove their point. Or Programming with someone who just does not care about the craft. If I was coaching them, these might be a good opportunity to educate them, but when trying to rapidly build world class products we don’t have time for this. Hence these are bad experiences from a pairing point of view, but good from coaching point of view.

Question. What setup makes pairing experience enjoyable? Both sharing one machine? Both sharing a single keyboard, mouse & screen Or Two keyboards, two mice & two screens?

I’ve paired for 10+ years now and based on that experience I don’t think any of these things matter. The attitude of the pairs matter exponentially more than the set up.

Question. In your good pairing experience, what best describes how you worked together?

  1. We were both focused on the code, and probably shared the keyboard fluidly.
  2. We were both focused on the code, and passed the keyboard according to a system (like ping-pong or popcorn pairing)
  3. One pair sat back and watched while the other coded, and we traded occasionally
  4. One pair did research or worked on something else while the other coded

While pairing, coding is a very small activity. What is most valuable is discovering an approach/solution through collaboration. Hence I would say who code does not really matter to me any more, as far as the pairs agree on the approach and then constantly inspect and adapt the approach.

Question. Some tasks do not seem fit for pair programming at all, they are too routine/mundane to have a pair work on them. Do you see this happening?

I often hear research, reading a book, searching on the net, learning new technology, documentation, etc. fit into this category.

I do most of these along with my pair and I find it really helpful and fast.

For Ex: While searching for something on the net, one might go to Google and start entering their search criteria. I often spend a lot of time refining my search criteria. While, when I‘m pairing, we discuss the search criteria, refine it and in the process always come up with a better search criteria, than the one I would have come up with myself.

Documentation is another very good example. Documentation is very similar to programming to me. There is something in your head, that you want to communicate. By working with a pair, one can ensure that what is been documented/expressed, is understandable by at least one other person. You might be making a lot of assumptions that are not clear to other people. Hopefully your pair will challenge some of those assumptions, leading to more understandable documents and hence better quality of the document.

I tend to pair on all these tasks, coz there is some knowledge involved in these tasks. I would like my team members to be aware of how to accomplish similar tasks later.

One of the things I have noticed in the past is, if its a single person trying to do these kind of tasks, they might be motivated to just manually do it and get done with it. Or sometimes, they might spend days together coming up with a framework to accomplish the task. But if a pair is working on it,

A [one of them] might say, “you know what, we might want to create this thing again and again, lets just quickly automate this“.
B might say, “but automating this might take 4 times more time than what we have estimated for this“
A: “Really, I was just thinking of writing an ant target to do this“
B: “Ohh…Yeah that‘s a good idea. But I‘m not very well versed with Ant“
A: “I have done some work with Ant, so I think we can get this done in 30 mins“
B: “Excellent! Lets get rolling”

You see…whenever there is learning involved, quality of end product is much better. Never under-estimate the outcome of 2 brains at work.

Question. What about remote pairing?

Since I’ve started working for Industrial Logic, I’ve spent a lot of time time pair programming with folks in the US. Yes, we do Remote Pair Programming.

Quite a few people have asked me:

  • What special editor or tool we use for remote pairing?
  • How effective is the pairing?
  • How much time is spent in setup each time?
  • How long does it take for one to get used to remote pairing?

Here is my answer:

The most important part of pairing is free flow of ideas between the 2 individuals. Its about the brains of the 2 individuals being at the same wavelength so communication can truly take place. Tools can certainly disrupt or get in the way of this flow. But IMHO the individuals contribute 80% towards the success of the pairing experience, tools contribute 20%. Skype with Video Sharing lets us achieve 80%. Better tools might improve that. We’ve experimented with some Eclipse based plugins, all of them have their trade-offs. There is no clear winner. Also on our team since we’re all used to Skype for conference calls, the threshold to get started is very low. So my recommendation is to get started with simple tools, something that you are already familiar with. When starting anything new, focus on the crux and not on the peripheral stuff.

Question. Won’t Pair Program kill our Productivity?

Often I find developers and managers who claim they understand the advantages of Pair Programming and are bought into the concept, but they are really concerned about loss of productivity.

This morning when I watched the following video, I thought, we could use this as an excellent example of what pairing can help you achieve.

My premise:

We are in the business of building software and this process requires craft and skill, rather than a series of manual steps. Programming requires lot of thinking, creating abstractions, figuring out the logic and trying out things. Its an evolutionary, iterative and collaborative process. Its a lot more than just typing code using the keyboard (or even worse, using the mouse).

If you resonate with the philosophy stated above, then you should be able to understand how pair programming can make it easier or more feasible to create master pieces that could be extremely difficult or rare for one individual to single-handedly create.

    Licensed under
Creative Commons License