Skip to main content
uk

  • Increase Speed to Market
    Deliver quality quicker by optimising your delivery pipeline, removing bottlenecks, getting faster feedback from customers and iterating quickly.

  • Enhance Customer Experience
    Delight your customers in every digital interaction by optimising system quality and performance to provide a smooth, speedy and seamless user experience.

  • Maximise Your Investment
    Realise a positive ROI sooner and maximise your investment by focusing your energy on high-value features, reducing waste, and finding and fixing defects early.
  • The Wellington City Council (WCC) wanted to deliver quality outcomes without breaking the bank. Find out how Planit’s fast and flexible resources helped WCC achieve this goal.

this is a test Who We Are Landing Page

BANKING
Banking like a start-up.
MEDIA & BROADCASTING
Capture your audience
EDUCATION
Do your systems pass the grade?
MINING & RESOURCES
Innovate with confidence.
GAMING & WAGERING
Game day performance.
 

In Agile, Two Heads Are Better Than One

By Kate Ellery | Account Director

INSIGHTS // Articles

9 Oct 2017

#Agile|#Consultancy|#TestManagement

INSIGHTS // Articles

#Agile|#Consultancy|#TestManagement

By Kate Ellery

9 Oct 2017

There is a fairly well-known saying, one which originated in the 1500s, that says that “two heads are better than one”. It infers that two people working together have a better chance of solving a problem than one alone.

In Agile, Two Heads Are Better Than One

Author C.S. Lewis expanded on the concept, stating that “two heads are better than one, not because either is infallible, but because they are unlikely to go wrong in the same direction”. The same principle can certainly be applied to Agile teams.

The concept of pair programming originated in XP (Extreme Programming), where two developers worked together at the same workstation. The person writing the code is called the ‘driver’, while the person reviewing is called the ‘navigator’.

By working together, they watch, learn, ask questions and make suggestions. Benefits of this approach include better quality code, ensuring best practice coding standards are met, and sharing knowledge to reduce the dependency on particular individuals.

Pairing is commonly used in Agile teams for solving problem and sharing knowledge between team members. But we take it a bit further and encourage regular collaboration between all team members, rather than restricting it to two developers working together as the traditional XP principles dictated.

In Agile teams, there are other types of pairing, which are as follows:

Two developers pairing up is beneficial for the resolution of complex issues and earlier detection of defects in the code. Swapping the driver/navigator roles regularly also helps to share knowledge between the two, reducing bottlenecks that often occur if only one team member is able to work on various tasks. It also reduces the need for separate code reviews, and gives greater confidence that the code being developed is of higher quality and the best designed solutions.

A developer could also pair up with a business analyst. This can assist the developer in understanding how the system is used by the business or end user, as well as helping to define how much is required to meet the acceptance criteria.

Developers pairing with testers can benefit both parties. Using their specialist skills, testers can help define test scenarios that the developer may not have previously considered when working alone. This is especially helpful when a Test-Driven Development (TDD) approach is being followed, and the tests are written before the code. Developers could focus on the positive/happy path while testers think of negative scenarios, such as boundaries or equivalence partitions, ensuring defects do not make it into the code.

Two business analysts working together can help to elaborate acceptance criteria and requirements, ensuring there are no gaps or ambiguity which could result in time wasted developing and testing the wrong thing. It can also help to share business knowledge, particularly if one of the business analysts is new to the team and/or organisation.

A business analyst and tester could also join forces. In this scenario, the business/domain knowledge is again valuable to guide the tester in designing their test scenarios, while the tester can mentor the business analyst using their testing experience. This way the BA can help out when testing activities require “all hands on deck” near the end of a release. This pairing also assists in ensuring acceptance criteria is complete and testable, reducing the risk of user stories being declined during review sessions.

There are several benefits of two testers working together.

  • Any two testers can work together to review automated or manual tests can ensure appropriate test coverage.
  • A new tester to the team can pair up with an experienced one to gain domain knowledge, or learn Agile practices if they haven’t worked in an Agile environment previously.
  • An experienced test automation specialist could work with manual testers to ensure the correct tests are automated, while the manual tester picks up new technical skills allowing them to automate their own tests once they gain this knowledge.
  • A performance tester can share their knowledge with the team to allow them to consider tests such as load and stress testing earlier, rather than leaving until the end.
  • A security tester can guide the team in testing for security issues earlier in the product creation, giving the project a higher chance of being released on time and meeting expectations.
  • Test managers can mentor and coach more junior testers to identify and mitigate risks early.

The team could also look at pairing with business users or end customers to understand how they use the system. Alternatively, an Agile coach could work with any team member who is new to Agile to help mentor them in the different ways of working compared to traditional projects.

Collaboration between more than just two people at a time is also encouraged in Agile teams. As the requirements or user stories are being elaborated, it is recommended to include the “power of three” or “the three amigos”, where the conversations include a business analyst, developer and tester in all discussions. This ensures all roles are considered when breaking down what and how the team needs to deliver to successfully meet the needs of their customers.

Often it is difficult to get buy-in from product owners, as they see two or more people working on one task as higher cost and you often need to explain the benefits to them. Discuss at your retrospectives whether pairing may have helped with some of the issues you encountered during your last sprint, and consider pairing when breaking your user stories into tasks at your next sprint planning session.

In summary, pairing is effective in receiving the advice or opinion of another person to help resolve problems or issues, or allow for the quick transfer of knowledge. Pairing can also help lift morale within the team, and build good rapport between team members.

The team is increasingly likely to take more ownership of their tasks, and take pride in the product that they are delivering. Everyone wants to work in a happy team that bonds well, so take some time to consider how pairing could benefit your team.

Listen out for blockers or issues in your stand-ups, since you may be able to assist in solving a problem that someone else is encountering. After all, for the right types of tasks, two heads are better than one!

Join The Discussion
Enquire About Our Services