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

Good Question!, Scrum

Scrum of Scrum introduced. Yes!

It’s great to witness how a company changes from somewhat “old school-ish” to something agile-like: Last week we finally started with a Scrum of Scrum and it turns out to be working pretty well only after a few days.

Actually most of our teams have been working with some kind of agile process for some time now: some are doing Scrum, some Scrumban, most are doing Kanban (although predominantely it’s more a visualized work-flow than “real” Kanban). All of them were having a Daily Stand-Up (or Daily Scrum) right from the beginning: some were having theirs in the morning, others before lunch and others after lunch.

I visited several Daily Stand-Up every day and experienced what happens to issues or tasks depending on other teams. Either a team member was planning to talk to the other team (and most often forgot about it right after the meeting: Damn short term memory…) or the issue was bounced via a project manager like myself (who most often missed the crucial part. Sorry…) or the team just simply complained about the fact that it had to wait for another team (but was not doing anything against it). In the end the tasks normally moved to the “pending” column and stayed there for much too long.

Funny enough we actually were doing a kind of Scrum od Scrum since about a year: It was the earliest meeting of the day with all Tech Leads dealing with only one question: Are you about to put something in another team’s way today? It is only natural that the info that was given in this meeting was not up to date anymore (as the last Daily Stand-Up of the teams were at least over 16 hours away).

Introducing a Scrum of Scrum does not only optimze communication but also enables fast and direct communication. We now have a synchronisation of all teams within 30 minutes: First all Daily Stand-Ups of the teams, then the Scrum of Scrum meeting.

All dependencies or impediments between teams are solved or at least communicated within 30 minutes. There is no failing because of short term memory, project manager etc. (see above).

Must read: Advice on Conducting the Scrum of Scrums Meeting from Mike Cohn

BTW: Our UXD are having a UX Scrum of Scrum at the same time. It seems to be working fine. We are still working to get our Product Owner to have their Product Owner Daily Scrum…

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…