A company that’s just been acquired is like senior year of high school.
People have conversations who’ve never made eye contact.
Everyone goes to the parties.
The theater geeks talk to the brains talk to the jocks.
People ask, “so, what are you doing next year?”
I was just asked whether I had metrics to demonstrate our pairing practice benefits the business compared to waterfall.
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
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.
I contributed a short essay to Hitotoki, New York.
Hitotoki is “an online literary project collecting stories of singular experiences tied to locations in cities worldwide.”
Gerry spoke at the Microsoft Women’s Conference this week.
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:
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.