I was hired into a company to run an enterprise product engineering organization. My job beyond feature development and release delivery was correcting a failing two-year Scrum transition.
After two years, the organization was delivering higher productivity per engineer, improved feature quality, and increased development velocity. Scrum development process was corrected and maturing. The time came for restructuring.
Customers were using more Cloud offerings and were requesting a Cloud offering from the company. Since less development engineers were needed on the enterprise product team, as part of the restructuring, I spun off a team of 30 highly skilled engineers and a manager to do strategy and early offering development for Cloud users. I took leadership of the team due to my Cloud experience.
I needed the new team to increase their learning speed by an order of magnitude, adopt new architectures, use new languages and embrace DevOps. While none of this was in dispute with executive management and the team, adopting pairwise development (programming) would be the key enabler. I had discussed pairwise development earlier with executive management. Pairwise development was considered too radical due to the potential of talent loss and confusion with HR’s focus on individual performance.
Getting a credible strategy and initial offering into the executives’ hands was critical. Other alternatives such as outsourcing, using a different internal team, hiring a new technical leader and hiring a new team were considered and ruled out because of timing, lack of skilled talent and lack of executive management support. Most of the company considered Cloud offerings to be more fad than reality. Using the existing team members meant that we had to increase their learning speed, knowledge and new value creation.
While there are many blogs and articles describing the benefits and pitfalls of pairwise programming, I found no definitive measures of before and after improvements, no assessment of team characteristics that would indicate success, and no clear business analysis of economic pros and cons. I decided to build an argument based upon knowledge, earned trust and focused experimentation.
Pivotal Labs was founded on the principles of Agile, customer value first and pairwise programming with their hands-on Dojo Labs. I asked the team to join me for an afternoon visiting the Cambridge Dojo Lab. After the visit, I held a group meeting where I talked about our journey together over the past two years, our skills gaps, our need for quick customer value development, and what lies ahead in the for our customers who will adopt Cloud offerings. I asked the team to take the next step to pairwise programming for the next 90 days as we focused on our first offering. I offered that the risk of failure would be owned by me and that the first pairings would be a starting point to be adjusted as needed. After 90 days we would assess their experiences and choose to adopt or adjust together as a team. I left the meeting to allow team discussion.
The team agreed with the reasoning and the approach. They took the weekend to consider who each would choose as a partner. Fortunately, the pairing requests were reasonable, and the manager was able to handle the conflicts. While awkward, they started to work in pairs on the sprint objectives. Slowly, most pairs took on their own singular identity and worked closely together on assignments. For the pairs who were struggling, the manager worked with them and restructured a few pairs to increase the chances for functional pairings.
As soon as the team agreed to pairing, I engaged executive management across the division. I informed them of the reasoning and team agreement. Since the risk was limited, need was clear and potential upside explained, management signed off on us continuing with pairwise development. I engaged HR to ensure that we would abide to their focus on individual performance.
Immediately, the rate of learning accelerated. Pairs were more willing to take up things that they didn’t know. They helped each other understand and apply the new technologies. While individuals historically wanted months to read, learn and apply. Pairs took days to dig into new topics and quickly showed results. Pairs instructed the team at-large on their findings and demonstrated the newfound value.
Pairs showed an increase in their willingness to take risks. The ‘I have got your back’ reality of a pair’s partnership helped a pair member share concerns and find solutions. This allowed the pair to take on more risk since another person was actively engaged to identify and address risks immediately.
After the 90-day period, the team agreed to keep pairwise development. Only one senior developer decided that he could not work in this model and left the project. The team created a go forward strategy and delivered the cloud offering as a viability proof. Subsequently, the team joined another SaaS effort and released this new SaaS offering into production. Two plus years later, the team continued to use pairwise development. When asked if they would go back, they could not imagine doing development any other way.
I should have done a few things differently. I should have dug deeper into documented cases where pairwise programming improved productivity, especially increased learning/application speeds and risk taking. I should have bootstrapped a smaller team earlier, for example, the initial team of 30 might have gone pairwise up to 6 months earlier. I should have spent more time with management early on especially with risk mitigations and leveraged the company culture more by invoking company culture of employee skill investment.
Looking back, I believe that highly skilled engineers want to continue to improve their professional skills. Showing how new approaches and technology helps their productivity and professional standing was a powerful force to motivate learning and facilitate application.
