A few years ago, I was tasked with “improving our software development process”. Some projects had been more painful than they should have been. We made good code that did the wrong thing, or didn’t make the code to do the right thing, or made code that worked but was awkward to use, or made code that people didn’t even know about and never took advantage of.
I rejected an initial plan that started with “A requestor fills out a form…” because that felt like the wrong fit for the organization: small team, generalists, continuous everything, flat structure. I’ve worked at places where senior technical staff only wanted to interact with people via the ticketing system and while it may have worked for them, it’s not my style.
I also rejected the popular term “acceptance criteria” because it feels (to paraphrase the Agile Manifesto) more like contract negotiation than collaboration. By the time you’re framing things as “is this acceptable to you?” you’re not really in the healthy creative collaboration space anymore.
I got it down to three sentences with just nine words:
Write it down.
Talk it out.
Get it done.
Here are just a few more words to elaborate on what those mean:
Write it down
It doesn’t really matter where or how you write it down, it could be a Jira or a Confluence page or a Google Docs document or a Google Slides deck. What matters is that someone took the time express their intention in writing and the simple act of writing forces you to organize your thoughts.
It also doesn’t matter exactly who writes it down. It’s not just people who are anointed as “project owners” or “product managers” or “primary customer contacts”. Knowing how to understand and describe problems is a skill that everyone should have, and like any skill, something that improves with deliberate practice and feedback.
On the other side, reading what someone else has written forces you to internalize their thoughts and (ideally) digest the entire idea before responding. Some people (maybe even me, sometimes) will interrupt a verbally expressed idea before it’s fully formed, saying things like “nobody wants this” or “this will be impossible” or “the software already does that”. Digest the whole idea before you…
Talk it out
It doesn’t really matter where or how you talk it out, it could be in Slack or on Zoom or in front of a whiteboard or over a beer. What matters is that the people who need to be a part of the conversation have a conversation. Ask clarifying questions, suggest alternatives. If you can’t get to consensus, at least get to mutual understanding.
Maybe you’ll find that while talking it out that the idea isn’t even possible, or that it’s too expensive, or that it’s not as important as some other idea.
If you do decide to move forward with it, everyone is now in a better place to…
Get it done
This is partially a reminder that we are working with a healthy sense of urgency.
It’s also a reminder that while in an evolving software platform, nothing is ever really finished and set in stone, there is a minimum standard that you need to achieve before you can claim that you’re “done”. Have the right people reviewed it? Is it documented? Are there tests for it? Did you coordinate external testing? Did you create example content and configuration for it? Has it shipped? Has anyone flipped the configuration switches to enable it for those who want it enabled? Have we informed impacted customers? There isn’t a one-size-fits-all checklist for all the specific steps for every kind of thing that gets done, but there are a handful of common patterns, and talking in terms of “get it done” helps people remember that writing the code is just a small part of professional software development.
So then, how does it work?
I rolled out this nine-word manifesto a few years ago and have been gently reminding people that all three steps are always necessary and I think it has been working well. It’s not a silver bullet, the hard things are still hard, but I feel that we’ve had fewer unforced errors, where we completely failed to get to mutual understanding.
Martin Cron 