At Oxygen, we have a team.

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.

Short link: http://jkat.me/gFsVOe

Tag(s): agile, Bob, CEO, coach, CTO, dev director, first UX Designer, Gerry, inspiring and audacious product owner, Luke, management, software development, Steve, xp

Comments: 1

Separation of Concerns is a classic software design consideration but in this anti-pattern, management takes a coherent concern (i.e. what opportunity does a potential software project represent), breaks it apart and tasks the pieces out to siloed business units.

One group creates revenue models to meet to top line goals, another group models costs as fixed budgets, yet other groups devise features and schedules. All without engaged participation by the developers who will be asked to implement.

Each actor has strong motivations to push one agenda (high revenues, low costs, aggressive schedules, ambitious feature lists) without offsetting responsibility for other concerns. The result is impossible project expectations.

Finally these separate models are patched together into a PowerPoint presentation and called a “plan”. “It’s alive! It’s alive!”

Related anti-pattern: the Anemic Management Matrix.

Short link: http://jkat.me/lfhtas

Tag(s): actor, agile, anti-pattern, classic software, coherent concern, potential software

Comments: none

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.

Short link: http://jkat.me/heM8f4

Tag(s): agile, CMMI, Jeff Sutherland, manager, OLAP, project manager, Ruby, VP, xp

Comments: 1

John Maeda has another post on leadership.

“In movies we often see two scenarios: 1) the leader is surrounded by her soldiers as a wall of protection; or 2) the leader is the one that is the first to rush into battle.”

I have trouble with war metaphors in a time of war but I get that success is built upon both protecting potential and creating it.

This sentiment reminds me of Garry Kasparov’s description of his chess play, attacking, aggressive, “where the player who makes the first mistake loses” versus a maneuvering, defensive style that “accumulates small advantages over time.”

I have played the latter, quiet game, advancing through various roles and towards an agile organization over years.

My game was winning over peers, demonstrating success, removing many obstacles and flowing past others, educating executives as they became receptive to it, and, above all, showing by doing — proving value on our terms by delivering value.

But as Mr. Kasparov points out, circumstances may require us to adopt alternative styles and I am clearly in that situation now.

My company may soon be integrated into a larger one. In that larger organization, I have met conscientious, competent people. If the acquisition goes through, they will work to realize as much benefit as possible while managing risks and minimizing harm.

However, drastic change will need to happen in a short time and there are three very different cultures at play: that of our team, our current employer and our prospective new one.

Time is a factor in another way as well. My team cannot endure setting the clock back on our product and software development practices. Agile development means little unless it is in partnership with an agile business. We don’t want to just build things well. We need to invent, serve users and win in the marketplace. We need it all.

If circumstances call for a more pressing style of play. So be it.

Short link: http://jkat.me/fNoweN

Tag(s): agile, chess, Garry Kasparov, management, player, software development practices

Comments: 2

Things we did right:

• laptops
• table with two tier top so laptops can sit under the surface
• dual monitor setups
• build bunny
• video projector at center of table
• room for product owner and scrum master at ends
• big whiteboards
• big corkboard
• wall space for bulletin board sized post its
• team picked colors
• space invaders
• poster board sign for ript
• webcam
• purell, handwipes, tissues, and hand lotion

Things we could have done better:

• private space in the corners
• better way to leave phone messages for team
• more webcams/better video conferencing
• kept killing plants
• needed a cleaning person
• better HVAC

Short link: http://jkat.me/g07aoc

Tag(s): agile, product owner, video conferencing, xp

Comments: 8