Tag Archives: manager

Why Should an Exec Support XP Pair Programming?

Posted on by

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.

To Mine Own Self

Posted on by

My company begins planning its integration into a new parent organization.

As a participant in that process I have to obey:

  1. Laws and policies.
  2. My duty as an executive to create strategic value.
  3. My duty as a manager to treat my team humanely and fairly.

I feel other ties:

  1. Guiding my actions according to ethical values and agile principles.
  2. Loyalty to my boss — he’s created opportunities for me. I owe him.
  3. Loyalty to my departing CEO — she is a visionary and a mentor. I can’t wait to see what she does next.

Brooklyn Street SignsThese obligations may contend but should not fundamentally conflict as long as the integration plan we develop clearly communicates an achievable, rational outcome.

“Above all, to thine own self be true.” — Hamlet, I, iii

Inspiring and daunting advice but not to be taken at face value. For the character who delivers it has too high a regard for his own ingenuity, places himself at the center of events and meets a bad end. A creation as complex as life.

I will try to heed a fool’s words without becoming a fool. To be true to mine own self in this circumstance is not to delude myself that this situation is in any significant way about me. Options that don’t make business sense will not serve the long-term interest of anyone involved. My obligation is to work towards the best outcome for all parties given that reality.

Managing and Leading

Posted on by

John Maeda on leading and managing and the need to do both.

The manager sets up the win with perfection for her team; the leader executes the win with passion.

The word “perfection” conveys discipline but the agile practitioner in me bridles at it. As John Maeda says, “a manager never manages alone.” Community defies perfection.

I do resolve to do better. Do by committing myself to action employing the most appropriate knowledge and tools at hand. Better by using the hard lessons of success and failure to make my actions more effective the next time.

Dysfunction in a Word

Posted on by

Handoff
Creative problem solving as rote mechanical construction. Twist the wrench and pass it on.

  • forces sequential phases, “first we determine what it looks like then we figure out what it does.”
  • forces development in horizontal rather than vertical layers, i.e. “we’ve spent weeks coding but none of it does anything yet. We’re almost done though”
  • forces thinking in schedules instead of priorities, “I’ll have my part done in two weeks. What is it again?”
  • silos workers from each other, “What are you working on? Well, anyway, goodnight.”
  • ensures workers don’t have big picture, “Her copy doesn’t fit in my div based on his mockup. It’s not my fault.”
  • encourages hierarchies and coordination overhead (chicken husbandry), “My manager will get with your manager”
  • enourages narrow specialties instead of versatility and craftsmanship, “He does jpegs and gifs. She does html, css, and javascript. She does C# and Java. None of us actually build applications. By the way, did I already say it’s not my fault.”

Approval

    Distill complex interactions into a pretty picture. Take authoritative guidance from someone who’s only spent 15 minutes thinking about the problem.

  • encourages passive, diffuse product ownership, “you’re on the hook but they’re the deciders”
  • locks in premature commitments, “I put aside $10K for database integration”
  • invites arbitrary changes. “make this bit here blue”
  • creates low-value artifacts that lie, “sure it will work just like the wireframe.”
  • rewards promises over performance, “it will do everything I say, cost $40K, and be done in one month.”
  • bakes failure in, “how did we end up with this late, expensive hunk of junk?”

Getwith

    offensive getwith: “you need to getwith Joe on this.”

  • forces input from people with authority, no accountability and no direct contribution — like being made to run around with a target on your back
    defensive getwith: “Does Joe agree with this decision?” “I gotwith him on it.”

  • ask someone to attend one meeting, characterize them as agreeing with anything you do after that — like pulling a target of your back and sticking it on someone else’s

Any additions?

The Beauty of Team

Posted on by

Our team just beta-released our first consumer product. Along the way, they accomplished something of more strategic value. They matured into a performing, self-directed team.

The Team Ript Page

A decent manager encourages software developers to do their best work while allowing them full personal lives. The heart of this effort is fostering strong teams. Individuals have bad days, make mistakes, lose momentum. A team watches each other’s backs, challenges each other, teaches each other. They build upon each other’s creativity.

The beauty part for a manager is — if you create the right conditions, start with the right people, trust them and hold them accountable — the team does the hard work of becoming. They deserve full credit for their achievements including the most ambitious achievement which is themselves.

That doesn’t mean it’s easy. Getting this consumer product to the general public has taken fifteen months. From our first study of agile principles to our current practice has taken the better part of four years of continuous improvement.