Tuesday, 12 August 2014

Pairing -- Effective tool for quality software

Pair programming or pairing in short is one of the many practices followed in agile software development where two people work together on the same piece of code. Usually a user story or a task is assigned to a pair of developers and they work together on its implementation on a single machine. One person is the driver who types the code and other is the navigator. There is no rule on who is the driver and who is the navigator but they should rotate roles frequently. 

Perks of pairing

  1. Code quality:- 

    When two people are trying to solve the same problem, they bring in their individual experiences and different approach to solve the problem. They question each other, discuss the details, brainstorm and then arrive at the best solution. This definitely improves the design and code quality as compared to an individual working alone.  A study has revealed that the code resulted out of pair programming has around 15% to 20% less defects than the code written by an individual.
  2. Individual learning:- 

    There is constant knowledge sharing happening while pairing. Pairs learn a great deal from each other, right from smaller keyboard shortcuts to design patterns there is a constant learning happening. Most of the time when two people pair, one is an expert in one area and other in another. For example, one person is a java script guru while other is  nosql expert and eventually when they pair they shower their blessings on each other.
  3. Elimination of human errors:-

    There are two pairs of eyes constantly looking at the code which eliminates human errors and silly mistakes are caught while programming. There is no scope of a person being lazy and taking shortcuts because there is another person sitting next to to him/her reviewing the code all the time.
  4. No knowledge pockets or dependencies created:-

    There is no dependency created on a single person. Every functionality is being implemented by a pair and with frequent pair rotations almost everyone in the team would have a fair idea of everything. There are no knowledge pockets created hence there is no need for a full fledged KT plan if a person is rolling off the project or leaving the organization.  There are definitely some module experts but continuously pairing with them spreads the knowledge across and pairing in itself is the best way of doing knowledge transfer.
  5. Increased productive time:- 

    People avoid unnecessary meetings and calls because they know their pair is waiting for them.  People are not usually pulled into distracting conversations if they are pairing which otherwise they would have. People don't waste time on social media, gaming or chatting while pairing but they still have someone to talk to in person all the time. It is being observed that people spend more productive hours while pairing rather than working alone. Along with this there is no dedicated time required for code review because as people pair they also review.

What pairing is not?

Many people/organizations have some misconception about pairing. Pairing is not where
  • one person implements and other reviews the code. 
  • two people distribute tasks among themselves and work individually.  
  • one person implements and explains the code and the other person listens.  
Pairing is where two people work simultaneously on the same piece of code where one is typing and other is reviewing and they switch roles frequently. Pairing is done on a single work station often known as a pairing machine.  Person who types the code is the driver and the one who reviews is the navigator and they switch roles frequently by taking the keyboard control. There is no rule on when to switch roles but it is advisable to switch on a logical break point. It is also recommended in one of the articles that not one person should not drive for more than 20 minutes. But again as I mentioned there is no hard and fast rule as long as people are switching roles.

Effective pairing combinations

To get maximum out of pairing, it is very important to have a proper pairing combination. It is advisable that an experienced developer pairs with a novice developer. This enhances the learning curve for the novice developer and provides mentoring opportunities for the experienced person. But then the experienced person should rotate pairs with someone who is more experienced than  him/her so that he/she also gets to learn and he/she is questioned and challenged enough. Sometimes it is also important that a novice person pairs with someone with same experience and similar skill set. This helps them explore more rather than just listening to the mentor. Hence, all the three pairing combinations are effective when used appropriately:-
Expert pairing with novice:- Most effective and most recommended.
Expert pairing with expert:- Most productive for complex features but an overkill for simple functionality.
Novice pairing with novice:- Advisable for simpler implementations with more learning space.

Pair Rotations:-  

One important aspect of pairing is frequent pair rotation. One person should not keep pairing with the same person for a long time. There is no defined time on when the pairs should rotate but it is always advisable at a logical point in the story or the functionality. Sometimes the stories are so small that the same pair can finish it but then ensure that they don't pair for the next story.  With proper pair rotations almost everyone in the team gets to work on the functionality and gets some idea around the code.

Who can pair? 

Developers pairing with developers is common and that is what pair programing is all about. Sometimes it is advisable for QAs to pair with each other while testing a complex module or automating functional tests. But along with this, some cross functional pairing is also very important and useful for delivering quality software.
  1. Developers pairing with QAs:-

    Developers can pair with QAs while writing unit and integration tests. QAs can help developers in terms of scenarios to be covered at unit and integration level. Also QAs get a hang of what is already covered at unit level so that they don't repeat the same scenarios during functional testing.
    Also, developers and QAs can pair while automating functional test (UI driven). Specially when there is a framework to be built for functional automation, developers can utilize their programming expertise and pair with QAs for initial implementation and then QAs can enhance there onwards.
  2. Developers pairing with BAs:-

    Some stories require some amount of technical analysis and at such situations BAs should pair with developers. BAs and developers pairing help BAs to understand the technical implications and feasibility of an application whereas developers come to know which way the requirements are going so that he/she can start thinking about the implementation in the same direction. BAs and developers pairing help in eliminating most of the last minute surprises.

  3. QAs pairing with BAs:-

    BAs and QAs should pair while writing acceptance criteria for a story and also while designing test cases. QA mindset of breaking the application can help BAs to come up with the negative acceptance criteria. While BAs can help QAs to understand the business relevance and prioritization of test cases based on business value.

    People might find pairing costly but it is definitely way cheaper than fixing  production defects and sometimes even bringing the system down. It is like saying I cannot afford insulating the wires but I can bear the consequences of an electric shock.


Thursday, 7 August 2014

Faster Waterfall is not Agile

Most of the organizations have a myth that if they have shorter release cycles they are agile. And at most times they don’t even follow basic agile principles. There is a general misunderstanding among organizations that they are agile if :-
  • They have shorter release cycles
  • They don’t document
  • They don’t plan upfront
  • Their requirements change frequently
  • They do daily stand ups
Hence as part of this post I would throw some light on what is an actual agile world and how a software is delivered in quick releases by following agile practices like Continuous Integration, Dev box testing, client showcase, etc.

Most of us are aware of the agile manifesto which talks about :-
  • Individuals and interactions over Processes and tools
  • Working software over Comprehensive documentation
  • Customer collaboration over Contract negotiation
  • Responding to change over Following a plan
But how to achieve these on a project on a day to day basis is a challenge. Here are the few practices that would help you follow these agile principles and enable you to successfully adopt agile :-

Individuals and Interactions over Processes and tools:-  

  • Instead of  requirement gathering sessions that lasts for around two months, do shorter project inceptions for a week or two. 
  • Rather than Tech Lead estimating on behalf of everyone, involve the entire team in estimation.
  • Practice pairing instead of tech leads and managers reviewing code.
  • Conduct retrospectives rather than doing individual performance reviews.

Working software over Comprehensive documentation:-

  •  Document requirements in smaller chunks as user stories vs heavy requirement specifications.
  •  Do regular Dev Huddles rather than documenting technical designs.
  •  Have a good automated test coverage instead of documenting test scenarios with detailed steps. 
  • Make QAs do testing on a developer box to get early feedback rather than publishing release notes to them
  • Have user friendly and responsive design instead of heavily documented user manuals.

Customer collaboration over Contract negotiation:-

  • Rather than asking customer to review heavy requirement specs get their feedback and sign off on user stories
  • Instead of waiting till the end for a complete product demo keep doing story showcase and keep getting regular customer feedback
  • If there is a bad news like technical complexities, unknown discovered or any other blockers share it with customers as soon as possible rather than giving last minute surprises.

 Responding to change over Following a plan:-

  • Instead of having a dedicated design phase and having a complete design upfront let your design evolve along with the product.
  • Rather than having a full fledged product/project plan, plan in smaller chunks for an iteration or a sprint.
  • Instead of manager deciding who does what and assigning tasks to the team let the team do a daily sign up and decide what they want to work on.
  • Implement product feedback regularly rather than creating product backlogs.

According to me a successful agile project should achieve following 3 goals:-

I. Get early feedback and fail fast:-

  • Customer involvement:- Involve customer and get their feedback on every stage - inception, story sign off, story showcase, super showcase.
  • Continuous testing feedback:- Get testing feedback and defects identification at unit and integration tests level, dev box testing, build, smoke, regression. Earlier the failure easier the fix.

II. Easily adopt to new requirements and give your clients agility:-

  • Early feedback and Adaptability:- Getting feedback from clients at every stage helps clients to be flexible. Changes can be easily incorporated as they are requested at the start of the cycle.
  • Product Vision:- Clients can see the product evolve and hence can come up with better ideas for the short and the long term vision.

III. Improve quality of the product and yet deliver faster:-

  • Improve Quality:- With so many checks and safety nets at every stage, the product becomes stable and of a high quality.
  • Faster delivery:- Practices like continuous integration, test automation, etc. helps in reducing the cycle time.

A quality software which is delivered at a faster and regular releases and is easy to incorporate changes and keeps the team happy and customers satisfied, determines the success of agile.