The Retrospective of Retrospectives

16 set 2009 | Cultura Ágil

Feedback is one of the XP values and key mechanism for all the agile methodologies. For example, Scrum teams religiously have Retrospective at the end of each iteration. This enables the team to reflect and adapt, improving the process for the next iteration. Agile Teams learn from their successes and failures. Retrospectives provide an effective way to incorporate feedback into the project.

But what about large Agile teams? Once again I will use my current large Agile program as a case study:

Lately I have been working on a large Agile program. With the large Agile program, comes common large team challenges, and the need to adapt the Agile development and management practices to better suit the large team challenges.

Currently the program has around 180 people distributed over 12 teams. Typically, each team is formed by 15 people (project manager, business analyst, quality assurance and developers; for short: PM, BAs, QAs and Devs). All teams in the program are following Agile practices, such as 2 week Iterations, Daily Scrums and End of Iteration retrospectives.

The teams were getting good value out of the Retrospective Agile practice. But the improvements were done in a team level. And the overall program was losing focus on continuous improvement. At times, the action point from one team’s retrospective was dependent on other teams. Other times, two team retrospective action points were contradictory.

Another challenge was that the program level management was not able to attend every team retrospective. There were 15 retrospectives happening at the end of each Iteration, The program manager (and other people) would like to attend each team retrospective; but it was just not possible to be at several meeting at the same time.

Retrospective of Retrospectives

Similarly to how the daily scrum is extended to the Scrum of Scrums for large Agile teams, I came up with the idea of having a Retrospective of Retrospectives for large Agile teams.

The Retrospective of Retrospectives (RoR for short) meeting is held after each individual team retrospective. The participants (representatives of all team and the program) meet to discuss what went well and what to improve in the program level. The RoR focus is on improving the overall program output, and not on individual team performance.

 

RoR format

Data gathering: The top 5 items from each team retrospective is the start point for discussions and possible program action items.

Participants: Similarly to the Scrum of Scrums, all managers participate in this meeting. The attendance of another representative of each team is recommended; and it is encouraged to be in a rotation basis.

Context: The context for the RoR is slightly different than the context for individual team retrospectives. While the context for a end or iteration retrospective might be: what can we do to improve next iteration for our team, The RoR context is: What can we do as one team (the whole program team) to improve the overall output for the program.

Mechanics: Each team retrospective top items are read. Repetitions and alike items are grouped together. Then the items go for voting. (for example 3 votes per participant).

RoR top benefits

Below are the top benefits I noticed from the RoR.

Quick access to all teams – all managers and stake holders have visibility on the top items for each individual team. And all is available in only one meeting.

Focus on improvement – for both the individual teams and the program level. One common problem on large agile projects is that one loses focus on the overall program by constantly focusing on local improvements. It is like being around the trees and lose sight of the forest.

Common goal – All managers (and the selected team members) are periodically talking and acting on the overall goal of the program. The RoR participants carry the common goal message (and action points) back to their teams.

Everyone is heard– Any local team problem will be heard by all the teams. Even if something is specific for a team, the message (team retrospective item) will be heard by all teams.

Paulo Caroli

Paulo Caroli é o autor do livro best-seller "Lean Inception: Como Alinhar Pessoas e Construir o Produto Certo" (o primeiro em uma série de livros sobre Estratégia e Entrega Lean). Ele também é o criador do FunRetrospectives.com , site e livro sobre retrospectivas, futurospectives e actividades de team building. Caroli escreve neste blog com frequência. Receba a próxima postagem em seu e-mail. Inscreva-se aqui.
A crise vai passar

A crise vai passar

Esta crise, como todas as anteriores, vai passar. As pessoas colaboradoras da Caroli.org vão apoiar a comunidade nesse momento. Confira neste conteúdo a iniciativa “Participe agora, pague depois” e avise aquela colega que vai se beneficiar disso.

ler mais
Crie a Visão de Troca de Valor

Crie a Visão de Troca de Valor

A Visão de Troca de Valor permite o claro entendimento de quem são os principais atores com quem a empresa e seu produto se relacionam, o que cada ator recebe, ou deveria receber, e entrega, ou deveria entregar, de seu produto. Veja neste artigo mais detalhes sobre o assunto, exemplos e como construir a Visão de Troca de Valor.

ler mais
Medir a produtividade em equipes de software vai além de olhar apenas o volume de código produzido: você precisa do Coeficiente de Produtividade

Medir a produtividade em equipes de software vai além de olhar apenas o volume de código produzido: você precisa do Coeficiente de Produtividade

Neste artigo, o autor Alberto Silveira usa uma simples metáfora de restaurante para ajudar os leitores a entender que, ao construir software, cada unidade de trabalho é importante e essencial. Entre os temas abordados com a analogia, estão: como as equipes de alto desempenho medem a eficácia, a importância de uma perspectiva mais humana, o desafio de satisfazer o cliente e muito mais.

ler mais

Pin It on Pinterest