As agile developers, we sometimes like to point our fingers and snicker at some of the more problematic personalities that can sometimes haunt waterfall development shops. To some extent, we take comfort from the sense that many of these personalities are able to hide out in the nooks and crannies of the waterfall methodology, but certainly Those Types Of People would never survive in an agile shop.
Take the classic example: the Hidden Deadbeat. While many agile environments force a lot of developer interaction by putting the team in a shared project room, the waterfall world still embraces the cubicle farm. And we’ve certainly met a large number of Hidden Deadbeats: people who don’t really do or accomplish anything, but who succeed in not doing anything for long periods of time because they don’t have to interact with people very often. If nobody really knows what they do, then nobody really knows that they’re doing nothing.
But agile projects have their fair share of… interesting personalities. There are some behaviours that are downright dysfunctional. Sometimes a difficult behaviour can provide a good counterbalance to another problematic behaviour. Pairing someone who just wants to get things done with someone who likes spending a lot of time thinking about concepts and theories creates a powerful team.
I’m interested, therefore, in trying put a name to various behaviours that sometimes manifest in agile teams, and hopefully explore ideas about how to work effectively with such personalities. I’m imagining this as a series of blog posts, each one looking at a different caricature.
Some agile writers talk about agile Anti-Patterns as a way of describing aspects of processes that teams sometimes adopt that often lead to massive fail. For my part, I think there’s a difference between “bad process implementations” and “challenging behaviours that people exhibit” (but maybe I’m wrong), so I’m avoiding that language.
My friend, Tiffany, teaches English Lit classes at a California University, and she often refers to “Goldfish row” — the row (or rows) of the lecture hall, where students come in and sit, staring, with mouth hanging open slightly. When she throws a question out to the class — something intended to inspire discussion, the goldfish row sits, impassively, declining to get engaged.
Partially, I understand how the goldfish row comes to be. From a very early age, kids promulgate a culture in which showing interest in school is considered uncool. Engaging in class discussion is for keeners and the best response is just to observe, dispassionately.
Unfortunately, the lessons we learn in Grade 2 aren’t easily shrugged off in adulthood. And one of the agile situations where I am most reminded of Tiffany’s complaint happens during estimating.
Agile teams go through a number of estimation exercises. Early in a project, the team might provide high-level story estimates for a number of story cards (in either pair days, or more traditional “big (3)”, “medium (2)” or “small (1)” sizes. Tasking exercises might break the story into a number of smaller tasks, each of which is measured in a handful of developer pair days.
And, in the dozen years that I’ve been taking part in these estimation sessions, I’ve rarely seen a session where more than three developers were regularly throwing out estimates. Often, most of the developers reproduce “goldfish row”. Sitting back. Just observing. Saying nothing.
There are factors that contribute to this: junior developers are often at a loss to estimate how long it will take them to perform a task. Some people have been badly burned by the whole “your off-the-top-of-your-head number is now a binding commitment” mentality. But mostly, I think, people just fear being judged. If they suggest a number that’s higher than others might suggest, that might indicate that they’re a slow developer. If it’s a number that’s too low, that might suggest that the developer doesn’t fully understand or appreciate the scope of the task. To the goldfish, it’s better to let someone else do the talking.
Often, people who act like goldfish during estimation sessions are fully engaged on any number of other types of activities. Goldfish can be highly productive coders, or may have be great at other interpersonal tasks. And to some extent, I appreciate that sometimes a conversation can get bogged down if everyone has to throw their two cents in on every point. Bogged down is the opposite of agile.
But the reason that I’m always a bit wary of goldfish is twofold:
- as I said, on any team of six or more, my experience is that more than half of the team act like goldfish during estimating; and
- when people don’t take part in the estimates, I think that people have a lower sense of ownership of the estimates.
What To Do?
Many exercises like story tasking or steering come about regularly. Try putting some of the goldfish in charge of running those sessions. Give them advance warning (“Hey, Goldie, you’re gonna lead the steering meeting next Monday!”), and sit down with them before the steering meeting to give them an overview of the stories that they’re going to be discussing at the steering. Then let them run the show.
Make no mistake, the first few times people run meetings like this, they’ll be awkward and less than perfect. But let the awkwardness be. Mix it up so that various goldfish rotate through different steering or tasking meetings.
I also recently saw an estimation session which was conducted almost like rock-paper-scissors: the person leading the meeting would count out “one… two… three…” and everyone in the estimation session would stick out their hands with a number of fingers raised — they had previously agreed that all stories would take either one, two or three days.
- “How can I estimate until we talk about how we’d design each piece?” To some extent, it’s true that there are some people who understand things best in as concepts and high-level boxes in a diagram. And there are some people who only make sense of things by looking at lower-level details. So, to some extent, asking for more details before trying to estimate is a legitimate request. But it’s also true that asking for more details is a classic strategy to avoid making decisions. For my part, I’m a bit suspicious of this kind of statement when it comes up in a tasking session. A key question: after discussing it in more detail, does the person ever volunteer an estimate?