Often, I observed discussions or disputes where I found that everybody was right – from their own perspective. But in the end, they didn’t found a solution. What a pity. One day, in a workshop, where we had some different types of cookies, I was faced with a similar situation. With the cookies at hand, I started to explain…
So, I took a shortbread type of cookie and took over the role of one of the disputants. I explained my flat-earth cookie, implicitly assuming that the other ones also live on my type of cookie. Then I changed my cookie – perspective to the lady on the cream-filled double layer cookie. While listening to the flat-earther, she asked: How about the filling? And the guy living on the wafer only shrugged shoulders…
Maybe this is another interpretation of Norman Kerth’s Prime Directive which I frequently use in beginning a retrospective:
Explaining with my cookie-style way, that having different perspectives is not only welcomed but necessary to be successful, is more visual then Norman Kerth’s brilliant text.
Feel free to use my cookie analogy and my picture. And please let me know about your experiences.
In one retrospective I gave the team 10 minutes for a silent brainstorming. They started writing sticky notes. As expected, after about three minutes, the writing slowed significantly down. As experienced facilitator, you have to stand this phase of low activity with all eyes focused on you, begging for salvation.
But what happened now in my retrospective? One put out his smartphone, followed by another one. I couldn`t believe it. The remaining time, I kept monitoring the situation and thought about it. When the timer bell ringed, I appreciated the participation. Then I told them about my observation. The omnipresent distraction by smartphones (and the upcoming smartwatches), resulted in a few sticky notes. The deeper engagement was sacrificed for the easy distraction – what a pity!
Here a typical activity diagram for such a situation:
In the first activity phase, participants find the obvious topics – the low hanging fruit. The first activity phase is followed by a phase of low writing activity but high brain activity. This phase is crucial for the identification of more revealing, creative, relevant, and understanding topics. This leads in most cases to more sticky notes.
However participants seek for shortening their brainwork – if consciously or not – the result is the same: Low hanging results with only little potential.
Unexperienced facilitators fall into this trap frequently by stopping the brainstorming when nobody writes anymore and all stare at them or in the air. Often they feel well because they increased the efficiency of the retro by saving a few minutes.
What are your experiences? Somebody knows more about the background? Please comment here.
During a retrospective, I realized that the two internal customers of the team are not used to write epics and user stories, whereas the developers have some experience but still in some areas little business knowledge. Often ambiguous or unclear specifications hindered the team to start working.
Thinking of Pair Programming as an instrument to spread knowledge, to increase quality and structure, and to promote collaboration, the idea of applying similar practices to the creation of specifications appeared to be helpful.
Development team consists of 5 developers (nice mix of work experience)
Two internal customers, one of them as Product Owner
Team applies Kanban (started some months ago)
Whenever new features need to be specified, the internal customer “pairs” with a “random” developer. Over the time, every internal customer should have paired with every developer.
The developer brings in his knowledge and experience in writing epics and user stories.
The internal customer brings in the business expertise.
Like in Pair Programming, the work is done collaboratively.
The expected benefits:
Internal customers and developers get to know each other better through collaboration.
Knowledge is transferred in both directions.
The results (epics and stories) are already reviewed and potentially “Ready to start”.
Developers will better understand the business reason of a feature and the prioritization.
Developers can bring in their ideas in an early phase.
Overall, this approach seems to be worth to be tested with a small number of teams.