Features

Packages

Our Team

Training

Contact

Book A Demo

A common issue in software is that a miscommunication between stakeholders (resulting in poor final value delivery) it often explained as “someone dropping the ball”. The temptation is often to find a personal explanation rather than look at process. To find a guilty party who is unqualified or just not trying hard enough. 

Whilst that may occasionally be true, it is worth being in mind that contrary to appearances (or a deep human need to blame) catastrophic misunderstandings often happen. And even very much so, among the brightest.

NASA’s Jet Propulsion Lab (JPL) in Pasadena is a place where only objective geniuses may apply. On a normal day they’ll be working on a Mars rover or complex orbit entry trajectories. Not the kind of people you would call “unqualified” or with whom you’d typically want to compare personal commitment or skillsets.

And yet they crashed $125Mill of space research, straight into Mars. 

The idea was for the rover to land on, and survey Mars, not enter its orbit like a meteorite, and disintegrate on contact.

The culprit? Imperial vs. metric conversions.  

Lockheed Martin, a key supplier on the project, provided data in imperial, and JPL used metric. Hardly stuff of engineering prowess legends. On either side you had engineers who were probably fluent in astrophysics and theoretical mathematics. 

Observe, tellingly, that it is not failing at the conversion that was the issue. Any of their engineer could have done the calculation mentally, without even the back of an envelope. No, the real issue was communication, both sides failed to openly communicate to the other what units they were using. Both sides assumed they understood each other.

Put differently: They did not build shared understanding, but thought they had.

Shared understanding (ignoring blame; optimising process)

In his riveting book, coining the term “User Story Mapping”, Jeff Patton dedicates an entire section to just that. Building shared understanding is that crucial, to take design flawlessly to business analysis, to project/outcome delivery.  

How teams build shared understanding in software engineering in real life
Walking into sharp objects: A visual illustration of how teams build shared understanding in real life

He writes that often what he witnessed instead of shared understanding was illustrated in this drawing:

Stage 1: Assumption: Everyone assumes they are agreed on the same vision but truly not, each stakeholder understands something different. 

Stage 2: Realisation: Demo day! Value is missed and nakedly exposed in a real-life illustration of this collective misunderstanding. Heads roll, fingers point.

Stage 3: Real-life actual Collaboration & Communication: Gathering around a prototype, a mock-up, a User Story Map, each stakeholder can debate, discuss, validate in a cross-functional team. Context is discussed, contingencies are debated.

Stage 4: Real shared understanding is built. We all actually get it. Not just what is written in the “user requirement” Word doc. We actually understand why we are doing it, this way, for whom, how, who will come in, when, to deliver what value. We get all the operational detail, we have flushed out all major contingencies, we have expressed what the assumptions are. We have ordered the activities and prioritised each task, taking all in consideration. Finally, we “get” the product vision as a coherent UX, rather just a list of user stories.

Documenting shared understanding 

Building shared understanding is the ideal outcome that you want out of your documentation.

Documentation should not be dry, unused Word docs on a shared folder, afterthoughts for what someone said during the backlog grooming. Documentation should not be used primarily as legal artifact, in case of later dispute, as to whom was supposed to do what. Documentation should ideally drive design. Yet it is more often used to “massage” a raw design idea, into an engineering sounding document, just for the ISO9001 certifier, say.

So, it follows that building genuine shared understanding calls for smarter, richer documentation. If the goal is to build and maintain shared understanding across project team and dimensions, documentation becomes a living thing. It requires a slight cultural shift, towards something more human sounding, more authentic, more compelling and usable.

Jeff Patton invented User Story Mapping just for that. A group activity that is a base for everyone to share their vision, SME insights and ideas. A cross-functional team placing post-its representing tasks, prioritising them, ordering them smartly. And which can be turned into dynamic documentation, that anyone can refer to if in doubt.

Real life smart documentation would be, say, a video recap of a User Story Map session as explained by the project owner for example (some record the entire sessions, but the consensus is to record the final walk-through). Post-its anyone can move around, pointing at screen mock-ups. Excited gesticulations from a cross-functional team. And the script of this high-energy group discussion video, walked-through by the PM or Product Owner, would sound something like this:

User story mapping in person, building shared understanding.
A PM explaining his vision / user story map in person; building shared understanding.

“We included this user story in this sprint because Dave in legal reminded us of contingency “T&C’s” which needs to conclude before we ask them to provide payment details.  

Jenny from Design made a good point in the sense that the user persona we based this map on, would just not place their first trade right after sign-up anyway. And would probably hate that color, so that’s why the mock-up is now more pastel 

We also received confirmation from Larry on the board, that we’d get X amount of $ only at this milestone anywayWhich is great, because thdevs. pointed out that removing technical debt would best done here, here and there. So the devs can get started on that sub-project immediately to keep our architecture stable and efficient from the off, without delaying product. 

Finally the Head of Marketing also made the good point that (external event) is on that date and so this section of the site at least, will have to be ready at the latest for release 3.  This way we can deliver early value and garner early insights from mass contextual traffic around that event.” 

Doing things right vs. Doing the right things 

Very often, we assume we are all clear and get “stuck in” right way. We get busy working on “stuff” because it makes us feel good. Many of us have this innate slant for action. Maybe also to be seen working, which is understandable, to a point.  

But it should not be on demo day that we gauge whether we really got it right or not.  

And that’s if you’re lucky.  

We do not always get the luxury of having a Stage 1 and 2. Sometimes you only realise the misunderstanding when you see your probe pulverised in a tiny crater on a planet it was supposed to survey.  

Forgoing Stages 1, and 2 saves time, $ budget and preserves key personal partnerships. Building shared understanding from the off is very much worth the effort. And there are only a few ways to do that, most of which rely on the use of prototypes. Whether a mock-up or a User Story Map, modelling a prototype as a basis for a much higher conversation, is incredibly valuable. 

Shared understanding: The final frontier 

As anyone even amateurly versed in psychology and communication sciences will tell you, human cognition is more dynamic than it appears. On one (narrow) plane we agree on signs, alphabets and cyphers giving us the illusion of shared understanding. But meaning and understanding, real information is usually composed of a nexus of data-sets, never just the one. And each of them must be interpreted right.  

For example: Everyone understands “7.32” as a mathematical expression. 

It is just a bit more than 7, but certainly not 8 either.  

But what, inches or feet? Meters? Is it too much or too little? Is that before or after release 4? Does it go left to right or the other way? How does that compare to industry standards? Has that been validated by the board? Is that even possible technically? Etc. etc.  

These are the essential questions that a cross-functional team around a mockup or a prototype need to ask openly and negotiate together. 

Context, not just the “what” but also the “why”, for whom, based on what assumptions, all of these questions and many more are crucial to valuable engineering.  

The answer usually lies in the engineering process, and how information is generated, relayed and validated, and hardly ever obviously, in the talent of any single individual.  

The process is effectively what we have come to rely on to fix the lack of communication, to ensure it is minimally effective.  

But if we blindly follow the process without understanding why it exists, then we end up not getting the outcomes we want. 

You don’t know what you don’t know 

If there is one thing more dangerous than not building enough shared understanding, it is to not build shared understanding and think however, that you do.  

Want to know maybe the best part about that Mars Rover that cratered straight into Mars?  

It’s not even that it was, quite literally here, lost in translation. 

It is that no one even thought such a basic mistake could be made, during the 9 months it took the probe to reach Mars.  

They had all that time to fix the calculations. 

Dangerous assumptions are everywhere. So are unsuspected pools of user value.  

Prototyping and testing is the only way to get real-life intel. The only real way to usher real-life feedback into the equation, so you can validate value, and discard erroneous assumptions. Also, so different opinions internally can be put to rest by reality. Real-life feedback is precious too in the sense that it is harder to argue. It can help harness the collective intelligence and energy of your team. Not towards endless, occasionally friction laden debates, but towards a more valuable goal with less conflict to agree a plan. 

Test often, garner feedback often.  

Fix early, fix often, fix cheaply.  

Pivot intelligently, tweak based on feedback, refine often, never stop chasing user value and discarding dangerous assumptions. 

It saves large amounts of time, money, and protects key internal partnerships.