Why Should an Exec Support XP Pair Programming?

I was just asked whether I had metrics to demonstrate our pairing practice benefits the business compared to waterfall.

Pairing at Oxygen (Daniel & Evan)In my business context, I can’t cost-justify the kind of measurement Jeff Sutherland illustrates in his paper demonstrating efficiencies with Scrum in a CMMI 5 organization. Someone needs to do the same thing for XP practices. We have raw data from our revision control and tracking if that will help.

What I have to say is subjective. As a VP, I want our work more innovative, our code more maintainable and our progress more predictable. Pairing supports these goals in the following ways:

Shared Ownership

A risk managed approach to IT encompasses the bus test – how deep a hole are you in if one or two key people we’re suddenly unavailable (as in hit by a bus). Aside from specifications, waterfall tries to solve this with comprehensive code reviews and standards guidelines. In my experience, these were good intentions that NEVER happened. The problem was they sat outside the inherent work of writing code and felt like overhead.

In pairing with switching, these goals are largely accomplished in real time. And rather than management pulling teeth, the team themselves champion it.

Visibility

In a waterfall process, accurately monitoring progress takes great amounts of non-value adding effort by someone with a high-level of development experience. In pairing, the pair is constantly discussing progress. A project manager (or scrum master in our case) in the room, is able to learn a lot osmotically without pulling developers off task.

Momentum

As a developer myself, I understand that even the most talented coder can get side tracked, distracted, bored or otherwise stall out. Pairing forces focus. In a culture of collaboration fostered by pairing, developers use each other to break through obstacles. Progress is much more predictable and developers produce more efficient and purposeful code.

New Hires and New Learning

Bringing new or junior members up to speed is a high overhead to a small team. Often, the best learning happens when two people of roughly the same skill work together. Sometimes someone with less experienced needs mentoring by someone with more. Pairing ensures each person has the opportunity to learn from everyone else. Carefully vetted, new hires on our team begin contributing within the first sprint.

I have complete confidence my team can bring in new technologies and languages. They’ve proven it to me with Ruby, WPF, and SQL Server OLAP/Analysis Services.

Creativity and Collegiality

Pairing at Oxygen (Luke & Wendy)The types of people who seek out a pairing environment are social, take initiative and want to engage in the big picture. These types of developers create a vital workplace and contribute more fully to product development. I’ve written several papers getting at the relationship between collaboration and innovation.

Pairing fosters friendships that extend beyond the workplace. Gallup has found a high correlation between worker engagement and whether they believe they “have a best friend at work.”

To Conclude

I admit these are all subjective observations. However, my day to day experience convinces me our team is much better for our pairing practice.

Since we began pairing, even the most senior of our developers has grown their technical and interpersonal skills. We have delivered predictably for our business on multiple streams of work in diverse, sometimes emerging technologies. I’m confident we can maintain our applications no matter which team member takes vacation.

Finally, not one of my team “clocks in”. They bring their whole selves to our work and our workplace. If a manager needs a chart to tell them why that matters, they shouldn’t have authority over people.

Microsoft and Ript

Gerry spoke at the Microsoft Women’s Conference this week.

Ript

I joined her so that we could meet with some key players at Microsoft to talk about Ript™, our WPF application.

Attending were Henry Hahn, WPF Program Manager, Darren Mc Cormick, Worldwide UX Role Owner, and Katherine Westgate, a Marketing Officer from Microsoft’s NY office.

The conversation ranged over the whole history of our project: our Scrum/XP practices, how our team collaborates on user experience, how we created our product vision and our plan to monetize the product.

The three of them were entirely approachable, engaged and enthusiastic. They also came prepared. They’d all downloaded and worked with our application. Henry actually submitted feature suggestions from his team he knows are easy to implement given what we’ve already created.

Katherine helped pull the attendees together and lined up our hands on demo of Surface™. She was interested in figuring how our experiences with Ript™, agile software development and collaborative product ownership might help her enterprise clients. She also asked Gerry how Oxygen approaches advocacy for women, corporate good will and citizenship. Katherine is sharp and conscientious. I could tell Gerry hit it off with her.

Darren described the Developer Platform Evangelists (DPE) programs for joint marketing and developer assistance around products built in WPF and Silverlight. We discussed some of Microsoft’s goals for Silverlight distribution and what Oxygen’s next steps are to engage these resources. Darren is clearly passionate about user experience at the level of product, brand and within an organization. Yet another example of Microsoft going outside its organization to bring in new thinking.

Gerry’s main points were that women are the principle market for consumer technology, that usability testing with women provides valuable insight, how software should playful, purposeful, simple and accessible and how product development should not focus on early adopters but the people who will make up the vast majority of end users should the product be successful.

The conversation also ranged over tech issues. Henry is a fan of our application and left an open door for further communication. He said the .NET team is working on some of our core concerns:

  • breaking up the .NET 3 installer into server and client modules making the package smaller
  • improving the experience of their default install (it plays out like a windows update, hiding itself in the system tray – this is very confusing in an application install process)
  • making it easier for ISV’s to run a silent install and wrap their own UI around the install
  • improving cold start time
  • providing more expressive API’s for automated UI testing

Don’t expect any of this soon unfortunately.

Clearly there are employees at Microsoft in leadership roles determined to engage with and support, not simply consume, innovative work originating outside the company. I had the same impression at the ALT.NET conference earlier this month.

This bodes well for both Microsoft’s future as well as for those of us looking to innovate in the marketplace using their tools and platforms.

Team

At Oxygen, we have a team. Knot

Building this team has been the collaborative work of years.

Our CTO, Steve, made IT a strategic asset and championed a seat at the table for software development. I introduced agile principles, carved out space for agile development practices and built a product team.

Our dev director, Luke, and coach, Kris, built a disciplined XP practice. Our product team, Ilio and Suzann, and our Scrum master, Salim, built our Scrum practice.

With Luke’s lead, the team built itself by adding exceptional talents and engaging human beings. Wendy, Oksana, Lee, Robert, Daniel and our first UX Designer, Bob. Each brings experiences, specialties, passions and humor that spurs creativity in our products and simplicity, quality, and expressiveness in their underlying implementation.

For the last year, our team has included our CEO, Gerry, an inspiring and audacious product owner.

Over almost eight years together, the core of us struggled through bad practices and mediocre projects. We taught ourselves better methods and brought in great talent providing the best fit. We grew, we availed ourselves of experienced coaches, we matured, we hit our stride. Now we contribute to our field through open code, writing, presentations and mentoring.

This team is a competitive advantage. We share values, practices, and history. We have complimentary strengths, camaraderie and spirit. We are inventive, versatile and fast on our feet. Our dedication to each other is our strongest retention and recruiting tool.

I care for these individuals and I love the team we’ve created.

The Oxygen Team

The Day Oxygen Became Extreme

Extreme What? by Justin DonnellyAt the precipice of change, we are getting sentimental here at the Oh! Network.

As a developer joining Oxygen NY in 2001, I entered a code and fix culture under a facade of waterfall planning. I fought arbitrary dates, bloated specifications, and reality-challenged reporting. I acquired a survivalist’s skill for landing valuable projects and picking co-workers who helped carry them to completion.

As team lead, I made myself project manager. I used a risk-managed, iterative approach based on Steven McConnell’s Software Project Survival Guide and Earned Value Planning. We provided transparency, met dates and exceeding expectations.

Still, I had the awful, lonely feeling it was unsustainable. A tiny team, we were isolated from each other. We needed a collaborative practice. We needed to share knowledge, commit to a common way of working, and lift each other past our individual limitations.

I found the following e-mail thread capturing the moment we adopted Extreme Programming (XP). A bit of everyman’s history with a very small ‘h’…


From: Ken Judy
Sent: Tuesday, January 13, 2004 2:40 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: Agile Methodologies

Here are sites for different agile methodologies. Of the five of them, XP is the most exacting. The others are generally light frameworks for ways of developing or managing projects that support the agile manifesto http://agilemanifesto.org/.

XP: http://www.extremeprogramming.org/
Scrum: http://www.controlchaos.com/
Crystal: http://alistair.cockburn.us/crystal/crystal.html
Adaptive Software Development: http://www.jimhighsmith.com/
Feature Driven Dev: http://www.featuredrivendevelopment.com/

— Ken


From: Luke Melia
Sent: Wednesday, January 14, 2004 5:09 PM
To: Ken Judy; Kristofor Selden
Cc: Keith Frank
Subject: RE: teamwork

Hi Ken,

Kris and I spent some time today reviewing the agile process frameworks you sent around and met this afternoon to discuss our planning. We’re going to follow the XP rules and practices for the most part.

http://www.extremeprogramming.org/rules.html

We will likely invest somewhat more effort in up-front detailed requirements in order to support your work-package tracking efforts. In addition, some practices are irrelevant for a team consisting of a single pair of developers. We’ll ignore those and pay close attention to the practice “Fix XP when it breaks” in order to arrive at a set of practices that is effective for us. I’ve read the criticisms of XP that argue it is “all or nothing” but I feel that this approach will work for us.

We’re going to be pair programming and plan to work together 11am – 1pm and 2:30 – 5pm. This will allow us time at the beginning, middle & end of the day to respond to email, etc.

This is all going to start this Friday. On Friday, we’ll do a code review, go over the task breakdown for the SES project and plan for our first milestone, as you suggested. I’m also going to rearrange my desk to make it work better for two people to sit at.

Luke


From: Ken Judy
Sent: Wednesday, January 14, 2004 5:31 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: RE: teamwork

Sounds good. Our team is so small that a strong agile approach should work well as long as we manage risks. I’ll look into the “Tracker” role in the XP model to see how to adjust my tools to your approach.

— Ken


From: Ken Judy
Sent: Thursday, January 15, 2004 10:33 AM
To: Luke Melia; Kristofor Selden
Subject: RE: teamwork

Hi,

Please go ahead and block out 11:00am-1pm and 2:30-5pm in your calendars as “busy”. I’ll send out an e-mail to IS all so they know what’s up. Feel free to decline any meeting requests at your discretion and let me know of anything in your calendars you need me to cover for you on.

We will need to start the morning “standup” meetings so that we keep focus on the project and one of the things we’ll need to address is how to best use Michele as owner.

— Ken

Scrum without XP?

My team built an XP practice before introducing Scrum. The desire for change arose within the developers and was about sharing, becoming better at our craft and making our productivity and quality more consistent.

Scrum became necessary when our biggest problems were no longer within the team but in how we took on work from the business.

I started thinking about that at the last XTC-NYC when Mike Roberts wondered aloud if Scrum software development can work when a team doesn’t practice at least some aspects of XP. In a similar vein, Scott Bellware has a post about XP deserving more credit for Scrum’s success.

At XP-Spin, Jeff Sutherland said the success you build on is delivering working code at the end of each iteration. To even begin you need work described in achievable stories with acceptance criteria and daily builds.

Oxygen Standup

Mike and Scott are definitely right when I look at my team.

Our present challenge is aligning our development with a clear and achievable business objective. Scrum is the tool for that. One of the things about Scrum is that you can use it for almost any kind of work requiring cross-functional teams.

But that challenge only exists because we were highly productive at creating quality software. The team’s XP practice with its low formality and high discipline gets the credit for that.