Now that we are rolling into the end of the year and most of you are doing holiday things, I thought I would find something a little warmer and fuzzier than normal to write about. So I am going to talk about one of the things I work hard to find with teams: Shared understanding.
Over twenty years of being involved in software development I have seen every flavor of process management. I have signed off on weekly status reports for ISO-9000 certified waterfall releases, and I have released software without a single Jira item logged against it.
Through all of these processes and philosophical arguments with people over what is and what isn’t agile, I have come to understand that different people and different industries tend to ship software effectively according to different rules.
Writing dispatch software for emergency works and 911 systems requires more deeply embedded waterfall design and structure. Making entertainment software tends to work better with shippable masters that are iterated upon using agile methodologies. I acknowledge that this is my personal experience speaking and that everyone has their own preferences for how to get stuff done.
One thing that is universally in common in all of these systems is the need for the people who design and plan for a product, and the people who build and maintain a product, to have a means of negotiation on what done means. Sometimes the things that are asked for require refinement or introduce special edge cases that need to be accounted for. Sometimes the requirements for the end product are not even possible as defined at the start.
One thing I have come to realize, through building lots of software and managing lots of teams, is that the best outcomes all had one thing in common—everyone was working to improve their shared understanding.
I am going to illustrate what that means through a badgile story. Yes I made up a word. Bad Agile equals badgile.
Once upon a time I was working on a consumer-facing website that had commerce integration. We partnered with a credit card processing company and we had a two week sprint to finish a set of tasks related to making credit card transactions work.
One of the developers picked up a task to generate a token that gets surfaced to the end user when a transaction gets approved by the credit card company.
At the end of the sprint, the developer in question demonstrated the api call and showed how entering in valid credit card information resulted in a Unique GUID that gets created and stored into the player’s account and added to his payment history.
The project owner shook his head and said “No, that is not done. This token is not human readable, I cannot approve the story.”
Record Scratch Noise… Wait What?
We stopped the meeting at this point to have a sidebar conversation. What we had here was a hidden acceptance criteria that was not communicated in the story, nor was that intent clear anywhere. On the surface, I can see the value of having a token that can be read aloud to a customer service agent over the phone, but that is extra work that was not in the scope of the original work request.
The good news is that everyone had an “aha” moment about this and we were able to declare that the work was done, and that we added a new story to modify the GUID to be human readable as the next task.
This is about the best example of a lack of shared understanding as I have ever seen, and I use it to help people understand its importance.
When I am working with new teams I do my best to try to introduce a few core concepts to help make them successful. The first and easiest is the notion of quorum, taken from multiple terms in student council while still in school and also taken cheerfully from Robert’s Rules of Order;the book that everyone loves to hate.
When I attend a meeting, I make sure that all the stakeholders are in attendance, and I am eager to ask people if we have quorum. If we do not then there is no point in starting the meeting only to regurgitate large amounts of it when all of the relevant stakeholders arrive.
The next thing that I do is teach the notion of shared understanding, which is one of the most important things I do when working with a new team.
I do not think that you can build great software as a team without shared understanding.
I also do not think you can develop shared understanding quickly without pointing out its importance.
It turns out that shared understanding is a powerful safety word for software development. I am the first to tell everyone to pump the brakes when I am confused, whereupon I will freely state “I do not think we have shared understanding here”.
It is a great way to get everyone to stop, think about what they know, and more importantly, how to communicate what they know to other people so we can all agree on the knowledge.
If you can get your teams to a point of declaring a lack of shared understanding, then suddenly the focus rapidly becomes how to communicate that understanding from the person who has it, to the person who does not.
Over time it is a beautiful process to watch. The act of declaring a lack of shared understanding helps people to refine their communication tools and to improve their ability to define and accept work.
The next time you are on a team and things are not working well, you should take a step back and ask yourself: Do we have shared understanding here?
If you do not then I suggest you declare it to all parties involved and try to figure out how to reach shared understanding together.
Thank you for reading along. This week’s article was short and sweet. I look forward to writing more articles next year, and as always I treasure your feedbackey-words, your likey-clicks, and your linkey-shares. The more social reciprocity you give me as adults, the less I will use cutesy-wutesy words to endear you to perform said activities.
