Ten character classes your project team needs

A dungeon-crawling party requires a good mix of character classes to be successful. If everyone is a wizard there's nobody who can fight off the orc warband. Similarly, a software development team needs a range of character traits and aspects to successfully deliver working software which meets the project's goals. Here's my take.

Scavenger

The Scavenger understands the importance of not re-inventing the wheel. To this end they acquire an encyclopaedic understanding of our languages' built-in libraries, the existing features of our system and other systems in the wider organisation, and open-source libraries.

Unless given a precise list of the project's wants a Scavenger will become a Mutant Renegade, scouring the post-atomic wasteland for useless relics, which are broken or undocumented or both.

Aspect: "Here's one we made earlier"
Traits: Focused laziness, Unfocused research, GitHub

Rat King

The Rat King understands that software development is a communal task. Consequently they work to forge a collection of disparate individuals into a team. Their remit includes facilitating meetings and arranging after-work socials. Despite their fearsome appearance and collectivist instincts the Rat King is extremely sensitive to what each person brings to the party, and strives to ensure that introverts and teetotallers are included without feeling pressurized.

Unless met with a smidgeon of friendly scepticism a Rat King will become a Facebook.

Aspect: "We must hang together or we will surely hang separately"
Traits: Teamwork, Communications, Contacts

Paladin

The Paladin is the defender of the project but is also committed to the ideal of a project which is worth defending. They ensure everybody follows best practice, adheres to coding standards and observes the agile ceremonies.

Unless there's a Rogue to balance them a Paladin will become a Grand Inquisitor (although maybe without the thumbscrews).

Aspect: "Just do it right"
Traits: Rigour, Weird inner light

Rogue

The Rogue is pragmatic where the Paladin is dogmatic. They have a swashbuckling approach to getting things done. They understand the concept of technical debt, they just tip the trade-off toward delivering stuff over following the rules. Very fond of observing that there's no such thing as "best practice".

Unless kept in line a Rogue will become a Cowboy. Yee-hah!

Aspect: "Let's do the show right here"
Traits: Resourcefulness, Acute bullshit detector, Cynefin

Mad Scientist

The Mad Scientist has a deep technical understanding of software development, both practice and theory. They are obsessed with innovative and extremely clever solutions to business problems.

Unless your business problem actually requires an extremely clever solution a Mad Scientist will become an Evil Supervillain, who will derail the project (but, to be fair, will not destroy the entire planet. Probably).

Aspect: "My monster lives!"
Traits: Single-mindedness, Visionary

Lab Assistant

The Lab Assistant is vital to delivering the work of a Mad Scientist. They document APIs on wiki pages, they write build scripts and unit tests, they productionize the PoC code. In short, they undertake all the tedious essential tasks which would distract a Mad Scientist from their creation.

A Lab Assistant to an Evil Supervillain is still a Lab Assistant, but the wiki pages are half-complete, the unit tests don't run and the code isn't fit to be checked into source control.

Aspect: "Here is the brain you wanted"
Traits: Flexibility, Service to the higher cause

Major-domo

The Major-domo helps the project run smoothly by taking care of all the little things everybody else forgets. They clean the whiteboard before a meeting starts, they bring Sharpies and Post-It notes to the retrospective, they write Jiras for the stories we just agreed we needed and they circulate minutes after decision-making meetings.

Unless other people occasionally do some of these tasks a Major-domo will become a Resentful Skivvy.

Aspect: "I'll add that to my To-Do list"
Traits: Well-stocked stationary cupboard, Scrivener

Court Jester

The Court Jester says out loud the things everybody else is thinking. They aren't afraid to appear ridiculous in order to make a point. Their role is to speak truth to power.

If they go too far a Jester becomes an Angry Ranter, ignored and shunned by everybody.

Aspect: "The true fool stays silent in the face of foolishness"
Traits: Humour, Insight, Lack of inhibition

Bounty Hunter

The Bounty Hunter lives for finding and fixing bugs. They are never happier when writing test cases to reproduce a bug or stepping through lines of code in debug mode. They understand that fixing production code is more important than delivering a new feature.

Unless kept on a tight leash a Bounty Hunter will become a Mindless Delver or a Tinkerer.

Aspect: “To defeat the bug, we must understand the bug”
Traits: Sense of purpose, Perseverance, Debugging

Druid

The Druid has an understanding of ecosystem beyond our project's bounded context. They know what the business seeks to achieve and how our project furthers those goals. They also know about other projects in the organisation, and work to ensure our project integrates with them harmoniously.

Unless given a clear sense of our project's priorities and direction a Druid is still a Druid, just servicing the needs of other projects.

Aspect: "Listen to the trees, dude"
Traits: Awareness, Empathy, Balance

Multi-faceted characters

Obviously these aren't main character classes. A project team comprises base classes such as Developers, Testers, Analysts, Architects, heck maybe even a Project Manager. What I list here are ancillary classes, which modify a base class. An Architect, a Developer, an Analyst or a Project Manager can benefit from having a touch of the Druid about them. Any Developer should spend some time being a Bounty Hunter or Scavenger. Different circumstances demand different class behaviours. When there's a major outage in Production we need Rogues to fix it, not Paladins muttering about process and sign-off. But after Production is back it is the Paladins who make sure the problem and its resolution are properly documented, and appropriate preventative measures put in place. Most people on the team will flow through several of these class behaviours, even over the course a single sprint.

When we're forming a new team to deliver some piece of software we focus on the hard skills. the main character classes. We need this many Developers, this many Analysts, a UX expert, an SEO specialist, and so forth. These are the easy things to define. But the success of the project will in large part depend on the soft skills and temperaments of the individuals in the team. This is a lot harder to measure. It's why personality tests like Myers-Briggs and Insights exist: some people think they're hokum but they provide a framework for assessing the make-up of a team in an age when we're uncomfortable casting horoscopes or taking auguries from the liver of a freshly-slaughtered goose. Using RPG character classes as metaphors for desirable behaviours has the advantage of jokiness. There is a categorical absence of pyschological research underpinning this article. Also it doesn't require us to obtain live waterfowl.

One last thing. The next time you find yourself at a retrospective with no marker pens and nothing to write on, look around for a Major-domo. And if you can't spot one why not appoint yourself to the role?

Epilogue

That final paragraph makes me sad for the times when retrospectives happened in a room with other people, with a whiteboard covered in post-It notes. Let's hope we can do them like that again.

The personal is technical

On Friday evening I attended an IT Job Fair at the Amerigo Vespucci in Canary Wharf. Let me say straight away that hanging out with a random bunch of techies and recruiters would not be my first choice for a Friday evening. But, hey! I'm looking for my next role, and right now the market is too tough to turn down opportunities to find it. Besides I was interested to see whether the Meetup template would translate into a recruitment fair.

On the day the translation was a mixed success. Unlike most Meetups, which can work with any number of attendees, a job fair requires a goodly number of recruiters, and recruiters will only turn up if they think there will enough candidates to make it worth their while. This first event didn't achieve that critical mass, and I would be quite surprised if I get an opportunity from it. Nevertheless I will try to attend the next event, whenever that may be, because pop-up job fairs in bars are a great idea. Not for the reason you're thinking (I drank cola all evening), but because it was enjoyable. I talked with some interesting people, and got a couple of email addresses as well.

But more than that I was impressed with the concept. The informal social setting is good for understanding what a person is really like, specifically what they might be like to work with. This has to be worthwhile. The CV is a dead letter: it lists skills and accomplishments but doesn't animate or demonstrate them. The formality of the technical interview makes it hard to judge somebody as a person. Anyway it's generally aimed at establishing how much of their CV is true. The social element is often missed entirely. Big mistake. Software is like Soylent Green, it's made of people.

Personality matters: the toughest problems most projects face are political (organizational, personal) rather than technical (except for system integration - that's always going to be the biggest pain in the neck). A modern development project is a complex set of relationships. There are external relationships, with users, with senior managers, with other stakeholders (Security, Enterprise Architecture, etc) any of which can jeopardize the success of the project if handled badly. But the internal relationships - between Project Manager and staff, between developers and testers, or developers and DBAs - are just as fraught with difficulty.

The personal is technical because the team dynamic is a crucial indicator of the likely success of the project. You don't just need technical competence, you need individuals who communicate well and share a common vision; people who are (dread phrase) team players. That's why Project Managers generally like to work with people they already know, because they already know they can work with them.

For a new hire, nobody knows the answer to the burning question, "Can I stand to be in this person's company eight hours a day, five days a week, for the duration of the project?" Hence the value of chatting about work and other things in a bar on a hot summer's eve over a glass of something with ice. I'm not sure how well the model would works for recruitment agents, but I think it would suit both hirers and hirees. It's not a technique that scales, but if people made better hiring decisions perhaps that wouldn't matter?

Closing out the year

Like many Britons I have been enjoying the Winterval. This is the tradition of using three days of annual leave to join up the Christmas and New Year bank holidays to engineer an extended break from work. Winterval means many offices are deserted between Christmas Eve and the beginning of January.

The effect is exacerbated in many organisations which run their leave year from January to December, with a "use it or lose it" policy. So many people finished working a week or even a fortnight before Christmas. Which is nice for the people involved, but it does cause problems for the rest of us.

For instance, my final project of the year was a data cleansing exercise, applied in-flight to a production database. The cleansing was done in overnight batches, which we estimated would take about two weeks to run. The initial deployment was a time consuming exercise, which required a large chunk of downtime and also applied a massive change to the database. If it went wrong, we would have to rollback everything and start all over again. So that meant we could only deploy at a weekend. As if that wasn't exciting enough, the exercise absolutely had to be completed by 31-DEC-2011.

The advent season added further spice. Office parties, nativity plays, Christmas shopping and using up leave all made it harder to arrange meetings. We couldn't rely on finding the necessary people to sign off documents, answer questions, provide technical support or undertake UAT. Plus of course the entire development team wanted to celebrate Winterval. If we didn't have made a successful deployment early in December we wouldn't be able to get the cleansing finished before Christmas. That would have thrown we did a lot of people's Christmas plans into chaos.

Fortunately we deployed cleanly first time. And the cleansing proceeded smoothly. In fact we made it with, oh, days to spare. So that was a nice way to round off the year, but it felt pretty hairy at the the time.

Next year I will be grateful if the Grinch isn't in charge of project scheduling.