Attention: More explication will follow.
This post is just for all the attendees of Manage Agile Conference in Berlin.
Lego Complexity Game
Leave a reply
Author Archives: Reiner Kühn
My 200th Retrospective
On 22.10.2019 I facilitated my 200th retrospective. Between 2012 and 2019 this means in average one retro in two weeks.
I want to say “thank you” to all the teams, I was able to support in their continuous improvement process.
More than 320 hours for me as facilitator, plus at least 400 hours for planning, preparing, and postprocessing.
Often, I was asked: “Isn’t this boring?” Not at all – and for many reasons:
- Working with people and on the organization is extremly interesting and important.
- With each retrospective, I learn something new: new people, already known people better, new behaviours, new methods, visualizing, and how the organizations works.
- It is very satisfying and less frustrating to see, how teams or even individuals work and react on the results of a retrospective and how they grow.
- Often, I’m not only the facilitator, but also coach, mentor, and teacher – well indicating to the team in which role I am right now.
During that time, I also invented own formats:
- Outdoor Retro
- Lego Retro
- Remote Retros across multiple location
- Retro Memory
- St. Nicholas Day Retro (it is typical in Germany that you receive sweets for good behaviour and birching with a rod in case of bad behaviour (literally meaning). “I deserve a lot of sweets because…” and “I deserve the rod for…”.
- An end-of-year retrospective with the minutes of all retros of the year, reflecting on the changes as well as on the methods.
- X-Mas Retro: We decorate the tree with a yellow Christmas tree ball for what we have learned and a green one for saying thank you to a colleague.
Especially worth to mention is my favourite retro team. During 35 retrospectives, they went through almost all of my experiments and it was logical that they deserved the jubilee retrospective with cake.
The most impressive moments were the appreciative exercises. Simply saying thanks to a colleague or expressing admiration. This always resulted in some (hidden) tears…
My worst retrospective was the forgotten one: Outlook reminded me 15 minutes before. Damn! But I thought: “Come on, with your experience, you can do a retro instantly”. It was a desaster. Not in the mood and not prepared. I’d better had canceled it. What did I learn from this? Take every retrospective seriously. The participants take their time and they deserve a good retrospective.
I also had to drop a team. I had the feeling that I could not help them. So they got professional support from HR.
My goal is not only to improve my own retrospective facilitation skills but also to enable more and more colleagues to perform good and effecitve retrospectives. In 2016, I created a retrospective facilitator program, consisting of a one day basics training and 4 subsequent quarterly half-day intermediate trainings. Meanwhile, almost 100 participants participated in the basics training and 20 passed the entire program.
I’m looking forward to the next retrospectives. Thank you very much!
How a Team Manifesto can boost collaboration
Some time ago, a team asked me to facilitate a team building workshop. While creating the workshop concept, we came across some concepts like a mission statement or a team charter.
As we talked recently about the Agile Manifesto, I thought, it might be an idea to use a part of the workshop for creating a Team Manifesto. similar to the structure of the Agile Manifesto:
- a introduction, or preamble
- values
- principles
- an epilog
Values are important for us humans: They control our behavior. They allow us to live together. And social norms/rules are derived from them.
Typically, they are very stable. We also need to think of team values and individual team member’s values. They might be conflicting.
Principles help us to live the values. They are rules and policies you adhere to.
The idea was set, but how? And which benefit do we expect? It was a kind of experiment.
For the team it was important to come to a common understanding what is important for them, how they work, how they decide.
How can we identify the team’s values?
When values are important for us, ask them what is important for them! With a nice and rich collection of sticky notes, we did some clustering and we named the clusters. The names of the clusters were often a value:
Values are often too abstract to guide us through our working day. We need something more tangible: principles!
How can we identify the team’s principles?
The question now was: How can we live the values? Again collect, cluster, name:
So, this was the first Team Manifesto. I created a wonderful wallpaper for them, they signed it all. And it went to the team’s room – visible all the time.
How the story went on
Over the time, other teams asked me to help them to create their own Team Manifesto. Building on the procedure of creating the first manifesto, I added some actions to involve all team members more actively.
1. Silent brainstorming: In regard of your work and the team, what is important for you?
2. Everybody presents the own keywords.
3. Clustering (4-6 Cluster) and naming.
4. From the keywords of each cluster, everybody forms a sentence representing the cluster best.
5. Presentation of all sentences
6. From all sentences, assemble one super sentence: The value description.
7. Loop over all clusters.
With the principles we proceed the same way – only with a different question: With the values in mind, what do you think might help you to live them?
The real fun with this procedure is puzzling out the sentences. I do it with sticky notes for each word. This allows you quickly rearrange words. Don’t forget to check each team member’s confidence with each sentence right after finishing (use thumb up/down).
Until today, I helped creating four Team Manifestos and one review (after one year).
What are the benefits of having and living a Team Manifesto?
Having a clear and common understanding of their values and principles makes discussions more precise. Decisions are not taken on a day-to-day mood but on explicit values and principles. Everybody in the team is entitled to address a violation or inobservance of values and principles – if it makes sense, it is at least done conscious and as an exception.
Maybe you can now imagine that this can boost collaboration. But it also requires discipline & commitment.
How can you create your team’s Manifesto?
I gave a talk about this on the Tools4AgileTeams conference in December 2017. There is a Youtube video available (in German only): https://www.youtube.com/watch?v=6QFGI4PwFHY
My presentation (in German) is available here: Team_Manifest_V2de
It also contains a guideline how to facilitate a Team Manifesto creation workshop.
Interested in an English presentation and guideline? Please contact me. Or invite me to your conference, event, …
Keep the production funnel free
In product development with collaboration of product management, development and operations, development often is the bottleneck – represented by a funnel:
Also it is typical that the product management has more ideas than the production funnel can execute:
With something like Portfolio Kanban, the organization can make this transparent and more manageable. Nevertheless, development limits the throughput.
Often it happens that too large packages must go through the funnel, resulting in longtime blockings:
Or even worse: the development team works on several of these large packages in parallel. This results in a later delivery of work results for all parallel packages:
In my experience, this well-known problem is too seldom resolved.
What often comes on top (especially in more technical products): Developers must help product management (for proof of concept, feasibility checks, checking of ideas, …). The capacity in the funnel is reduced by this support. The effect of narrowing the funnel is later delivery. Sure, somebody will notice…
Bugs are also capacity thieves. Due to poor quality (maybe due to high pressure), the development team spends a part of the capacity to fix bugs.
This reduces the time available for delivering valuable stuff which will be delivered later. Sure, somebody will notice… Pressure will increase, which leads to poorer quality. A vicious circle.
Daily business also can narrow the production funnel.
What can we now do about it?
Of course, the first step would be to identify if our development team is affected by this and to which extent (I guess most development teams are affected).
One pillar of Agile (not only Scrum) is transparency. Provide transparency about the capacity thieves in the production funnel allows us to argue and to find solutions. How to provide this transparency? Somehow the development team must gather data about the stolen time. Maybe you have a time tracking system in place – then you must ensure accurate bookings. Or you put a sheet of paper on the wall and let everybody write down once a day the stolen time. The gross capacity also needs to be recorded.
After a reasonable period, data is transferred to a spread sheet to do the math. The data can be shown as the following examples show:
As you can see, making the graphs visible to all stakeholders, makes it easier to make decisions. It also is a good input for the team retrospective.
Another helpful practice is to reduce the number of task switches due to capacity thieves. That means, concentrate them in a timeboxed meeting or timeslot or on one team member (rotating).
Also address malfunctions of the product owner:
• Insufficient product and/or market knowledge
• Poor requirement management skills
• Poor quality of requirements
The development team’s first responsibility is to deliver and not covering malfunctions. But also try to reduce inefficiencies and increase skills in the development team.
Spending time to support product management in ideation and requirements elicitations is not necessarily bad. Early involvement may later result in less risks, clearer requirements and better mutual understanding.
By consciously taking care of the production funnel width and keeping it as clear as possible the development team can deliver better and faster.
I hope, you enjoyed my new blog article. Feedback welcome!
Brainstorming adventures and insights
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.
Reanimating my blog
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.
04.04.2014 | Even mammoths can be agile | Cluj-Napoca (Romania)
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.
http://colorsinprojects.ro/eveniment-cluj-4-5-aprilie-2014
Find the presentation here: 20140404 Slack is the ultimate Weapon – publish.pdf
Spam flood
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.
Scrum Guide Game/Workshop
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:
- Copies of the actual Scrum Guide
- Optional (more for reference reasons) copies of the Agile Manifesto and its Principles
- Flipchart, Whiteboard, Post-Its, Markers,…
- Stopwatch
How to:
- 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”.
Pair Specifying
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.
The environment:
- 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)
My idea:
- 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?