Issue 7: Who Does What?
Hello,
This week someone asked me a simple question. “Who should create that ticket?” It’s probably a question that’s been asked many times before. Who creates tickets? Who updates your issue tracking software? Who writes test cases? Who sends release notifications? There’s endless questions to ask about who does what.
But I realised something. The answers to those questions should be obvious. There shouldn’t be the slightest ambiguity or doubt about which people do what work, because as soon as there is doubt there are questions, and once there are questions there are delays.
So, can everyone on your team answer those questions without a further thought? I’d be willing to bet that they can’t.
I think almost every software team I’ve worked in has at some point gone through a phase of documenting how they work, in an effort to avoid such questions being necessary. Often the trigger for this is a round of new hires. New people need to know how we operate, so we’d better write it down. Almost without fail this results in the first new-hire getting the job of documenting how a team works. On occasion I’ve been that new-hire, and let me tell you, it’s a horrible way to join a team.
The whole reason we want to write this stuff down is because it’s hard for new people to assimilate the information. It’s awkward for them to ask questions about everything and there’s every chance they’ll miss something important because they didn’t want to bother the more experienced team members. So getting the new person to document your process is an absolute non-starter.
Furthermore, I’m pretty certain that if you asked each existing team member to document your process they’d all come up with something slightly different.
So, what I would do in this situation is exactly what I do when I’m starting to help a new team to go faster. I get them all in a room and I ask them how a feature goes from idea to live-in-front-of-customers. We draw a diagram on a whiteboard, or we arrange post-its on the wall. This can take a surprisingly long time. People disagree on seemingly fundamental points (“Do we do QA after we merge, or before?” “We use git-flow.” “Well I don’t!” etc). Take the time and build a consensus representing what the team actually does, not what they’d like to do or think they should do.
Once you have it documented, turn it into a nice big diagram and stick it on the wall. That’s right, on the wall. Not buried away in some wiki somewhere, not on the shared drive, not anywhere electronic. On the wall. Wikis are where documentation goes to die. The wall is where it thrives.
That way, when a new person starts you can show them how you work in just the same way as you show them to their desk or show them where to get a cup of tea. Nobody needs to be in any doubt, and the constant presence of the big diagram on the wall means that people remember what they agreed to.
You might occasionally need to re-draw bits of it, of course, but that’s just fine as long as everyone still agrees on the process you’re using.
Hopefully you’ll find that you spend less time answering questions are more time delivering software to your customers.
Going Faster: Weekly ideas on speeding up your software team by Jez Halford, a software development consultant helping teams to deliver better software more quickly.
There’s more from Jez on Twitter, Medium and jezhalford.com
