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.

Posted: January 28th, 2008 under Uncategorized.
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.

Posted: October 30th, 2007 under Uncategorized.
Comments: 1

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.

Posted: October 16th, 2007 under Uncategorized.
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.

Posted: October 14th, 2007 under Uncategorized.
Comments: none

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?

Posted: August 29th, 2007 under Uncategorized.
Comments: none

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.

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.

Posted: August 23rd, 2007 under Uncategorized.
Comments: none

As a technical manager, what am I for? What are my core values?

Nurture a passionate, focused, autonomous team. Attract, retain and develop people who do right for their team.

Approach the manager’s work with humility. It’s not about getting people to do what I want. It’s about having a team that owns what they do and does it well.

Wed developers’ desire to contribute and love of problem solving with practices that minimize waste, reward learning and provide continual contact with customers.

Hold the team accountable for their commitments. Have them define their own standards of performance (estimates, quality practices, definition of done). Allow them to feel the inevitable disappointments. Celebrate their achievements. Always expect them capable of improvement. Treat their collective workspace, opinions, and time with utter respect.

Always seek out the next challenge and deliver on commitments.

Don’t wait for ways to provide value to my employer. Anticipate the next change or growth. If wrong, react to it.

Avoid make work. The goal isn’t to keep the team busy. It’s to keep them contributing.

Teach senior management the value of the team by what they do. Project success drives organizational change. It trumps reasoned debate. Project success can sometimes even win out over habit, emotional ties, and political ingenuity.

Treat all people ethically

Authority is a trust assigned to me for a purpose. A leader’s behavior shores up the workplace behavior of others and affects the health, happiness and family life of staff. Be accountable to that.

If there is a purpose in work and in life it is not to create unnecessary human suffering.

Posted: August 11th, 2007 under Uncategorized.
Comments: 1

I started talking about the manager’s role in scrum as facilitating a series of conversations between the team and the larger company.

The first of these is the product owner and the team.

As a manager, I have to constantly remind myself I’m a chicken, not a pig. My main responsibility is to deal with issues escalated to me by my scrum master. I also coach around practices. This is often about challenging team members to find their way towards our expressed values and principles.

On occasion, I do intervene in the dev room. This is dangerous ground. Innovation springs from the ability of an organization to surprise itself. Such creativity finds its source in autonomy, accountability and necessity.

Software development doesn’t proceed down straightforward path. For each unexpected problem there is a wealth of possible solutions. Ingenuity can add wasteful complexity or differentiate and define a product. You want a team to keep momentum but you want them to think deeply.

I need my team to be open to the problems before them, purposeful and playful in devising solutions but determined to release. This takes more than good work for good wages and it’s profoundly more than good leadership from managers. Project success has to be the individual team member’s success. Tomorrow’s intellectual property is not code yet to be written, it’s the inventive potential of the coders.

If I step in therefore it should be to maintain personal investment and esprit de corps rather than to reverse any individual decision. I have a scrum master and I rely on him to maintain morale and productivity in sprint reviews and planning. Still, with my experience as a developer and unique observer role, I’ll intervene in conversations between the product owner and the team to:

• dispel misinformation
• surface contradictions
• flag intractable disagreements

Misinformation is toxic to the product and individual accountability. A misinformed team builds the wrong product. A pattern of misinformation leads a team to lose trust. They will focus on not failing in their narrow scope of execution rather than a successful business outcome. Playing safe eliminates surprise and invention and ultimately leads to failure.

Contradictions create opportunity. A solution that addresses both a value and its antithesis such as high quality and low cost can differentiate a product.

Some disagreements cannot be solved by conversation. Time and more information may resolve the conflict. Sometimes disagreements simply need to be acknowledged. In the spirit of “any decision is better than no decision”, the product owner or scrum master needs to be encouraged to move in one or other direction despite dissensus in the team.

All of this assumes the project in question is healthy. Intervention into a troubled project is a different animal [see my earlier post on stopping the line].

Posted: February 24th, 2007 under scrum.
Comments: none

Jeff Sutherland posted notes from an open space hosted by Jens Ostergaard on Nov 2006. The subject was the role of manager in a Scrum.

1. provide strategic vision, business strategy, and resources,
2. remove impediments surfaced by Scrum teams that the teams cannot remove themselves,
3. ensure growth and career path of employees, and
4. challenge teams to move beyond mediocrity

For me, introducing agile practices has been evolutionary not revolutionary – five years work, three title changes and counting. My role is to make sure the team’s accomplishments build towards something progressively more and more valuable for the company and the individual team members.

In my experience, this involves facilitating a conversation between the business and the team on at least three levels:

• Product owner and product team,
• Organization and employees, and
• Leadership’s grand vision and the team’s accomplishments.

[the oxygen team and management]

I’ll go into this in more detail in later posts.

Posted: February 23rd, 2007 under scrum.
Comments: 1

One college summer, I worked at a small theater on the Mississippi river. It was a drought year. I remember it raining once the whole time I was there. The river flowed way below its usual level and ran dirty. The corn crop was devastated.

The theater was within miles of a huge pet food rendering plant. When the humidity allowed a breeze everything smelled quite literally like death warmed over.

And then the shad flies hatched. Lumbering insects that flew just well enough for one night of frantic bashing into things and mating. The next morning, their bodies covered the ground like gravel. I crunched my way from my apartment to the theater.

All this proved an appropriate backdrop.

The theater was a paddle wheel tug cemented to the bank of the river. The repertoire had been selected by the parks department. It consisted of fifty year-old musicals which required large choruses and performers who could sing, dance and act. The theater didn’t pay well and had no reputation. So our company consisted of twelve teens and twenty-somethings. About fifty less people than the larger musicals required. As for triple threats, some of us could passably act and sing or sing and dance.

And so we shambled our way through the summer – performers versus shows. Each evening or matinee without fail the shows kicked our ass. The artistic injury alone should have knocked that tugboat loose to immediately and permanently submerge in the river mud.

And yet, matinee or evening, audiences were entertained. They laughed. They applauded. They even waited outside to thank the performers.

What does this mean? What should I take from this experience?

We must strive to be better at what we do, to do our jobs well as we see it, without concern for recognition.

Mastering craft towards a beneficial end is a noble human aspiration. It is a good in the world. Like all attempts at doing or being good we cannot expect others around us to acknowledge us for it or even to recognize the difference even if they benefit from the effort.

Thankfully, I’ve moved on in my life. I’m a manager, a software executive, and a father but like the hopelessly miscast kid that I was, I still struggle to improve.

Posted: February 12th, 2007 under Uncategorized.
Comments: none