Of all the “agile” practices, Retrospectives are the only one I advise ALL teams should be doing regularly. Why? It’s the most effective way to figure out what works best for your team and to ensure you’re continually evolving and improving the way you work.

I love them so much I built the Agile Retrospective Wiki! Still going strong with thousands of visitors from across the globe every week 😊 (link in the comments 👇)

However, too often, retros aren’t much more than “improvement theatre” Chris Parsons (edit) – transactional, energy draining and nothing changes as a result of them.

Anyway, here’s my guide 👀

📚 Facilitation is a skill

Ensuring meetings are not being driven by whoever shouts the loudest, or ending up as a long ineffectual debate takes thought and practice.

Facilitation is an art. The first three chapters of Derby and Larson’s book, “Agile Retrospectives: Making Good Teams Great,” is a must read IMO.


🔄 Rotate the facilitator

It’s common to be one person’s role to lead retros. This is the best way to make sure they stagnate! It prevents teams from feeling engaged and empowered to solve their own problems, and risks bias to one persons’ agenda. Whilst it may be one role’s job to make sure they happen, that doesn’t mean they have to run them all.

Get everyone to take turns facilitating.


✅ Achievable actions, clear ownership and tracking

Common failings 😥
– Not taking any actions
– Taking on too many actions
– Actions that are too big or vague
– Not following up on actions

Do this instead 😃
– Make actions small and precise (see SMART)
– Ensure actions have owners
– Track the actions just like any other work (e.g. on your work tracking tool).
– At the start of the next retrospective, review outstanding actions


🖖 Embrace “The Prime Directive”

You don’t have to remind people at the start of every retro, but this has to be front of mind, to set the right tone:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
–Norm Kerth, Project Retrospectives: A Handbook for Team Review


🎲 Mix it up! Try different retrospective plans

Doing the “Start, stop, continue” retro every time? 🥱 Try something different! The Agile Retrospective Wiki is full of different plans you can try (other sources are available!)

If you’re an early stage startup thinking you need to hire a CTO, what you probably really need is a “Founding Engineer”*. Startups have a tendency to over-inflate titles. While a fancy title might seem appealing, it’s important to prioritise the actual needs and growth stage of your startup.

What’s the Difference? 🔍

– Founding Engineer: A dynamic, hands-on developer, driving your product development, adept at turning ideas into tangible, market-ready realities and shipping at pace.
– CTO: A strategic executive-level role. Aligns technology with business goals, demonstrates commercial acumen, brings extensive leadership experience, and shapes key strategic decisions to enable sustained growth.

Why Start with a Founding Engineer? 🏗

– Immediate Needs: Early-stage startups need to focus on product development.
– Budget-Friendly: You typically cannot afford, or justify an experienced full-time CTO (consider a part-time or fractional CTO instead 😉)
– Flexibility: Calling someone a CTO when that’s not really what they are could cause problems down the line (e.g. when you do actually want to hire a proper CTO).

What to Look for in a Founding Engineer 👀

– Full Stack Expertise: Versatile in both front-end and back-end development, capable of handling a broad range of technical tasks.
– Experience: They’re seasoned, they’ve walked the walk. They have a proven track record (e.g. as a senior or lead developer)
– Adaptability and Problem-Solving: Comfortable with ambiguity, able to adapt to change quickly.
– Strong Communication Skills: Effective in articulating technical concepts and collaborating with both technical and non-technical team members.
– Entrepreneurial Mindset: A self-starter with a strong sense of ownership, driven to build and innovate in a startup environment.
– Cultural Fit and Resilience: Aligned with the startup’s values and culture, and resilient under the high-pressure, fast-paced startup conditions.
-Growth potential: Many Founding Engineers can (with the right support) evolve into CTOs as the startup matures and the need for strategic tech leadership increases.