How many times have you experienced this?
The project is underway. You’re past ‘discovery’ and are well into ‘build’ or ‘execution’ (or whatever your team calls these). Your team started together. You did inception workshops, or kick-off meetings (or whatever your team calls these). You talked through the problem to be solved, worked up the requirements and the approach, diagrammed the solution model, agreed on the delivery and set up the epics and the first sprint stories. Everyone’s clear, everyone’s aligned. You’re all happy, and everyone’s optimistic.
Then, halfway through a sprint, someone starts talking through what they’re building or the delivery lead presents a side-quest the team is working through to resolve an apparent problem, and… it is clear that you are no longer all on the same page. ‘We’re doing x because y’, they say, and because you know that there IS no ‘y’, you’re like, Wait, what??
For the longest time, this situation perplexed and frustrated me, and I was not good at reacting to it. Here’s how it tended to go.
Someone: ‘We’re doing x because y.’
Me, inside my head: WTF? There is no y, and even if there was, we don’t want x! It’s all in the docs! We AGREED on this. WHYYYY is this happening, WHYYYY are we talking about this again??
Me, out loud: ‘Oh, ummm…. no but that’s not right, because abc. Remember like in the model? Because remember [restates abc from model/requirements, usually talking a mile a minute and waving my arms around]. Remember we went over all this in the workshop, and we all agreed?!’
Smooth. Why didn’t that always play well I wonder?
Plus I was frustrated and stressed out a lot of the time, wondering why things didn’t ‘stick’ and why we had to keep going over the same ground over and over again, when things had already been ‘agreed’.
But then, I read what has turned out to be one of the most influential things ever for me, which is this post by John Cutler: Building Shared Understanding is Hard.
“Building shared understanding is hard. And fleeting. You have to keep at it.” – @johncutlefish’s blog
There were a couple of other things happening around the same time. I switched jobs, joined a new team with a strong focus on change management. My new boss commended my ‘passion’ in a way that I suddenly understood was not really a compliment. I realised I could be more effective (and less stressed out).
Here’s what I learned
1.’Building shared understanding is hard’. The fact that things don’t ‘stick’ straightaway is actually normal. You have to factor that in. You don’t mark that stuff as ‘done’ after everyone has agreed to it in a workshop and assume it is set. Honestly, just really learning this lesson has been huge for me, and has saved me from a lot of the stress I used to feel in project management.
2. You have to give people time to work stuff out for themselves. They will also learn and understand it in the process, which has compounding time-saving effects down the track, as the work continues. Plus they enjoy and own it more. Don’t begrudge that time!
3. Guess what: You may be wrong! Or you may not have taken into account something that comes up once the build gets into the detail. Their side-quest may well be spot on.
Here’s some stuff that helps
Print out the guiding model on A3 and post it up everywhere. Yes the team has the Confluence page, and the details in the Jira ticket. Having the guiding ‘north star’ on the wall is what they will actually see, and you can show it to anyone else passing by who wants to know what you’re working towards as well.
Whiteboards and walls. Walls with cards and colours all over them. There is a reason these work. Especially when mapping out complicated or complex processes. It is much easier to work out and understand these on a visual wall in a sweeping glance, than it is to scroll up and down and back and forth, or page by page, through graphs and diagrams on screens.
There is no single diagram or explainer page that will work. You probably need multiple and various things. (Also, while the wall is great, you also need the diagrams, graphs and pages as well. Documentation is still a thing).
Find a key phrase that nails the thing you are trying to make ‘stick’. Whenever you and the rest of the team are discussing questions or issues, use this phrase to relate it back. For example, in a current project, one of the core requirements of what we are doing is that two linked processes must be ‘tightly coupled’. As we work through the details of how we do that, anytime a proposed idea veers away from that requirement, I use this phrase to bring it back:
‘Okay, so how do we do that and keep x and y tightly coupled?’ (Once upon a time I would have maybe said something like ‘No, because that’s not tightly coupled!’ But I have also learned to respect the way ideas and solutions develop, and not to assume something is wrong out of hand).
Trust the team. Work together. Solve together. You are not doing it all alone.
If I’m being honest, I still struggle with this sometimes. But at least I know now that it is normal for shared understanding to take time, and that none of us really understands much before we start the work.
the non-project project 