Sunday, April 16, 2017

Exploring Five Pair Programming Techniques

A collaboration by Antonio Gonz├ílez Sanchis and Mario Moreira

Extreme Programming (XP) introduced a programming technique that’s been famous since its early days: pair programming. It sounds simple, two people working together with the same computer. However, what people don’t know is that there are many ways in which you can approach this technique. Let’s explore a few:

Driver-navigator: This is the best known style of pairing. It consists of one person ‘driving’, taking the keyboard and coding or doing the work, while the other one is ‘navigating’. The Navigator’s job is to pay attention to the work being done by the driver while keeping the big picture in mind.  They should guide the driver in the right direction. It is very important that driver explains every decision they make, otherwise the navigator might lose interest and may stop paying attention. It’s healthy to switch roles every now and then.

Ping-pong: For this approach you might need two keyboards connected to the same computer. In contrast to the driver-navigator mode, in ping-pong both people can be driving at any point in time. A good strategy for this approach is to have one person writing the tests while the other one tries to pass them. As in the previous approach, you should be switching roles often.

Backseat navigator: A typical approach when there’s a new team member in the group or a junior colleague. The navigator (usually the more senior team member) tells the driver, who has the keyboard, what to do to solve a problem with every little detail. The navigator should provide insights on how to solve the problem but also on why that’s the best solution in mind. It’s a good way to ramp up new members in your team as they build relationships with other people in the team while learning about the working style.

Tour: If there is an even number of team members or someone who you used to pair with went on holidays, you are not going to stop working. However, when those people return or you start pairing with someone, you don’t want them to start right away. Therefore, a good way to start would be to do a ‘tour’ through the code or work you did in their absence. The person who doesn’t know the most about the work takes the keyboard and the mouse and starts driving through the code while the ‘expert’ acts as a navigator and explains every detail.

Distributed pairing: Often people tend to think pairing is for collocated teams but that’s not entirely true. While pairing face-to-face is definitely much more effective than remotely, there are many tools and ways colleagues can pair. A good suggestion would be to use a videoconference messaging tool with a screen sharing app that allows the navigator to see in real time what the driver is doing.
These are not the only pairing styles that you might encounter but they are the best known.  They are also the easier techniques to try when you want to start pair programming. Also, examples seem to focus on software development but pairing is applicable to almost every field.  For example if you are in marketing and are launching an email campaign, you can pair with someone to navigate through the email while you write it, etc.

There might be anti-patterns when pairing. For example, you might find cases when the navigator is ‘sleeping’. This means the navigator can be checking emails, texting or even coding in parallel without paying much attention to the driver. Try to identify the root causes of this behaviour before you jump in into action. Usually it might be because the driver is not explaining properly the reasons why he is doing a specific task in a particular way.

Lastly, keep in mind that while pair programming may work in every role or department, it might not be suitable for every work. There will be times when you just want to discuss the approach with the team and go do it by yourself. That’s also a way of getting feedback, which in the end is the main purpose of pair programming: getting feedback early.  

If you are interested in trying pair programming, the first thing to do is review the list of possible techniques (above) and select one that you will experiment with.  Then identify your pair.  Brainstorm on how you might approach pair programming, specify how long you will try your experiment, and begin.  

------------
Learn more about Antonio Gonz├ílez Sanchis at https://www.linkedin.com/in/antoniogonzalezsanchis/

Read more of Mario's article at: http://cmforagile.blogspot.com 

Sunday, March 26, 2017

New Book: The Agile Enterprise: Building and Running your Agile Enterprise

Imagine an enterprise where everyone focuses on the highest customer value.  Where strategy to tasks are visible so everyone knows if their work is aligned with the highest value work. Imagine an enterprise where a discovery mindset wins over certainty thinking. Where experimentation with increments and feedback help define the way toward customer value.

Imagine a company where employees use 100% of their brain power to self organize around the work and be trusted to think of better ways to work. Where leaders encourage employees to put customer value first.  Imagine an enterprise where customers embrace the products and services being built because they are engaged in the building of the work all along the way.

If you can imagine it, it can be yours!  In this unique and cutting edge Agile book, veteran Enterprise Agile Coach Mario Moreira, will guide you to build and run an Agile enterprise at every level and at every point from idea to delivery. Learn how Agile-mature organizations adapt nimbly to micro changes in market conditions and customer needs and continuously deliver optimal value to customers.  Learn cutting-edge practices and concepts as you extend your implementation of Agile pervasively and harmoniously through the whole enterprise for greater customer value and business success.

Readers of The Agile Enterprise will learn how to:
  • Establish a Customer Value Driven engine with an enterprise idea pipeline to process an enterprise’s portfolio of ideas more quickly and productively toward customer value and through all levels of the enterprise
  • Incorporate the Discovery Mindset; experimental, incremental, design, and divergent thinking; and fast feedback loops to increase the odds that what you build aligns more closely to what customer wants.
  • Leverage Lean Canvas, Personas, Story Mapping, Cost of Delay, Discovery Mindset, Servant leadership, Self-organization, and more to deliver optimum value to customers
  • Use continuous Agile Budgeting and enterprise idea pipeline at the senior levels of the enterprise to enable you to adapt to the speed of the market.
  • Reinvent Human Resources, Portfolio Management, Finance, and many areas of leadership toward new roles in the enablement of customer value. 
  • Establish a holistic view of the state of your Agile Galaxy from top-to-bottom and end-to-end allowing you to understand where you are today and where you’d like to go in your Agile future.
  • Be truly Agile throughout the enterprise, focusing on customer value and employees over all else.
This book is geared for: Sponsors of Agile Transformations; Executives and Senior Management; Agile Coaches, Consultants, and Champions; Portfolio Management; Project Management Offices (PMOs); Business and Finance; Human Resources (HR); Investors and Entrepreneurs; Scrum Masters, Agile Project Managers, and Product Owners. 
This book concludes with an adventuring through an Agile Enterprise story that shows you how an enterprise may transform to Agile in an incremental manner with materials in this book.  Let the material in The Agile Enterprise help you achieve your successful customer value driven enterprise.

Thank you to the contributors JP Beaudry (on Story Mapping) and David Grabel (on Cost of Delay)!  A special Thank you to the Apress editing team!

Sunday, March 5, 2017

Are you closing the Distance in your Agile Journey?

An interesting phenomenon has arisen in Agile environments that could become litmus tests to determine if you are Agile.   This phenomenon is the concept of “closing the distance”.   There are three areas that closing the distance is both Agile and good for companies.  The three areas include the distances amongst employees, the distance between employees and customers, and the distance when an idea comes in until it hits the marketplace. Let’s explore each in more detail. 
Closing the Distance amongst Employees – Agile focuses a lot on individuals and interacts as one of its values.  The intent is that employees should be on teams with a common purpose bringing people closer.  Agile advocates the concept of swarming where employees collaboratively work together to get work done.  If you are a manager, Agile asks you to get closer to your employees by removing their impediments and also aligns with the practice of walking the “gemba” (walking the halls and asking if you can help employees by removing impediments and more).

Closing the Distance between Employees and Customers – In many non-Agile organizations, there are often a number of degrees of separation between employees and customers.  Agile asks that employees come face-to-face with customers in the demos to gain the precious customer feedback.  I recommend the “two degrees of customer separation” rule where no employee (including management) should be more than two degrees of separation from the customer (e.g., you to employee to customer or you directly to customer). 

Closing the distance between recording an idea until it hits the Marketplace – In this case distance is the lead-time (clock time between the moment the idea is recorded to when it gets released).  If you are doing Agile well, you will ensure the new idea (e.g., new requirement), assuming it is of high enough value, gets looked at immediately, and not wait until the next budget cycle.  Additionally, Agile expects that you will proactively attempt to shorten the distance from idea to release by reducing wait states and removing impediments.  

In summary, have you noticed that during your Agile journey that you have seen the distances get shorter? Are you getting closer to your colleagues and employees?  Are you getting closer to customers?  And is the lead-time distance being shortened from the moment the idea is recorded to when it gets to market?  If not, then maybe you’re not as Agile as you thought.  If you have, then you are headed in the right direction.  Could awareness of these three distances provide you a litmus test on whether you are moving in the direction of agility?