I spend quite a bit of my coaching time helping teams improve how they determine what needs to be built in order to satisfy a business need. I warn them right from the start that they're going to hear me repeat the same term many, many times before they get rid of me. That term is "Shared Understanding".
There's a thinking tool that I use to help people understand what shared understanding means. I go to a whiteboard or flipchart and write the following:
Mary had a little lamb.
I then ask the group what that sentence means.
After some puzzled looks someone will say, "It's a nursery rhyme." I then ask, "Sure, but can it mean anything else?" More puzzled looks. Occasionally, someone will say, "Mary ate some lamb?" Yes! I also suggest that Mary is a ewe and just gave birth. Recently, someone suggested that Mary was a person and had a very nice child. The term lamb can be used when referencing a child.
After some puzzled looks someone will say, "It's a nursery rhyme." I then ask, "Sure, but can it mean anything else?" More puzzled looks. Occasionally, someone will say, "Mary ate some lamb?" Yes! I also suggest that Mary is a ewe and just gave birth. Recently, someone suggested that Mary was a person and had a very nice child. The term lamb can be used when referencing a child.
I point out that we had very quickly just come up with 4 different meanings for the same sentence, which was supposedly very simple to understand:
- What if someone in the room wasn't from a Western culture? Would that person know about the nursery rhyme? Is that a cultural bias?
- The use of lamb to mean child is relatively old and not heard very often now. Is that a generational bias?
- If a person has been raised from birth as a vegetarian would they even consider eating lamb? Is that a social bias?
All of this from what seemed like a simple, well known sentence. Imagine, then, how difficult it must be when we're trying to build software systems!
The Pain Point
I was extremely lucky early in my software career. From the moment I wrote my first program to be used by someone else in 1982 until almost 15 years later, I was able to speak directly to the people who were the consumers of my software.
We would discuss what problem they were trying to solve and how the software would do that. I could build something small, show it to them, let them try it, and adjust direction from there. I had heard about other more professional methods, but they seemed quite academic to me. After all, I was only building these small systems for a maximum of 20 people and doing it mostly on my own. Those systems were being shipped, the people were happy and I enjoyed solving their problems!
As I moved further into my career, I joined larger teams building larger systems. Suddenly the development team very rarely spoke to the stakeholders or actual users of the system. There were experts for that! Suddenly the previously simple communication model was much more complex and face to face (or even phone) conversations were replaced by the dreaded big binder of requirements.
There were numerous occasions where we built features assuming that Mary was a girl in a nursery rhyme, but the actual users of the system meant that Mary was a slightly peckish wolf. It was painful to say the least for both parties to reach a shared understanding using that communication model.
Fast-forward to my "Agile days" using stories arranged in a backlog. We had ditched the requirements binder. We had ditched all the up-front analysis, design and planning. We were still doing those things but in much smaller increments. That also included development and testing.
When the teams with whom I worked had direct access to the Customer, they excelled! They could ask questions and receive answers immediately. They could put a page or report together and receive near instant feedback. I was reliving the great experiences of my early career!
However the moment any team encountered a situation where there was difficulty communicating with the Customer, the old problems surfaced immediately. Lost was the context of whether Mary was a sheep who had given birth to a lamb, or Mary was a person with a small child.
Not surprisingly, that lost context resulted in problems with story acceptance ("That's not what I/we wanted!"), and decreased the throughput of value through the team. Additionally, teams had to deal with much more churn of priorities because there were times where the team members would have to decide what was important because the Customer wasn't there.
They were right back to the issues that an Agile approach was supposed to cure!
Let the Map Be Your Guide
Sometime around 2008 or 2009 I heard about a technique called Story Mapping. Jeff Patton had coined the term in 2007 and I was intrigued by the idea. I finally saw Jeff in a session at Agile 2010 called Beyond Sprint 0 which totally blew my mind! It isn't often that someone can hold your attention for 60 minutes in a non-interactive talk, but Jeff absolutely pulled it off. In his session, Jeff repeatedly emphasized outcomes over mere delivery and illustrated how collaborative product discovery, including story mapping, helped achieve this.
While that session was an epiphany for me, it was quite some time before I was able to actually use the technique. When I did, though, the positive effect was immediate. Simply creating personas and mapping out how they work produced insights that converted tacit knowledge to explicit knowledge.
When groups move on to creating stories they have a much better feel of the context in which those stories "live", and are therefore better able to write the stories. We can apply traditional splitting techniques with a sharper eye for what splits make sense because we understand what outcomes are most important.
Finally, determining the increments of the product becomes much easier because the conversations that have taken place have helped the technical people understand what's important from the business perspective, and the business people understand the technical trade-offs that must be made.
Eureka Moments!
While discussing the personas and simply discussing what those people do in carrying out their jobs, there were so many instances of team members saying, "Oh... I didn't know that" or "OK, that's different from what I thought". With other approaches, those insights happen much less often (or not at all) and much later in the process of building a product.
These "Eureka Moments" are absolute gold! They are when a person or group has made a tectonic movement towards a shared understanding of what's needed, and represent the value of this approach.
Conclusion
My litmus test now for grading myself as a facilitator is how many times I hear those "eureka" phrases or see that moment of enlightenment on someone's face. If that isn't happening then I'm doing something wrong!
It takes some time to develop personas, determine the outcomes important to those people, map out how they work, create stories and fit them into increments that will deliver the desired outcomes. That time, though, is measure in hours to days. Compare that to the gymnastics and gyrations that occur when, late in a development cycle, a stakeholder says, "That's not what I wanted!"
Everyone is working from the same meaning of "Mary had a little lamb", and that shared understanding will minimize or eliminate the pain associated with those misunderstandings.
Finally, I highly recommend that you read Jeff Patton's book, User Story Mapping.
Comments