Pairing works for everything

Task assignment is a team anti-pattern

"The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don't play together, the club won't be worth a dime."

– Babe Ruth

Assigning tasks to individuals might feel like the most natural thing in the world, but in reality, when you are trying to create a highly functioning team, it might be doing more harm than good. This is true even when tasks are self-assigned by team members, and certainly true when tasks are imposed upon individuals by managers. Here’s why.

Having one individual responsible for a task takes responsibility away from the team and instead focuses on the individual. This can be damaging in a number of ways, not least that the individual is under more pressure to deliver. Short termist management might think this encourages productivity, but the internal pressure this generates can be a short cut to burnout. The focus needs to be on collective responsibility: it’s the responsibility of the team to release something, not the responsibility of the individual.

This issue is compounded if the team’s work in progress limit is too high. If there are nine team members, and nine things currently in progress, then in the best case each person will have nine things to do, and in the worst case one person will have all nine things to do and the other eight people will be sitting around waiting for them to finish, putting enormous pressure on those who are the bottleneck. The more items of work that are currently in progress, the more than a focus on assignment will bite you.

Assignment promotes a command and control attitude. Sometimes, each member of a “team” is actually being managed individually and has their own stream of work. This can produce output in certain cases, but the individuals being managed are not a team: they’re a collection of individuals who might happen to sit together.

Individual assignment can create silos of information. If one person is responsible for a task, and everyone has their own tasks or types of work, then it’s harder to work as a team: the knowledge is held only with a few people, rather than across everyone. Pairing dramatically helps break these silos down.

Assignment can also give rise to the hero anti-pattern: where a few people are responsibility for the success of the entire team, and they end up pulling an all-nighter just to get the release out the door. The hero culture might seem appealing to short-sighted managers, but when eventually the hero inevitably fails to deliver, hero culture quickly turns to blame culture.

How to shift this culture?

• Reduce your team’s work in progress limit. Insist they don’t start anything else until the team finishes what’s in progress, and that they go to pair with those who are still working on tasks, even if it’s not their normal discipline.

• Stop giving people things to do. At the very least, ensure that the team are choosing their own tasks from a list rather than being managed individually.

• Stop tracking assignment. Don’t record on the task who is working on it. Simply track what’s being worked on by talking about it each standup meeting.

• Avoid the trap of buck-passing. If you’re not careful, giving a weaker team collective responsibility means that they pass the buck. The thinking goes: “if I’m not individually responsible then I’m not responsible at all.” The antidote is team accountability: praise the entire team for their successes and ensure they all investigate the reasons for failure together. This includes the product owner and the user experience people - they are all part of the team.

Does task assignment cause problems for you? What silos could be broken down by having more of a team assignment focus?

Pomodoros help you refactor

"If you finish a task while the Pomodoro is still ticking, the following rule applies: If a Pomodoro Begins, It Has to Ring. It’s a good idea to take advantage of the opportunity for overlearning, using the remaining portion of the Pomodoro to review or repeat what you’ve done, make small improvements, and note down what you’ve learned until the Pomodoro rings."

– Francesco Cirillo, The Pomodoro Technique

What’s the single most important part of Test Driven Development not to miss? Refactoring. What’s the part of TDD that’s most often missed? Refactoring.

With refactoring, we work our way toward a great design, clean code, and flexible organic tests. Without refactoring, we have ugly brittle test suites and uglier code. We know this. What I don’t always do is take advantage of the moments I have when I can effectively refactor for free.

At the end of a task, when the build is running, I’ve previously let my mind wander to the next thing, or check email, surf the net, and generally get out of the zone. This bad habit has been highlighted to me in my use of the pomodoro technique recently.

I was doing the same for the shorter pauses during normal TDD. My pomodoros statistics were telling me that I’m very bad at concentrating whilst coding: the average time spent before I let my mind wander was 11.67 minutes. I was allowing my mind to drift whilst Rails started up to run whatever test I was working on. Not good.

Time to improve

This week, I’ve been trying to take the time to look at my code critically for areas of improvement. A pomodoro is indivisible, which means I’m not allowed to think about anything else.

And guess what? I always find something to improve, and I feel that little bit better about my code.

The also helps with the thing I’ve missed most about not pairing: that other person’s critical eye on what you’re doing, always thinking about the code being written. During the natural pauses, you can be that other person and ensure the code you write is great. Being two people is more fun, too.

Every Ash Cloud Has A Silver Lining

Enrique and I recently became victims of the ash cloud, and spent rather longer in the US than we anticipated…

I spent a weekend in Chicago last month chatting to some other exceptional companies about the way we all do business. I learnt a huge amount about Eden and how we want to make it better in the future. We were due to leave on Sunday night, but unfortunately the ash cloud had other ideas, and we were stuck in Chicago for a further five days. It wasn’t much fun to be stranded, but when you’re stuck somewhere, you might as well make the most of it…

Whilst on my extended trip, I got to hang out at 8th Light and Obtiva, at the latter for several days. Thanks especially to Obtiva for hosting us for much of the week! Over the ten days I paired with Micah Martin, Dave Hoover, Chad Prye, Doug Bradbury and Eric Smith. I hacked on RSpec2 briefly with David Chelimsky. I went to visit the new offices at Hashrocket Chicago. I spent several days sharing a little suite of rooms at our hotel with Gustin and Enrique, hacking on edash. I wandered about the city, mostly looking up a lot.

In the evenings, I got to meet and have dinner with Corey Haines’ lovely girlfriend Sarah, to hang out with Chad and Joe from Obtiva at a fascinating restaurant, and ate at a vegan place - not normally on my radar, but it was an experience!

These were some of the many highlights of a five day trip that turned into a ten day experience. Of course I’d have preferred that I wasn’t delayed, but when life gives you lemons… you pair :)

Five things I learnt from Corey Haines

Recently I attended QCon and got a chance on the last day to pair with Corey Haines. We worked on a new rails project we’re building with a few friends (that’s the subject of another post). We’d spent a fair amount of time hanging out, but I hadn’t had a chance to sit down and actually code with him. We paired for a couple of hours in the QCon expo area just as everyone was packing up.

Here are a few lessons and some things I picked up.

REALLY learn vim. Watching Corey fire around vim was something else: my brain could barely keep up with where the cursor was sometimes. Sometimes it felt like he’d just moved the cursor to where he wanted it to be through Sheer Power of Thought. I’m no slouch in vim, but was impressed by just how much faster I’ll be able to go someday, as I continue to practice.

resource_controller. formtastic. That is all. These gems take out the legwork of building a thin restful resource-based rails app. You end up with a lot of tests and very little code to worry about. As webapps become more about javascript and the front-end, rails apps are becoming thinner and thinner, and these gems make them really fast to write.

Alias everything. Corey has a few really useful little bash tricks, like:

alias c='script/console'
alias r='rake routes | grep'

..and some others I didn’t catch. They save so much time and are so obvious that later I found myself banging ‘c’ into a console and wondering why it doesn’t work.

The summary of these lessons is another more general one:

Work to remove whatever constrains you from getting the computer to do what you want. We need to ensure that there is as little as possible in the way of getting stuff done. Everything else is yak shaving: slow typing, tool-illiteracy, whatever. Anytime we’re not thinking about the problem, we’re wasting time.

And finally, a meta-lesson:

Extend your pairing gene pool. It’s amazing how much you learn when you pair with someone outside your immediate sphere. Rather like when I first paired with Enrique, I learnt about stuff I would never have heard of otherwise.

I spent two hours working with Corey and it was a pleasure. Sadly we live a few thousand miles apart, but I’m looking forward to remote pairing sessions in the future.

The Story Card Is Not The Story

At Eden we’ve used a number of different options for tracking work to be done on projects. In the early days we used Basecamp tasks. We then rolled our own system, which we’ve since abandoned due to a gradual shift in our business practices. We’ve used Pivotal Tracker extensively. Whilst we still use Tracker a fair amount, on one of our new projects we’re currently using index cards stuck to a kanban board, with Google Wave for extended documentation and discussion.

In the past, we’ve spent a bunch of time arguing about which of these devices better and which is worse, with a view to settling on the “best” system. The merits of simple systems over complex ones, and digital over analogue, have been endlessly debated. I now think that all of these arguments miss the point.

A couple of weeks ago, Enrique spent some time teaching us an early version of our one-day agile workshop. Through the ensuing discussion, I finally got to an important insight about what a story actually is, or rather what it isn’t.

The story is not the terminology, or which precise language you use to describe it. It’s not the text on the card at all in the fact, or even the card itself. It’s not the line in Pivotal Tracker and it’s not the task in Basecamp.

All of the tools we use represent some facet of the story, and help kick-start discussion. They remind us of the story, but they are not the story itself.

The story is simply the team’s understanding of the work to be done: nothing more.

This understanding reframed my view of the endless cards vs online vs Tracker vs everything else debate. These are merely useful props: methods of communicating within the team in order to achieving shared understanding. Granted, some tools are better than others. But they are just that: tools. Nothing should be sacrosanct: we should feel free to replace tools and methods that are failing for a particular client, even if they’ve succeeded on other projects. I now think settling on the “best” system is a vain exercise: we’d spend our time much better simply by properly listening to the customer and doing what they say.

The same principle applies to the almost-as-endless UX/Design communication methods fight. Should we use Balsamiq mockups, or HTML wireframes, or Photoshop mockups, or Sharpies and paper? Answer: use what works. Use whatever tools you need to get your message out into the collective consciousness of the team (that includes developers, designers, testers and customers), so that the work can get done to the customer’s satisfaction. These methods are simply ways of getting messages across: they have differing emphases, and carry different risks.

Often I think the whole way we approach the tools debate is wrong. We ask: “how can we use our favourite tool/method to track the metrics for this project?” Shouldn’t our question instead be: “How can we ensure we are communicating properly with the customer so we can deliver what they really want?” The tool question then becomes secondary and the critical issue of good communication becomes paramount.

The story card is not the story. Let’s ensure our projects serve the customer rather than our favourite tool.