– Agile --

Retrospectives-- in ten slides --

CC-By-3.0@itstechupnorth

Robert Burrell Donkin

– with --

Retrospectives

Developers

for

by

Substancefollows

Form

appoint a

timebox

Read more http://tinyurl.com/64mohre

CC-By-3.0@itstechupnorth

Robert Burrell Donkin

– Agile --

Retrospectives-- in ten slides –

----

Thanks-- for listening --

– Agile --

Retrospectives-- in ten slides --

CC-By-3.0@itstechupnorth

Robert Burrell Donkin

Briefly introduces retrospectives in an agile context.

The style is an experimental blend of drawing and text. Judge for yourself whether this is a hit or miss...

First presented as a Lightning Talk at Agile Yorkshire http://www.agileyorkshire.org in 2011.

Some more on retrospectives http://tinyurl.com/64mohre

Original http://tinyurl.com/5wfs8yy

LicenseRobert Burrell Donkin http://robertburrelldonkin.name created “Agile Retrospectives in Ten Slides” in 2011.This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

Do, reflect, repeat is the classic cyclic rhythm of iterative development. Iterative methods are powered by frequent application of this positive feedback loop.

Millions of words must have been invested by agilists in the do. A rich palette of tools and techniques are now well known, and ready to be applied.

By contrast, reflection has been relatively neglected. But it is a mistake to expect that without effective reflection, simply doing iterations will continuously improve performance.

It is now, I think, widely appreciated that investments in learning tools and techniques for doing development are repaid quickly by reducing bugs and increasing productivity. It's time to start investing in tools and techniques for reflection.

– with --

Retrospectives

Retrospectives are a tool often adopted by agilists to aid reflection. These meetings reflect on the last iteration aiming to improve team performance for the next.

By contrast, review meetings (advocated by more traditional styles) look back to establish what happened and why, perhaps aiming to prevent future negative outcomes.

Iterative methods rely on a positive feedback loop, and so forward looking, positive retrospectives fit better than negative, backward looking review styles.

Developers

Modern tools automate the mechanical side of the development process: issues trackers record task execution; version control track contributions; code is exercised and assessed at build time; continuous integration servers collect, collate and correlate metrics. Agile methods are customer focussed, and work intimately linked to immediate user need.

So, modern tools and agile methods negate the need to meet to establish the process aspect of what and why. This allows an increased focus on human aspects. These are a strength for retrospectives, and is another reason why they are a good fit for agile development.

Retrospectives arise from a tradition which emphases the importance of the human side of team performance. Developers have feelings too. It's time to stop pretending they don't, and time to start talking.

for

by

The class post-mortem review meeting begins with a senior manager deciding that something must be done and ends with eliminated esprit de corps and reinforced failure. The easiest way to destroy the future effectiveness of reflective meetings is to use them to play the blame game.

A retrospective is by the team and for the team. The form and duration should aim to maximise the benefit to the team. Like any Agile tool or technique, the team should aim to continuously improve retrospectives. Expect the form and content to evolve over time. Keep retrospectives fresh by mixing in training and coaching, and by experimenting with new forms and elements.

Substancefollows

Form

The form taken by a retrospective should be flexible, and should follow from the expected substance. Think about the aims of the retrospective, and consider expectations. Then choose an appropriate form.

I find stand up retrospectives are surprisingly successful, especially when learning, building teams, or using short iterations. When time is short, or when the project is progressing well, I find it better to use this form than to skip the retrospective.

When the content is expected to be more substantial (for example, at the end of long sprint), prepare a more structure form. Use physical exercises to gather data, generate insights and move forward. But prepare to be flexible, and adapt the form to the emergent substance.

Regardless of form, a minimal lightweight structure helps a meeting to flow and the team to focus. A good patten is that the facilitator to start the retrospective by setting the stage, establishing the tone and engaging the team; to stand back (metaphorically and physically) and observe, measuring interventions carefully; and to close the meeting at the end of the timebox, bringing everyone together to create a clear collective memory.

appoint a

Separation of concerns is a tactic that should be familiar to developers. Facilitation separates process from content concerns.

The facilitator is responsible for process aspects of the meeting – time keeping, flow, balance and tone, for example. The participants are collectively responsible for creating the substantive content. By stepping back from the group and maintaining a neutral position, direct control is traded for thinking time and psychological distance.

A key retrospection anti-pattern is facilitator

participation. Discipline is essential. When the team is so small that everyone needs to participate, use a different technique.

timebox

The team should be intensely engaged with the retrospective. Clock watching breaks collective concentration. The facilitator should be charged with keeping the meeting to time.

Timeboxing is a planning technique popular with Agilists. Timeboxing fixes duration and quality but allows scope to vary. Retrospectives are an excellent match for this technique. The participants typically agree the timeboxes but leave the implementation to the faciliator – allowing them free to focus on activities and exercises.

A faciliatator should begin by setting the scene – establishing the tone, breaking the ice and encouraging everyone to speak – and close the retrospective – reflect on the shared experience and reinforce lessons learned.

A key influence on the health of a retrospective is the environment - the space, ongoing physicality and the location chosen. And this is within the control of a facilitator. Consider location and choose appropriately. Prepare the space carefully. Step in quickly to remove physical impediments.

Observe team physicality during the meeting. Watch for signs of engagement and disengagement; energy and fatigue; cliques and bonding.

Read more http://tinyurl.com/64mohre

CC-By-3.0@itstechupnorth

Robert Burrell Donkin

– Agile --

Retrospectives-- in ten slides –

----

Thanks-- for listening --

And thanks for reading these notes.

Remember that retrospectives should be fun :-)