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.
For almost two years, I neglected my blog. There were many reasons.
Now, I want to reanimate my blog. There are so many insights, adventures, stories, jokes to tell that cross my way.
Sources are teams that I accompany, colleagues I talk with, the community, other blog posts or tweets, and friends & family.
If you like it (or even when not), let me know. Retweet or forward my posts.
Reiner was invited as keynote speaker.
The topic: Slack is the ultimate weapon
Slack or free time is one of the main ingredients for obtaining improvements and innovation. But how to introduce slack in an environment where resource utilization ist a main KPI and managers measure progress by the amount of delivered features. Slack can result in a lot of positive effects – but slack is not for free. One is clear: successful organizations use slack.
Find the presentation here: 20140404 Slack is the ultimate Weapon – publish.pdf
During the last weeks, I realized an increasing number of spam posts to my blog.
Happy that I first have to approve every post, it costs me more and more time to check them. For that reason, I decided only to allow registered users to post articles and comments. If you want to contribute, please register.
During a workshop with 8 team leads and managers, I realized that in general, they all had a certain knowledge about agile and Scrum but our discussions went around details of the Scrum Roles and Artifacts.
How can I help them to come to a better understanding? Teach them? Send them websites to read? No!
How about a game? Better. Or for those who don’t like games, a workshop.
What you need:
- Split the team into 5 sub-teams if you have more than 5-6 participants
- Give each one a copy of the Scrum Guide and Manifesto
- Explain by yourself the first paragraphs (Purpose, Definition, Theory)
- Let every team/participant pick a chapter or assign it. Maybe split the Events chapter in two parts – it is pretty long in comparison with the others. If the number of participants/teams is more than 6, let one read the Manifesto and the Principles.
- Give them a timebox of 10 minutes to read, giving the information that later on they have to explain the essence of what they read to all others.
- In the next timebox of 15-20 minutes let them visualize by filling flipcharts, whiteboard, or however they like it.
- Give each participant/team another timebox of 5 minutes to present. It one can not end within the timebox, allow one more minute to finish. Not the timebox is the most important factor here, the information counts. Start with the Manifesto and its Principles and continue with the chapters according their order in the Scrum Guide.
- Optional: After the presentation, the participants can discuss.
In this way, you can let them interactively update their knowledge and understanding about Scrum.
I played it once with a very positive feedback of the participants. I will try it in future with some more teams that show similar symptoms.
BTW, this game also can be played with other documents. I especially think of “Agile Manifesto” and “Kanban Properties and Principles”.
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.
How do you think about this?
One of the most important websites for agile: http://www,agilemanifesto.org
Often, teams working agile already for a while, tend to forget the intentions and the principles. This could result in a slow but progressive undermining. So, from time to time, it might be a good idea to recall the manifesto. There is a nice game to support this: Pocket-sized Principles.
Hi & welcome.
For a long time, I thought about having my own blog. But for what? For whom? How?
I was searching for a place to share information and to express my position on things that are interesting for me.
Out of the discussions, trainings, etc., I want to share resources, thoughts, ideas with others. In the history, I collected all this in my mail program.
** For whom?**
For colleagues, friends, my network & everybody interested in what I share.
Still not so clear about this. I will start now and evolve during using the blog.
I highly appreciate any feedback.