Rose, thorn, bud is a simple tool for reflection for yourself or your team. The basic idea is to look back at a recent project or how things are going and consider each aspect of a rose:

Rose: what are the successes? What's gone well?

Thorn: what are the challenges? What could we do better?

Bud: what are opportunities with potential? What could we explore or try?

If running as a team retro activity or retrospective, you might spend a few minutes individually adding thoughts for each prompt, then talk through each of the thoughts in Rose, Thorn and Bud.

A separate but no less important step is often to capture actions from the reflection—what you'll do as a result. If you're conducting retros regularly, consider revisiting actions from previous sessions.

I like "rose, thorn, bud" as it's beautiful to consider that a rose contains such different facets, like so many things.

I've come across many retro and reflection activities that are variations of these three prompts: "What went well?", "What didn't go well?" and "What else?" A few to mention:

The sailboat retro: Goal/vision, Rocks, Wind, Anchor — a nice feature for a team is that this activity places you all in the same boat

Strengths, Weaknesses, Opportunities, Threats (SWOT)

A reader suggested a fourth aspect of the rose analogy to reflect on as its leaves or roots: what are the unnoticed or behind-the-scenes things that contribute to the rose's success?

I've come to consider that it doesn't matter too much what activity you choose to get a discussion going. What matters most is regular reflection, hearing all the voices in a team, and making progress together. One teammate ran an excellent retro by us all finishing early and heading to the pub.

I didn't intend it, but some of the products and prints for rose, thorn, bud out to be some of the nicest I have.

Also see: Information radiator, MoSCoW prioritisation, RACI, How to peel a Post-it so it doesn't fall down, the upward spiral

Rose, Thorn, Bud

The frog boil metaphor illustrates how it's easy to miss small changes that build up over time until it's too late. The scenario, as told, is that of a poor frog who would leap away from hot water but, if put into cooler water that is gradually warmed, won't respond in time to getting boiled.

As a metaphor, it describes a powerful and pernicious shortcoming in how we perceive the world. A student kitchen that gets messy mug-by-mug, a business with gradually slowing sales, software that builds up with tech debt, a river that is slowly polluted, a road that gets busier each day, a bay that sees fewer fish each year, content that drifts, cancer that slowly spreads, a story or behaviour that becomes normal, a website that gets slower feature-by-feature, or a climate that slowly warms are all cases where we may not be happy where we end up, but we didn't notice how we got there.

It's hard to respond to gradual change, especially when it spans generations. Jared Diamond called it out as a potential fate of the Easter Islanders and how they could have cut down the last tree. One barnacle is nothing, but many barnacles can cause significant headaches for big ships.

Fortunately, there's a flip side. Many, many things are getting better without us realising. Small positive changes, such as in attitudes, education, or healthcare, add up over time—the Destiny Instinct can mislead us. Fast and slow layers make a system, like a forest, more robust. Getting one percent better each day leads to a 37x improvement in a year. And enough molehills can make a mountain.

What a frog does, in this case, is not, apparently, true—don't try it—it's much better as a metaphor, not an experiment.

The frog boil metaphor

The bus factor is how exposed you are if key people, perhaps with critical knowledge or skills, were hit by a bus.

Examples might include the only people able to keep a company running, restore a server from a backup, or someone who held the only key to unlock crypto assets of its customers. As a result, many places are set up with, or required to have by investors or insurers, some redundancy — say two experienced developers with knowledge of how a service works — to minimise the risk of a tragic accident also being a severe problem for a company or its customers.

As a metaphor, the bus factor may be helpful to consider without the need for people to actually be hit by a bus. It may be worth thinking through how you might operate if someone was late, missed their flight, was ill on the day, or simply quit. In operational roles, this will often lead to a minimum of two people for each key position if nothing else to allow one to take a break from time to time.

An alternative framing, with fewer fatalities, is 'what if we all won the lottery?' and so decided to go do something else.

Bus factor

Just as mistakes and the unexpected are part of life, bugs are part of software development. In general, the longer the time between when a bug was first introduced and when the bug is identified and fixed the more expensive it is in both time and money.

If you spot a bug as you're writing a new feature everything is fresh in your mind and it can sometimes take just a moment to fix.

If a bug turns up later or perhaps soon after it's deployed you might have an idea of where it might be and track it down fairly quickly.

If a lot of time has passed since a feature was worked on and a bug is spotted or tackled then it might take a fair bit of time to figure out how everything works again before you can fix it.

And if a really long time has passed then, aside from the cost of interrupting what you are otherwise working on, it may not even be clear what was intended by the original code, probably written by others, and there's a fair chance more has been built on top of the buggy code making it more complex and a bigger task to tackle. The only way to solve it may be stepping through and figuring out behaviour slowly and steadily line-by-line.

You could probably replace 'bugs' with 'code' 'problems' or 'mistakes' in most scenarios.

Aside from it matching my experience, Joel Spolsky gives a nice explanation in his classic article The Joel Test.

The cost of fixing bugs

The chaos monkey is a smart piece of software and a brilliant idea from engineers at Netflix.

The chaos monkey deliberately switches off servers in live environments at random. It takes the pain of disappearing servers and brings that pain forward. By deliberately sabotaging their own systems it created strong alignment for the team to design-in redundancy and automation for the necessary resiliency and reliability in the face of random failures. Training for this randomness helps make stronger, more resilient and fault-tolerant systems and software and keeps your movie streaming so you can keep chilling without interruptions.

The chaos monkey is a great metaphor and trigger to actively work on what life could throw at your system before it happens.

More monkey inspiration for writing and for bananas.

Chaos monkey

Yak shaving describes how when setting out to do something, you found you had to first do something else, which needed you to finish this other thing, and so on until you found yourself shaving a yak, or equally unrelated activity, to do the first thing you set out to do.

It's pretty frequent in life — tidying your room? — and particularly resonates in software development, where when tackling one thing, you often find yourself fixing something else, which needs you to fix something else, and so on. Here's the ever brilliant xkcd on fixing problems.

Yak shaving features, lovingly polished, in my book Big Ideas Little Pictures.

Here's a brilliant 40s clip of Hal changing a lightbulb from Malcolm in the Middle, classic yak shaving

Early yak shaving features in the song There's a Hole in My Bucket in which fixing a bucket requires straw, which requires a knife to cut it, but the knife needs sharpening, which needs a stone, which is too dry and needs wetting with water, which needs fetching...with a bucket

The first I found of yak shaving was a short article on productivity in the first issue of Make magazine by Danny O'Brien and Merlin Mann.

Yak in the style of Alison Green and Adam Stower's excellent children's book, What can you Stack on the Back of a Yak?

Yak shaving

Rubberducking is a problem-solving technique where you explain your code or task to a rubber duck—or any inanimate object—and discover the solution yourself through the act of explaining. It's brilliant because it works and is effectively free.

Rubberducking, or rubber ducking, is most commonly associated with debugging in software development but can be applied to any problem-solving process.

The name comes from the book The Pragmatic Programmer by Andrew Hunt and David Thomas. In it, the authors suggest using a rubber duck as a conversation partner to clarify one’s thoughts. This is an accessible and effective way to troubleshoot problems without requiring someone else’s time.

Have you ever been called over to someone’s desk to help them solve a problem, and as they explain the problem to you or demonstrate it, they figure out the answer themselves? It happens all the time to me, particularly when someone's showing me how something doesn't work, and it magically works just by having me watch over their shoulder.

The rubber duck technique is as simple as that, except that instead of calling someone over, you can simply replace the person with a rubber duck, teddy bear or heck, even your stapler.

The psychology behind rubberducking relies on how explaining a problem forces you to process your thoughts more clearly, often revealing gaps or errors in your understanding. Here’s how you can try it yourself:

1. Set up your “duck”: Place a rubber duck, teddy bear, or any object on your desk.

2. Explain your problem: Describe your code, logic, or issue to the duck, step by step, as if you’re teaching it.

3. Watch for insights: In explaining it aloud, you’ll often uncover what’s wrong or identify a new approach to solving it.

For example, a developer struggling with a bug might explain every line of code to the duck. Verbalising their logic can highlight an overlooked detail that resolves the problem.

Rubberducking works because it forces you to articulate your thoughts clearly, moving them from abstract notions in your head to concrete statements. This shift can:

• Help you identify assumptions you didn’t realise you were making.

• Mimic the process of pair programming without needing another person.

Rubberducking a problem also reduces dependency on others for problem-solving, making it a cost-effective—basically free!—and time-efficient tool for debugging.

Here are some situations where it’s particularly useful:

• Debugging code: Talk through an error or bug in your program.

• Explaining logic: Test the clarity of your solution by explaining it step by step.

• Learning new concepts: Summarise a concept to the duck to check your understanding (see the Feynman Learning Technique)

• Decision-making: Walk through the pros and cons of a decision.

In software development, rubber duck debugging has become a recognised term for this process. It’s so common that some developers keep an actual rubber duck on their desks to symbolise this practice. Teams might 'joke' about needing “a duck” for the simplest bugs.

Debugging is an integral part of coding, and the rubber duck technique makes it less daunting. By verbalising your thought process, you streamline problem-solving without needing external help.

Frequently Asked Questions about Rubberducking

Nope. While a rubber duck is the classic choice, you can use anything nearby—your coffee cup, a stapler, or even a photo on your desk.

Q: What if talking out loud isn’t possible?

Writing out your explanation or saying it in your head can work just as well. The key is clarifying and articulating your thought process.

Q: How is this different from pair programming?

Pair programming involves working alongside another person on the same task. Some people swear by pair programming, and to be honest, I've always found it effective whenever I try it. However, rubberducking is a solo activity where the act of explanation itself is the solution.

Next time you're stuck on something, grab a rubber duck and give it a try.

Rubberducking is similar to the empty chair technique for psychotherapy, which involves speaking to an empty chair as if addressing a person.

It's also easily confused with "rubbernecking," which is slowing down to look at an accident as you drive past—a common cause of traffic jams.

What is Rubberducking? An Explanation of the Rubber Duck Debugging Technique

Smaller software releases generally means fewer bugs, and bugs that are easier to fix. The number of bugs created typically increases with the complexity of interactions of code, which in turn increases with the size of release. This means that a number of smaller releases can hopefully get you to a large change in a safer way with less bugs, and less problematic bugs, created along the way than a single release with the whole lot. There’s probably a somewhat more general relationship with amount of unexpected problems created and the size of any change.

Bugs and releases

I love this diagram by Henrik Kniberg for determining what to release to your customers and when.

The idea is that a standard approach of having your grand plan of what you think people want at the start and then working on each bit at a time until finally, after months of work, you have something that works is not so smart. Each piece, in the car example, doesn’t help the customer at all until it’s all put together.

Instead, you can focus on providing the next piece of functionality that helps someone get their job done a little better than before. In the beginning, they’ll probably have to put up with a lot if they want to use it, but with each successive release, they find they can get their job done a little better than before and get value out of what you’re building. A side-effect is the feedback you get along the way will likely help you learn and build something that is better than what you had in mind at the beginning, and all along the way, the customer had some value instead of waiting for months.

Providing usable functionality at every step is not always easy, and it requires rework as you move from one step to the other. But it’s generally a price worth paying to give your customers value sooner and start learning as soon as you can.

This diagram is explained in the brilliant product management book User Story Mapping by Jeff Patton.

A release strategy for happier customers, sooner

Shares information passively, with the neat effect that having a good one in an office can go a long way to getting people on the same page without explicitly calling meetings or sending out updates to do so. Handy to also have a good space in front of it for talking, discussing and generally collaborating. A common term in agile development, originally I believe from Alistair Cockburn of Thoughtworks. To quote from his article, of many possible:

- Is large and easily visible to the casual, interested observer
- Is understood at a glance
- Changes periodically, so that it is worth visiting
- Is easily kept up to date”

Information radiator

I learned about this nice principle from agile software development. Basically, that when thinking about how much you’ll get done next week, what you got done this week is a good proxy. Sure this week was different because you had that external presentation and an offsite, a bug to fix on live and Amy was sick. But the reality is things will interrupt you next week too. Just like the weather, what happened before is a good first guess at what will happen next.

Development sketches