The Agile Agency

How Lean and Agile Will Transform Your

Creative Agency

Bart Vermijlen
This book is for sale at http://leanpub.com/theagileagency

This version was published on 2013-12-09

This is a Leanpub book. Leanpub empowers authors and

publishers with the Lean Publishing process. Lean
Publishing is the act of publishing an in-progress ebook
using lightweight tools and many iterations to get reader
feedback, pivot until you have the right book and build
traction once you do.

©2013 Bart Vermijlen

Tweet This Book!
Please help Bart Vermijlen by spreading the word about
this book on Twitter!
The suggested hashtag for this book is #theagileagency.
Find out what other people are saying about the book by
clicking on this link to search for this hashtag on Twitter:
https://twitter.com/search?q=#theagileagency
Contents

1 Introduction . . . . . . . . . . . . . . . . . . . 1
Why Is This Book Relevant? . . . . . . . . . . . 1
Why Did I Write This Book? . . . . . . . . . . . 2
About the Title . . . . . . . . . . . . . . . . . . 3
How Did I Write This Book? . . . . . . . . . . . 4
What Is the Structure of This Book? . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . 6

2 What Is Agile? . . . . . . . . . . . . . . . . . . 7
The Roots of Agile . . . . . . . . . . . . . . . . 7
Individuals and Interactions over Processes and
Tools . . . . . . . . . . . . . . . . . . . . 9
Working Software over Comprehensive Docu-
mentation . . . . . . . . . . . . . . . . . . 11
Customer Collaboration over Contract Negotiation 11
Responding to Change over Following a Plan . . 12

3 Interlude: Complexity and What Art Can Teach

Us about Agile . . . . . . . . . . . . . . . . . . 14
Coincidence? . . . . . . . . . . . . . . . . . . . 14
CONTENTS

4 Say Goodbye to the Masterpiece Mentality . . 17

Nec Plus Ultra . . . . . . . . . . . . . . . . . . . 17
Installing the Sink . . . . . . . . . . . . . . . . . 19
Waterfall Thinking . . . . . . . . . . . . . . . . 20
The 3 Week Fail . . . . . . . . . . . . . . . . . . 22

5 User Stories. Defining Scope in an Agile Way 25

Enter: User Stories . . . . . . . . . . . . . . . . 26
The Client Brief vs. User Stories . . . . . . . . . 28
Conclusion . . . . . . . . . . . . . . . . . . . . 30

6 What Is Scrum? . . . . . . . . . . . . . . . . . 32
Roles . . . . . . . . . . . . . . . . . . . . . . . . 33
Timeboxes . . . . . . . . . . . . . . . . . . . . . 33
Artefacts . . . . . . . . . . . . . . . . . . . . . . 35
The Boot and Shoe Repair Shop . . . . . . . . . 38
Scrum vs. Waterfall . . . . . . . . . . . . . . . . 40

7 Scrum Principles and Practices . . . . . . . . . 42

Transparency . . . . . . . . . . . . . . . . . . . 42
Inspection . . . . . . . . . . . . . . . . . . . . . 42
Adaptation . . . . . . . . . . . . . . . . . . . . 43
Trust . . . . . . . . . . . . . . . . . . . . . . . . 43
Planning Poker . . . . . . . . . . . . . . . . . . 43
Definition of Done . . . . . . . . . . . . . . . . 45
Demo or Die . . . . . . . . . . . . . . . . . . . 46

8 Applying Agile and Scrum in an Agency En-

vironment . . . . . . . . . . . . . . . . . . . . 48
The Daily Scrum . . . . . . . . . . . . . . . . . 48
CONTENTS

Demo or Die . . . . . . . . . . . . . . . . . . . 50
The Scrum Board . . . . . . . . . . . . . . . . . 51
The Burndown Chart . . . . . . . . . . . . . . . 52
Budget and Backlog Prioritization. Scope Can
Change over Time . . . . . . . . . . . . . 53
Retrospectives . . . . . . . . . . . . . . . . . . . 54
The Role Threesome . . . . . . . . . . . . . . . 55
Why Account Managers Are Pigs . . . . . . . . 56

9 What Is Lean? . . . . . . . . . . . . . . . . . . 59
Optimize the Whole . . . . . . . . . . . . . . . 60
Focus on Customers . . . . . . . . . . . . . . . 60
Eliminate Waste and Create Flow . . . . . . . . 61
Build Fast, Learn Fast . . . . . . . . . . . . . . . 62
Keep Learning . . . . . . . . . . . . . . . . . . . 62

10 The Lean Bicycle Factory . . . . . . . . . . . . 64

It’s Not Working . . . . . . . . . . . . . . . . . 64
Traffic Jam . . . . . . . . . . . . . . . . . . . . 64
Visualization . . . . . . . . . . . . . . . . . . . 65
Work in Progress Limits . . . . . . . . . . . . . 65
Pull vs. Push . . . . . . . . . . . . . . . . . . . . 66
Slack . . . . . . . . . . . . . . . . . . . . . . . . 66
Cycle Time . . . . . . . . . . . . . . . . . . . . 67
Stop Starting, Start Finishing . . . . . . . . . . . 67

11 What is Kanban? . . . . . . . . . . . . . . . . . 68

12 Applying Lean and Kanban in an Agency En-

vironment . . . . . . . . . . . . . . . . . . . . 74
CONTENTS

The Lean Startup . . . . . . . . . . . . . . . . . 74

Business Model Canvas and Lean Canvas . . . . 75
Work in Progress Limits and Lead Time . . . . . 78

13 Case Study: Using the Agile Manifesto as a Tool 83

Where Are the Problems? . . . . . . . . . . . . 83
Where Are the Solutions? . . . . . . . . . . . . 84
In Practice . . . . . . . . . . . . . . . . . . . . . 84
How? . . . . . . . . . . . . . . . . . . . . . . . 85
The Results? . . . . . . . . . . . . . . . . . . . . 85

14 Case Study: Scrum for Rock Bands. How to

Measure Progress When Recording . . . . . . 88
The Band Splits . . . . . . . . . . . . . . . . . . 88
Building a Backlog . . . . . . . . . . . . . . . . 89
Estimating the Weight: Planning Poker . . . . . 89
Prioritizing the Backlog and Scope Creep . . . . 90
Measuring Progress with the Burndown Chart . 92
The Result . . . . . . . . . . . . . . . . . . . . . 92

15 Case Study: Using Scrum with a Hyper Fixed

Deadline . . . . . . . . . . . . . . . . . . . . . 95
The War Room . . . . . . . . . . . . . . . . . . 96
Bring In the Customer . . . . . . . . . . . . . . 98
The Result . . . . . . . . . . . . . . . . . . . . . 99

16 Case Study: How to Mix Scrum and Kanban . 103

Why Was This a Perfect Project to Test-Drive? . 103
How Did We Get Started? . . . . . . . . . . . . 104
Did This Kanban Board Do the Trick? . . . . . . 106
CONTENTS

What Was the Result? . . . . . . . . . . . . . . 107

17 Case Study: Using a Visual Control System to

Manage a Portfolio . . . . . . . . . . . . . . . 110
A Visual System . . . . . . . . . . . . . . . . . . 111
Side Effects . . . . . . . . . . . . . . . . . . . . 112
Next Steps . . . . . . . . . . . . . . . . . . . . . 113

18 Case Study: Why You Should Play Games at

Work. Gamestorming for Retrospectives . . . 116
Bad retrospectives . . . . . . . . . . . . . . . . . 116
Good Retrospectives and Gamestorming . . . . 117
Actions for Retrospectives . . . . . . . . . . . . 118
What Happens When You Start Gamestorming . 120

19 Case Study: Why Stop with Production? . . . 123

Mapping Iterative Working on the Whole Value
Chain . . . . . . . . . . . . . . . . . . . . 123
Google and Their Agile Creativity . . . . . . . . 125
Mindtunes. Agile Creativity Applied. . . . . . . 126

20 Case Study: Culture Hacking. Why Agile and

Lean Actually Work in an Agency Environment 129
What is a Culture Hack? . . . . . . . . . . . . . 129
The Pop-up Inspiration Session . . . . . . . . . 132
The Digital Production Checklist . . . . . . . . 133

21 Conclusion . . . . . . . . . . . . . . . . . . . . 137

Epilogue . . . . . . . . . . . . . . . . . . . . . . . 140
CONTENTS

Bibliography . . . . . . . . . . . . . . . . . . . . . 141
1 Introduction
Why Is This Book Relevant?

Nowadays you can’t manage a project in a creative agency

the same way as 20 years ago. This book is about an al-
ternative approach on projects, processes and collaboration
culture.
What has changed? First of all, the type of projects. It is
not just about print, television or radio anymore. Relevant
projects these days are much more complex and are deeply
related to technology and innovation.
Secondly, the economical situation has changed. Agencies
and clients don’t have the same budgets as they used
to. This results in a need for maximum efficiency and
productivity.
Thirdly, things are speeding up. 365 is the new 360¹. Com-
munication is hyperreactive. Campaigns and products now
have to be made in only weeks or even days. The line
between advertising campaigns and products starts to blur.
It is the end of advertising as we know it.²
¹http://www.psfk.com/2009/06/goodbye-360-degrees-hello-365-days.html
²Rei Inamoto on http://www.fastcocreate.com/1683292/the-end-of-
advertising-as-we-know-it-and-what-to-do-now
Introduction 2

Finally, due to all these circumstances, the concept of “an

advertising agency” is under fire. This book can help agen-
cies redefine themselves by transforming their company
culture with lean and agile.

Why Did I Write This Book?

When people ask me “what is the one thing you would

like to do within the next 5 years?” I always reply that
one day I would like to write a book about my view on
project management. In June 2013 I had been blogging for
one year on lean and agile and I made a deal with myself. I
would write two pages a day during July and August, and
see where I would end up. The result is now in your hands.
Why about lean and agile? When I started as a project
manager I had read the default books about project man-
agement, which handled every project as a series of closed
phases, the so called waterfall model. But as soon as I
started implementing these methods, I got stuck. Deadlines
were never met, and gradually I became more frustrated
about my work. Was it really my mistake? All these project
management books had a rather dogmatic view on projects,
and as these approaches never worked, the cause had to be
me I guessed.
But then I met a senior project manager who talked to me
extensively and full of passion about lean and agile during
lunch. A new world opened up. It wasn’t my fault. The
problem was the project management approach I used.
Introduction 3

Scrum was the most popular agile toolbox at that time.

So I took a two day scrum master certification. I started
using scrum right away, and from day one I witnessed how
projects went live better, faster, with higher quality, and
most important, with less stress and pressure for the people
working on it.
From that day on, I started evangelizing about agile, scrum,
lean and everything related to it. I read a whole deal
of books, started blogging about it, and now I am even
teaching classes at two colleges. Resulting in this book you
are currently reading.

About the Title

The title “The Agile Agency” is a plea for your agency to

become agile and to grow your company culture around
values such as transparency, continuous improvement and
trust.
Originally, I considered a different title for this book.
“Leap”. This title is not only an acronym for “lean and agile
practices”. It also refers to the legendary words by Neil
Armstrong when walking as the first human being on the
moon in 1969: “That’s one small step for [a] man, one giant
leap for mankind”. I believe strongly that when you start
applying lean and agile step by step in your organization,
you have to use small steps. But as soon as you start doing
it, this means a giant leap for your organization’s culture.
Introduction 4

And that what it is all about. The guts to change your

organization through lean and agile.
However, I did a small A/B test on doubtcloud.com³ prior
to the release of the book, and “The Agile Agency” acquired
the most votes.
As the subtitle reveals, this book is written in the first place
for people who work at creative agencies. Project Man-
agers, Digital Producers, Account Managers, Creatives,…
I deliberately don’t use the term advertising agency or
communication agency. Probably for the same reasons as
the Cannes Lions changed their name from International
Advertising Festival⁴ into International Festival of Creativ-
ity. Nowadays it is not just about advertising anymore. It
is about creativity. But not only the large network agency
can use this book. Also the small web agency or 5 people
boutique development shop will benefit from agile and
lean.

How Did I Write This Book?

This book is written in a lean way. It is only a photograph

of how I think about things at this moment, and it was
written in just 2 months. You could call it a “minimum
viable version” of the book. You will learn further on in
this book what this actually means.
³http://doubtcloud.com/zgb
⁴http://www.fastcompany.com/1763421/cannes-festival-name-change-
reflects-bigger-messier-reality-ad-industry
Introduction 5

Parts of it were already published on my blog http://

www.bartvermijlen.com as separate blog posts. This book
however tries to tie them together as a comprehensive
story.

What Is the Structure of This Book?

You could see the structure of the book as a house.⁵

Chapters 2 to 5 are about agile, and chapters 9 and 10 about

lean. They form the foundations for the rest of the book.
The chapters on scrum and kanban are built on these, each
as an example framework or toolbox of their fundament.
⁵The house is also a classic representation of Lean thinking. http://www.
vision-lean.com/lean-manufacturing/lean-house/
Introduction 6

The roof, the second part of the book (chapters 13 to 20),

consists of case studies based on both the foundations as
the walls.
If you already have basic knowledge about lean and agile,
you can go straight to the chapters about scrum and kan-
ban. If that isn’t new either, you can go directly to the case
studies.

Acknowledgments

I would like to thank a fine league of proofreaders for

their constructive feedback on this book. Jef Cavens, Tom
De Bruyne, Jürgen De Smet, Kris Hoet, Louise Martens,
Jan Seurinck and Karel Vinck. This book is only a start.
Consider yourself as a proofreader from now on. I hope I
will receive lots of comments so I can update the book in
the future. I will also try to add more relevant cases, giving
it more depth with every new edition.
Finally, thanks to Kwint De Meyer for the illustrative work
and Liselore for being the best critical editor you can
imagine.
2 What Is Agile?
The Roots of Agile

In February 2001 a group of 17 people gathered to ski and

have a chat at Snowbird, a ski resort in Utah¹. They also
had another purpose. All of them were using some kind
of “anarchistic” software development practice. Extreme
Programming, SCRUM, DSDM, Adaptive Software Devel-
opment, … All these practices were a counter reaction to
traditional waterfall methodologies.
During two days they tried to find something in common in
their development practices. The outcome was a statement
called the “Agile Manifesto” that reflected what they had
in common.

¹http://agilemanifesto.org/history.html
What Is Agile? 8

Manifesto for Agile Software Development

We are uncovering better ways of developing software by

doing it and helping others do it. Through this work we
have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we

value the items on the left more.²

The participants didn’t have a clue that the Manifesto

would have such an impact on the future, going further
than just software development. They were a “group of
people who held a set of compatible values, a set of values
based on trust and respect for each other and promoting
organizational models based on people, collaboration, and
building the types of organizational communities in which
we would want to work.”³
Because of this focus on people and collaboration, the
Manifesto is still relevant today, and is easily applicable
in all kinds of organizations. Although it started within
the IT departments of companies, it eventually began to
²http://agilemanifesto.org
³http://agilemanifesto.org/history.html
What Is Agile? 9

contaminate also other departments the last few years.⁴ In

particular Human Resources departments were confronted
with the rather unconventional ways of working from their
IT colleagues.
Nowadays agile is a buzzword that every manager likes to
use. Forbes⁵ and Business Insider both have their agile or
lean articles every few weeks. Especially the startup culture
has given an extra boost to put these practices into the
spotlight.
But using the word agile every 5 minutes doesn’t exactly
mean understanding what lies behind. The core lies in col-
laboration culture and continuous improvement. I will try
to give some more background, using the core statements
of the Agile Manifesto.

Individuals and Interactions over

Processes and Tools

The Agile Manifesto puts individuals and their interactions

first. Nevertheless it is important to emphasize the word
“over”. Items on the right of the manifesto do have value -
⁴In management circles the Declaration of Interdependence was created.
Looking at those values versus the Agile ones you notice that Agile (bottom-
up) meets the needs of the managers (top-down, interdependence). It is normal
that agile values live through many different processes and systems around
the globe. For more information on the Declaration of Interdependence, check
http://pmdoi.org/.
⁵http://www.forbes.com/sites/patrickhanlon/2012/09/28/google-says-its-
time-for-agencies-to-get-agile-2/
What Is Agile? 10

which is explicitly stated - but agilists value items on the

left more.
left

• individuals and interactions

• working software
• customer collaboration
• responding to change

right

• processes and tools

• documentation
• contract negotiation
• following a plan

So when you encounter discussions or problems, and your

team partners start stating that the solution lies in using
particular tools or processes, it should ring a bell. Tools
and processes can help you optimizing your organisation,
but they will practically never be the “deus ex machina”
solution. When searching for solutions, try to focus on how
you can optimize interactions between individuals. It will
solve problems better and faster.
What Is Agile? 11

Working Software over Comprehensive

Documentation
The same counts for the second statement. Agile doesn’t
say you should burn all documentation and put nothing
on paper. The general idea is that you minimize elaborate
documentation and search for minimum viable documen-
tation. Only note down the strict minimum to keep your
process on the tracks.
The word “software” can easily be changed into “products
or services”. Then this statement becomes universally ap-
plicable. Start talking with your partners or customers and
stop writing. Focus on conversations and write down only
the strict minimum. Although this seems to be unnatural,
you will soon notice that you generate much better output
with less overhead.

Customer Collaboration over Contract

Negotiation
This summarizes in a way the first and the second state-
ment. Collaborate with customers instead of trying to force
them into a contract. Focussing on a contract will maybe
work for a while, but you will end up with a customer
that is tired of paying for “change requests” and not getting
what he or she actually wants.
Especially in creative agencies this is a very valuable con-
cept. It is very hard to force a customer into a position. A
What Is Agile? 12

customer just wants a good campaign that works. That is

what they are paying for. And if they don’t like the way
you work, they will just drop your advertising agency and
go to another one. And you will have to fire 5 or 10 people
because of the budget you have just lost.
The alternative is to have a very transparent and open com-
munication with your customer. Once again, stop writing
and start talking.

Responding to Change over Following a

Plan

Don’t pretend you are be able to predict in advance what

is going to happen. This may have worked for radio or
print production, but nowadays (digital) projects demand
another way of planning. Embrace change, instead of fo-
cussing on the plan.
What Is Agile? 13

Summary
• Agile has its roots in the Agile Manifesto.
• The Agile Manifesto was conceived by
software developers as a counter move-
ment against traditional project management
methods.
• The Agile Manifesto consists of 4 basic prin-
ciples that are universally applicable.
– Individuals and interactions over pro-
cesses and tools
– Working software over comprehensive
documentation
– Customer collaboration over contract
negotiation
– Responding to change over following a
plan

Agile clearly acknowledges that the different steps in a

project can’t be predetermined. But that doesn’t mean
that everything happens by coincidence. The next chapter
introduces the concept of complexity.
3 Interlude: Complexity and
What Art Can Teach Us
about Agile
In October 2012 Raoul De Keyser deceased. He was one of
Belgium’s most famous abstract painters from the last 50
years. When the author Bernard Dewulf was interviewed
on Radio 1¹ about his career, he summarized the painter’s
love for the anecdotical as follows:

“When you are attentive to coincidence, it’s no

coincidence anymore.”

This beautifully grasps what agile is all about.

Coincidence?

When problems emerge during a project, people tend to

be genuinely surprised. “Huh? This wasn’t a milestone on
our GANTT²-chart? By coincidence this extra functionality
¹http://www.radio1.be/
²A Gantt chart is a type of bar chart, developed by Henry Gantt in the 1910s,
that illustrates a project schedule. Gantt charts illustrate the start and finish dates
of the terminal elements and summary elements of a project. http://en.wikipedia.
org/wiki/Gantt_chart
Interlude: Complexity and What Art Can Teach Us about Agile 15

popped up just before we went live!” Does this sound

familiar?
When you look at projects in an agile way, coincidence
does not exist anymore. Why? An agile mindset perceives
unpredictability not as coincidence but as complexity.

“Complex” is everything that lies between chaos

and order.³

Agile is about embracing the complex unpredictable nature

of (software) projects and their teams. You don’t stick
to a methodology, but you adapt the process throughout
the project. It is about valuing responding to change over
following a plan.

³Read more on Jurgen Appelo’s definition of Complex on http://www.noop.

nl/2008/08/simple-vs-complicated-vs-complex-vs-chaotic.html or check out the
Cynefin model on Wikipedia >http://en.wikipedia.org/wiki/Cynefin>
Interlude: Complexity and What Art Can Teach Us about Agile 16

Summary
• An agile mindset perceives unpredictability
not as coincidence but as complexity.
• Agile is about embracing the complex un-
predictable nature of (software) projects and
their teams.
.

Agile started as a reaction against waterfall thinking. But

what is waterfall thinking actually about? The next chapter
looks at one of its causes, the masterpiece mentality.
4 Say Goodbye to the
Masterpiece Mentality
“Stop keeping your imperfect and unfinished
ideas in your head, like dying butterflies in a
glass jar. It’s always better to let them fly.”¹

Why don’t people use agile practices as a default? As a

normal human being, you are preprogrammed to apply the
“masterpiece mentality”. I will illustrate this concept with
the example of me writing my Master dissertation almost
10 years ago.

Nec Plus Ultra

It was clear. I was a good student, but my dissertation was

going to be nec plus ultra. I particularly loved the academic
part of my studies, and as the subject was really close to my
heart (it was about music journalism) the dissertation was
going to be a genuine piece of art.
And so I started. Most of my fellow students just read
enough books to fill up the theoretical part of their dis-
sertation. But that wasn’t enough for me. I started reading
¹https://twitter.com/BBHLabs/statuses/357500021291233281
Say Goodbye to the Masterpiece Mentality 18

everything that was by close of by far related to the subject.

As well academic as non academic literature. I didn’t want
to miss any possible interesting source.
So I read a lot. I planned to finish the theoretical part by
January. It became April. No problem. I still had time until
the end of July to finish the rest.
Then I had to do my research. I chose to do qualita-
tive in-depth interviews with both music journalists and
other players in the field. Musicians, concert promoters,
independent promoters, … Instead of doing the usual 10
to 15 interviews, I ended up interviewing 37 people (if I
remember correctly). I finished the interviews by the end
of June. Still no problem. I had one month left.
Another minor detail. The professor who supervised my
dissertation wanted all interviews to be written out. So
I had to write down all 37 interviews, with an average
duration of 45 minutes.
Together with some friends and family members I started
the transcriptions. Ending up with more than 300 pages. It
was only 8 days until the deadline and I still had to start
with the analysis of the interviews.
I won’t go into detail how I managed to finish the disserta-
tion (think coffee, a lot of drama and a corrupt word file),
but this perfectly illustrates the bankruptcy of a project
when you apply the masterpiece mentality.
Say Goodbye to the Masterpiece Mentality 19

Installing the Sink

I found the concept of the “masterpiece mentality” on

Eric Karjaluoto’s blog². He uses it while talking about
communication design, but it is easily applicable for all
kinds of “intellectual labor”.

“Designers are detail focused, and there’s noth-

ing wrong with this, as long as we concentrate
on the right details at the right time. Think of
it this way: you’d be a fool to install the sink
before the foundation is poured; nevertheless,
as designers we do this all the time. We get
excited about one idea before we know that
it’s really the most workable one, and we start
polishing out of pure energy and excitement.
This makes for bad design solutions. We need
to remind ourselves to step back and ask if
we’re concentrating on the most appropriate
points.”

The masterpiece mentality is all about having an idea and

trying to groom and polish it as good as possible before
releasing it or handing it over, overly focussing on details,
and grooming until there is nothing left to groom.
²http://www.ideasonideas.com/2008/12/applying-agile-principles-to-
communication-design/
Say Goodbye to the Masterpiece Mentality 20

Waterfall Thinking

The Agile Manifesto emerged from a group of “anarchistic”

project methodology practitioners mainly as a counter-
movement against the classical project methodologies. Most
of these more established approaches have waterfall think-
ing in common.
The masterpiece mentality is a perfect metaphor for this
waterfall model. Let us start from the Wikipedia definition:

“The waterfall model is a sequential design

process, often used in software development
processes, in which progress is seen as flowing
steadily downwards (like a waterfall) through
the phases of Conception, Initiation, Analysis,
Design, Construction, Testing, Production/Im-
plementation, and Maintenance.”³

Waterfall means you divide your project into different sub

sequential phases. Every phase is closed, before the next
one is opened.
Exactly this last point is the core of the problem. In complex
environments, it is impossible to predict in advance how a
phase is going to open and close, and what the timing will
be. Not to mention if it is possible to make a perfect delivery
within one specific phase.
³http://en.wikipedia.org/wiki/Waterfall_model
Say Goodbye to the Masterpiece Mentality 21

If you wonder why every project keeps running late, and

a milestone is always missed, this is the reason. Waterfall
just doesn’t work.
The classic waterfall approach to a project in a creative
agency looks as follows.

Analysts do their work thoroughly. They don’t talk to the

designers or the developers. They are perfect. They know
everything. They write a 20 page description about what
should be build, how, and on which technology. As soon
as their task is over, they drop it into the designers mailbox
and end their commitment to the project. The designers
think the analysts did a crappy job. They make their own
interpretation. They think they are perfect too. And they
drop it into the developer’s mailbox. And so the story goes
on and on. Maybe this is exaggerated, but sometimes this
is not far from reality.
It is like a 4 x 100 meter relay race, where every runner
drops the batton in the hand of the next runner at the
latest second possible. Not really a comfortable way of
collaborating.
Say Goodbye to the Masterpiece Mentality 22

Photo by Christian Dalager. Under Creative Commons License (CC

BY 2.0). http://www.flickr.com/photos/dalager/14110369/

The 3 Week Fail

Let us say you have three weeks to build an app or a

website. 1 week for the concept, 1 week for the design, and
1 week for the development. Most of the time it will go like
this:
After 1 week.

“Damn. We have a really great concept, we just

need 2 days more and it will be the next big
thing.”

After 1,5 weeks

“Yeah! Let’s start designing. And make it top

of the notch design. This concept is so good, it
definitely needs top design!”
Say Goodbye to the Masterpiece Mentality 23

After 2,5 weeks

“w0000t. What a superb design! Damn. Do we

only have 2 days to develop it? Come on guys,
let’s work 36 hours a day, and ship this thing!”

And then you end up with crappy code, a lot of bugs, an

angry customer, and a concept that actually completely
sucked.
Say Goodbye to the Masterpiece Mentality 24

Summary
• The masterpiece mentality is a metaphor for
waterfall thinking.
• Waterfall means you divide your project into
different sub sequential phases. Every phase
is closed, before the next one is opened.
• Agile is an alternative to waterfall.

In the next chapters, we will see which alternatives the

Agilists came up with to tackle this waterfall model. But let
us start where every project starts: scope definition. Most
agile practices use user stories to define scope.
5 User Stories. Defining
Scope in an Agile Way
The real challenge nowadays does not only lie in conceiv-
ing a great idea, but in its execution. A great idea which
is executed poorly, results in ‘good’. And as Jim Collins¹
states: “Good is the enemy of great”.
In all kinds of projects a lot of waste occurs between idea
and execution. To use some lean terminology:

• Transportation and Motion: ideas are briefed from

creatives or business developers through account
managers and project managers to architects, design-
ers or developers. The core of the creative idea gets
lost in translation.
• This results in over processing and overproduction:
the end result does not match the expectations of the
idea creators. Work needs to be redone, losing time
and money.

The well known tree swing comic² summarizes this pretty

¹COLLINS (J.). Good to Great: Why Some Companies Make the Leap… and
Others Don’t. 2001.
²http://www.businessballs.com/treeswing.htm
User Stories. Defining Scope in an Agile Way 26

well³.

How to prevent this? How is scope best defined when

moving from idea to execution, if you want to apply an
agile mindset?

Enter: User Stories

I am not going to proclaim big theories or dogmatic rules

in this field. I am just going to share what I found a big help
in these kind of situations, in particular in digital creative
projects: user stories.
³http://tamingdata.com/2010/07/08/the-project-management-tree-swing-
cartoon-past-and-present/
User Stories. Defining Scope in an Agile Way 27

Although user stories originated in Extreme Programming

(XP) and are nowadays heavily used in agile development
practices such as scrum, they are not part of the classical
digital advertising project or process. It is my opinion that
they really help to put the creative idea in the center of your
project.
User stories are short (or as short as possible) descriptions
of functionality, phrased as follows:

As a TYPE OF USER, I want to GOAL, so

REASON.

For example⁴:

As a visitor of the website, I want to submit my

email address, so I receive the newsletter.

Ron Jeffries describes the 3 critical aspects from user stories

as the 3 C’s⁵:

• Card: the user story is written down on a card. It is

tangible, it sticks to walls, it moves.
• Conversation: more important than the card itself, is
the conversation it instigates. All stakeholders talk
about the right things from the start, focusing on
what is essential to the execution of the idea.
⁴Read an example set of user stories based on the functionality of
Twitter on http://www.slideshare.net/bartvermijlen/how-to-build-a-product-
backlog-with-user-stories-the-example-of-twitter
⁵http://xprogramming.com/articles/expcardconversationconfirmation/
User Stories. Defining Scope in an Agile Way 28

• Confirmation: every user story has acceptance crite-

ria. These are used to define on which basis a story
will be tested or validated.

Acceptance criteria for the example above could be:

• My email address is checked on syntax, and I receive

an error message when it is not correct.
• I must tick a checkbox for an opt-in.
• …

By gathering all the functional elements of your idea in user

stories, you brief with minimum documentation, talking
from the start about the right things, leaving open enough
space to add maximum value.

The Client Brief vs. User Stories

“The Client Brief” is a proven concept used in advertising,

describing how clients should brief their agencies in the
best possible way. The British IPA⁶ has made a good
summary of this concept, putting forward 3 main principles
behind a good brief:

• Written briefs
⁶http://www.ipa.co.uk/Document/The-Client-Brief-summary-best-
practice-guide
User Stories. Defining Scope in an Agile Way 29

• Clarity of thinking
• Clearly defined objectives

The motives behind these 3 principles perfectly match with

user stories.
Written briefs:

“Both parties see enormous benefits in starting

with a written document (…) which is then
analysed and debated between the two teams”.
“The opportunity to discuss this at a subse-
quent verbal briefing usually allows us to cover
any inconsistencies and, if necessary, develop
focus through mutual agreement.”. “A written
brief is also vital in ensuring the ‘buy-in’ of
other key people in your company. This buy-
in is essential in order to avoid the significant
waste of time and resources.”

Clarity of thinking:

”A good brief is not the longest or most de-

tailed, it’s the one whose clarity and focus
creates the platform for a great strategic leap,
a blinding customer insight and an effective
solution.”

Clearly defined objectives:

User Stories. Defining Scope in an Agile Way 30

“All briefs should have effectiveness criteria

and evaluation methodology written into them.”

Conclusion

The client brief and user stories are very much alike. They
are the same solution to the same kind of problem. They
focus on conversation, collaboration and interaction, early
in the process, to deliver as much value as fast as possible
to everyone involved. Stop writing, start talking.
User Stories. Defining Scope in an Agile Way 31

Summary
• User stories are short descriptions of function-
ality.
• They are always structured the same way: as
a USER, I want to GOAL, so that REASON.
• User stories are defined by 3 C’s: card, con-
versation and confirmation.
• User stories show strong affinity with the
classic Client Brief.
.

User stories are only a way to define scope. Let us take a

look at scrum, a toolbox that allows you to apply agile to
all steps of your process.
6 What Is Scrum?
From all agile practices, scrum is the most commonly
used in software development, and thus also in digital
production for advertising and communication purposes.
It was the first agile toolbox I started using after following
a certified scrum master course from Jeff Sutherland¹,
one of the founding fathers of scrum together with Ken
Schwaber².
Scrum is a framework for agile software development
consisting of roles, timeboxes and artefacts.
Scrum is not a full-blown process methodology. It doesn’t
have precise instructions for every step in the process. It
neither is a philosophy or a theory. You could call it a
“minimum viable framework” for software development
(referring to the Lean Startup’s minimum viable product
which we will tackle further on in this book).
The elements of the framework are:

• Roles: team, product owner, scrum master

• Timeboxes: sprint, daily stand-up, sprint planning,
sprint review, retrospective
¹http://jeffsutherland.com/
²http://kenschwaber.wordpress.com/
What Is Scrum? 33

• Artefacts: scrum board, product backlog, sprint back-

log, burndown

Roles

The product owner owns the product. This may sound

stupid, but it is paramount. He or she has the responsibility
to define scope together with the team and to prioritise
which work has to be done first. Next to that he or she
also has to validate from “ready” to “done”.
The scrum master has the task to make sure that everyone
knows how to do things. He or she guards the process. A
scrum master also facilitates and removes impediments for
the team members.
The team consists of all people (designers, developers,
analysts, testers, UX,…) working on the project.

Timeboxes

Timeboxes in scrum are fixed. They don’t change. Duration

is fixed and start and end moment are fixed.
First of all there are sprints. These vary between a 1 and 4
week duration. It is the period in which work is being done.
A sprint starts with a sprint planning meeting (the second
timeboxed event, typically between 2 hours and a day).
This is where the product owner explains and prioritizes
What Is Scrum? 34

the user stories. The team can ask questions to clarify the
stories so they are able to estimate them.
Every day the scrum master and the rest of the team gather
for the daily stand-up. During this timeboxed event of 10
to 15 minutes, every team member has to tell what they
have done since the last stand-up, what they are going to do
before the next stand-up, and what their impediments are
(so the scrum master can resolve them). Alternative topics
on a daily stand-up can be for example “what have I learned
today”. It is important to switch the format from time to
time so it doesn’t become boring. Don’t forget it should be
fun at all times.
The product owner is not invited by default to the daily
stand-up. At the end of the sprint there is a sprint review,
where the product owner can review the user stories that
were developed. Note that the product owner cannot inter-
fere during the sprint nor change priorities or user stories.
Although the other way round team members do have the
right to ask extra information to the product owner. He or
she should be available at all time to answer questions.
The process ends with the most important meeting: the
sprint retrospective. This is where all parties involved can
evaluate the way of working in the past sprint. Good retro-
spectives end up being clear measurable actions. Gamestorm-
ing in particular is a very rewarding way of doing retro-
spectives. I will talk some more about gamestorming and
retrospectives later on in this book.
After the retrospective follows the sprint planning for the
What Is Scrum? 35

next sprint. And so the process goes on and on in an

iterative way until the product is finished, time runs out,
or there is no budget left. Big projects can have 20 sprints
of a month, small projects can consist of 3 one week sprints.

Artefacts

The most well known artefact in scrum is the scrum board.

A lot of people even think that scrum is nothing more than
a these 3 columns: “to do”, “ongoing” and “done”.

In the different columns are user stories from the product

backlog. This list contains all features the product owner
has defined and prioritized, described as user stories. User
What Is Scrum? 36

stories are written on index cards or sticky notes and put

on the wall.³

The scrum board Jeff Sutherland used during my Certified Scrum

Master course

When the team starts working with the backlog, they some-
times define tasks between each other in a separate sprint
backlog. Where the product backlog is the responsibility
from the product owner, the sprint backlog is exclusively
managed by the team.
A very usable tool in the scrum toolbox is the burndown
chart. After the team has estimated the weight of all
the different user stories for a particular sprint, the chart
³There are also online scrum boards available (e.g. Trello) although I prefer
the physical scrum boards if your team is co-located.
What Is Scrum? 37

displays the number of story points on the y axis, and

time on the x axis. This way progress can be measured
and displayed, and even more important, it visualizes if the
foreseen number of story points will be finished by the end
of the sprint.
The example below shows a 5 day project, containing
stories with 127 story points.

The red line indicates the ideal evolution. When you start
measuring the number of burned story points during a
sprint, you can determine the velocity of a team. This is
a number that qualifies the speed of development. If you
start tuning your process along the way it allows you to
measure the impact (either positive or negative) of your
changes. When your actual burndown goes above the ideal
line, your velocity is too low, as you can see on day 2 and
day 3 of the example.
What Is Scrum? 38

The Boot and Shoe Repair Shop

Ok. Now you think: “So what? Now I still don’t know what
scrum really is!” Fair enough. I will try to explain on the
basis of a simple example of four guys building a website
for the shoe repairer down the street.
The four guys (one guy managing the work, one guy
designing, two guys developing) meet the shoe repair guy
during a meeting in a coffee bar to talk about the new
website he wants. This meeting is the sprint planning.
The shoe repair guy is the product owner. His task is to
explain to the team (the designer and the developer) what
he actually wants. The result is a prioritized list of features.
The team agrees with the shoe repairer that they know
what he wants on his website, and why. This becomes the
product backlog.
The shoe repairer, the manager (scrum master) and the
team agree that they will review the work done by the
team after two weeks (the first sprint) in a new meeting,
the sprint review.
The team members divide the product backlog for the
first sprint into a new list they will manage themselves,
containing all the tasks they will have to complete for every
feature. This is the sprint backlog.
They put all the backlog items on cards, and place them on
the wall in 3 columns, to do, ongoing and done: the scrum
board.
What Is Scrum? 39

Everyday, the team members and the scrummaster meet

exactly 10 minutes during the daily stand-up. Each team
member says what he has done since the previous stand
up, what he will do the next day, and if he has anything
that prevents him of doing his work (impediments). At the
same time, cards on the scrum board are moved from one
column to another.
The scrummaster has the task to solve all issues or imped-
iments. He keeps track of progress during the sprint on a
burndown chart.
After the first sprint, the team, scrummaster and product
owner gather for the sprint review. The shoe repairer now
can validate every feature or not. If not, the feature can be
put on the list for the next sprint.
After the sprint review, the team and the scrummaster
evaluate the sprint together during the sprint retrospec-
tive. They don’t talk about features, but about teamwork,
efficiency,…
The next week the process starts all over again with a fresh
sprint planning.
Notice once again the differences with a traditional project
management approach:

• No elaborate documentation or exhaustive project

plan.
• Focus on agile values such as customer collaboration,
working software and interaction between individu-
als.
What Is Scrum? 40

Scrum vs. Waterfall

Let us take a look at the default waterfall approach for

creative development projects.

When you apply an agile mindset, it looks somewhat like

this.

So instead of putting one phase after another, you make

small iterations which contain all the activities in small
batches.
What Is Scrum? 41

Summary
• Scrum is a framework for agile software de-
velopment consisting of roles, timeboxes and
artefacts.
• Roles are: team, product owner, scrum master.
• Timeboxes are: sprint, daily stand-up, sprint
planning, sprint review, retrospective.
• Artefacts are: scrum board, product backlog,
sprint backlog, burndown.

Scrum is more than roles, timeboxes and artefacts. Let us

take a look at some principles and practices typical for
scrum.
7 Scrum Principles and
Practices
There are 3 basic principles in scrum: transparency, inspec-
tion and adaptation¹.

Transparency

Using a scrum board, a backlog,… focussing on talking

instead of documenting,… All these practices make your
process transparent. For all stakeholders, not just the team
members.

Inspection

Because everything is being visualized in a transparent

way, it becomes possible for everyone to inspect the state
of a project at all times. People don’t have to wait until the
next status meeting in 3 months.
¹http://www.scrum.org/portals/0/documents/scrum%20guides/scrum_
guide.pdf
Scrum Principles and Practices 43

Adaptation
When you can see and inspect, you automatically have the
power to adapt your process at all times. When it is not
working, you will be confronted with it in an early stage.
And when you tackle issues early, they disappear quickly.
When you don’t adapt, these issues turn into big problems.
And then it is too late most of the time.

Trust
Often a 4th principle is being emphasized, namely trust².
Scrum cannot work without a relationship of trust. Not
only between team members, but also between stakehold-
ers and the team.
Next to these principles there are some popular practices
that are worth taking a look at.

Planning Poker
After defining user stories for your project, it is a good
practice to give them a weight. It can be given in hours,
but is even better to do this in story points. Why? Because
points are more abstract, and more flexible in use.
A common way to attribute points to all the stories in your
backlog is planning poker³. The idea is to give everyone in
²Hat tip to Jurgen De Smet.
³http://en.wikipedia.org/wiki/Planning_poker
Scrum Principles and Practices 44

your team a deck of planning poker cards. The most used

cards have fibonacci sequence numbers on them (0, 1, 2, 3,
5, 8, 13, 21,…) or a variation on that.

Photo by Jun Ohwada, under Creative Commons Licence CC BY

2.0, http://www.flickr.com/photos/june29/3754566093/

You start by choosing a straightforward story and you give

this story 3 points. For example the story “as a user, I can fill
in my email address so I receive a newsletter”. This will be
your reference story. All other stories have to be estimated
in relation to this reference story. So when your team thinks
the story “as a user, I can fill in a contact form, so I contact
the webmaster” is twice as complex as the reference story,
you attribute 6 points to it.
Everybody in the team has to put its card at the same time
on the table. When there is a large difference between the
Scrum Principles and Practices 45

highest and the lowest score, those two people have to

discuss why they think that particular story deserves their
estimation. After a few minutes there is a re-vote. When
there is still a large gap (which happens rarely), the highest
estimation is taken as weight for the story.
The fascinating thing about this practice is that it reveals
differences in comprehension of stories early on in the
process. The real value doesn’t lie in the precision of the
estimation, but in the conversation that is triggered by the
planning poker session. When there is a large difference in
weight given to particular stories, this always is related to
a difference in understanding of a particular story.
You can use the stories and their points afterwards to
measure progress in backlog completion.
As you notice, this is another example of “individuals
and interactions over processes and tools” and “customer
collaboration over contract negotiation”.

Definition of Done

One of the most important things when working together

is actually agreeing in advance on when an item in the
backlog is actually “done”. This may sound as a no brainer,
but it is one of the most dangerous pitfalls when using
scrum.
The team, scrummaster and product owner have to be very
clear on when an item from the backlog can be moved from
Scrum Principles and Practices 46

one column to another. Done can mean “it is working on

my local machine” or it can mean “has been tested on the
live environment and can be put live within 10 minutes”.
The more specific and detailed your definition of done, the
better.

Demo or Die

Another best practice while using scrum is “demo or die”.

Some people tend to just use a couple of powerpoint slides
in the sprint review meeting to show that some features
have been coded.
But that doesn’t guarantee code actually works, does it?
The better way is to ask teams to demo things in real time.
They will be forced this way to test thoroughly before
moving a feature to the “done” column.
Scrum Principles and Practices 47

Summary
• The 3 basic principles in scrum are trans-
parency, inspection and adaptation.
• Planning poker is a way to estimate the
weight of user stories.
• “Definition of done” is a best practice that
emphasizes the importance of agreement on
what “done” actually means.
• “Demo or die” is about the importance of
reviewing working software in front of an
audience.
.

Scrum has proven itself in software development. Let us

take a look at how we can apply this in an agency environ-
ment.
8 Applying Agile and Scrum
in an Agency Environment
Scrum originated in large software development contexts
with project life spans between 6 months and 3 years, using
sprints of 2 to 4 weeks. In a digital agency most projects
only have a production lifespan of 6 to 12 weeks, so it is
natural you can’t apply scrum exactly as it was meant to
be in every case.
Nevertheless there are some elements worth considering
for daily use.

The Daily Scrum

A lot of agencies have trouble with meetings. Or they don’t

have meetings and constantly communicate via email and
reply to all. Or even worse, they are constantly planning
meetings and statuses, that constantly run overtime, and
clutter the whole agency’s agenda. Stress. Frustration. Pro-
ductivity none. Or to use Jason Fried’s wording: meetings
are toxic.¹
¹http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php
Applying Agile and Scrum in an Agency Environment 49

Daily scrums have a few advantages. First of all they are

timeboxed. They are limited in time, and automatically stop
after 10 or 15 minutes.
Secondly, they have a clear agenda. The typical daily scrum
consists of three questions for every team member:

1. What have you done since the last daily scrum?

2. What will you be doing today?
3. Do you have any impediments?

After a while you can start using other formats for your
daily scrum, for example “what did you learn today?”. Most
important is to keep a steady pace, and to never skip a daily
scrum. Secondly is to safeguard the purpose of the daily
scrum. If a discussion starts, tell the people involved to take
it out of the daily scrum and to address it at another time,
with only the necessary people involved.
You can do daily scrums with developers, but also with
brand teams, management teams or other entities within
your organization. Don’t forget daily scrums have to be
fun. Otherwise they won’t last long.
There are a lot of theories on when is the best moment for
this daily catch-up. My experience is that 11:50 until 12:00
is the best moment. People are hungry, so they don’t tend
to start lengthy discussions. And it is the middle of a day.
Morning people are still in their good hours, and evening
people have finally woken up.
Applying Agile and Scrum in an Agency Environment 50

Demo or Die

Ask developers to demo for all the stakeholders early on in

the project. Even if things aren’t finished yet. It has multiple
advantages.

• Everyone is more involved.

• Developers in particular get motivated by the demo’s.
Now they can actually showcase their work them-
selves.
• Questions can be asked immediately.
• A lot of things that would end up in the bug tracker
while they are no bugs, can be tackled on the spot.
• Developers are forced to make things work early on
in the project (focus on working software).

Just try it. You will notice it works instantly.

Applying Agile and Scrum in an Agency Environment 51

Developer Niels giving a demo and showing the actual code.

The Scrum Board

Applying hardcore scrum in an agency is not always pos-
sible for a number of reasons. You don’t always have the
opportunity or the right projects to enable a team to work
full time on one project. But that doesn’t mean you can’t
use this visualization technique. Putting cards on the wall
has a huge impact on the way a project is perceived. To use
an old scrum saying:

“When it’s in an excel, it’s your responsibility.

When it’s on the wall, it’s the team’s responsi-
bility.”
Applying Agile and Scrum in an Agency Environment 52

So don’t be scared and start sticking paper on the wall. You

will be amazed by the power of sticky notes.

The Burndown Chart

Burndown charts are great tools to display progress on any

kind of project. I used it for example when I was migrating
from 3 old hosting partners to one new partner. We placed
the number of hostings that had to be moved on the y axis,
and the 25 days we had on the x axis. Time was important,
as every extra month on the old hosting environment was
costing the company a lot of money.
Every time a manager passed along the burndown chart he
Applying Agile and Scrum in an Agency Environment 53

or she could instantly see if we were on track or not. Easy,

transparent, efficient. And the team was highly motivated
to get things on track before the deadline came closer.

Budget and Backlog Prioritization. Scope

Can Change over Time

A default waterfall project has 4 dimensions: time, quality,

price and scope. The four of them are fixed from the start of
the project. Scrum on the contrary explicitly makes scope
variable in time.
Scrum originated in a “no fixed price” environment, where
development is billed internally or externally based on per-
formed hours. So no problems occur when scope changes
during the project, and items are added to the scope.
One of the reasons that agencies don’t like to use scrum,
is because they always work based on a fixed price agree-
ment. And it is not a good idea to allow scrum and expand
scope without expanding the budget as well. This is called
“scope creep”², a classic problem in project management.
Scrum offers you two possibilities to tackle this. The first
one is to ask for extra budget every time something is added
to the scope. This is not always a workable situation, as you
don’t want to charge your customer for every good idea
they add to the backlog. Your client also doesn’t always
has the possibility to get extra budget for his project.
²http://en.wikipedia.org/wiki/Scope_creep
Applying Agile and Scrum in an Agency Environment 54

When you have a fixed budget, there is an alternative

approach that works perfectly, called “Change for Free”.
Every time something is added to the backlog, another
piece of functionality with the same weight has to be
removed from the backlog. At the start your clients will
find this somehow hard, as they have the feeling they are
getting less for their money. But as soon as they notice the
flexibility of the system, they will see the added value.
It has a lot to do with the Pareto principle³. 80% of the
value of your application lies in 20% of the development. So
dropping something from the remaining 80% development
time, will only affect 20% of the value.⁴

Retrospectives
When a project is finished, it is perfectly natural to forget
about it and focus on the next project. And this is some-
thing where a lot of companies make a mistake. Only when
you focus on evaluating every project rigorously, you can
become a learning organization.
When you start a culture of retrospectives, you will start
noticing an interesting dynamic. First of all there is the fact
that all people involved get the opportunity of giving their
vision on how the process went. This influences the group
dynamics for future projects.
³http://en.wikipedia.org/wiki/Pareto_principle
⁴I always illustrate Pareto for my students with the following example.
Apparently 80% of the income of a “house with red doors” is earned by 20% of
the girls who work there.
Applying Agile and Scrum in an Agency Environment 55

And don’t forget to include all team members. The most

interesting reflections are those from the people that are
rather introvert during a project.

The Role Threesome

Central in scrum is the limited number of roles. Product

owner, scrum master or team member. The fact that a
product owner is responsible for scope and prioritization,
and that the scrum master guards the process, is something
that works extremely well in an agency environment.
Most of the time it happens as follows. An account manager
receives a briefing for a project. He or she does the radio,
tv and print. At the end they realise that there also is some
digital stuff to be done. So they dump the banners and
the minisite with their digital project manager. He or she
knows nothing about the project, nothing about the general
campaign, and just starts doing as much as possible in a
minimum amount of time, trying to catch an impossible
deadline.
And that just doesn’t work.
It is much more interesting to see the account manager as
the product owner (or proxy for the product owner who is
the end customer). When they are given responsibility over
scope, they can see that the project is in line with the other
media, and - more important - is in line with what the end
customer wants.
Applying Agile and Scrum in an Agency Environment 56

This also results in a shift where the project manager

can focus on the process (similar to a scrum master), and
removing impediments for the rest of the team.
On top of that, you stop mixing the responsibility for scope
with the responsibility for quality and timing. Those two
intrinsically conflict, and when you put them with one
person, that person either becomes schizophrenic, or starts
making mistakes.

Why Account Managers Are Pigs

The story of the chicken and the pig is often used in

scrum to illustrate the difference in commitment between
different people on a project.

Pigs are those who are responsible for delivering quality

in time and within the budget. Account managers, product
owners, project managers and developers/designers can be
considered pigs. They have to deliver what they committed
to! Their bacon is on the line.
Internal or external stakeholders can be qualified as chick-
Applying Agile and Scrum in an Agency Environment 57

ens. Examples are the C-suite, managers, directors,… Some

of them believe they have the right to interfere at any
moment, although they tend to vanish when it starts to heat
up. They just throw eggs.
As a project or account manager, always be aware of who
the chickens are and who the pigs are. If you feel that the
integrity of your team is being violated by a chicken, react
as a pig.
Communicate clearly that you are owning the project to-
gether with your team. You will take the chicken’s opinion
into account, but as it is your team’s responsibility to
deliver, you will make the final call.
Applying Agile and Scrum in an Agency Environment 58

Summary
• Although scrum by the book is not always
suited to apply in every agency, there are a
number of elements in the scrum toolbox that
are very valuable.
• The daily scrum is a great lightweight alter-
native to time-consuming meetings.
• Try to make a distinction in roles between
scope and process.
• “Demo or die”, the scrum board, the burn-
down chart and retrospectives are perfectly
suited for agencies.
• Keep in mind for every project who are the
pigs and who are the chickens.

So far for agile and scrum. Whereas they originated in

software development, a similar evolution happened in
manufacturing a few decades earlier. This movement is
commonly known as Lean.
9 What Is Lean?
In the late 1980s, American business analysts were strug-
gling with the fact that General Motors needed 7 years to
build the new model for a car, and Japanese constructors
only needed about 1 year to do the same.
So they started to investigate what was going on, and they
gained interest for the Toyota Production System (TPS).
The term “Lean” was first suggested by Womack, Jones
and Roos in their book “The Machine That Changed the
World: The Story of Lean Production” describing Toyota’s
management approach¹.
The most exhaustive book in this matter is “The Toyota
Way” by Jeffrey Liker². Liker described the system behind
Toyota using 14 principles.
In their “Lean thinking” book, Womack and Jones defined
5 core pillars of lean thinking³:

• Value
¹WOMACK (J.), JONES (D.) & ROOS (D.). The Machine That Changed the
World: The Story of Lean Production. Toyota’s Secret Weapon in the Global Car
Wars That Is Now Revolutionizing World Industry. 1990.
²LIKER (J.). The Toyota Way: 14 Management Principles from the World’s
Greatest Manufacturer. 2003.
³WOMACK (J.) & JONES (D.). Lean Thinking: Banish Waste and Create
Wealth in Your Corporation. 2003.
What Is Lean? 60

• Value Stream
• Flow
• Pull
• Perfection

As Anderson correctly states⁴ there are as many definitions

of Lean as there are authors on the subject.
So instead of doing a lengthy exhibit of all 14 principles
from Liker, I will use the summary made by Mary and
Tom Poppendieck when they mapped the principles to
software development⁵, mixed with Henrik Kniberg’s in-
terpretation⁶. When you want to dig deeper be sure to take
a peek at the bibliography at the end of this book.

Optimize the Whole

When you try to optimize your process, don’t focus on
optimizing only small parts. Try to focus on the complete
value stream and think long term. Define the purpose of
your organization as clearly as possible.

Focus on Customers
This might be yet another open door, but it is something
that a lot of software developers tend to loose out of
⁴ANDERSON (D.). Lean Software Development. 2011.
⁵POPPENDIECK (M. & D.). Lean Software Development: An Agile Toolkit.
2003.
⁶KNIBERG (H.). Lean from the Trenches. 2007.
What Is Lean? 61

sight. Making wireframes doesn’t necessarily mean you are

focussing on end users.

Eliminate Waste and Create Flow

The concept of “waste” is very important in Lean thinking.

Waste is anything that isn’t adding value to the product.
The Poppendiecks summarize it pretty well by saying that
you should avoid:

• Building the wrong thing.

• Building the thing wrong.
• Having too much work in progress that is waiting in
a queue.

Your process should be a constant smooth flow of work.

Once again, I could go on and on about the different kinds
of waste, but then we would deviate from the central topic.
Anderson redefines the term waste in an economical way⁷,
identifying 3 form of non value adding activities: transac-
tion cost (e.g. setup), coordination cost (e.g. communica-
tion) and failure load. This last one covers everything due
to not only bugs, but also usability problems and things
such as poor performance or load problems.
⁷ANDERSON (D.). Kanban: Successful Evolutionary Change for Your Tech-
nology Business. 2010, p. 216.
What Is Lean? 62

Build Fast, Learn Fast

Here you strongly feel the link with agile. Focus on building
things as fast as possible. This way you can start learning
early on in the process. The longer you wait, the less
you will learn. You can only solve problems if you tackle
them. In lean this is known as A3 thinking, where you put
everything on an A3 paper and apply “Plan, Do, Check,
Act”-cycles (PDCA)⁸. In other words, an iterative approach
to problem solving.

Keep Learning

And it doesn’t stop just there. The point in lean is that you
keep learning. It is not enough to learn something and say
“Alright. Now we know how it’s done.” Learning should
become a central part not only in your process, but also
in your organization, constantly repeating PDCA-cycles on
all levels.

⁸http://adaptivebms.com/Understanding_Lean_A3_Thinking/
What Is Lean? 63

Summary
• Lean originated in manufacturing and is
based on the Toyota Production System.
• Key principles:
– Optimize the whole.
– Focus on the customers.
– Eliminate waste and create flow.
– Build fast and learn fast.
– Keep learning.

To make it more tangible, let us take a look at what lean

looks like on the floor of a factory.
10 The Lean Bicycle Factory
To give you a feeling about what lean is about, I will tell
the story of a fictional bicycle factory. It is pretty similar
to what the guys from VX Company do in their little
book “Stop Starting, Start Finishing”¹. I will also use their
fictional character called Justin Time².

It’s Not Working

Justin starts his new job at a bicycle factory. He notices that

all employees have too much work. There is no pleasure
in what they do, and they are running behind constantly.
The result is that bikes are delivered way too late on every
occasion. Something has to change. But what?

Traffic Jam

The next day Justin gets stuck in traffic on the motorway.

He tries to find out why he is stuck. It is mainly because
of an excess of vehicles that try to go from one point to
another. At night there are less vehicles, and everybody
¹ROOCK (A.). Stop Starting, Start Finishing! 2012.
²This name refers to the most known business strategy derived from the
Toyota Production System http://en.wikipedia.org/wiki/Just_in_time_(business)
The Lean Bicycle Factory 65

can drive fluently. The motorway just doesn’t have enough

capacity to cope with all those cars during peak hours.
Maybe it is just the same with the employees at the factory?
They don’t have enough capacity to cope with all the tasks.
And they react exactly the same as the motorway. The
whole thing jams up and nothing moves.

Visualization

When he finally arrives at the office, he asks all employees

to put their tasks on cardboards and stick them on the
wall. He divides their tasks in different columns. One for
the assembly of the bikes, one for the paint jobs, another
for the gears and brakes, one for the testing and quality
assurance,…
When all the tasks are on the wall, the problem becomes
visible. All departments at the factory are working on a
huge amount of tasks and bikes at the same time.

Work in Progress Limits

As the main issue is the fact that his colleagues are working
on multiple bikes at a time, he agrees together with them
to put a maximum of bikes being worked on for every
department. So only 3 bikes in assembly, 4 bikes in the
painting department,… All the excess unfinished bikes are
put at the front of the assembly line.
The Lean Bicycle Factory 66

The result is satisfying. Everyone is much less stressed, and

cards start moving on the wall. Bikes are finally leaving the
factory.

Pull vs. Push

When one of the departments, for example the paint de-

partment, have no next bike to work on, they give a shout
at the guys from assembly they need a new bike soon.
They know they should focus on finishing one bike as
soon as possible, so their colleagues don’t have to wait too
long. When possible the paint department gives them an
extra hand to finish a bike. They pull new jobs into their
department, instead of constantly being overwhelmed by
too much new work in the past.

Slack

Another thing departments do when they don’t have much

at hands, is optimizing their own work. They maintain their
tools and talk on how to become better craftsmen. Slack is
not being perceived as a bad thing anymore.
The Lean Bicycle Factory 67

Cycle Time

To measure how fast bikes are being manufactured, Justin

starts measuring cycle time³. This is the time between the
start of the first step in the process and the final delivery of
the bike. Before his changes, it took a few months. Now a
bike is completely manufactured in less than a week.

Stop Starting, Start Finishing

Before the work in progress limits, everyone was constantly

starting with jobs. Now they are focussing on finishing
jobs. Where the initial strategy of the management was to
hire extra people to get things moving faster, they now are
producing more value (finished bikes that can be sold) with
the same amount of people.
The same way scrum is a toolbox using agile values, kanban
is a practice that is grounded into lean thinking. Let us take
a closer look.
³http://leanandkanban.wordpress.com/2009/04/18/lead-time-vs-cycle-
time/
11 What is Kanban?
David Anderson started using his Kanban system at Mi-
crosoft in 2004, combining Lean thinking from a production
environment with the learnings he made earlier on apply-
ing agile.

“Kan-ban is a Japanese word that literally

means “signal card” in English. In a manu-
facturing environment, this card is used as a
signal to tell an upstream step in a process
to produce more. The workers at each step
in the process are not allowed to do work
unless they are signaled with a kanban from
a downstream step.”¹

Once again I could start revising all possible definitions of

kanban (and the difference between kanban and Kanban,
with a capital K), but that would take us too far.
Kanban starts with mapping the value chain. So instead of
the 3 columns in scrum (to do, ongoing, done) you visualize
the work by making columns for all the steps in the process.
¹ANDERSON (D.). Kanban: Successful Evolutionary Change for Your Tech-
nology Business, p. 6.
What is Kanban? 69

Photo by Paul Downey. Under Creative Commons licence CC BY

2.0 http://www.flickr.com/photos/psd/7645555148/

In a very basic development setting these would be: analy-

sis, design, coding, user testing, deployment.
What is Kanban? 70

The next step is to set work in progress limits for every step
in the process (cfr. the lean bicycle factory). This is where
you make the big difference with scrum. When you would
just visualize the different steps, it would be nothing more
than an elaborate form of a scrum board, a visual control
system. But by imposing work in progress limits, you add
the lean concepts of pull and flow.
What is Kanban? 71

Note that this is a simplification. On a real-life board you

will also see “to do” or other kinds of backlog bin columns
on the left, and a final “done” column on the right. In
the different columns most practitioners make subcolumns
with to do, ongoing and done. The work in progress limits
then can be set on the main column or the subcolumn, as I
did for the design column in this example.
What is Kanban? 72

The aim of these work in progress limits is to bring forward

where the bottlenecks in your process are. You will notice
right away which value adding activities will have to wait
for others to complete their work. Once you have identified
a bottleneck, you can start working on a solution for it,
thus improving your process. Once you have lifted one
bottleneck, the next one will soon arise, and the process
starts over again.
Notice the parallels with Plan-Do-Check-Act from classical
lean thinking and Build-Measure-Learn from the Lean
Startup.
What is Kanban? 73

Summary
• Kanban is Japanese and means signal card.
• David Anderson started using kanban as a
management tool at Microsoft in 2004.
• Kanban start with mapping the value chain.
• Every step in the value chain gets a work in
progress limit.
• The goal is to identify bottlenecks in your
process one by one and eliminating them.

Let us take a look at how lean and kanban can be used in

an agency environment.
12 Applying Lean and
Kanban in an Agency
Environment
The Lean Startup

This book by Eric Ries¹ was without a doubt the first break-
through for lean on the management shelves of bookstores
around the world. SXSW, the annual hipster conference on
music, film and interactive even devoted a special track to
the book during its 2012 and 2013 editions.²
The idea behind The Lean Startup is to apply lean and agile
principles on startups.
The book (and the movement it started) is a counter move-
ment against the culture of startups raising 5 million dollars
and doing 3 years of development to notice that nobody is
actually interested in the product or service.
The alternative is to build a Minimum Viable Product
(MVP). This is a version of your product or service made
with the smallest amount of work or effort needed to
¹RIES (E.). The Lean Startup. 2011.
²http://leanstartupsxsw.co/
Applying Lean and Kanban in an Agency Environment 75

validate your hypothesis. The idea is to test the product

as soon as possible, even if it’s only 10% finished. You
validate if your unique value proposition gives value to
your customers (value hypothesis), and allows your prod-
uct or service to grow sufficiently to be profitable (growth
hypothesis).
After you release the MVP on the market, you start mea-
suring if your hypothesis are still standing and you try to
get some learnings out of it.
This is what Ries calls a Build-Measure-Learn cycle. (cfr.
the PDCA cycle in lean thinking)
After every cycle you can choose to use the same hy-
pothesis, or to go for a new one. This is called a pivot.
Instead of working out a masterplan (cfr. the masterpiece
mentality), you build a MVP which you adapt through
pivots after every new release. There is a significant chance
your product turns out to be completely different to what
you had in mind initially.
Needless to say that this approach is highly valuable in an
agency.

Business Model Canvas and Lean Canvas

The Lean Startup model is closely related to Alexander

Osterwalder’s Business Model Canvas³, where you plot
³http://www.businessmodelgeneration.com/
Applying Lean and Kanban in an Agency Environment 76

your business plan on an A0 paper. Elements of the canvas

are:

• Value Proposition
• Channels
• Customer segments
• Relationships
• Activities
• Resources
• Partners
• Cost Structure
• Revenue Streams

Creative Commons Attribution-Share Alike 1.0 Generic

http://businessmodelalchemist.com/tools
Applying Lean and Kanban in an Agency Environment 77

Business Model Canvas is all about making a MVP of your

business plan (not a 200 pages document, stop writing,
start talking) and constantly doing a reality check. In other
words, constantly validating your hypothesis in an iterative
way.
Another great book is “Running Lean” by Ash Maurya⁴.
He combines The Lean Startup with the Business Model
Canvas into a Lean Canvas. The book is all about focussing
on how to find out what people really want, without falling
back into too much theory.

Lean Canvas http://ceigateway.com/article/lean-canvas-model

It should not be a surprise that this way of approaching

things is highly applicable in an agency environment.
Instead of building great ideas and concepts, start of with
⁴MAURYA (A.). Running Lean. 2012.
Applying Lean and Kanban in an Agency Environment 78

the smallest inception possible, and start testing it immedi-

ately.
Especially digital projects can easily be tracked and mea-
sured with free tools that give you all the information you
need to validate hypotheses, such as Google Analytics. So
why bother spending money, when you can test the MVP
of your idea before throwing a year worth of budget to it.
It is also a great way for your strategic department to track
in real time if their insights and hypotheses actually make
sense. Instead of doing a big strategic exercise, followed
by a massive creation round, and finished with production,
taking over a year, you can do smaller cycles consisting
of a week of strategy, a week of creation, and 2 weeks of
production, and this 12 times. The big difference is that you
will always be able to apply learnings in the next cycle.

Work in Progress Limits and Lead Time

The same counts for time management: the less things you
do at the same time, the more efficient you become.
Although multi-tasking addicts will try everything to con-
vince you of the opposite, don’t be fooled. The more ele-
ments you add to your work in progress, the less productive
you become.
I will try to illustrate this with Goldratt’s Theory of Con-
straints⁵, interpreted by Jürgen De Smet & Erik Talboom in
⁵http://www.goldratt.com/pdfs/toctpwp.pdf
Applying Lean and Kanban in an Agency Environment 79

their wonderful book “Personal Kanban in a Nutshell”⁶.

Let us start by stating that your Net Profit, is your through-
put (what you produce) minus your expenses. In a formula
this would look like this:

Net profit = throughput - expenses

Let us say your development team works during 1 week

and they are working on 20 tasks at a time. (scenario A)
When they can finish 10 tasks after 5 days, their net profit
is:

10 (throughput) - 5 (expenses, being the

time they spent) = 5

When they can finish 10 tasks after working on 10 tasks at

a time (scenario B), the net profit stays the same.
The big difference however, shows when you start looking
at R.O.I. The return on investment is your net profit divided
by your investment. And every task you started working
on, can be seen as an investment.

R.O.I. = Net profit / investment

In scenario A, your R.O.I. is 5 (net profit) / 20 (investment)

= 0,25
⁶DE SMET (J.) & TALBOOM (E.). Personal Kanban in a Nutshell. 2012.
Applying Lean and Kanban in an Agency Environment 80

In scenario B however, your R.O.I becomes 5 (net profit) /

10 (investment) = 0,5
In other words, when completing the same 10 tasks in one
week, your R.O.I. doubles, just by having half the number
of tasks under “work in progress”.
And this is the true value of kanban. By limiting work in
progress, you don’t elevate throughput, but you maximize
return on investment. You put less stress on the system, and
you create a maximum of flow, giving the people in your
organization room to breath and to excel.
The same is valid for an agency. When you focus on giving
people less projects at the same time, they will be able to
decrease lead time, and thus finish earlier.
And you don’t need to be a rocket scientist to know that
the sooner a project is delivered, the less costs it generates.
Not only pure production costs, but also overhead such as
client services and extra rework.
Applying Lean and Kanban in an Agency Environment 81

Summary
• The Lean Startup by Eric Ries is a perfect
example of how you can apply lean thinking
to an agency environment.
• Business Model Canvas is another way to
visualize a business model in a lean way.
• Work in progress limits are an essential part of
kanban, and the perfect tool to increase return
on investment.
.
Applying Lean and Kanban in an Agency Environment 82

That is enough theory I suppose. The following chapters

contain a number of case studies applying lean and agile in
a creative agency.
13 Case Study: Using the
Agile Manifesto as a Tool
The Agile Manifesto is often criticized being too much a
vague set of principles, not a strict methodology, nor a how-
to guide to use in your day to day practices.
At a leadership retreat hosted by Co-Learning¹, I discov-
ered how to use the manifesto as an analysis tool.
The topic for the retreat was “Team Gelling”. Through a
variation on the Fearless Journey game², participants had
to find problem-solution fits for specific team gelling issues.
At the end of the retreat, it became clear that by combining
root-cause analysis techniques such as 5 Whys³ with the
Agile Manifesto as a Force Field Analysis⁴ tool, you can
increase the ease of finding problem-solution fits.

Where Are the Problems?

When you look at the manifesto, the right column tends to

cover the area where most issues arise.
¹http://www.co-learning.be
²http://fearlessjourney.info/
³http://en.wikipedia.org/wiki/5_Whys
⁴http://en.wikipedia.org/wiki/Force_field_analysis
Case Study: Using the Agile Manifesto as a Tool 84

Problem example: team members are always late for meet-

ings.

Where Are the Solutions?

If you want to use the manifesto as a tool to solve problems,
try looking for solutions in the left column.

Solution example: do not schedule recurring meetings, but

encourage people to talk to each other on an informal basis.
Try to place them physically next to each other.
By focussing your team’s activities on the left column, you
minimize problems and maximize efficiency.

In Practice
I admit, this is still pretty vague. That is why after the
retreat I immediately put this into practice when I was
Case Study: Using the Agile Manifesto as a Tool 85

project manager on a middle sized project. Not explicitly,

but more as a wolf in sheep’s clothing.
For the experiment, I focussed the team on “individuals
and interactions over processes and tools” and “customer
collaboration over contract negotiation”.

How?

Normally we are pretty over the top that EVERYTHING

has to be in the bug tracker. Not now. Important bugs were
detected and resolved face to face and instantly. We tried to
eliminate as much email clutter around scope discussions
as possible.
As development, account manager and project manager
are only 30 feet away from each other, I facilitated the
team so they would do as much face to face conversations
as possible. Only the bare minimum was documented in
the project management tool. Only things that explicitly
needed archiving were documented.

The Results?

The results were great and instant:

• Input for development was delivered early on every

occasion.
Case Study: Using the Agile Manifesto as a Tool 86

• The site was ready 6 days earlier than necessary,

which is a lot in a project lifespan of 2 weeks.
• There were no bugs, issues or feature requests after
go live.
• Everybody happy!

As you see, small adaptations to practices can have spec-

tacular results.
Case Study: Using the Agile Manifesto as a Tool 87

Summary
• The Agile Manifesto itself can also be used as
a tool.
• Problems with team gelling mostly occur on
the right of the manifesto, where solutions
can be found on the left.
• Don’t be afraid to drop tools or other given
things in your organization.
• Dare to try out different approaches.

.
14 Case Study: Scrum for
Rock Bands. How to
Measure Progress When
Recording
The Band Splits

When rock bands go into a recording studio, they don’t

always get the job done the way they want to. It tends to
go as follows:

• They start off with a lot of energy.

• The stakes are high, so they invest a lot of energy in
all the details. They want the best result possible.
• They get stuck on those small details, and lose a lot
of time.
• At the end, they notice a total lack of time to record
everything they need. Even the basic tracks have to
be rushed.
• Quality decreases. The band starts to argue. The
band splits. (This last point is exaggerated, but it is
no exception.)
Case Study: Scrum for Rock Bands. How to Measure Progress When
Recording 89

So what is happening here? There is a lack of focus. There is

no idea at any point on how much work has been done, and
still has to be done. There is no measurement of progress.
At the end everybody panics, resulting in poor quality.
These issues are also common in software development
projects. That is why I used scrum when recording an EP
with one of my bands.

Building a Backlog

At the start of the recording session, the band sat together.

Every instrument that had to be recorded for every song
was written down on a post-it as some kind of user story.
The backlog contained the following types of cards for
every song:

• Pilots: tracks we used as a reference

• Drums
• Bass guitar
• Guitars
• Lead vocals
• Backing vocals
• Keyboards and special effects

Estimating the Weight: Planning Poker

Next, we did a planning poker session. As I didn’t have my

planning poker cards with me, we used our hands to give
Case Study: Scrum for Rock Bands. How to Measure Progress When
Recording 90

estimates.¹
We used the recording of the pilots as the reference for our
estimates. We gave it 3 points. All the other cards had to be
estimated by everyone simultaneously, in relation to the
“pilot card”. I explicitly talked about complexity instead of
time, when rewarding points to cards.
Some examples:

• Lead vocals song 1: 5 points

• Bass guitar song 2: 2 points
• Backing vocals song 1: 4 points
• …

The total count of all the cards in the backlog was 110
points.

Prioritizing the Backlog and Scope Creep

Next step was to put the sticky notes on the windows (the
walls didn’t stick very well), and to prioritize them. Drums
and bass were put at the top, followed by guitars, lead
vocals,… . We used 3 windows: one for “to do”, one for
“ongoing” and one for “done”.
¹Please note that only two of the band members have any affinity with
software development. The others were novels to scrum. But that didn’t cause
any problems. The simplicity of these techniques allows to use them with anyone
who shows involvement and wants the project to succeed.
Case Study: Scrum for Rock Bands. How to Measure Progress When
Recording 91

At this moment our lead singer stated there was a lack of

space for improvisation. So we decided to create an extra
card called “Inspiration”, to give it 20 points, and to put it
at the bottom of the backlog. This way the time-consuming
improvisation part was given a name and deprioritized in
advance in relation to all the other tracks that had to be
recorded.²
It was great to see that scope creep was defeated in advance,
by giving it a name (“inspiration”) and by giving it a weight
– 20 points – in relationship to the other tasks.
²Project managers may notice the analogy with scope creep, where projects
fail because of the constant addition of new features to the scope. The project
runs overtime and the quality decreases.
Case Study: Scrum for Rock Bands. How to Measure Progress When
Recording 92

Measuring Progress with the Burndown

Chart
As I wrote earlier on, the hardest thing when recording is
measuring whether you are on track. Are we working fast
enough? Are we working too fast? Will we finish in time?
We had a fixed timeframe of 5 days (1 sprint) to record
everything for the 4 songs (130 points). So I made an Excel
chart in Google Drive, where the ideal progress was 26
points per day.(130 divided by 5).
Next, I made a burndown chart, plotting the days on the
X-axis, and the points that are burned on the Y-axis. The
red line indicates the ideal progress.

The Result

The first day, we were still on track. Only the second and
the third day our velocity decreased. Mainly because of the
Case Study: Scrum for Rock Bands. How to Measure Progress When
Recording 93

lead vocals that weren’t going as smooth as foreseen. But

as you can see on the graphic, we immediately noticed that
we were putting too much time in those vocals after day
three. Thus we speeded things up a little bit, going into a
hyper productive state the fourth day.
We burned 24 points the first day, 17 points the second
and 19 the third. On the hyper productive fourth day we
managed to burn 46 points. The final day we had only 24
points left. 4 for a keyboard track, and the remaining 20
points for inspiration.
Case Study: Scrum for Rock Bands. How to Measure Progress When
Recording 94

Summary
• Scrum can be used for all kinds of projects,
not only software development.
• Your team can consist of all kinds of people.
They don’t have to be hardcore agilists with
a fetish for charts and post-its (like me). As
long as they are committed and motivated,
they can perform in a scrum environment.
• Give scope creep a name, and talk about it
early in the process.
• Don’t be afraid to experiment with scrum
or other techniques. Even in a “rock’n’roll
environment” they can prove their value.

.
15 Case Study: Using Scrum
with a Hyper Fixed
Deadline
5 years ago, I received a briefing which had the stamp
“mission impossible” in red ink all over it. We had to
design and build a campaign platform for a large Belgian
department store, linked to their second biggest campaign
that year.
It consisted of a general site containing a number of content
pages, a registration module, and a gaming platform aimed
for children. A virtual world where kids could build their
own village. To build the village, they had to buy acces-
sories. To be able to buy these, the kids could win credits
by playing no less than 25 mini games.
Everything had to be built in flash, and high security was
needed for privacy reasons. Next to that there also had to be
an auctioning platform to exchange gadgets, linked to both
the virtual world part, the mini games and the registration.
As the action was linked to offline communication (radio
and print) the deadline was fixed without discussion. An-
other challenge was that design had to be validated by not
only the customer, but also two other parties who were
involved because of legal reasons.
Case Study: Using Scrum with a Hyper Fixed Deadline 96

And to make the story complete, we only had 10 weeks

from briefing to launch.

The War Room

We first decided to take a meeting room and block it for

the next three months, for the whole team to co-locate.
Designers and developers were in the same room as the
account and project manager. A very good practice, as
the HiPPos (highest paid opinions in the office) do tend
to highjack a resource once in a while when one of their
pet projects is running late. This didn’t happen this time,
as entering the war room was rather not done, especially
when everyone could hear it would be to ask something
that was by no means on the planning.
In the room was also the scrum board next to the burndown
charts that were updated daily. At the center were some
comfortable chairs to talk or relax and a large projection
screen.
Case Study: Using Scrum with a Hyper Fixed Deadline 97

The scrumboard for this project.

This worked out great. Every team member could ask

another team member what he or she needed at any time.
This speeded up things considerably. There were much
less confusion about things. Mail was almost banned out
completely in favor of face to face communication.
As we had 2 extra freelance developers on the team, this
was even amplified, as these newbies got to work together
with the others even better and faster.
And let us not forget it also was a lot of fun.
Case Study: Using Scrum with a Hyper Fixed Deadline 98

Bring In the Customer

We had the luck that the customer was working for the first
time with scrum on another project within our company
- the refactoring of all their sites to one large platform -
and just had followed a crash course on scrum and all its
principles. So they were familiar with concepts such as user
stories, burndowns, sprint reviews, etc.
The customer also committed to come to our war room
every single week to attend the sprint review demo. In
other projects we always worked with an account man-
ager/product owner as a proxy for the end customer. But
not in this case. In reality they almost always made it into
the meeting.
The only problem there was that the customer sometimes
sent someone else from the same team, which made it
rather difficult as they weren’t there in the prior review.
But nevertheless the impact was very positive. It meant
instant feedback and it pushed the developers to build
things that work bug free, as the end customer would be
review them sitting next to them.
There was even one occasion that one of the developers
coded a change the customer asked for, in real time on the
projection screen. As it took more time to note it down
and resolve it later then just changing it on the fly. Which
made the customer thrive, as it is something they are not
really used to. Normally they received things through mail,
having to wait to see something change. Now it was instant.
Case Study: Using Scrum with a Hyper Fixed Deadline 99

The Result

With this kind of campaigns developers mostly had to work

nights and weekends to hit the deadline, using free pizza as
bait to keep the guys at work just a few hours more. But not
on this project. Using scrum we managed to be ready one
day prior to launch, which was unseen at the agency for
this kind of projects.
But also the quality aspect has to be emphasized. We
didn’t have one single bug after go live. Of course the
customer asked for a few minor amendments, but no core
functionality had to be changed.
As the customer had been involved very intensively during
the last weeks before launch, no surprises occurred, and
everything went live smoothly.
When you put time and chaos on a graph, you could
visualize a common project as follows.
Case Study: Using Scrum with a Hyper Fixed Deadline 100

Whereas this time it looked more like this.

So no stress in the end. Everybody happy. The marketing

manager from the customer even told our account director
a few weeks after the launch that this was the first time one
Case Study: Using Scrum with a Hyper Fixed Deadline 101

of their campaigns landed so smoothly in more than 7 years

since he worked at the company, working with 3 different
agencies. To receive such a compliment from a customer,
is worth a lot. It shows you the power of agile and scrum
when using it with a customer that is willing to go into the
trenches with you.
Case Study: Using Scrum with a Hyper Fixed Deadline 102

Summary
• Think about physical co-location for impor-
tant projects. A well groomed environment
boosts efficiency.
• You don’t have to work with a proxy product
owner in an agency environment. Educate
your end customer, and involve them in the
process.
• Invert the default practice where involvement
and discussion only occur at the end. Empha-
size collaboration and discussion at the start
of your project.

.
16 Case Study: How to Mix
Scrum and Kanban
After reading Henrik Kniberg’s “Lean from the Trenches”¹,
I was very eager to try his combination of scrum and
kanban on a project. In July 2012 I started a large project
for an international customer. Although the development
partner didn’t have much experience with either scrum or
kanban, we decided together to give it a try.

Why Was This a Perfect Project to

Test-Drive?

The development partner was not explicitly using scrum

or other frameworks. But they worked in a very agile
way without knowing it. All team members were very
good communicators. They liked transparency and used
a lot of common sense. They always deliver early with
good quality, and they prefer people before processes, and
talking before documenting. So there I had a good match.
The project itself needed high quality code. The scope
embodied a campaign platform where users could upload,
¹KNIBERG (H.). Lean from the Trenches: Managing Large-Scale Projects
with Kanban. 2011.
Case Study: How to Mix Scrum and Kanban 104

manage and share content with a rather short lifespan (3

months). A highly secured testing and staging environment
was imposed by the end customer. Next to that the project
had a wide array of functionalities that needed permanent
integration testing during the development.

How Did We Get Started?

First, I made a draft of the kanban board I thought would do

the trick together with the Project Manager. We explicitly
held in mind it would be a first version, and it could be
changed along the way. It looked like this:

I wanted to start as open as possible, in the meantime

using some restraints. The bin contained all the user stories.
Important was the work in progress limit of 5 in the “next
Case Study: How to Mix Scrum and Kanban 105

design” column and the “next development” column. Only

5 stories could be simultaneously in design or development.
Also we agreed on 4 definitions of done.

Next step was building a backlog. We already had a set of

user stories, which were used for defining the budget and
wireframing during backlog grooming. The wireframes
were elaborated and agreed on by the proxy customer (the
account manager that was the spoc for the end customer,
and represented the customer as some kind of product
owner).
I made a new set of user stories, based on these wireframes,
and used them in a sprint planning where all user stories
were discussed, and some were added. We weren’t sure if
we were going to measure progress, and how we would to
that. We did some estimation using planning poker, just to
Case Study: How to Mix Scrum and Kanban 106

get a grasp on the weight of the user stories. And as all good
planning poker sessions, this generated some extra gaps in
the existing user stories which were added and estimated
in their turn.

Did This Kanban Board Do the Trick?

Actually, no. We had only 5-6 weeks for development and
design. After 2 weeks, there was a huge stack of stories
getting stuck in the “design done” column. The proxy
customer could not get approval on the designs from its
customer. As we had no time to waste, and development
had to kick off, we modified the board to the following
layout.

What happened? We reverted the normal approach, and

we started with developing all functionalities in code. We
Case Study: How to Mix Scrum and Kanban 107

deleted the “design” part on the board, and replaced it with

“styling”. This way, we finally could start moving user
stories on the board from the “bin” lane into the next lanes.

The order of the “next 10 dev” column was chosen by the

team, keeping in mind the core functionalities, just like in
a full blown “pull” system. The order of “next 10 styling”
was determined by which designs were agreed on in the
meantime, combined with which user stories had their
development done.

What Was the Result?

Development and design could work simultaneously. The

integration of the first into the latter was placed at the
end of the board. Things started moving from left to
right, and the next review demo contained as well rough
Case Study: How to Mix Scrum and Kanban 108

functionalities as styled functionalities, with the advantage

that both had been tested way more upfront than in the
initial scenario.
All functionalities were ready to go live just in time. The big
surprise was the low number of bugs and issues, probably
because of the coding upfront mechanism and the weekly
demos. The first 2 demos were done on a local environment,
but for the next demo we made sure it was done on the
production environment, which had a positive impact on
the number of defects after going live.
The focus on backlog grooming early in the project also had
the effect that almost no user stories were added at the end.
Even non functional items such as hosting environment
and metrics were indicated clearly on the kanban board
from the start.
The largest advantage of the board however was the fact
that the progress in development was visually clear in every
stage of the project for everyone involved.
Case Study: How to Mix Scrum and Kanban 109

Summary
• Don’t hesitate to use scrum or kanban with
partners who don’t have much experience.
• Scrum can be mixed with kanban.
• Focus on definitions of done and work in
progress limits.
• If the process doesn’t work, don’t be afraid
to turn it around in the middle of a project.
Tailor make your process and keep learning
throughout the project.
• Good visualization always does the trick.

.
17 Case Study: Using a
Visual Control System to
Manage a Portfolio
The prior cases showed examples of agile practices on a
project level. But you can also use lean and agile on a higher
level. In this chapter I will show how you can manage the
portfolio of a whole department.
At our agency, I try to communicate as much as possible
about ongoing digital projects with my manager. We try
to meet each other at least once a week to have a status
about ongoing projects, possible new briefs, learnings from
completed projects and possible risks that might occur.
When we first started doing this, I just had a list of all
projects that I ran through, pointing out the status and
relevant information. As time is pretty scarce, and we both
have a pretty tight schedule, this soon became a problem.
Running in detail through all projects took too much time,
and we overly focused on details, instead of talking about
what really mattered.
Case Study: Using a Visual Control System to Manage a Portfolio 111

A Visual System

So I started using a large movable whiteboard as a visual

system for these meetings. It roughly looks like this:

Instead of putting user stories on the board, we use cards

for every project. The different columns have a specific
meaning.

• Pipeline: all projects creatives or other colleagues

have been asking feasibility questions or rough es-
timates about.
• Proof of concept: all projects my creative technolo-
gists have been working on together with the cre-
ative teams to make small proof of concepts.
Case Study: Using a Visual Control System to Manage a Portfolio 112

• Budget/scope: all projects where our digital produc-

ers are working on defining scope or budgets before
going into production.
• Budget ok: all projects where the client has agreed
on budget, but which haven’t had a kick-off yet.
• In production: all projects that are currently in pro-
duction.
• In evaluation: all projects that were delivered but still
have to be evaluated.
• Done: there is no work left on the project.

When we do our status now, we use the board as visual

system to talk about all projects. This speeds the process
up considerably. What would take 30 minutes without the
board, now takes only 5 minutes. The overview is also a lot
more complete. Especially the items in “pipeline” or “proof
of concept” were not so emphasized before we used the
board.

Side Effects

The use of the board has a few positive side effects. First of
all, the board is in front of my desk, so every time I look at it,
I get an instant overview of all projects, without having to
look into my time management system to look if everything
is still on track.
Case Study: Using a Visual Control System to Manage a Portfolio 113

It also has an influence of the rest of the agency. Often

people stop in front of the board, and take a look. When
they see something that might interest them, they ask
questions and get involved. Out of the blue. Without any
extra effort.

Next Steps

I am only using the board since a few months. I already

altered the columns and the layout a few times. The next
step would be to impose work in progress limits. This would
turn it from a mere visual control system into a real kanban
board. As soon as I start imposing work in progress limits,
bottlenecks should occur.
Case Study: Using a Visual Control System to Manage a Portfolio 114

I also started to put start dates of projects on the index

cards, to measure lead and cycle time. I haven’t done any-
thing with the data, but that would also be an interesting
next step.
Case Study: Using a Visual Control System to Manage a Portfolio 115

Summary
• You can use visual control systems not only
for projects but also on a higher level. For
departments or even for your whole organi-
zation.
• A visual control system helps you to be trans-
parent, inspect and adapt.
• Visualization in the office affects the whole
or your organization. People are curious by
nature.
.
18 Case Study: Why You
Should Play Games at
Work. Gamestorming for
Retrospectives
Bad retrospectives

Retrospectives are not only essential to scrum, but to every

agile or lean practice. Reviewing the process frequently
and constantly in an iterative way is key in a learning
environment.
But most of the time, retrospectives are just “classic” meet-
ings:

• Too many people.

• A lot of talking by a few people.
• Little interaction from the majority.
• No clear agenda.
• No actionable outcome at the end of the meeting.
• …

(I could go on a few pages)

Case Study: Why You Should Play Games at Work. Gamestorming for
Retrospectives 117

Next to that, classical meetings tend to procrastinate, lead-

ing to more meetings, without real decision making. People
just see it as a moment to vent frustrations for a few
hours. But not as an opportunity to look for actionable
improvements.

Good Retrospectives and Gamestorming

But there are alternatives. The essence of a good retrospec-

tive, is the fact that it leads to action¹. One of the most pow-
erful tools for generating action-oriented retrospectives is
gamestorming.
Let us take a look at the wikipedia definition of gamestorm-
ing:

“Gamestorming is a set of practices for facil-

itating innovation in the business world. A
facilitator leads a group towards some goal
by way of a game, a structured activity that
provides scope for thinking freely, even play-
fully.”²

This book is not about gamestorming, so if you want to gain

more insights, be sure to take a look at the 2 most important
¹http://brodzinski.com/2011/11/good-retrospective.html
²http://en.wikipedia.org/wiki/Gamestorming
Case Study: Why You Should Play Games at Work. Gamestorming for
Retrospectives 118

books: “Gamestorming”³ and “Innovation Games”⁴.

The core of gamestorming is that you use games (with a set
of rules, an opening, a game and a closing) to brainstorm,
conduct meetings, do user experience sessions,… And they
are especially suited to evaluate projects and processes.

Actions for Retrospectives

When first starting with gamestorming I tended to use the

same set of games, but after I while I created a specific
version of “Actions for Retrospectives”⁵ which works pretty
good for project evaluations.
You start with gathering people in a room for a fixed period
for example 1 hour. It is important you start without delay
and that the timebox is fixed.
For project evaluations I try to get the creative team into
the room, the digital producer, the account manager, the
project manager, the designers & developers. I like to use
7 as the maximum for the number of people, following the
“Two Pizza team” rule from Jeff Bezos.⁶
Actions for retrospectives works with the following quad-
rant.
³GRAY (D.), BROWN (S.) & MACANUFO (J.). Gamestorming: A Playbook
for Innovators, Rule-breakers, and Changemakers. 2010.
⁴HOHMANN (L.). Innovation Games: Creating Breakthrough Products
Through Collaborative Play. 2006.
⁵http://innovationgames.com/actions-for-retrospectives/
⁶http://zurb.com/word/two-pizza-team
Case Study: Why You Should Play Games at Work. Gamestorming for
Retrospectives 119

You give everyone in the meeting a set of post-its. They

each time get a few minutes to think of:

• ”:)”: Things they liked in the process.

• ”:(“: Things they disliked.
• Flowers: Specific people or practices they would like
to compliment.
• Ideas: What could we do better next time?

Everyone puts the sticky notes on the wall, briefly stating

what he or she has written down.
Case Study: Why You Should Play Games at Work. Gamestorming for
Retrospectives 120

Two results of an actions for retrospectives gamestorming session

You repeat this each time for each of the quadrants. At the
end you try together to distill the most important items and
make an action out of them. Every action ideally has:

• An owner: Someone who takes responsibility to make

it happen.
• A fixed moment when the action will be completed.

What Happens When You Start

Gamestorming

First of all, don’t tell people that they are gamestorming.

Just put the sticky notes in their hands, and let them do
Case Study: Why You Should Play Games at Work. Gamestorming for
Retrospectives 121

their thing. You will be surprised how little opposition you

will get.
Next you will notice that the more introvert people on a
project really thrive on the fact that they can give their
opinion in a safe environment. The fact that people can talk
about a project adds great value to team spirit and mutual
respect.
You will also notice patterns that emerge. When we did 3
large retrospectives at the start of 2013, it was interesting
to see that all of them ended with the same kind of actions.
They were about:

• The need to define a design owner at the start of the

project.
• Better cooperation concerning UX between the UX
team and the designers and developers at the early
stages of the project.

Another nice add on was the fact that these retrospectives

were well documented (reports with key facts and pictures)
and shared within the organization.
Case Study: Why You Should Play Games at Work. Gamestorming for
Retrospectives 122

Summary
• Retrospectives are key in a learning organiza-
tion.
• Retrospectives give a voice to everyone, not
only the extravert.
• After a while retrospectives reveal patterns.
• Good retrospectives have clear actions as an
outcome.
• Gamestorming allows you to make retrospec-
tives efficient and fun to do.
.
19 Case Study: Why Stop
with Production?
Mapping Iterative Working on the Whole
Value Chain

Most of the examples I used until now are applications

from lean and agile practices on digital production. Of
course you can also go one step further and apply iterative
thinking on your whole value chain.
The value chain in most creative agencies mostly looks like
this.

If we apply the agile mindset just to the production part, it

would look something like this.
Case Study: Why Stop with Production? 124

If we want to bring iterative practices into the organiza-

tion, you immediately see where the big opportunity lies.
Exactly. We should embody the idea conception also in the
iterations from production, which would look like this.

Seems pretty logical no? Then why are so few people

working like this?
Case Study: Why Stop with Production? 125

Google and Their Agile Creativity

Google came up with exactly the same approach in August

2012 on thinkwithgoogle.com and called it Agile Creativity.
Google lists up 7 agility tips to use in agencies.

• Physically (or Virtually) Co-Locate.

• Add Technologists to the Creative team.
• Develop T-shaped Talent.
• Get “Real-Time” Insights (the Minimum Viable Brief).
• Plan an Offsite “Idea-thon” (Hackaton Mode).
• Iterate and Test Campaigns (Campaign Prototyping).
• Partner on Pilot Projects (Beta Testing with Clients).

When you take a look - especially at the second bullet about

adding technologists to the creative team - you notice how
close this gets to the model on the previous pages.
Physical or virtual co-location is a no brainer. It is clear that
lean and agile practices are strongly in need of co-location.
Adding technologist to the creative team is a new con-
cept. Most advertising agencies still work with the default
copywriter - art director team and apply the masterpiece
mentality. Although you start seeing Creative Technologist
in a lot of agencies, it is not the mainstream approach.
T-shaped talent is a very useful concept. The general idea
is that people all have their core knowledge combined with
a broad knowledge about other relevant topics.
Case Study: Why Stop with Production? 126

Hackatons are about learning your people how to quickly

prototype ideas and test them and getting them in the right
frame of mind for campaign prototyping.
So why not try this on a project?

Mindtunes. Agile Creativity Applied.

One of the concepts of Agile Creativity is simple: change

the archetypical team of art director and copywriter, by
adding a technologist. So art+copy becomes art+copy+code.
Google started talking about agile creativity in August
2012, but went a step further when last March they launched
their “Art, Copy and Code“-project, as the follow up for the
highly acclaimed Project Re: Brief.
Case Study: Why Stop with Production? 127

One of my agency’s key projects in 2013 happened to be a

perfect example of art, copy and code. The basic idea was
to make it possible for physically disabled people to make
music with their brainwaves. This idea in its purest form
came from such an archetypical team. From the moment
the idea was mentioned, we immediately teamed them up
with a developer.
In order to explore the idea as quick as possible, we ordered
the cheapest EEG headset we could find, to try out the
technology and acquire affinity. The next step was to take
this into production, and we started collaborating with a
neurotechnology expert and an Ableton (music software)
programmer.
But we didn’t remove the developer from the team after
production started. This is where the most interesting
stuff happened. The developer became like a technological
addendum to the team. He kept following the project and
kept working as an equal team member together with the
art director and the copywriter. And this was where the real
magic happened. It allowed the whole team (also account
managers, project managers, etc.) to have a continuous
point of contact for everything related to technology and
its impact within the project. Pushing the overall quality of
work to an unseen level.
Be sure to check out the documentary about this project on
YouTube.¹

¹http://www.youtube.com/watch?v=PgfxKZiSCDQ
Case Study: Why Stop with Production? 128

Summary
• You can apply agile and lean thinking not
only to production, but to the whole value
chain in an agency.
• Google acknowledged this with their con-
cepts “Agile Creativity” and “Art, copy and
code”.
• Add technologists to your creative team.

.
20 Case Study: Culture
Hacking. Why Agile and
Lean Actually Work in an
Agency Environment
I remember very well the first time I used scrum on a
project. I was surprised about how well it worked, and how
big the difference was with the waterfall approach. And
ever since, I had this same feeling when trying out new
stuff such as gamestorming or kanban.
But how come this stuff actually works so well? When I
heard Stefan Haas talk about “Culture hacking”, I suddenly
had the impression that this was the link I was missing all
the time.

What is a Culture Hack?

Let’s take a look at the definition on the biz culture hackers

site.

“Culture, like language, is an adaptive self-

organizing complex system. Metaphorically, it
Case Study: Culture Hacking. Why Agile and Lean Actually Work in
an Agency Environment 130

is the operating system of an organization

which cannot be changed by simply apply-
ing “best practices” or “new rules”. Ideas are
agents within the cultural system. A culture
hacker uses observation and empathy to sense
cracks within the cultural system.

A crack is something which feels uncomfort-

able. It feels like tension, perhaps a conflicting
idea or assumption, which would be revealed
by or could serve as a leverage for the hack.

A culture hack is the minimal, artful interven-

tion which, if successful, influences the culture
of an organisation by making use of the crack.
A hack consists of activities creating events
that have the potential to change a prevalent
idea or assumption, e.g. by introducing narra-
tives telling a different truth.”¹

The more you will explore in the world of lean and agile,
the more you will notice that it is not about these practices,
but about the way they change your company’s culture.
You could look at gamestorming for example as a culture
hack. The “crack” would be the boring evaluation meeting.
By applying gamestorming, you hack this boring meeting,
¹http://bizculturehackers.com/a-culture-hack-is/
Case Study: Culture Hacking. Why Agile and Lean Actually Work in
an Agency Environment 131

and turn it into something that changes the way the system
of your organization works.
Another important part of hacking is “playfulness”.

“The act of engaging in activities in a spirit

of playfulness and exploration is termed hack-
ing.”²

You will have noticed that scrum for example is more or

less like a game, with a begin, an ending and a set of rules.
All culture hacks show this same element of play.
Common in most practices described in this book is visu-
alization. The mere fact that work in progress is visualized
on the wall and not in some project management system
that nobody uses, is a perfect example of a hack. You put
the scrum board right in front of people. They don’t know
what happens, but after a while they use it as if they never
worked with something else.
Haas also makes the link with art. For example the Chinese
contemporary artist Ai Weiwei. He uses cracks in the
Chinese culture and hacks them with his controversial art.
The same can be said about the dadaïst movement, which
emerged after the first world war as a reaction on the
atrocities of war. They used everyday culture - think of
Duchamp’s urinoir - to hack society.
²http://en.wikipedia.org/wiki/Hacker_(programmer_subculture)
Case Study: Culture Hacking. Why Agile and Lean Actually Work in
an Agency Environment 132

The same system of looking for cracks and applying hacks

is a way to look at how agile and lean influence your whole
organization.
I will give two very specific examples of culture hacks I
applied in my current organization.

The Pop-up Inspiration Session

In creative agencies much is being talked about the im-

portance of knowledge sharing. People should constantly
inspire each other. At our agency this was the case as
well. Different sessions were booked in calendars weeks
on beforehand. But every time the sessions were cancelled
because of some important briefing or something else.
Another problem that is was impossible to block all agen-
das of all employees at the same time. “That wouldn’t
work” I was told. So it was time to try something else.
We did a pop-up inspiration session. Instead of announcing
it 3 weeks in advance, we only sent an email the day before.
Instead of doing a 3 hour session, we tried to tell people 30
minutes about a certain subject, focussing on demoing the
technology and hands on experience.
The result was inspiring. Almost everybody showed up,
especially because of the new nature of the session. We
didn’t call it “inspiration session”, but talked about a “magic
technology performance”. And the fact that it wasn’t in
Case Study: Culture Hacking. Why Agile and Lean Actually Work in
an Agency Environment 133

the agendas as another meeting request, only made it more

appealing to attend.
A nice example of how a culture hack works.

The Digital Production Checklist

Every few months I try to have a moment with the ac-

count managers and digital producers at our company.
We already evolved from a boring meeting to a “lessons
learned” approach, where we share best practices and
lessons learned from past projects. Simply a debrief of the
retrospectives basically.
But nevertheless the same little mistakes tended to happen
on projects. So I distilled 8 best practices into a list, inspired
by CP+B’s Producers Mixtape.³
At CP+B they made checklists for every type of project
with things that had to be kept in mind. They updated the
checklists regularly, and printed them out, making them fit
in a audio cassette jewel box so everyone could take them
with them easily.
When personnel left the company they took the mixtapes
with them. At the start the management at CP+B didn’t
like it, because they put a lot of effort in it. But after a
while they embraced the idea, and they even put all the
checklists online on http://producersmixtape.com/. They
³http://producersmixtape.com/
Case Study: Culture Hacking. Why Agile and Lean Actually Work in
an Agency Environment 134

even included a 3D model of the jewelcase, so people can

print their own version of the case.
Inspired by CP+B, I made a similar checklist for account
managers and digital producers.

Working together as account managers and

digital producers, we will always:

1. Seek for a solution in a constructive way.

2. Talk about feasibility of a concept or idea
before sending it to the customer.
3. Agree on budgets before sending any
detailed quotes or forks to the customer.
4. Tackle campaign goals, KPI’s and the
measurement of those KPI’s before the
start of production.
5. Do project kickoffs together as equals.
6. Do everything to make room in our agenda
if the technical partner wants to evaluate
a project after launch.
7. Do QA together, before putting material
online (websites, mailings, banners, ap-
plications, …)

After presenting the list to the group, I handed out a version

of the checklist printed on a business card. Although every-
body first laughed at the idea, they all took the checklist
with them. Some of them have sticked it to their computer
screen, others have put it in their wallet.
Case Study: Culture Hacking. Why Agile and Lean Actually Work in
an Agency Environment 135

It is also a tool I now use to introduce new people on the

team in how we work together. A nice hack to build a
sustainable culture.
Case Study: Culture Hacking. Why Agile and Lean Actually Work in
an Agency Environment 136

Summary
• A culture hack is the minimal, artful inter-
vention which, if successful, influences the
culture of an organisation by making use of
the crack.
• Culture hacking implies playfulness.
• Most agile and lean practices are examples of
culture hacks.
.
21 Conclusion
I am strongly convinced that all the tools and frameworks
in this book actually work. But they only work when you
use them with the right mindset. Scrum or kanban are not
about dogmatically following a set of rules. They are about
changing your company’s culture.
Some of us agilists and lean people are going through the
same evolution. Where congresses 5 years ago were about
the cards on the wall, they are nowadays about culture and
how you must dare to change it.¹
It is not just about manufacturing or production anymore.
Agile and lean are growing mature, and are now ready
to be applied in a whole field of disciplines in multiple
ways. I believe that the complex nature of creative agencies,
combined with the current economical situation, will force
us to start behaving like agile agencies. The example of
Mindtunes shows that relevant and innovative campaigns
can only grow on agile agency cultures.
And that is the reason why a hope this book can be
relevant inspiration for everyone who is working in this
¹http://www.belgiancowboys.be/technology/durf-je-organisatie-te-
veranderen-wij-spraken-met-jurgen-appelo-ceo-van-happy-melly-tijdens-
dare-2013-interview/
Conclusion 138

field. Agencies but also clients. It will only show its fullest
potential when there is a buy-in from all parties involved.
In the end you want highly productive people in your
organization. And when are people most productive? When
they are happy and motivated. Daniel Pink states that
people need three things to be truly motivated. Autonomy,
mastery and purpose.² Lean and agile offer the people
in your organization the tools to have more autonomy,
develop their skills and have a clear goal.
So you want to start tomorrow? Be sure to keep the
following in mind.

• Drop the masterpiece mentality. Start working iter-

atively.
• Stop writing and start talking.
• Make things visual. Dare to put paper on the wall.
• Don’t be afraid. Fail early. Learn early.
• Have fun!

I am perfectly aware of the fact that some aspects were

neglected in this book. Lean UX for example. The idea of
lean campaigning³ and applying lean to your marketing
strategy is also worth more pages. Dare to send me your
comments and ideas, so I can use them in the next iter-
ation of this book. Engage via Twitter using the hashtag
²http://www.bartvermijlen.com/scaling-agile-at-spotify-and-daniel-
pinks-drive/
³http://www.andrewcoyle.com/blog/2013/02/25/lean-advertising-the-new-
consumer/
Conclusion 139

#theagileagency, or leave a comment on http://leanpub.

com/theagileagency.
Epilogue
The famous talk by John Cleese on creativity⁴ is one of
the best I ever saw on the subject. Without knowing, he
perfectly describes the importance of applying an agile or
lean mindset to your creative process.
In his opinion, creativity is not a talent. It is a way of
operating. It is not an ability that you either have or not
have. It is not related to your IQ. Those regarded by their
peers as most creative are not different in IQ than their
“non-creative” colleagues.
So where does the secret lie? The most creative have
acquired the ability to get themselves in a particular mood
- a way of operating - which allows their natural creativity
to function. An ability to play. He even draws the parallel
with Japanese business culture, saying that their success is
built around the ability to plan unstructuredness.
And that perfectly summarizes the importance of agile and
lean for your creative organization. Embrace complexity
and your creativity will skyrocket.
⁴https://www.youtube.com/watch?v=AU5x1Ea7NjQ
Bibliography
ANDERSON (D.). Kanban: Successful Evolutionary Change
for Your Technology Business. 2010.
ANDERSON (D.). Lean Software Development. 2011.
APPELO (J.). How to Change the World. 2012.
APPELO (J.). Management 3.0. 2011.
AVERY (C.). teamwork Is an Individual Skill: Getting Your
Work Done When Sharing Responsibility. 2001.
COHN (M.). User Stories Applied: For Agile Software De-
velopment. 2004.
COLLINS (J.). Good to Great: Why Some Companies Make
the Leap… and Others Don’t. 2001.
DE SMET (J.) & TALBOOM (E.). Personal Kanban in a
Nutshell. 2012.
FRIED (J.) & HEINEMEIER HANSSON (D.). Rework. 2010.
GRAY (D.), BROWN (S.) & MACANUFO (J.). Gamestorm-
ing: A Playbook for Innovators, Rule-breakers, and Change-
makers. 2010.
HOHMANN (L.). Innovation Games: Creating Breakthrough
Products Through Collaborative Play. 2006.
Bibliography 142

KNIBERG (H.). Lean from the Trenches: Managing Large-

Scale Projects with Kanban. 2011.
KNIBERG (H.). Scrum and XP from the Trenches. 2007.
LIKER (J.). The Toyota Way: 14 Management Principles
from the World’s Greatest Manufacturer. 2003.
MAURYA (A.). Running Lean: Iterate from Plan A to a Plan
That Works. 2012.
PINK (D.). Drive: The Surprising Truth About What Moti-
vates Us. 2009.
POPPENDIECK (M. & T.). Lean Software Development: An
Agile Toolkit for Software Development Managers. 2003.
RIES (E.). The Lean Startup. 2011.
ROOCK (A.). Stop Starting, Start Finishing! 2012.
SCHWABER (K.). Agile Project Management with Scrum.
2001.
SUTHERLAND (J.) & SCHWABER (K.). The Scrum Guide.
The Definitive Guide to Scrum: The Rules of the Game.
2011.
WOMACK (J.), JONES (D.) & ROOS (D.). The Machine
That Changed the World: The Story of Lean Production.
Toyota’s Secret Weapon in the Global Car Wars That Is
Now Revolutionizing World Industry. 1990.
WOMACK (J.) & JONES (D.). Lean Thinking: Banish Waste
and Create Wealth in Your Corporation. 2003.