Agile Manifesto: The Complete Guide

0. About my agile journey

Hi, I'm Arthur von Kriegenbergh.

(And I'm the founder of the Workshop Wednesday)

In 2006 I was struggling big time with my bachelor IT studies. It felt as if I needed to jump through hoops.

One of the biggest issues I had, was with the amount of mandatory planning we had to do before actually being allowed to DO the work.

We had to make big Gantt-charts and plan every single detail. At least the ones we could think of at the moment.

There was a huge amount of assumptions in the planning, given the fact that we never did any of the work before.

And then I learned about working agile.

And it worked from day one!

Today, I have helped more than 20 organisations and 60 teams to apply an agile way of working:

Needless to say, when it comes to working agile, I feel confident what I’m talking about.

And in today’s guide I’m going to show you everything I’ve learned.

Consider this your agile tutorial.

1. The Agile Manifesto fundamentals

In this chapter we’re going to cover the basics of the agile manifesto.

(Including why it works and why it’s still important in 2023)

78% of organisations believe agile working will benefit them. However, only 44% of organisations are applying agile successfully.

I’ll show you how agile has helped countless businesses grow by leaps and bounds.

What is agile?

Agile is a set of values and principles. It's documented in the Agile Manifesto.

This set of beliefs helps teams to make better decisions, and by that create better solutions for customer's problems.

The simple definition of agile is step-by-step. Take something big, and break the most urgent thing into smaller pieces. By taking small steps you can see clearly if you're doing the right thing. If not, you can adjust course.

The hard thing about values and principles is they aren't as visible as tools and processes. This is why you see many companies make the same mistake:

They copy processes and tools they have seen from other companies, but fail to do the hard work in helping people understand the principles and values.

I'll deep dive on that more in the next chapters.

First, let's have a look at agile's origins.

How was the Agile Manifesto created?

The Agile Manifesto was made early 2001. A group of 17 people met in Snowbird, Utah, to discuss the future of software development. The Agile Alliance (as they called themselves) had a shared frustration about the status quo, but all had their own view on how to resolve this.

Their frustration:

Companies were excessively focussed on planning and documenting their software. Because of that, the companies forgot what really was important. Helping their customers.

(Exactly! Identical to mine during my studies.)

The companies had defined nice company values as "quality" and "impact", but in reality they were organised in a way that was preventing them from helping their customers early and often. The Agile Alliance wanted to change that.

They all had a background in software development (Scrum, XP, Kanban, RUP) and years of experience. The trip to Snowbird was their chance to create a shared vision on how to break the status quo.

They created the Agile Manifesto in a weekend. A short and to the point document with four values and twelve principles, that since then has changed the way we do business.

It has made many startups rapidly successful. Because of that, many traditional teams and organisations are embracing the agile way of working.

But the problem is, that you can't simply copy and paste values from one organisation to the other. Not without doing the hard work.

The Agile Manifesto authors

The authors of the agile manifesto are:

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler

• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick

• Robert C. Martin
• Steve Mellor
• Ken Schwaber
  
• Jeff Sutherland
• Dave Thomas

You might be wondering:

So what's so special about these agile values and principles? And how can I make them work for me?

That's what I'm going to cover in the rest of the guide.

Keep reading...

2. The four Agile Values

In this chapter I’m going to show you exactly how to build the foundation of strong and autonomous teams using the agile values right now (in 2020).

In fact:

These are the same exact values that I used to grow more than 100+ teams.

Let’s do this!

------

When it comes to agile, one of two things can happen:

✅ Thing #1: You Do The Hard Work

Grow, with the people around you, resulting in happier customers and a far more successful company.

❌ Thing #2: You Copy An "Agile Model" From Somewhere Else

Watch people struggle and get frustrated faster than you can say "what happened?!".

It's like a relationship: You invest in each-other, because in the end you know it's worth it.

With that, these are the four agile values that are dividing the winners from the losing companies.

Ps. They are written in the form of "statement over statement". This means that while there is value on the right, there is more value in the statement on the left.

‍

1: Individuals & interactions over processes & tools

Agile value #1 is about people.

There is a clear shift in what people expect from companies nowadays. Both as a customer (where do I buy?) and employee (where do I want to work?).

Fact is, in the 90s options were limited. Because of that, companies had a position where they pushed their products and services. There was not so much to choose from.

At the same time the definition of succes for the majority of people was to make the most money as possible.

The companies were in control.

Nowadays, technology has made it far more easy to compare and switch companies.

The most recent great customer experience at company A, becomes the minimal standard for every other company.

Also, a whole new generation is almost representing 50% of the work-floor: The millennials.

Their definition of success: Do work that makes an impact.

They value mindset, more than degrees. Engagement, more than money. And work-life balance, more than company politics.

This is happening worldwide. It's the new standard.

That's why agile value #1 is the most important value of them all. Focus on people. Both inside (employees) and outside the company (audience).

Create an environment where it's easy for employees to communicate with customers, and each-other. Make sure the interactions are valuable. Focus on the interactions that are necessary right now.

All processes and tools should support the interactions people are having. If they get in the way, they should be reviewed. Are they applied correctly? Or are new ones necessary?

Now you're focussed on people, and their problems, it's time for agile value #2.

‍

2: Working software over comprehensive documentation

Agile value #2 is about s̶o̶f̶t̶w̶a̶r̶e̶ solutions.

As the agile manifesto was written by IT experts they chose for the word software in this value. But, agile has proven itself outside of IT settings long time:

• Banks,
• Healthcare,
• Media,
• Transport, and
• Schools

have all benefited from agile.

Focus on working solutions. This means something that actually solves a customer's problem.

Something they can use at the right moment. The moment they have the problem.

It is in our lizard-brain to be risk-averse. When faced with new or big challenges (like a project), we want to reduce risk at all cost. We don't like to be surprised.

We tend to overthink and document every possible scenario. Often this is done in the form of meetings.

You might know this as waterfall project management.

It's staggering to see how many projects today still fail because of this traditional approach.

Fact is, when starting something new, you simply cannot think of every possible scenario. The only way you will learn if what you're doing is the right thing, is by doing it.

And the only way to measure if you're doing the right thing, is to measure if you're actually helping the customer.

There are a lot of assumptions involved when creating new solutions, like products or services.

The winners of today are companies that have successful strategies to validate their assumptions.

They accept they don't know everything.

They build strategies and tactics that allow them to take action. They know the answer cannot be found in their documents.

But, they need to learn from their customers.

Is this actually helping solve a problem?

That's why there is agile value #3.

‍

3: Customer collaboration over contract negotiation

Agile value #3 is about feedback. Customer feedback.

Eight out of ten people is willing to pay more for a great customer experience.

If you want to build a perfect experience for your customers, you need conversations with them. Learn what their pains, needs and challenges are.

Only then, you can start validating if you're really providing value for them.

The companies that are winning today are great in creating this customer experience. They have excellent customer feedback loops.

And when they learn something is not working for their customers, they solve it.

Even traditional industries like banks, transport, insurance, and the medical industry are starting to realise this. They are changing their models from pushing products to actually listening to their customers.

Of course, there is value in contracts. But it should never get in the way of helping your customers.

And then it's just a small step to the last agile value.

‍

4: Responding to change over following a plan

Agile value #4 is about being flexible.

The world around us is rapidly changing. When looking at business, change can come in many forms:

• Market change. There is less demand for your solution when finished.
• New technology. It may be easier to do things than before.
• Competitors. A competitor beats you with a better solution.
• Regulations. You have to comply with new government ruling.
• Assumptions. Something turned out different than you expected.

An often used quote used in agile settings is:

In preparing for battle I have always found that plans are useless, but planning is indispensable.
- Dwight D. Eisenhower

That is what this agile value is all about.

When trying to climb a mountain for the first time, it's impossible to predict everything that you will find along the way. You simply cannot plan something you don't know.

And even if someone else tells you how their journey has been, it's impossible to prepare for every possible scenario.

This makes your planning indispensable. You need to bring the right equipment and inventory. Guess how long you expect this journey to be. Add extra time for unexpected things to happen.

Then, when something unexpected happens, you can manage. Getting lost. A wild animal attacking you. Snowstorms. You will manage.

And because you do that, you will succeed in reaching the top of the mountain.

Responding to change means having an open mindset.

Set a hypothesis. Accept things around you will change. Develop strategies and tactics to use this change in your advantage.

It's okay to find out that your original plan is not what you expected. Even better, when realising this it means you've learned something new since making the plan.

----

Those are the four agile values.

Hopefully you have a better idea what an agile mindset means.

But, the problem with values is they are open for interpretation.

That's why in the Agile Manifesto there are also twelve principles.

Here we go.

3. The twelve Agile Principles

Now it’s time to show you how to apply the agile principles to work smarter and more effective.

Specifically, I’m going to show you how to apply these principles to your day-to-day work.

These principles are specifically designed to help you create super valuable solutions that your customers will love.

So if you’re ready to build a HIGHLY effective team, this chapter is for you.

-----

So, the values are helping you make better decisions.

Consider the principles as your compass on your journey 🧭.

When you feel like agile isn't working for you, you're probably doing it wrong.

The principles will help you get back on track.

At the same time when reading the agile principles, you'll probably think by yourself: I'm already doing some of this...

That's great! It gives you a solid foundation to continue building on.

The principles are designed to focus on helping customers, and welcome change. They can be used to improve and reflect on your current way-of-working.

If you're not following a principle: Why? Is it on purpose? Or is there room for improvement?

We'll run by them one-by-one and look at real life examples.

‍

1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.

The first thing you'll notice is that the principles are more elaborate than the values.

So let's break them down into smaller pieces (pretty meta huh 😄).

There are four interesting parts to this principles:

1. Highest priority. When making decisions, are you always favouring the customer?
2. Satisfy the customer. What are your customer problems? How is your solution solving this?
3. Early and continuous delivery. Even if your solution isn't completely finished yet, it could already solve (parts of) your customer's problems. Are you making initial versions (often referred to as the Minimal Viable Product) available as soon as possible? Do you build new versions on top of that?
4. ‍Valuable solutions. Learn from your customer. Is your solution really as valuable as you thought it would be? Have conversations and look at the data.

The businesses who are winning have made an art of this principle.

Fact is, when building new solutions:

The longer you wait the higher the risk.‍

‍

2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

The definition of Agile is: the ability to move quickly and easily.

If you can respond directly to the latest changes, you can build better solutions as a result. When the market changes, or a new technology becomes available it would be stupid not to take advantage of it.

However, many projects today still fail because the original plan is being executed. Instead of new learning being applied. Because of that projects get bigger, and bigger. Eventually to even get canceled. Millions are wasted.

Being able to welcome change, forces you to build your solution in a way that it can be made available any time.

Let's have a look at that in agile principle #3.

‍

3: Deliver working solutions frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Deliver working solutions frequently.

To be able to apply this principle, you have to understand an important concept of agile:

Incremental.

An incremental process is one in which solutions are built and delivered in smaller parts. This is opposed to delivering everything at the same time (a.k.a. Big Bang-delivery). Each small part, or increment, is a working part of the total solution.

The increment may be either small or large, but there's a preference for smaller increments. Because the sooner you can make those available, the faster you can learn. Which will help you get a higher return on investment.

A great example is this one of creating a painting:

You can compare working incremental to building a wall. Each increment will add bricks to it, and after lots of increments you have a big wall.

This concept is almost alway combined with another important agile concept:

Iterative.

When working iterative you are looking for cost-effective ways to test if you're doing the right thing.

Often times a simple sketch of the solution is the easiest way to do this. Making a sketch will force you to make the idea in your head more concrete, by putting it on paper.

This is a cheap solution and will help in testing if it's worth actually building. Customers can look at it, and you can learn from their feedback.

As you have probably noticed by now, is that when you get better at this agile principle (deliver frequently), it will force you to do principles #1 and #2 better as well.

That's the beauty of the principles. By focussing on and improving one principle, you will get better in other areas as well.

That being said, let's move to #4.

‍

4: Business people and developers must work
together daily throughout the project.

This one sounds like a no-brainer, right?

However, fact is many organisations are setup in a way that creates expertise silo's. Especially bigger organisations.

People with the same expertise are put together in departments.

But to get work done for their customers they need to work together with different departments. This creates all kind of dependencies.

And because all these departments have their own priorities, there is a LOT of waste within these organisations. Organisational waste can be disguised in many forms:

• Waiting time. A team has to wait on stakeholders before being able to move forward.
• Non-utilised talent. People's talents, skills and knowledge are fully used, because they only know part of the problem.
• Handovers. 50% of knowledge gets lost in handovers.

These all result in longer waiting time before the customer is able to actually use final products or services.

That's why in agile you have small cross-functional teams. They have end-to-end responsibility over solving the customer's problems.

Also, help them set up for success with agile principle #5.

‍

5: Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.

In his book Drive - The surprising truth about what motivates us, Daniel Pink talks about intrinsic motivation, rewards and punishments.

When it comes to creative work, carrots and sticks lead to poor performance:

• More carrots (aka higher rewards) won't lead to better creative work.
• More sticks (aka punishments) won't lead to better results.

What drives employees is:

• Autonomy. The freedom to self-direct own decisions.
• Mastery. The possibility to get better at stuff.
• Purpose. The feeling that their work matters.

By giving this kind of environment, and supporting the team when they need help, the team will be more successful.

I'll give you some insights on how to get started with creating this environment in the next chapter.

First, let's dive into the next principle.

‍

6: The most efficient and effective method of
conveying information to and within a development team is face-to-face conversation.

This principle is about preferring conversations over the written word.

There is a lot of chance of ambiguity when reading text someone else has written.

Think about the email threads going on-and-on. Presentations that are 200 pages (with 100+ words on every page). Slack messages that go back-and-forth. A text message that's written in a way that you're not sure what it means.

Text can be confusing, especially when it comes to discussing big projects.

When working face-to-face, it's easier to align. It's easier to notice if someone doesn't fully understand what you're saying.

It also makes it easier to make things visual, and get a shared understanding of what you're talking about.

Side note: Since 2019 video is getting huge. You can have real-time (Skype, Google Hangouts, Zoom) and on-demand (Loom, Screenflow) video conversations with the simple push of a button.

People are becoming more and more comfortable with recording videos.

These can be a great addition to this agile principle. But remember Agile Value #1: Individuals and Interactions over Processes and Tools. If technology doesn't work, people get frustrated quickly. So make sure when using video that it's a smooth experience.

‍

7: Working solutions are the primary measure of progress.

"Measurement is fabulous. Unless you're busy measuring what's easy to measure as opposed to what's important."
- Seth Godin

Vanity metrics are ones that look great on paper, but can be the reason why your company is failing.

Examples of vanity metrics are things like number of likes, NPS, and story points burned.

They are easily gamed and manipulated.

They do not necessarily correlate to the numbers that really matter: engagement of your customers, the cost of getting new customers, and ultimately revenues and profits.

The North Star Metric (NSM) is a powerful concept that has emerged in recent years from Silicon Valley companies with breakout growth. It helps teams move beyond vanity metrics to instead focus on generating long-term retained customer growth.

The North Star Metric the core value that your product delivers to customers. Optimising your efforts to grow this metric is key to driving sustainable growth across your full customer base.

Examples of North Star Metrics:

• Airbnb: Nights booked. This captures value delivered to both guests and hosts.
• Spotify: Songs listened. Spotify is able to create a profile around the songs users listen to, and give better recommendations. Artists earn compensation when their songs are played.

Try capturing the value you deliver to your customers and capture it in a single North Star Metric. There may be more than one metric that works, but try to boil it down to a single NSM.

‍

8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

One weird contradiction in agile is the use of the word Sprint.

Businesses are in this for the long run. Instant success is an illusion.

However, in agile a Sprint defines a time-boxed period where an agile teams works to complete a set amount of work.

Of course, to sprint also means to run at full speed over a short distance.

That can be confusing, especially in an era where one out of eight people has signs of burn-out.

Agile promotes working on a sustainable pace.

Making your business successful is a marathon. It's not something that will happen overnight.

That's why you need to be able to keep doing what you're doing, to build lasting and continuous long-term success.

‍

9: Continuous attention to technical excellence and good design enhances agility.

In traditional projects, all of the hard thinking is expected to be done in the initial stages.

This means you have to try and cover every possible scenario, without knowing for sure if it's actually going to work.

There are huge risks in this old way of thinking. We already covered one in Agile Value #2 (you can't know everything when climbing a mountain for the first time).

Another one is that of accountability.

Handovers are really common in these failing projects.

• Who's responsible for fixing issues after a handover?
• And what if the responsible person is working on another project at the time person B finds out? What's more important?

Next to that, this agile principle is about craftsmanship.

When you know you have to maintain a solution you have build, you'll make sure that it will be easy to maintain.

‍

10: Simplicity--the art of maximising the amount of work not done--is essential.

The most successful solutions are super simple to use.

• With a tap on a button you can order a taxi at your doorstep
• You can hold your phone against a terminal to pay your groceries

But the thing people forget:

Simple IS NOT EASY.

Actually, making something simple for customers to use turns out to be very hard.

And you can also look at this principle from a team perspective. Teams who can focus, and drive goals to success one-by-one will be five times more successful.

‍

11: The best architectures, requirements, and designs emerge from self-organising teams.

A self-organising team doesn't need to wait on others to help their customers.

It has the mandate to decide on what's best for the customers interest.

Because of that, it is super effective and can solve complex problems.

It can work around or solve boundaries that are slowing them down from getting there.

There is high alignment, and high autonomy in the team.

In bigger organisations this is the number one challenge when moving to an agile organisational model.

In a hieratic model there is low autonomy. Usually a manager tells a team what to do.

(And this manager is being told what to do by her manager.)

This is a problem, because most of the times the team has the most knowledge on how to solve  problems. Not the manager.

In an agile, self-organising team there is no traditional manager. It is replaced by someone who guards the vision and goals of the team, but doesn't tell them how to achieve it.

‍

12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

In the Manifesto, they've saved the best for last.

The twelfth and final principle is my personal favourite.

It's all about the power of the Compound Effect (book by Darren Hardy).

If you can improve one small thing every week, then over time you'll achieve amazing results.

Which would you choose? €3 million in cash right now, or a magic penny that doubles in value for the next 31 days?

Spoiler alert: After 30 days, the magic penny is worth already €5,7 million.

Seemingly small improvements applied over time can have huge results.

For agile teams this this compound effect is achieved with Retrospective meetings.

In it's most simple form your team answers this questions in a Retrospective:

• What have we improved since meeting last time?
• What good things should we keep doing, or do more of?
• What can we improve?
• How can solve our number one frustration this week?

The rhythm of doing this every week will surface existing problems in the team and organisation. By solving a small problem every week, over time the team will become hyper-effective.

Great agile teams will be able to identify problems and next steps within a 10 to 60 minute time-box.

Agile is one step at a time.

And that's the whole Agile Manifesto. Four values and twelve principles.

It's a lot to grasp at one time, right?

And that's okay. It's perfectly normal to revisit this guide when you need it.

(I even do it myself. I simply can't recite every principle by head.)

It's why agile enthousiasts are talking about going on an agile journey.

The next chapter will help you get a flying start on that journey.

Because it takes practice.

Remember Daniel-san in the movie Karate Kid? (No? Go watch it on Netflix!)

It illustrates the concept of learning something new, with the Japanse concept Shu-Ha-Ri:

• Shu - Follow the rule: In the beginning of the movie Karate Kid learns the basic martial arts principles by cleaning cars. Wax in, wax out. 🚗
• Ha - Break the rule: In the middle of the movie he has figured out how catch a fly with chop-sticks. 🥢
• Ri - Be the rule: At the end all odds are against Karate Kid (as in any good movie!). However, with what he has learned, he is able to come up with a new karate move. He wins! 🏆

It will be the same on your agile journey.

Find great examples, mentors, books, videos, and podcasts.

Follow their lead to learn the rules, before you start breaking them.

In the next chapter I will help you with a head start in that journey.

4. How to start working agile

Now it’s time for me to show you how to start working agile.

This will help your team achieve twice the work in half the time.

In fact, agile teams release more often to their customers, are delivering more valuable output, become more predictable, and are more engaged.

(Which all result in a stronger and more valuable business)

Let’s get right into it.

What is the best agile way of working?

The world of agile is confusing.

Today, there are many agile frameworks and agile methodologies out there. All claiming to be the best way to work agile.

However, the fact is there is NO one way of agile working.

The Agile Manifesto was created as a set of best practices, a common ground between the things that were working well for all 17 authors.

But in 2001 the Agile Alliance already all had their own take on this (Scrum, Kanban, XP, DSDM, Pragmatic Programming).

They were surprised themselves that they came up with a mutual manifesto.

In 2020 it's even worse, with agile scaling models like:

• Nexus
• SAFE
• Less
• Scrum at Scale
• "Spotify model"

It's a lot!

So, how do you start?

Doing agile versus being agile

Remember chapter #1: Being agile is a mindset.

It helps you to deliver more value to your customers.

A customer doesn't care how your organisational model looks like. Or how long it takes you to bring something to market.

She cares about the experience of being helped with her problems.

So, if you are just copy/pasting how other companies are doing it, you're doing it wrong.

Doing Daily Standups and keeping a backlog in JIRA because you see other people do it. That's simply jumping through hoops again.

Becoming agile requires change and patience. It takes time to understand WHY things work.

Make it clear for everyone why you want to start with agile, and invest time in learning the basics of agile project management.

But remember: Think big and start small.

We're going to start with agile principle #12: Reflect and adjust.

This can be a small tweak to the things you are already doing. But, it can have a great effect.

You're going to facilitate a meeting!

The problem with meetings

I hear you thinking: What's his great solution for starting with working agile?

A meeting!?

Hear me out.

I've been in horrible meetings.

The most horrible ones were in a building where the meeting rooms were in the middle of building. The meeting rooms were closed with sliding doors, without any glass in it.

We had no daylight. No fresh air. All lights were dimmed. The beamer on.

With 20 people we were looking how one (1!) person was updating tickets in JIRA.

On top of that: We did this every day.

If you ever find yourself in a meeting like this: Leave!

Make use of the The Law of Two Feet:

If you find yourself in a situation where you are not learning nor contributing, it is your responsibility to use your two feet and go someplace else.

There are many problems with meetings:

1. People come unprepared.
2. Meetings take way longer than needed.
3. Meetings have a lack of focus.
4. Meetings start late.
5. You can't get work done between all meetings.
6. One person hijacks the meeting and keeps talking the whole time.

If you recognise some (or all) of the above:

It's time to break the status quo! 👊

Meetings executed the right way are the fuel for making your team successful. 🚀

A successful meeting:

• is well prepared,
• has a clear goal,
• a structure to achieve that goal,
• starts and ends on (or before) agreed times,
• allows everyone in the room to contribute,
• and is facilitated effectively.

The meeting you are going to facilitate in agile terms is called the Retrospective.

It is a recurring weekly event, in which you discuss:

• What have we improved since last week?
• What went well this?
• What one thing do we need to improve?

By doing this on a weekly basis, you create accountability, focus and the compound effect of improvement.

To guide you through your first Perfect Retrospective, I've made a step-by-step guide for you.

Let's get started!

The Best Online Retrospective for beginners (video)

For this retro you need a maximum of 60 minutes.

This forces you to focus only on the most urgent issue in your team.

(Remember the compound effect. By solving one issue per week, you will make your team hyper-productive in the long run.)

I'll give you an overview of the how to do the retro in this video:

Share the agenda

You want to help your team come prepared to the meeting. Give them a heads-up at least a week before:

Hi team!

I have noticed [reason you want to do the retrospective].

I came across this meeting format on how we can improve as a team: Best online retrospective for beginners

I would like propose a four-week experiment. Every week we follow this agenda:

1. Set the stage. Why are we doing this meeting? When is it successful? What did we accomplish since last meeting?
2. Gather data. What's working well for us? What stopping us or slowing us down?
3. Generate insights. What patterns do we see? How can we improve?
4. Decide what to do. What's one thing we can do this week to improve?
5. Close the retro. How can we make our next meeting better?

The meeting is time-boxed to a maximum of 60 minutes. (Usually, after a couple of times we need less than 60 minutes.)

Looking forward to it!
[Your name]

Working together alone

The most horrible thing that can happen when you need creativity from a group of people, is when the HiPPO takes over. 🦛

HiPPO stands for Highest Paid Person's Opinion.

Don't get me wrong, there are a few scenario's where it's simply necessary for a boss to TELL her team what to do.

A Retrospective is not that place. (Remember agile principle #5: Autonomy is a major driver for employees)

It's your job as a facilitator to help the team find better ways of working together.

The best way to get results fast in a group setting, is to work together alone. Let me explain in this video:

So, set a timer for every activity!

If you give people one minute to do a task, they will use only that minute.

When you give ten minutes for the same task, our brains are wired to make use of the full ten minutes. (And often times a couple minutes extra. It's called Parkinson's Law.)

So for each exercise of the five stages in the Perfect Retrospective agenda, follow the same steps:

1. Note

Give people some breathing time to think for themselves what they think about what's asked from them.

Ask them to write every thought on separate sticky notes (this way you can later cluster the team's ideas).

2. Share

Everyone puts their post-its on the wall. Cluster all similar post-its, so you can easily spot overlapping and competing ideas.

Important: You are not the one who's making the clusters. Let people make clusters themselves. This forces people to read each-others post-its. (No one likes wrong cluster, right?)

If necessary, ask clarifying questions if post-its are unclear. Make sure the group doesn't go into discussion modus yet!

3. Vote

Everyone gets one vote. They can use it to vote on the post-it that should be the winner.

That doesn't mean that the other post-its are "losers". It just means that there is going to be one thing you focus on right now. The others become maybe-laters. (It's also possible they get solved by focussing on the winner)

Everyone can vote on any post-it, even their own.

To prevent people from influencing the rest. Ask the team to wait putting their vote on the sticky, until after you have counted down.

3-2-1, vote!

4. Decide

Pick the winner. In a Retrospective setting this is the one with the most votes.

Then move on to the next agenda item, and repeat this structure.

Now that we're on the topic of the agenda, let's deep dive into that!

The Perfect Retrospective Agenda

The fun thing with retro's is that the activities can change every time.

At the same time, that's also the challenging part.

You have to make sure that the activities you do in a retro are aligned with the goal you want to achieve.

So that's why for this retrospective I've made the agenda for you.

You can copy the Google Slides presentation here.

The goal of this retrospective is to uncover:

• what's working well in your team,
• and what needs to be improved.

This way your team can get used to the rhythm of the weekly meeting.

It creates accountability.

So, if you notice what you agreed on in the retrospective is not followed up on, then you've uncovered a bigger problem in your team.

(If that's the case, let me know and I'll help you out.)

Let's have a look at the complete agenda:

1. Set the stage - Positive & True

❓Why: Create a positive vibe and give everyone an opportunity to speak.
⏰ 5 minutes

Get everyone in the right mood.

Make sure everyone understands why you are doing this meeting in the first place.

2. Gather data - Learning Matrix

❓Why: Gather topics to talk about and appreciation.
⏰ 15 minutes

Get clear what’s working well, where to improve and show appreciation for each-other.

3. Generate insights - Lean Coffee

❓Why: Have a focused discussion of the top topics
⏰ 15 minutes

Find out where there are patterns and overlap in the data you just gathered. Why are certain things happening?

Describe the future state, so that you can backtrace the steps needed to get there.

4. Decide what to do - Worked Well, Do Differently

❓Why: Keep track of suggested action items
⏰ 15 minutes

The Perfect Retrospective has at least one action item. Make sure there is buy-in, and that it is something you can really act upon.

You've spent time to uncover what the root issue is. Now it's time to focus again. Come up with an actionable item.

You cannot solve everything at once. So focus on one thing you can do this week.

Otherwise you've wasted an hour of everyone's time.

5. Close the retro - AHA

❓Why: Discuss lessons learned and return on time invested
⏰ 5 minutes

Check if there's real buy-in for the action item. Also, see how you can improve the next Retro.

Creates some breathing space and lets people reflect on the past hour.

Why agile retrospectives are helpful

OK so those are the 5 steps to follow for your first retrospective.

Within 60 minutes you can get your team super-aligned on how to improve one small thing every week.

And, even better: Once you get the hang of it, you will need less time.

The most important thing to do now is to be consistent. For the next four weeks, make sure that you do the retrospective every week.

What you will notice is that it will not be easy.

Making the time to improve every week will be difficult at times when you feel overwhelmed.

Especially then, you should take the time to make smarter decisions.

Doing this will help you:

• Improve accountability. Once committed, people want to live up to their word.
• Higher engagement. You will learn new ways to better communicate in meetings. There will be no time to doze off.
• Increase appreciation. The safe environment of the retro gives a space to acknowledge each-others accomplishments.

After four weeks, you will have created a lasting compound effect of improvements.

You should now have a solid foundation to take the next step in your agile journey!

5. BONUS: Advanced Agile

Here’s a quick list of advanced agile tips and tactics that I’ve picked up over the years.

The 1-Workshop Workweek

Agile can work great if your team is not in the same physical location.

Better yet, when done right, working agile and remote can increase your productivity.

But where to start?

The 1-Workshop Workweek is an agile framework that helps your team work together asynchronous-first:

✅ Fewer and better meetings.

✅ More time for getting things done.

✅ Work anywhere you want.

✅ Work when you are most productive.

Have a look at my 4-week bootcamp if you want to master agile with your team.

Design Sprints: Innovate and solve complex problems in a week

When starting long-term projects with your team, you're usually up for challenging situations:

• The stakes are high. You're facing a big problem and solving it requires a lot of time and money.
• You don't have enough time. You're up against a deadline, and need good solutions, fast.
• You're just plain stuck. It has been difficult to get the project off the ground.

The best way for agile teams to start a new project is with the Design Sprint.

(Don't to be confused with a Scrum Sprint)

A Design Sprint is kind of like a recipe from a great chef for that three star Bouillabaisse with crab and poached lobster.

Following the recipe, you go through a four-day process. That way you solve complex problems with your team through prototyping and interviewing real customers.

Following step-by-step instructions you get from abstract problem to concrete solutions. At the end of the week you will exactly know what to do next.

After facilitating more than 30 Design Sprints, I can safely say this is THE best way for agile teams to start new projects.

Go ahead, if you want a detailed overview of Design Sprints.

Case study: One year of agile working at a digital product agency

In 2015 I started working at a digital product agency. We did strategical, design and product development work for companies like Red Cross, BMW and NU.nl (biggest news website in The Netherlands).

When I joined the company, they had grown to 20 employees in four years time. For a start-up this is usually a phase were the "old rules" don't work that well anymore.

Before, with 8 people, it was easy to know who was working on what every time. But the bigger the company, the harder that becomes.

It was time for the next step.

You can find a detailed, step-by-step overview in the case study: One year of agile teams.

It covers the problems we were running in to and agile practices we used to solve those problems.

Twelve things successful agile teams do

1. Don't copy/paste agile tools
2. Create a common goal
3. Have small cross-functional teams
4. Think big, start small
5. Work with fast feedback loops
6. When in doubt, decide
7. Create a network of teams
8. Be strict on time-boxing
9. Reflect every week
10. Test before building
11. Build on other methods
12. Optimise for flow

6. Conclusion

I hope you enjoyed this guide to the agile manifesto in 2023.

I know, it's a lot!

Like I said before, that's perfectly normal.

Now I’d like to hear from you: What has helped you most from today's guide?

What are you going to try first thing tomorrow? Or what's stopping you from taking action?

Let me know by leaving a quick comment via mail right now.

‍