Books, Good Question!, Meeting Facilitation, Scrum, Scrumban

Check-In Activity for Agile Retrospectives

Fortunately retrospectives are already a standard at our company now. Not only our developers teams, but also our sales team, our team assistents and as of late also our management (surprisingly, the last.. :)) have regular retrospectives. Because it has become standard to have retrospectives there is also the chance of falling into a dull routine, both for the team members and the facilitator (mostly myself). To counteract this dull routine we try to do different activities. I tried the following Check-In activity in the last weeks:

Esther Derby and Diana Larsen suggest in their book “Agile Retrospectives” as a Check-In activity to ask every participant “In one or two words: What are your hopes or wishes for this retrospective”. No post-its, no explanation, just one or two words. This always works great.

This question inspired me to ask participants an even more general question as a Check-In excercise: “Why are we doing retrospectives anyway?” I do this as a kind of fast brainstorming and jot everything down on a flipchart. It is surprising what the participants are coming up with. I heard everything from “I don’t know.” (Oops!) and “Because you told us to.” (Ooooooops!) to “Kaizen. Continuous Improvement.” (Thx.) and “We don’t want to do mistakes a second time.” (!!!)

It is also a good excercise to remind the participants of the principles of the agile manifest, one of them is: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” (Dare to ask if everyone knows and understands the Agile Manifesto… and maybe be surprised.)

And, of course, it is a good excercise to jolt the participants from their retrospective routine.

BTW: I recognized only days ago that Esther Derby and Diana Larsen book “Agile Retrospectives: Making Good Teams Great” is legally available also as eBook! Buy it!

Good Question!, Meeting Facilitation

How to Deal with Results from an Agile Retrospective?

Have you ever heard a team complaining about results of a retrospective not being realized? I have. And it’s important to change something immediately after hearing it.
Realizing the agreed improvments from the retrospective is one of the agile principles of the Agile Manifesto:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (http://agilemanifesto.org/principles.html)
So if you are earnestly doing an agile “Inspect & Adapt” and do not realize the agreed improvements of a retrospective, you are missing the whole point and are doing a simple “Inspect”.

The answers to the following questions could help to make sure improvements are realized:

  • Who is responsible to realize the improvement?
  • How can you be sure that the improvements are not forgotten?
  • How are your improvements logged?

Who is responsible to realize the improvement?
Always agree in the retrospective who will be responsible for putting the improvement into effect. This can one or two persons. Write their names next to the agreed improvement. Do not assign the responsibility to the whole team as nobody will feel responsible then.
Problems that the team can’t solve themselves are impediment and  it’s then the Scrum Master’s job to push it up to the management: fast and direct. And it’s the Scrum Master’s job to get on the management’s nerves until the impediment is solved.


visualize improvements from retrospective
How can you be sure that the improvements are not forgotten?
Visualize the results of the retrospective. What seems to be working very well with us is to put a copy of the agreed improvements on the team’s board: Everyone sees it everyday at the Daily Stand-Up. Alternatively: Improvements turn to User Stories that are done within the next (!) sprint. Here it’s the Scum Master’s job to make sure this happens.

How are your improvements logged?
With “logged” I mean the structure of your agreed improvement in the retrospective:
1) Write whole sentences and not bullet points. This may take a little longer, but you (and everyone else) will understand them also after a few days.

2) As mentioned: Assign one or two responsible persons for the improvement.

3) Agree on a deadline when the improvement should be put into effect (or at least agree on a date when the team gets feedback on the status of the improvement)

Related post:
3 Retrospectives in 2 Days

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…