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?

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

Tag(s): Java, management, manager, USD

Comments: none

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.

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

Tag(s): John Maeda, management, manager, manager sets

Comments: none

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.

These 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.

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

Tag(s): CEO, Hamlet, management, manager

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

Team managers should till the soil with their teams.

Anything else is waste and waste must be rooted out.

Still it is hard.

Luke Melia wrote about how he performed as functional manager and dedicated 75% of his time pairing.

There are two tremendous challenges with this.

The first is limiting distractions in order to remain a reliable contributor.

Luke has tremendous reserves of focus and enthusiasm. As his manager, I did everything I could with our scrum master, Salim Divakaran, to support him, remove distractions and share workload.

The second challenge is being both the boss and a peer.

Luke recruited most of the team, he held weekly one on ones with each person, he insisted on unvarnished feedback, and is worthy of respect as both a peer and a manager.

So, here is the pattern: An experienced coach with people skills and authority over development practices pairing in with the developers. An experienced scrum master. Functional management residing in one or the other or divided up in some sensible and easily described way among the two of them.

This enables direct participation in the work, management attention to the team, and strategic contribution to the rest of the company.

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

Tag(s): agile, experienced coach, Functional Manager, Luke Melia, management, manager, Manager in Agile Team managers, Salim Divakaran

Comments: none