Big & Micro Retrospectives

Diego Pacheco
6 min readSep 5, 2020


I’m doing retrospectives for more than 10 years. I saw it all, the good, the bad, and the ugly. Retrospectives are fundamental and instrumental part of Agile. Even if you are not doing Agile or is not agile-ish in our way of work I would 100% you need o to have some form of retrospective. Retrospectives are an important mechanism to introduce improvements. Pretty much all companies spend lots of time in planings sessions. Long planing sessions are pretty normal(4h or more). However long retrospectives are not popular at all. It’s possible to work without classical retrospectives however you would need some form of Reflection and Guilds/Chapters might be a place to have retrospectives. IMHO Retrospectives is something you want to do without mercy(Maybe I’m watching too much Cobra Kai). Meaning you should do lots of retrospectives. Retrospectives have different flavors and styles however I believe there are 2 important ones: Big & Micro. Retrospectives help to change the status quo and shape the culture. Retrospectives can be hard. Specially on the beginning. IMHO Retrospectives are like going to the GYN, you might not like to get in but you will love it when you get it out(finished the workout). Let’s understand why retrospectives are hard.

Scrum and Culture

Scrum shapes for Long planing and small retrospectives(15min to 1h). However, what happens is retros become a compliance thing. Often people do not challenge things and they often do not tackle hard and complex problems. I would say 100% you want to have longer retros and small plantings. We live in a Feature Factory world where features are the only thing that matters.

However, having a SOLID Foundation which is called STABLE SYSTEM in Lean teams is important to have better productivity and Scale and still operate with Fast innovation pace. Facebook at the beginning had the motto: “Move fast and break things”. Because in the beginning, you cannot move fast if you dont break things. Them later on Facebook change his motto to: “Move Fast with Stable infra”. Mark said that the principle did not change. It’s the sample principle. Which is fascinating. Meaning, When you dont have a scale you need to break things when you have a scale in order to move fast you need to do the things in s STABLE way which has 100% synergy with Lean for instance.

Which leads to the heart of the question. How do we know what is the right thing? We have diversity, people think differently, so how we take the best from everybody and reflect upon what we did to do it better? How do we review our systems, practices, culture, and improve? I would say retrospectives are fundamental for that.

Retrospective Alternatives

You don’t need to do retrospectives. However, you need some embedded mechanism to handle discussions and improvements. IMHO the best practices to tackle that are Chapters/Guilds however even with them I would still do retrospectives. Why? Everybody is busy, we are always dealing with tons of issues, incidents, being paged, attending meetings, getting things done. Often we dont have time to STOP and have human conversations about everything thats going on.

It’s possible to book meetings and always be discussion things and do improvements. However often we are very reactive when we just operate on that why. Doing formal big and long retrospectives allow you to be proactive and improve things before problems become a big deal.

The Case of Big Retrospectives

I’m all about Big and Long Retrospectives often taking from at least 8h and maximum 12h. I have to say I did retrospectives bigger than 12h. It’s very easy to have +8h retrospective if you think about 3 simple dimensions: People, Process, and Product. People dimensions you want have sort of 360 feedback where everybody gives feedback to everybody, this makes the team stronger and re-enforces relationships. For the Process dimension, you want to review how you are working if you are missing anything or also what’s not working well. Finally, there is the product dimension where you want to improve your product, your software. Having Deep and Long conversations with your team is priceless.

How we can do that in 15min or 1h? It’s very hard. What happens is lots of “blind spots” and we end up losing some many good opportunities to improve. Often people have “resistance” too long retrospectives because is hard to book 8h in someone’s calendar. However, that can be done by getting ahead and booking retros beforehand and maybe 1 month early. Are you too busy to listen and improve?

Often people are afraid of retrospectives. They are afraid of what people might say. But think about this, let it sync for a minute. If that’s the case I 100% believe we have bigger issues, are we addressing these issues or just pretending they are not there. Some problems need to be addressed in 101s, not in retros. Especially problems that are very personal or not related to the team. There are some tricks about Big Retros such as:

* Do it 1 time per month or every 2 months — so they are affordable. (1 per month is ideal).

* Set up ground rules, Team agreements, and rules (such as turn on your video).

* Talk about them in 101s to make sure people always open in retros. (this is a good extra).

* Experiment before judging. It’s easy to say 8h is crazy :-)

The Case for Micro Retrospectives

So you also can combine Big Retros with small retros. Micro-retrospectives are 5–10minutes retrospectives you introduce at the end of everything. Every meeting, every planing, every 101. They allow you to look for “signals” which you might elaborate further down on 101s or in Big Retros. Micro-retrospectives cannot focus on the action because you dont have time to deeply discuss the problems and agree on actions. However, they are a good mechanism to collect feedback. It’s very appealing to do micro-retrospectives and skip big ones, I would say you want to combine both but not skip the big ones.

Experiments: This is the way

The number 1 thing you want to avoid in Big Retros is to not have actions. It’s 100% important to have actions. If you dont do actions retros are just “complaining sessions”. Feedback is critical to improvement in people, processes, and product dimensions. However, sometimes is hard to get people to change without experimenting with things. The Agile(Also Mandalorian way) is to run experiments. So run some experiments, try 2–3 times before making your mind one way or another.

Experiments are great ways to learn and to try things and they decide if they work if they don’t work. Teams should run multiple experiments, Agile Coachs / Engineering Managers (Coach Engineers is the term I like to use :-) ) should use experiments as the number 1 tool to drive change.

So go run your experiments, have fun, and grow with your team.

Originally published at on September 5, 2020.



Diego Pacheco

Brazilian, Software Architect, SWE(Java, Scala, Rust, Go) SOA & DevOps expert, Author. Working with EKS/K8S. (Opinions on my own)