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.

I was reminded of this after our panel talk @ hashtag#dtxmcr23 yesterday, when someone spoke to me afterwards who’s accountable for the digital workplace strategy at his org.

The great thing about paper, pens, spreadsheets and WhatsApp groups is they’re ultra flexible and the technology works for /you/.

If you have a broken process, invariably, adding more technology makes the situation /worse/. Why? Because you’ve now sealed the process in concrete and making changes is 10x harder (and more expensive). Your users are now beholden to the technology. You’ve probably not made their lives better, or their work more efficient.

Where do you start? I fell in love with Service Design (see comments for Wikipedia link), after seeing folks like Katherine Wastell, Kathryn Grace and Elisse Jones use it at the Co-op. Start by mapping your end to end process – people, systems, tools, workspace – and identify the pain points.

When you do this, more often than not, you find technology is /not/ the answer to the biggest problems.

And if you do choose to add new tech into the mix, you’re doing so with a much better understand of why and what problem it’s going to solve.

To me, that’s the heart of Digital Transformation.

In Agile circles we talk a lot about autonomy, and good teams being autonomous. However, there’s a common misconception. No team is ever fully autonomous. No team lives in a vacuum.

Autonomy needs boundaries to be effective.

Look at a top-flight football team, where high performance is essential. They need to be empowered to self-organise, so they can adapt to what the opposition is doing.

But their autonomy has clear boundaries – how many players you can have on the pitch, the playing area and many other rules. Without them it would be more like the Royal Shrovetide Football game, an early form of football dating back to the 12th century which is basically just a massive fight (the main rule is, somewhat bluntly, no killing).

A team is an example of a complex adaptive system. Every successful complex adaptive system is bound by rules, even in nature. A flock of birds works on 3 simple rules, allowing them to self-organise, avoid crashing into each other and leading to mesmerising patterns like murmurations of starlings.

To enable autonomy, it’s important for teams to have clarity about what they’re responsible for and the boundaries around what they can make decisions on.

Defining boundaries is a delicate act. Overly rigid and you can inadvertently limit the very autonomy you aim to foster. Too much leeway can lead to misalignment and inefficiencies. The goal is to offer enough structure, while preserving the space for creativity.

Like a conductor with an orchestra 🎻: set the tempo 🎵, but let the musicians shine ✨

Your proposition might be bleeding edge, your tech doesn’t need to be. Go with well-known, battle-tested technology.

Both start-ups and established orgs frequently fall into the trap of chasing the latest trends and opting for cutting-edge technology. More often than not, they later find themselves burdened with complex stacks that are not fit for purpose and hard to maintain.

Here’s the thing: unless you’re operating at a mega scale or working in a very specific niche, you can accomplish nearly everything you need with tech that’s been popular for decades. The benefit? They’re well-known, well-supported, and it’s easier to find engineers who are familiar with them.

🚨 The Trade-off Trap 🪤
When assessing new tech, many developers overlook the trade-offs. They get caught up in the allure of the problems the new tech will solve, without understanding the new ones it might introduce.

🚨 The Re-write Trap 🕸️
When the opportunity to re-write something arises, the temptation to choose shiny new tech is strong. However, more often than not, the tech stack wasn’t the core issue. The main reasons are typically out of support frameworks and languages, and an architecture and codebase that have become too complex to maintain. By opting for unfamiliar tech, you risk complicating your re-write even further. 🚧

Common examples 🔍
– Choosing NoSQL databases over traditional relational databases
– Overcommitting to a microservices architecture
– Going all-in with a serverless architecture like AWS Lambda
– Opting for GraphQL over more traditional REST-like APIs
– Dare I even begin when it comes to front end web frameworks 🥺

While all these choices have their merits, they are best suited for specific use cases and you need to know what they are.

Innovation 💡 in your product or service is where your focus should be, not in the technology that supports it. By choosing reliable, common technology, orgs can avoid unnecessary complexity, freeing up more time and resources for what really matters: solving real-world problems and growing their business.

It may seem paradoxical, but you often get more done by doing less, better.

Delivery slow 🐢? Expectations and deadlines regularly being missed 📅? All too often it’s because teams are just trying to do too much at the same time.

Think of a congested motorway, frequently caused by nothing more than too many vehicles trying to go too fast. Smart motorways solve this by reducing the speed limit, meaning everyone gets where they’re going more quickly.

Larger organisations trying to do too much can be very inefficient, further exacerbated by dependencies between teams and complex org structures creating competing initiatives, akin to a city gridlocked at rush hour.

Why better as well as less? You didn’t plan for misunderstanding requirements, didn’t plan for code becoming more complex and harder to change, didn’t plan to fail QA, didn’t plan for it to break something in production.

These are all things more likely to happen when you’re juggling too much work at the same time (and they all slow you down), but won’t necessarily improve by just doing less. If you’ve been working this way, bad practices are probably baked in culturally.

📉 Doing less 📉

⚠️ Reduce and limit the amount of work in progress at any one time (see WIP limits)
🔪 Break work down into the smallest possible deliverables
✅ Focus on getting things done before picking up new work

🌟 Doing less, better 🌟

🎯 Ruthless prioritisation to ensure you’re always focusing on the work that will have the most impact
🤝 Make sure outcomes and requirements are clear and agreed before you start new work
👩‍👩‍👦‍👦 Take collective ownership and work as a team rather than passing tasks between silo’s
🔧 For engineers, focus on writing maintainable and well unit tested code, so it’s easy to change and reduces the likelihood of introducing bugs.

What practices have you found help create better focus, streamline delivery and get more done as a consequence?

There is no existential threat from Artificial Intelligence any time soon, despite what the headlines might have you believe, so I’m going to try and explain why.

Why are we hearing so much about it then? Fear, uncertainty, and doubt (FUD) make for great headlines, sell papers, and generate advertising revenue on podcasts. However, if you dig a little deeper, the substance beneath is considerably less sensational.

Understanding the current state of AI

AI as we know it today predominantly falls under what’s known as Machine Learning (ML). There are other concepts in use, but the vast majority – including those using Large Language Models (LLMs) like ChatGPT and MidJourney – are based on ML principles.

ML is learning in the very loosest sense. It’s intelligence in the very loosest sense.

Machine Training would, be a more accurate description. Algorithms are fed data, evaluated on their outputs, adjusted, and then fed more data until their results improve. This iterative process eventually creates models capable of some very impressive tasks. But they’re not ‘learning’ in the way we think of a child or a baby chimp discovering the world. They’re not generating new, novel insights or demonstrating any form of consciousness or understanding.

Artificial General Intelligence (AGI) is no more than theory

ML isn’t remotely close to the kind of intelligence that could theoretically pose an existential threat to humanity. The fundamentals of ML have been around for at least 40 years and it’s taken us that long to get to a point where it has genuine, widespread practical applications.

As for AGI, there are currently no accepted theories for how it could even be achieved. There are plenty of ideas, but they remain hypothetical. Could machines become genuinely intelligent? Possibly. But no one knows for sure.

Predictions of when the “Singularity” (the point at which artificial intelligence surpasses human intelligence) will arrive, are thus pure conjecture.

Ignore the FUD and focus on the real issues of AI

While ML-based AI is undeniably changing our lives, it is doing so in the same way computers have been since the invention of the pocket calculator. There are tasks at which computers already outperform us, like processing large amounts of data and performing complex calculations, but for the vast majority of what we consider to be human intelligence, they’re still light years away.

We’re no closer to a Terminator-style “Judgement Day” than when Alan Turing first started kicking around the idea of AI in the mid 20th Century.

That’s not to say AI doesn’t present us with challenges. Job displacement, privacy concerns, potential misuse, and inherent biases are real and pressing issues we need to address. We’d be better off focusing on these tangible problems rather than worrying about hypothetical existential threats posed by AGI. Let’s redirect our energy to making sure that our use of AI is responsible, ethical, and beneficial for all.

I grow more convinced each day that one of our biggest battles, in our organisations and even society as a whole, is with Confirmation Bias.

Confirmation Bias is when we unconsciously look for, interpret, and remember information that backs up our own beliefs or values, and downplay information that doesn’t.

It’s all around us and has likely grown worse with the rise of social media. We create “filter bubbles” by following only what we like, and recommendation algorithms make this even easier to do.

Recent events like Covid, Brexit, and even Twitter’s rate limiting over the last few days, show how people selectively use information to back our view.

This also happens at work, especially in “them and us” cultures between teams. A common example I see is between commercial and development teams:

Development says, “Commercial sell new features without asking, make unreasonable demands, and don’t care about tech.”

Commercial says, “Development take too long, only care about the tech stuff and don’t care about the business being successful.”

In both cases, we tend to amplify the information that backs our view and ignore what doesn’t. This makes our biases stronger and the “them and us” gap bigger, which hurts open communication and cooperation (let alone being an unpleasant working environment).

So, what can we do?

First, have some humility. Realise that YOU are just as likely to be vulnerable to Confirmation Bias as anyone else. We like to think we’re more self-deterministic than others. We’re not. Get over it!

Second, show some empathy. Put yourself in the other person’s shoes. Engage positively and with an open mind. It’s amazing how many times I’ve had an “Ah ha” moment, and even apologised for how I acted when I better understood their view point. Crucially, this also builds trust, which is vital in being able to work together to solve problems.

Lastly, burst your filter bubbles. Follow and read viewpoints you disagree with as well as ones you do. Be careful about opinions that don’t have evidence to back them up. And check that the evidence is reliable.

Challenging our biases can be tough, but it’s worth it. By doing so, we build stronger connections, foster better communication, and create more collaborative environments. And who knows, we might even change our minds along the way!

I think it was Jamie Arnold who first introduced me to this phrase.

In engineering teams it’s – sadly – still all too common that Quality Assurance (QA) is the last step in the delivery process. Developers code, then throw it over the wall to QAs to test. Teams working this way typically have a high rate of failure and large release bottlenecks – features and releases pile up, waiting on the QAs. Developers pick up more new work whilst they’re waiting. Bugs come back and developers are now juggling bug fixes and new work.

It’s slow, inefficient and costly!

What I dislike the most is the cultural aspect – the implication that quality is the responsibility of QAs, not the developers who wrote the code.

Quality is a team sport. The most valuable role for QAs* is to ensure quality is baked into the entire end-to-end delivery process. This has become known as “shift-left” – QAs moving away from spending all their time at the end of the delivery lifecycle and focusing more on how we can “build quality in” throughout.

What does this look like in practice?

– QAs involved in requirements gathering and definition, making sure requirements are clear, well understood and we’ve considered how we’re going to test it (inc. automated tests).

– QAs ensure we’re following our agreed Software Delivery Lifecycle (SDLC) and the steps and control we have in place to ensure quality is front of mind.

– QAs collaborate with developers to write automated tests, developers collaborate with QAs on mutation testing, compatability testing, performance testing.

– If there’s any manual testing required, /everyone gets involved/. QAs make sure everyone in the team is capable of doing it.

It’s a much richer role for QAs, and far better for everyone!

This is something I said in a talk on high performing teams recently that resonated with a few folks.

In my experience the most effective teams are small, between 3-5 members, and the most effective organisations are the ones that manage to stay small overall.

Why might this be? Fewer people streamlines communication: a 3-member team has 3 channels, a 5-member one has 10. It rises exponentially with every person you add.

In small teams, alignment is more organic. Greater shared understanding fosters greater autonomy and more informed decision making.

“Better” is not just about technical expertise. Behaviours are just as important, if not more so (teamwork, communication, adaptability and so on).

In a high performing team, the whole is greater than the sum of its parts.

With an underperforming team adding more people will most likely slow things down (it may not look like at first because everyone is “busy”, but it will).

How can you stay small? Do less, better.