Agile Coaching, Meeting Facilitation

DIY Flipchart for less than 15€

Most of the or rather all Agile folks love to work with flipchart when presenting or workshoping. Some are so obsessed with the “flipchart-marker-visual-facilitation-universe” that you could think they have a Neuland tatoo. 🙂 Or they want to have a flipchart even at their home. Like me! 😉

In this post I will write about building your own flipchart: a very low-budget version for less than 15€, an advanced version for less than 45€ and, with a little more effort, an awesome version.
I created an Amazon wishing list with all material you could use: http://nearn.de/Zw

1) DIY low-budget flipchart for less than 15€

Very easy, indeed: Buy a set of over the door clothes hanger, find a flat door in your home, hang the hanger and the flipchart paper. Ready to go. No tools needed.

door clothes hanger 
2) DIY advanced low-budget flipchart for less than 45€

Buy 2 pieces of plywood and stick them together. Drill 2 holes for the door clothes hanger. Find a door in your home, hang the hanger, then the plywood construction and finally the flipchart paper. Basic crafting tools needed here.

door clothes hanger for flipchart   DIY flipchart 

 3) DIY awesome low-budget flipchartDo the same as with 2). Additionally, saw a stripe off of the plywood, drill well-fitting holes for big and small markers and glue or attach the strip to the plywood. And your awesome flipchart for your home is ready!

marker holder 
If you have DIY flipcharts as well, please let me know and send me a photo!

Advertisements
Agile Coaching, Scrum

Checklist for Scrum Masters

You are a Scrum Master and you have the feeling, that your team “actually works fine” OR You are a Scrum Master and you would like to check what else there is to do to help your team to improve? OR You are a Scrum Master and you are looking for confirmation that you are doing the right thing?

checklist-e1438035281655

Then  Michael James’s Scrum Master Checklist will help you.

The checklist offers questions that will challenge you:

  • Part 1 – How is my Product Owner doing?
  • Part 2 – How is my Team doing?
  • Part 3 – How are our Engineering Practices doing?
  • Part 4 – How is the Organisation doing?

Additionally: My colleague Urs Reupke and me were doing the translation for the ScrumMaster Checlist in German.

Please comment if you think that a question is missing.
Please comment if you could check all items on the checklist.

ScrumMaster Checklist »

Agile Coaching, Meeting Facilitation

LEGO Serious Play: Modeling & Story-Telling

Some weeks ago I attended the “StrategicPlay® Fundamentals Facilitator Training” at the StrategicPlay® headquarters and have used elements of LEGO Serious Play™ (LSP) quite some time with teams since then. As a Playmobil® fan it is “shocking” to see how easy you can use LSP for solving complex problems or helping team members to understand each other better. 😉 And additionally it is fun.

LEGO Serious Play Session

LSP’s theoretical background consists of four key elements:
Constructionism, Play, Imagination and Identity. You can dig into the science of LSP by reading this wonderful PDF.

A LSP session can have the following acitivities:
Building a model >> Presenting others your model by telling your story >> Watching and hearing the others presenting their model >> Deconstructing and then building a new model or rebuilding your model…
LEGO Serious Play Session 2By iterating this sequence you are becoming more and more confident about your modeling and story-telling skills. As all participants are building a model about the same subject, you are at the same time sharing knowledge, ideas or problems with the others. After starting with straight-forward subjects (like “Build a tower as high as possible.”) it feels easy to deal with methaphorical subjects (like “Build your perfect team process.”) after some iterations.
I have just started to use LSP with teams, but am convinced, that an experienced StrategicPlay® facillitator can help any team to reveal the true essence of a problem and then find sustainable solutions.

By now I have used LSP in a couple of 2 hour team sessions mainly to discuss their process and their roles within the team. This is only the start. LSP seems to allow infinite options for working with (agile) teams. I am very lucky to have our management sponsoring the LSP Landscape and Identity Set (not available at the moment…), which you definitely need for larger workshops (“We are building our company vision.”). I’m planning to have a Sprint Retrospective with LSP before Christmas and will let you know about my experiences.

Agile Coaching, Meeting Facilitation

Agile Team Retrospective Activities: Starfish & Team Radar

Variety in retrospective activities are definitely necessary. The more retrospectives I do, the more I’m getting tired of using the same method over and over again. And hey, this will most probably bore the teams I work with as well. Therefore it’s good to challenge the team AND you with new retrospective techniques. In the last weeks I tried out Starfish and Team Radar in retrospectives.

Starfish
Starfish is a fantastic activity to get your team to re-think the basic questions:
What went well in the last iteration? How can we do better?

starfish retrospective

Starfish refines those two questions and gets more detailed information from the participant instead of just a binary view. If you know retrospectives the different categories of the Starfish are self-explanatory, for everyone else I recommend the post from Pat Kua from 2006.

You can either let the team write post-its for every category one after the other or let the team handle all categories at once.
After the team has gathered the data you can start right away with some clustering or go straight to agreed, detailed improvements for the next wees by exploiting categories: stop, start or less.

Team Radar
Team Radar is powerful if you have a communicative team. It’s not so good if team members prefer writing post-its to talking (if you know hwat I mean… 😉 ).
You can pick 4 to 5 subjects that either you or the team think are worth discussing in detail. Those subjects can be team values like Respect, Feedback or Communication. Alternatively you can also choose reoccuring subjects from former retrospectives like quality of code skills, effectivity of the team etc. If you are not 100% sure what subjects to choose, only suggest subjects and then let the team decide.

team radar retrospective
This is how you can work with Team Radar:

  1. Explain to the team what you think that every subject means and then let the team discuss/agree on that
  2. For every subject let everyone dot/rate on a scale from 0 to 10 where she/he thinks the team stands concerning this subject
  3. Discuss each subject in detail and agree on concrete improvements:
    • Be aware if dots are far away from each other on one subject. This is most probably because of misunderstandings within the team.
    • As I mentioned before: This activity is for communicative teams. Take care that everyone gets the same time limit for their opinion.

Team Radar is described in detail in still the best book on Agile Retrospective Activities: Esther Derby and Diana Larsen “Agile Retrospectives: Making Good Teams Great”.

Nevertheless, with a new team, it is important to start and train the basic chain of a retrospective before starting with alternative activities and risking to overburden the team:
1) Warm-Up: What happened in the last iteration?
2) Prime Directive and basic group rules: Explain why those are important.
3) What went well in the last iteration?
4) How can we do better, how can we improve our process?
5) Is there anything we CAN’T change by ourselves?
6) What in detail will we change until the next retrospective?

Related Post:
3 retrospectives in 2 Days

Agile Coaching, Books, Kanban, Scrum, Scrumban

Soft Agile Transition: Slowly from nowhere to Scrum

Lean Thinking is what I’m trying to learn and adopt at the moment.
What a perfect coincidence that I stumbled over Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum from Craig Larman and Bas Vodde. On page 54 they describe Kaizen, one of the crucial Lean Principles, as a plausible “inspect & adapt”:

  1. choose and practice techniques the team and/or product group has agreed to try, until they are well understood
  2. experiment until you find a better way
  3. repeat forever

When I try to find this Kaizen practice in my work of the last years, it fits to what I call the “soft agile transition from nowhere to Scrum.” 😉
Here is the formula:
(0) Nothing > (1) Daily communication > (2) Visual Workflow > (3) Kanban > (4) Scrumban > (5) Scrum

When we started working with agile techniques we had a divergent mindset in our product teams. Only one team was ready and willing to start with Scrum straight away. Other teams were reluctant to try anything agile and stayed with “Nothing” or were led by project management.

By now all our teams are somewhere in the “soft agile transition from nowhere to Scrum” and I’m happy that all of them have passed step “(1) Daily communication” already.

The above described Kaizen was my fundamental line of action to move step by step from (0) to (5).

What are your experiences with introducing agile techniques to your company?

from nowhere to scrum via kanban and scrumban

Characteristics of the “soft agile transition from nowhere to Scrum”

(0) Nothing
– Black Box
– Led by Project Management

(1) Daily communication
– Daily Scrum

(2) Visual Workflow
– Daily Scrum
– Team board
– Regular Retrospectives

(3) Kanban
– Daily Scrum
– Team board
– Regular Retrospectives
– WIP
– Lead Time
– Optimize size of batches

(4) Scrumban
– Daily Scrum
– Team board
– Regular Retrospectives
– WIP
– Lead Time
– Optimize size of batches
– Agile Estimation
– Regular Review Meetings
– Release Plan via Lead Time

(5) Scrum
Do it without ScrumButs

Agile Coaching, Good Question!

NOT done!

One of the principles behind the Agile Manifesto is maximizing the amount of work NOT done! If you really manage to do it, it is very liberating. It actually sounds very easy but is really hard to get it started and keep it going.

tasks-not-done

In meetings I again and again find myself trapped in the role of a project manager: Collect as many assigned ToDos as possible, be happy if you leave the meeting with a long list of ToDos and if you have produced MORE work (mostly for others…).

Thinking a lot about the Agile Manifesto and the Lean Disciplines I started to measure the success of a planning or status meeting in a different way now:

  • How many cards with User Stories or tasks have been ripped into pieces at the end of the meeting?
  • How many items of the backlog have been deleted (b/c “not relevant anymore”, “nice to have and will never have time for that”, “what was this about anyway”)?
  • How many minutes could we end the meeting earlier by stopping useless discussions and meanigless monologues?
  • How many tasks or tickets that have not been changed in your issue tracking system since 60 days (or longer) can we delete? (If the task or ticket is really important it will pop up again via a new task or ticket anyway.)
  • How many tasks or tickets of your team that are not completly clear have we bounced to the person responsible (most probably your product owner or project manager)?

This list is to be continued…

Agile Coaching, Books

Really listening

At the moment I’m reading “Agile Coaching” from Rachel Davies & Liz Sedley.

It strikes me, how much of the things they describe as the basics I’ve naturally done in the last years. Nevertheless one of the most important, easiest but also hardest things is to really listen to & to really pay attention to your colleagues when they are talking to you.

A lot of colleagues visit me in my office these days. It’s ok that most of them ignore that I’m either actually working on something or am just about to leave for a meeting; they simply jump in…
For a couple of days I find myself restarting in those situations:
I’m listening to what my colleague has to say, I’m trying to be open and relaxed, I allow silence in the conversation and try to pay my complete attention to the colleague.

We all know it’s important. It sounds easy. But it’s hard.