Good Process

Every functioning software development team or organization has a process. It might be formal or informal, functional or dysfunctional, chaotic or stable, but their is some way to describe how things get done.

I don’t think there is any one best process, but I do think there’s some markers of what makes a good one.

Overall, the most important thing that makes a process good is that people believe in it and follow it. It seems like following a bad process would be worse than not following it, but that is rarely a long term problem. Usually if the process is bad, what happens is that people don’t follow it, so they never bother to fix it. If people follow a process they will find a way to fix it and make it better.

When people aren’t following the process a common failure mode is to try to bring someone in to “do the process stuff”. This is also a bad idea. Whatever the process is: the box checking, status updating, sticky note moving etc. should always be done by the people doing the work, otherwise they won’t respect it or feel invested. Sure, the people will complain about doing this “busy work” but people will always complain. Just make sure that the busy work takes less than 5 mins a day which isn’t really that hard to do.

Note: Sometimes the problem with process is that there’s too much time spent debating or reviewing or over-analysis. That’s more of a high level problem that I talked more in another post.

Virtually all processes have artifacts which represent the current state of the project. This might be a Jira board, a bug database, sticky notes, or spreadsheet or something else. I have seen teams succeed and fail with any of these methods but there’s a few things to remember to help maximize your chance of success.

• Single Source of Truth – As much as possible resist the urge to copy things from one place to another to provide status etc. Something will always be out of date, people won’t be able to resist the temptation to massage or distort things and eventually trust will fail.
• Integration is good – Prefer systems where the tools integrate well together vs trying to cobble together a bunch of tools that you think are the best for each task. None of the tools are perfect and interoperability fosters better communication and collaboration which is a key reason to have any kind of process in the first place.
• Speed matters – If your tool takes forever to load and is slow to respond, people are just going to be frustrated and stop using it. I’ve waiting minutes for a Jira search to complete and all that does is make me not want to do it ever again.
• Have a quality bar – No one wants to spend all day filling out a bug report or updating status, but in 2 mins you can add a lot of context that you don’t include if you are just trying to get it done as fast as possible. Try to enforce that some structure on this content.