Agile - Pair Programming - what, why, when, how and few objections against this practice

Pair programming:

When I heard there is something called “pair programming” 8 yrs. back when I joined an Agile team, I was fascinated. I was like “WOW”…what is that? I was swayed away by open atmosphere created in our team, and moreover perhaps I was more of relieved to know that my peer would review the code when I would be coding! Errors made by me would be immediately caught and would be rectified. Since this would be collaborative effort, everyone would be responsible for the code quality and I hoped to get hands-on guidance/training from my seniors in the team as well.

What is pair programming?

Pair programming is something where two programmers are engaged in coding, one being driver (actively writing the code), other being navigator (reviewer). They can switch the role periodically.

The navigator is expected to review the code when the driver is coding. Normally navigator gives the strategic direction on code, after having an open and honest discussion with her partner. Concept of user stories and pair programming shift the focus from regular waterfall documentation to discussion. Of course, we have to be engaged with effective and to the-point discussion.

When can you contribute to a discussion? – Yes, you are right, when you are a good conversationalist. As Dale Carnegie said, “to become a good conversationalist, you have to be an attentive listener”.  Ask good questions. Give honest input.

My experience is, pair programming is more effective and produce best result when both programmers are matured, good listeners and both believe on collective ownership of code. Pair programming can be a wonderful learning experience for both the programmers if both of them add value to code, if both of them are engaged with fresh thinking that is aligned with the story they are working on.

Driver and navigator generally have useful and effective conversation on, for example,

1.        improve code quality

2.        if a class/function(s)/module needs to be re-factored. If yes, they can discuss on effective way of re-factoring the code on-spot before proceeding to further coding.

3.        code coverage/statement coverage. If the agile team is following TDD (Test Driven Development), the pair programmers are normally concerned about the code coverage.

4.        they can decide to concentrate more on complex area of a class/function/module.

5.        spike/brainstorm on some issue

Why pair programming?

Probable answers are:

1.        Fundamental intention being code-review happens sooner and as a result; this gives wonderful chance to rectify the code sooner than the total time aggregated by series of process activities like - code-build goes to tester, tester finds a requirement gap (for example), raises defect, defect is picked up by developer, developer discusses with peers/HLD owner and then resolves it.

2.        Pair programming facilitates the knowledge transfer. This is an ideal way to bring new developers up to speed on the application.

3.        If in case, pair programming is genuinely not possible 100%, then team can gauge over most difficult area in the code or most sensitive module of the code. XP coach or SCRUM master can determine the stories that really require pair programming. Identify stories that may not be independent, i.e. code depends on other code module. Identify some stories that may not be clear from requirement point of view, OR some portion of the code seem like non-testable – those cases, pair programming is supposed be effective.

4.        XP coach or SCRUM master takes care of another aspect of pair programming, which is move people around.

         This helps the idea of “team” feeling, “collective ownership”, cross functional team. Members of a pair can break once a task is complete and pair with other member.

How pair-program?

Pair program, as the name suggests, two people working on a task on a single computer.

The best way to pair program is through co-location, sitting side by side in front of the monitor. Slide the key board and mouse back and forth. Both programmers concentrate on the code being written.

However, I observed an issue with this style of pair-programming set up. The navigator, if he has an input and wants to modify the code, he sometimes “hover over” the keyboard when the key board is with the driver. The best way I experienced was, having single monitor but a pair of keyboards and a pair of mouse, each device with each programmer of a pair.

Objections:

Sometimes, management discourages pair programming.

 Objections/concerns are raised from management point of view.

1.        “Pair programming is expensive. Why shall I pay two programmers for a job that can be done by one person?”

-Pair programming will cost more in short term. However, that additional initial cost will very likely be paid back with shorter schedules and with higher quality. That means lower maintenance cost. Since discussions and code-review get done at the same time of coding, there is less chance of missing a requirement, less chance of affecting an already existing functionality with your new code. This can be reinforced again by automated regression testing, I shall touch upon later.

Mike Cohn advises “Pair on the most difficult modules and see if they have fewer defects and are easier to maintain later, perhaps in comparison to similar modules from other programs done without pair programming.”

2.        During my initial days of exercising pair programming when I was in an Agile team (eXtreme Programming), I myself thought –“why the XP coach is deploying two resources to do one task. We are in hurry.”

-I asked her one day shading all my inhibitions. She was calm and replied “this is the time- we need pair programming the most”. Gradually I experienced, pairing leads to shorter project duration since fewer hours passed on the clock (it may take more person hours). High-visible projects are always under financial pressure. However, the comforting fact is- the overriding concerns are not so much person-hours as time to market. After all, everyone’s aim is to get the product faster in the market.

At last, ideally pair programming is not a mentoring program. There is not teacher-student relationship. The pair programmers are co-programmers, they are peers.

Agile: About continuous learning and how we can plan to learn

Plan to Learn is important concept and competency in Agile/SCRUM.

Management strives to foster team learning in different ways. If the scrum team behaves as whole team, if the scrum team is self-organized- this is when scrum master becomes happy and satisfied. Hold on! There are always scope of learning and improvement. The team is already performing, product owner is happy. Then why team needs improvement? Striving and achieving for knowledge improvement is again incremental and iterative process like SCRUM itself.

I must quote Mike Cohn’s remarks here. He discussed how to ensure learning conditions exist in the team.

In the proactive pursuit of team learning as a goal of the project, there are five conditions that are necessary for team learning to occur:

1.        Teams must be designed for learning.

2.        Individuals must have concrete ways of sharing knowledge.

3.        Leaders must reinforce the importance of learning.

4.        Teams need to be presented with motivating challenges.

5.        A supportive leaning environment must exist.

I believe these are the soft skills the leaders can cultivate in the team. Scrum team along with leaders can grow together as a “whole team”.

If the scrum environment is open and management foster team learning, there are built-in meetings in scrum that help to learn. Retrospective is one of them.

What is retrospective? Yes, you are right. The parent of English word retrospective is Latin word retrospectare. This means “Look back”. Why do we look back? We look back with the intention to improve. This is team improvement. The retrospective meeting is held by the whole team - Scrum Master, Product owner, scrum team. 

Who is facilitator? Scrum Master. Scrum master can maintain retrospective log. This is useful to validate the action items with next sprint’s events or actions. 

When does the meeting happen? Ideally it should happen at the end of each sprint, when team’s memory is fresh. If the sprint length is two weeks, retrospective normally happen at the end of the sprint, which is after sprint demo.

Ground rules to have successful retrospective? Leaders may wish to lay ground rules like:

1.        The team members need to give honest comments on what went well in the last sprint, what did not go well.

2.        Agile/SCRUM preaches to keep retrospective meeting short, simple and fresh. We followed Thinking Hat method to make the meeting interesting. We used two kinds (colors) of sticky notes - Yellow hat and Black hat. Yellow hat represents optimistic items - what went well. Black hat- what went wrong?

3.        Leaders should emphasize the learning aspect of retrospective, creating open environment. He is refrained from pin-pointing a team member who did not perform well and as a result velocity might not meet expectation.

4.        Promote active participation.

5.        Steal ideas from other scrum teams.

6.        Few steps/activities during retrospective meeting:

a.        Gather data,

b.        Analyze data

c.        Root cause analysis

d.        Generate insight

e.        Take decisions and

f.         Generate improvement plan if any.

The improvement plan and the lessons learnt are to be applied from immediate next sprint/iteration. For example, if there were significant impediments identified in the middle of last sprint and the team mitigated the risk of derailment of sprint schedule, should become a hot topic in the retrospective. 

Retrospective is different from project post mortem by nature. A project post-mortem is a process, usually performed at the conclusion of a project. This is to determine and analyze elements of the project that were successful or unsuccessful. Post-portem is performed when project is in closing phase, meaning there is no scope of implementation of lessons learned in the current project.

Learn through User Stories:

User stories can be defined as Agile requirement that indicates who will benefit, what we’re trying to accomplish, and clear acceptance criteria. Scrum team can learn about the product/service they are working on if they are thorough with each user story.

Having said this, user stories are different from well-formed requirement documents we create and baseline in waterfall model. Let me explain this below:

Initially, when the product is conceptualized, we have only high-level feature descriptions. This might be called “Epic”. Epic can give general shape of a product, but with missing specifics about functionality. Each feature is progressively elaborated as the project progresses.

Why progressively refine requirements?

·          Requirements will change due to priorities change over time.

·          Deliver as much as feature what is asked from scrum team, to give an early visibility of the product to the product owner/customer.

-          It helps us avoid falling into the trap of believing plan - While working in Waterfall model for quite sometime now, I have been creating test plan, reviewing test plan and baseline test plan. I do these series of activities when requirements for a project are said to be baseline. When I am happy considering my test plan is well-documented and is accepted by key stakeholders, I come to know there are quite a few CRs coming on the way and they have test impact. I have no other choice but to re-work on the plan including schedule. 

      Progressively refining a plan emphasizes the idea that even the best plan is subject to change.

  

User stories are derived from Epic-level user stories. Epic is divided into lower level deliverable user stories, forming product backlog. So backlog is desired functionality not present in the product. It is maintained by the product owner and can be shared with whole team. In contrast with traditional requirement documents, product backlog is dynamic in nature. Stories are added, removed, reprioritized each sprint as more learned about the product. Fix of a defect can become a user story in the next sprint or in current sprint if capacity allows.

User stories along with the simple steps are written on a HTML file or WORD file, for the developers to code. These are maintained in software tools.

One interesting fact is name of the user stories are often written on sticky notes and arranged on walls or tables to facilitate planning and discussions. Stories are arranged like: “Not started”. “WIP (Work in Progress)”, “Completed” in the story wall. Don’t you think if you are practicing agile/scrum, you are working in a vibrant ambiance?

Stories typically follow a simple template:

As a (type of user), I want (goal) so that (some reason).

Gaining acceptance on user stories:

Definition of “Done” – Team’s agreement on criteria to determine whether a story is complete

Definition of “Done Done” – Product owner’s acceptance on functionality required to confirm successful completion of a user story.

I have heard an objection while training the team on agile – “We are back-end software developers. We work on database. Why do we have to create user stories?”

Yes. Back-end software developers also have to create and follow user story if they are following agile. We should remember user stories are small chunk of functionality a team can produce in one iteration/sprint.

I have plan to further add some more topics under "Plan to learn" section:

1. Pair Programming

2. Simple design

3. Evolutionary design

4. Spiking

5. Refactoring

6. Team-based estimation  

Coming up next .....till then Happy Reading! 

Agile: About Self-organizing team

As an agile trainer, thought to start a series of articles on Agile/Scrum.

Let me begin with the fundamental concept of agile, that is "team". Agile relies on its team, we love to call the team as "self organizing team".

Self Organizing Teams:

Self Organizing team is a group of individuals, practicing Agile/SCRUM, organize themselves around a problem/challenge given to them by organization, without management’s direct control. Individuals are right people, chosen by management or they are already conditioned and think agile way. They are matured to give and receive feedback in constructive and proactive manner. They work in an open work environment, being "honest" to each other. They understand the client's interest, hence the goal that says delivering the software frequently. As a result, they are groomed and start cultivating the qualities/competencies that help them to deliver frequently. If they are matured to exercise SCRUM, noise will be less in the team. If there is any noise, management should step in to remove impediments. Scrum master is responsible person to guard the scrum team from external and internal impediments.

We believe that agile/scrum starts from “team”, not from “process”. Self-organizing team is fundamental concept of agile software development.

A self organizing team ideally will have following features:

Collective ownership:

Multiple individuals within the Scrum team pull tasks to contribute to the completion of a user story. Everyone shares responsibility for the quality and completion of the code. No single person claims ownership over any part of the system, and anyone can make any necessary changes anywhere. Another way of telling this as team works as “Whole Team”.

Why collective ownership is emphasized in SCRUM? This policy is believed to minimize delay from absent member of the team. The individuals in the team are expected to be cross-functional and owner of whole code. Since every iteration/sprint is time boxed, delay or lag is not entertained.

Cross-functional teams:

Every member of scrum team is expected to be multi-skilled. Does that mean a developer can test or a tester can code? Ideally, yes. However, with growing complexity of the system, this might not be 100% possible. Scrum master should strive to encourage the team to be armed with multi-skills and independent of fellow team member.  Scrum master can create an open environment and reward system that during time of need, right member of Scrum team can step up at right time.  And this is largely possible when the team is small team, isn’t it?

Small teams:

Team size is limited to 5-9 people to ensure everyone knows what the other members are working on. Members will pull unfinished stories and nobody will duplicate effort. The goal is to ensure reduction of waste. I have seen - the team can self-organize themselves, so that few members can work on main user stories of that ongoing sprint, and some can work on re-factoring of existing code to make the code more flexible to adapt change. Experienced scrum member can identify the perfect time of need to re-factor the code.

Parallel development and test:

Fail fast. What is that? Scrum preaches this policy. This means identify defects sooner rather than later. To ensure this, coding and functional test occur at the same time reducing down time for individuals supporting their user stories and catching defects at the earliest.  

I can think of two ways to achieve this:

1.   Pair programming: Two/multiple resources within a scrum team sit together to complete a task/user story. One is driver, who writes the code, and the other member is observer, who reviews each line of code. This way static testing of code can be achieved. The two members can discuss coding techniques, design pattern to follow, optimization of code, code coverage during pair programming. 

2.   TDD, Functional test and Automatic regression test: Test cases in TDD can be unit tests.

            When the code for a user story is committed in a repository, it should be unit test/functional test-passed and regression test passed. Since, scrum is incremental and iterative development methodology, regression test is mandatory.

Sustainable pace or sustainable velocity:

Scrum master should try to achieve this. This is something to do with building trust with Product Owner by being able to deliver a consistent amount of work over multiple sprints. The goal is to drive consistency in delivery. “Whole team”, “independent team members”, “cross functional team” are keys to achieve this competency.

Everything is hunky-dory? Please read on...

Per Mike Cohn, a misconception is that because of this reliance on self-organizing team, there is little or no role for leaders of agile teams. He says, self-organizing team does not free from management control. Control is exercised; but, it is subtle, indirect. Management chooses the product to build, or sometimes chooses the members to work in the project. Management control is exercised when needed, for example, if team needs direction after impediments created from evolution of behavior that comes from interactions of independent members of the team.

Another impediment could be wrong attitude coming from a team member who has agile-phobia. A person, who comes from a background that exercised thorough waterfall model for too long, shows resistance to accept agile. He tends not to accept the idea of “whole team” OR refuses to accept cross-functional work. Management control is exercised in giving him adequate agile-training.