Luxshan Ratnaravi & Mikkel Noe-Nygaard

Forewords by Kent Beck and Dave Snowden

 For all the agile spirits

who keep fighting to improve their organizations

Contents
Foreword by Kent Beck 5 Powerful Questions 35
Root Cause Analysis 36
Foreword by Dave Snowden 6
The Scrum Values 38
Preface 9 Scrum Patterns 39
Introduction 10 No Sprint Goal? 40
Agile Metrics 42
How to Read the Book 11 NoEstimates 43
1. Transformation 12 Metrics Dashboard 44
The 'Why' of Going Agile 13 Cynefin 45
The Transformation Plan 14 Servant Leadership 46
The Quest 15 Spill-Overs 47
Hierarchy 16 Improvement Kata 48
Agile HR 17 Escalating Impediments 49
Agile Island 18 Unblocking 50
The Agile Line Manager 19 Sub-Teams 51
Psychological Safety 20 Little's Law 52
Penelope Prince 21 Capacity 53
The Agile Project Manager 22 Progress Reporting 54
The Agile Triangle 23 3. Product Owner 56
The Agile Process 24 High-Level Estimates 57
Post-Transformation 25 SPoC 58
The Snap 26 Done 59
2. Scrum Master 28 Prioritization 60
Let's Call It... 29 How to Prioritize 61
The Scrum Master We Need 30 Story Slicing 62
Manager vs. Sprint Backlog 31 PO from the Business 63
The 9th Stance 32 The Journalist PO 64
CFD 33 Say 'No' 65
Daily Scrum 34 The Goal-Oriented Roadmap 66
Features, Features, Features 67

3
 Empowering the PO 68 Agile Consultancy 103
The Anatomy of Estimates 69 The System Team 104
Feature Toggling 70 The SAFe Requirements Model 105
Product Discovery 71 Agile PMO 106
Descaling and POs 107
4. Team 72
Spotify 108
Skateboard 73
The Program Backlog 109
Team Velocity 74
Value Streams 110
Technical Debt 75
The Force 111
Retrospective 76
The SAFe PO Prison 112
Jira vs. Azure DevOps 78
The Background of RTEs 113
DevOps 79
Business Owners 114
WIP Limit 80
The Unagile Release Train 116
Test-Driven Development 81
An UnSAFe Protest 118
Mob Programming 82
Delegation Poker 83 6. Miscellaneous 120
Ready 84 Agile at Home 121
The Stable Team 85 The UX Specialist 122
Reasons for Reorganization 86 Agile Meetup 123
The Self-Managing Team 87 Diversity 124
Sprint Planning vs. Hackathon 88 Return to Snowbird 126
The Story 89 The Comic Agilé Manifesto 127
Ideal Developer Days 90 The Scrum Guide 129
Team Topologies 91 How to Become an Agile Coach 130
Bottleneck 92 PRINCE2 Agile 131
Team Sunshine 93 Waterfall Shaming 132
Agile Budgeting 94 Conway's Law 133
The Distributed Monolith 134
5. Scaled Agile 96
The Program Board 97 Afterword 135
PI Objectives 98 About the Authors 136
The Scaled Agile Showdown 100
New Silos 101 Acknowledgements 137
Guide to Scaling Frameworks 102

4
Foreword
by Kent Beck

Rage, despair, joy, laughter—the pages you are about to view gave me an
emotional roller-coaster ride.

• Laughter. The absurdity of software development, the almost-infinite

leverage colliding daily with the almost-infinite creativity we apply to
screwing it up, leaves laughter the most sane response.

• Joy. Geekiness finds a way. Warms my heart to see examples in these

pages of people reaching out to meet each others' needs despite the many
gratuitous obstacles.

• Despair. These pages document the many ways software development is

as bad or worse than it was 30 years ago. How could we have set out with
such energy, such high aspirations, and failed so utterly?

• Rage. Ultimately, anger is the most useful emotion I took away from my
reading. Software development could be so much more for so many
people - programmers, users, testers, purchasers, managers, investors,
and, ultimately, society. Dissatisfaction is the seed of change.

Augusto Boal believed catharsis was a tool of oppression. Watching the

overseer get his comeuppance on screen reduced the desire to balance the
scales in real life. His dream was a Theater of the Oppressed that incited
change. I dare you to read Comic Agilé in that spirit.

Kent Beck

Creator of eXtreme Programming,

co-signer of The Agile Manifesto and
fellow at Gusto.

Photo: Rob Ao Opiyo

5
Foreword
by Dave Snowden

I still remember the first set of cartoons I saw, and I can't have been more
than four or five years old. My parents loved the Giles cartoons from the
Daily Express, and a standard Christmas present, bought on my behalf by
my mother for my father, was the annual collection of the best of his work.
They hated the politics of the Express, as did Giles himself, but needs had to
be met, and they offered him the handsome salary of 20 Guineas a week. A
year after I was born, Giles was earning the equivalent of around €200k for
producing three cartoons a week.

Political and social commentary cartoons have been a part of my life from the
iniquitous Dilbert to the more culturally specific Alex, not to mention the
Peanuts in the 70s when I was at university.

By the time I moved from a strategy role to a research and development one
(following the IBM takeover of Data Sciences), I had moved from enjoyment
to active use and a greater understanding of how cartoons would work in
sense-making in general. We developed a body of methods and tools to
extract archetypal characters from the day to day anecdotes of the employees
of an organisation and used cartoonists for the final representation. That
resulted in interesting work where managers would have to confront the
difference between the archetypes they had of the organisation and those of
their employees. The archetype cartoons provided a powerful indicator of
culture that people found easy to engage with. Indeed, the archetypal
characters ended up as advanced emoticons on internal chats and became a
part of the overall language of the organisation—in effect, allowing people to
have conversations through the medium of the cartoon characters. If you
want a fancy word for all of this, it's semiotics, and it's of growing
importance in the wider field of distributed sense-making.

So, when confined to my home thanks to COVID-19, and Comic Agilé started
to appear on social media, I had a natural affinity to the medium. The
cartoons, themselves, were the essence of this approach to meaning-making.
They are humorous and, to a degree, painful, they make you think differently

6
about things you took for granted, and provide new insights and
understanding. Like all good sets of cartoons, they have their different types,
but every character is, to quote Dylan Thomas in Under Milk Wood, “not
wholly bad or good”. These are the essence of archetypal characters that you
find in all storytelling traditions. The audience recognise a little bit of
themselves in every character. Stereotypes are cruel, archetypes ask
questions, and Comic Agilé does that well.

I forget from time to time how 'young' the cartoons are, and I suspect over
time, as with all such work, the archetypes will become more archetypal and
recognisable—you can see this in Peanuts and Dilbert if you compare early
with later work—as they do have the potential to become a part of the
language of the agile movement as a whole.

Another key aspect of any cartoon canon is that its authors are well-versed in
the field and have wider access to the various stupidities and inauthenticities
that are a part and parcel of corporate life and rich fodder for the cartoonists.
I remember Scott Adams saying that he needed to seek no further for
inspiration than the emails that came in daily from people confined to
cubicles, victims of the pointy-haired Boss and Catbert. I suspect that this
will also be true for Comic Agilé as they grow and expand. The more they
call out self-righteousness and hypocrisy in an increasingly commoditised
movement, the better and more influential their work will become.

However, there is always a balance to be struck between being legitimate

satire and downright sadistic cruelty. One of my favourites is the response to
the Kanban Cumulative Flow Diagram; when asked if it tells people how
they are doing, the response received is: “I have no idea, but I like the
colours”. That is perfect. For anyone who has spent any time in marketing,
you know that presentation is 80% of the battle over content. If it looks good,
people are predisposed to like it. The cartoon makes you aware of that and
triggers memories, and also it gets reflected in current action. The battered
Scrum coach on crutches with a bandaged foot, head and a black eye or two
having received 'powerful answers' in response to asking 'powerful
questions' is a delight and seek out the one on root cause analysis to see why
many of us think that technique is contextual in its application.

All of this says that it was a pleasure to be asked to write the foreword, and I

7
didn't realise until after I had accepted the link to Aarhus, one of my
favourite Danish cities (and quite different from Copenhagen). I remember
turning up there once after an over-indulgent conference in Florida. One of
those where you have a few thousand people in the audience, and they all
line up afterwards to shake your hand and tell you how they have
transformed their lives. You know they don't mean it, but it is an indulgence.
For those audiences, you might get over one or two points, but have to tell
lots of stories. I then flew into Aarhus to an evening lecture at the university
and forgot that, in a Danish audience, you need several points and only a few
stories, and the last thing you should do is provide the sort of 'motivational'
speech that is de rigour in other countries. As a result of this failure, I
discovered the full horror of the Law of Jante, which translates elsewhere as
tall poppy syndrome. I was cut down to size in no uncertain manner, but
they were oh, so polite!

Comic Agilé is in the tradition of the Law of Jante, and I commend it to you.

Dave Snowden

Creator of the Cynefin framework, thought leader

within complexity science and knowledge
management and founder of Cognitive Edge.

Photo: Cognitive Edge

8
Preface

Thank you for buying our book and joining us on a mission of agile
edutainment.

Our journey started in 2016 where we met as part of the same Scrum team in
Vestas, the global leader in sustainable energy solutions, based out of Aarhus,
Denmark, where Luxshan had the role of Product Owner and Mikkel that of
UX-er. Magic arose instantly—we'll spare you those details—and we quickly
started making small provocative comic strips that could act as a release for
our frustrations and discretely put them up around the most used coffee
machines. And people liked them.

During the first lockdown in Denmark in March of 2020, we started sharing

our work online and were blown away by the response. So, to accommodate
our newly found addiction to triggering a dopamine release through our
comic, we had to create more strips. And more. And even more, until,
suddenly, we had enough to make a book!

Feel-good hormones aside, what really drives us to depict the moments

where agility meets reality is that they are learning opportunities. Our
ambition is to help all agile practitioners, companies and communities
unlock the full potential of the agile ways of working, thus, creating a world
of happy people that make lovable products for ambitious customers who
improve the lives of all of us.

This book is our humble contribution to that.

Enjoy,

Mikkel og Luxshan

NB: Don't forget that our journey continues

on LinkedIn (“Comic Agilé”) and our website
(ComicAgile.net), where we release new
comic strips on an ongoing basis.

9
Introduction

Why does agility clash with reality? Why can't we just take, say, Scrum,
implement it and reap the benefits? Aren't we light years past Taylorism and
the industrial age, so that, today, the agile mindset doesn't conflict that much
with how we run companies?

What we see is that companies still keep running their heads against a brick
wall of waterfall mentality. The lack of willingness to make systemic changes
causes any serious agile initiative to end up as a lackluster attempt to sub-
optimize parts of the organization. We even see agile transformations
executed as waterfall projects instead of as iterative and incremental changes
that are expanded organically.

So, what should we do about this misery? Well, we have all talked about
fixing agility for quite some time, and that did not cause any real behavioral
change. Our hypothesis is that depicting the specific instances of reality
ruining the intention of agility can trigger the reflections needed to go back
and make it work. This process is represented in the world-renowned Comic
Agilé LRFS Cycle™ as seen below:

By 'edutaining' through our comics strips, we hope to entertain you, make

you reflect on how you adopt agility in the context of your company, and
potentially trigger a little bit of frustration if agility doesn't work properly for
you currently.

Ultimately, our aim is to motivate you to make the needed changes in order
for your organization to fully harvest the wonderful benefits of working
agile. Our way of doing that is by creating comic strips with accompanying
advice.

10
How to Read the Book

There is no right or wrong way of reading this book. Either, you can start
from the following page and continue reading until the last page, or you can
go back to the Contents and find the exact scenario that you want to explore.

If you need a specific strip digitally in high-res, let us know, and we will
provide it to you free of charge, so you can use it in your presentation, pitch,
course, handout, or similar (as long as you attribute it to Comic Agilé /
comicagile.net).

If you recognize an anti-pattern and do not feel that the accompanying text is
sufficient for you to take action on it and fix it, feel free to reach out to us
through email ([email protected]) or LinkedIn (search for Comic Agilé),
and we will provide you with some tips and tricks to overcome the
challenges in your specific context. What's the prize, you ask? Well, that you
might end up in a comic strip.

11
1. Transformation

The misery begins.

12
The 'Why' of Going Agile #4

If your organization exists in a VUCA (Volatility, Uncertainty, Complexity and

Ambiguity) environment, 'going agile' will most likely increase the value-add of
your organization, happiness of employees and engagement of customers, but it
will not make you better at meeting the Iron Triangle.

Therefore, if your company is adopting agility for improving your current waterfall
approaches, educate your leaders on what working agile really means, exactly what
it will improve and what it will definitely not improve. Do it before AgileBS
Consulting arrive because, then, it's too late…

13 1. Transformation
The Transformation Plan #15

Instead of taking a waterfall approach to your agile transformation, take an iterative

one and grow the scope organically; align on the 'why' of going agile (e.g., “increase
customer engagement”), identify a hypothesis (e.g., “if the Commercial Value
Stream goes agile, its customer engagement will increase) and an MVP for testing
the hypothesis (e.g., “take an agile approach to further developing Product X in the
Commercial Value Stream”), and pivot or expand the scope of the transformation as
needed.

Also, remember to slice your transformation pilot organizationally vertically and

not horizontally to get the most representative results.

1. Transformation 14
The Quest #20

If you can only focus on one thing, focus on changing the organizational culture to
align with an agile one; to overcome the unwillingness to change it, bring forth the
awesome examples from your agile pilots and have leaders, teams and customers
communicate how this has improved the way they work together to deliver value.

15 1. Transformation
 ,

Hierarchy #43

Product Owners don't dictate anything just because they're accountable for
maximizing the value through effective product backlog management. Instead, at
Sprint Planning, the entire Scrum Team collaborates on creating a plan for the next
Sprint. Together.

1. Transformation 16
Agile HR #47

Besides HR working in an agile manner, Agile HR is about understanding the

values of agility and accelerating the adoption of these values across the enterprise
by modifying existing practices to align better with them, such as measuring the
performance (i.e., the value-add), developing the competencies and setting the goals
of teams instead of individuals.

Thus, for your agile transformation to be a success, create a highway between HR

and your agile coaches (or even a cross-functional team), so they can help each other
with the required complimentary skills.

17 1. Transformation
Agile Island #56

In order to avoid creating an isolated agile island, when initiating an agile

transformation, make sure that your pilot delivers end-to-end value and, potentially,
spans across the company (e.g., follows a Value Stream), so that the success of the
pilot is a vertical and cross-organizational one. This will make it much easier to
expand the scope of your transformation to other Value Streams or products.

1. Transformation 18
The Agile Line Manager #57

When undergoing an agile transformation, don't forget the Line Managers; they're
usually very resourceful in regards to changing the company culture, coaching
colleagues, ensuring quality assurance and building recruitment skills within teams.

And, besides having the potential to become enterprise-wide Agile Coaches, they
can often be very good Product Owners whenever the need for actual Line
Managers eventually isn't there anymore.

19 1. Transformation
Psychological Safety #103

Ask your colleagues, through an anonymous assessment, how high the

psychological safety is in your organization. When (and not if) you realize it's too
low, seek to make working agreements with managers and teams where blameless
post-mortems are part of them, so you create a culture of promoting, e.g., healthy
conflicts and celebration of mistakes (and learning from them).

Also, help your managers in demanding more psychological safety from their
superiors, as that's a prerequisite for the managers creating it for you.

1. Transformation 20
Penelope Prince #42

Until your company is “fully” agile (if that ever happens), Project Managers can be
the key to shielding your agile setup from the evils of waterfall (such as reports and
gate meetings). Also, we love Molly Malone.

21 1. Transformation
The Agile Project Manager #102

Having “Agile Project Managers” (and not just “Project Managers”, as described on
the previous page) is a symptom of your organization holding on to waterfall ways
even after your agile transformation.

Dive into why you have this role (e.g., because your agile setup is still surrounded
by a stage-gate-based execution or funding model) and start fixing the root cause,
initially by explaining to Management how you won't harvest the real benefits of
agility before transforming your organization vertically.

1. Transformation 22
The Agile Triangle #112

In the agile world, we want the vision to drive a dynamic scope with fixed cost and
time, but if you've only partly adopted the agile way of working, the scope might
also be fixed, so the only parameter that the teams can really vary is how much
technical debt to create.

23 1. Transformation
The Agile Process #114

Don't take a waterfall approach to working agile; the DoR, A.C. and DoD are not
gates, and even after starting development, you can refine your stories further, so
don't let the direction of your workflow, represented by the activities on your
Kanban board, trick you into doing the activities only serially.

1. Transformation 24
Post-Transformation #70

Onboard your Project Managers mentally from the beginning of the agile
transformation, so their competencies, intrinsic motivation and drive are leveraged
on. Do this by educating the individual Project Managers on what agility is and isn't
and invite them to express where they see themselves in the future agile
organization.

25 1. Transformation
The Snap #109

An agile transformation should be managed as a change. Therefore, after the

transformation is when we really need qualified and present agile coaches in order
to preserve our agile ways of thinking and working.

In the Prosci ADKAR change framework, it's about remembering the R

(Reinforcement). And please do this part with internal agile coaches, so the
knowledge and lessons learned stay with your organization.

1. Transformation 26
27
 2. Scrum Master

The translator of Story Points into hours.

28
Let's Call It... #6

Kanban is a potentially powerful approach to managing flow of value, reducing

lead time and identifying areas of improvement, so let's stop using it as an excuse
for running Scrum half-assedly. And don't even think about calling it Scrumban.

29 2. Scrum Master
The Scrum Master We Need #61

What characterizes an awesome Scrum Master? It's not so much about having battle
scars, but about meeting the team and organization where they are. Experience
always helps, but it's useless without a positive spirit, people skills, a growth
mindset, natural curiosity, a ton of empathy, and sound knowledge of how to put
the agile principles into practice in different contexts. In that sense, we should all
aspire to become awesome Scrum Masters, no matter what our job titles are.

2. Scrum Master 30
Manager vs. Sprint Backlog #7

It's essential that your immediate managers understand that they cannot use their
position to force Scrum Teams to do specific work. If they still do it, however, the
Scrum Master should coach the managers to go to the Product Owner with their
request (not order).

31 2. Scrum Master
The 9th Stance #23

If you find yourself forced to be more of a pragmatist than an agile idealist, win
some trust by showing that you can actually create results by solving problems, and
then gradually infuse small increments of idealism in order to slowly change the
world for the better.

2. Scrum Master 32
CFD #27

CFDs are an excellent way of diving into how to improve your flow; if the WIP of
"Development” is high, enable the team to better swarm around work and introduce
WIP limits. If the activity time of “Development” is high, maybe stories are getting
blocked frequently, and if the lead time is high, maybe the team has trouble refining
or getting stories accepted by the PO.

33 2. Scrum Master
Daily Scrum #35

At the Daily Scrum (not “Standup”), most of what developers say should be
relatable to everyone in the team (because it's about the Sprint Goal), and if it's not,
identify what anti-patterns are present and what is causing them (e.g., sub-teams
within the team caused by personal interests or competencies split).

2. Scrum Master 34
Powerful Questions #36

For Powerful Questions to work, a certain level of trust and openness must exist in
the team, which can be built over time by fostering an honest and respectful
environment within the team.

When the team members are ready for the deeper level of questioning, reflection
and discovery of working with Powerful Questions, slowly start including them at,
e.g., Sprint Retrospectives and when facing impediments in order to learn what they
help improve.

35 2. Scrum Master
Root Cause Analysis #37

If your root cause analysis leads to several unrelated root causes, simply let the team
vote on which root cause they want to focus on. Make sure that the root cause is,
actually, a root cause and not a symptom by asking 'why' repeatedly.

2. Scrum Master 36
37 2. Scrum Master
The Scrum Values #40

One way of creating awareness of the Scrum Values is by "implementing" one at a

time with the team or organization. E.g., focus the next Sprint Retrospective on how
the team felt about 'courage' and concretize how this value could look in your team.

An experiment for 'courage' could be to agree that, now, developers will adjust the
ordering of the Product Backlog. For the developers, it could require some courage
to talk to the stakeholders, and for the PO, it might require some courage to hand-
over the backlog ordering to the developers. Consequently, next time, a little less
courage would be needed to do a similar change, as more trust will have been built.

2. Scrum Master 38
Scrum Patterns #41

As described by authors Jeff Sutherland and James Coplien in their book “A Scrum
Book: The Spirit of the Game”, Scrum Patterns provide guidance to both new and
experienced Scrum Masters and practitioners on where to focus to get the most
value from improvements, so grab the book and use it as a reference guide to
accelerate your Scrum journey.

39 2. Scrum Master
No Sprint Goal? #54

A Sprint Goal gives the Scrum Team a shared focus. If you don't need that, maybe
you don't need to be a team at all. However, don't take our word for it; ask the team.
And, if they do want to be a team, make it the goal of your next Sprint Retrospective
to find a way to create a shared focus.

2. Scrum Master 40
41 2. Scrum Master
Agile Metrics #60

Many popular metrics, like the ones illustrated above, can help identify areas for
improvement, but increasing them is not necessarily desirable in itself. In our
humble opinion, the only two meaningful things to measure are 1) the satisfaction of
the customers and 2) the happiness of the team members. If you focus on these two
metrics, all other metrics don't really matter.

2. Scrum Master 42
NoEstimates #58

Even if you as a Scrum Team decide to fully eliminate estimations, your PO will
probably still need to forecast. Here, changing the unit of velocity from Story Points
to the number of User Stories delivered in a sprint can be a useful metric (if the
stories are sized more or less similarly).

43 2. Scrum Master
Metrics Dashboard #100

Before you start measuring anything, get to the real 'why' of doing it; remember that
any metric will drive a particular behavior, so ask yourself or Management what
you're trying to achieve with it before you initiate it.

2. Scrum Master 44
Cynefin #65

You can also use Cynefin to categorize your PBIs in the four domains in order to
take different approaches to them depending on their domain. Remember to work
on moving the PBIs from Chaotic to Complex to Complicated (and maybe even to
Obvious) through refinement, spikes and experiments.

45 2. Scrum Master
Servant Leadership #66

This strip was made prior to the 2020 edition of the Scrum Guide in which it is
reiterated that the Scrum Master is now a true leader and not “just” a servant leader.

Servant leadership, however, is not only for roles such as Scrum Masters, Release
Train Engineers and Agile Coaches, but a leadership approach that all leaders can
take as part of their leadership repertoire—including “traditional” leaders.

2. Scrum Master 46
Spill-Overs #67

If your team consistently has spill-overs, and it actually is a problem (e.g., because
you miss your Sprint Goals), reduce the number of stories that you work on, focus
on refinement and try working with spikes to speed up learning. And stop planning
stories that are not ready.

47 2. Scrum Master
Improvement Kata #69

Improvement Kata is a structured approach to continuous improvement through

experiments. Here, it's important to continuously re-assess the relevance of your
current challenge and target condition in order to keep the experiments relevant.

2. Scrum Master 48
Escalating Impediments #83

Of course, escalating an impediment is not the same as escalating a conflict. We

should have as a goal to remove the need to escalate impediments by empowering
teams to remove their impediments, themselves, by reaching out to whomever they
need. Go grab Management and ask them to help enable the teams to do so.

49 2. Scrum Master
Unblocking #88

Creating transparency doesn't improve anything in itself, as it's merely an enabler to

taking the right actions.

So, if a story gets blocked, stop everything you're doing and swarm around
unblocking it.

Following, take a deep-dive into the different root causes of blocked stories and start
attacking those. An increased focus on refinement and a DoR can often help identify
and mitigate the risks of blockage.

2. Scrum Master 50
Sub-Teams #94

In Scrum, there's only one team, the Scrum Team. If your team is split in multiple
sub-teams, either by the type of work or differing priorities, consider realigning the
whole team to one priority, or split the team; you can't have both and expect to gain
the benefits of being a Scrum Team.

51 2. Scrum Master
Little's Law #95

According to Little's Law, the lead time of stories will increase if we increase our
work-in-progress without, somehow, increasing our delivery rate or throughput, by,
e.g., making smaller stories.

Conversely, we can reduce the lead time by decreasing the work-in-progress by, e.g.,
planning fewer stories or Story Points.

2. Scrum Master 52
Capacity #97

We look at the team's capacity because the work is done as a team. Looking into each
team member's capacity is only for identifying potential absence which might
impact the team capacity for the upcoming sprint.

53 2. Scrum Master
Progress Reporting #99

If Management asks you to report on your progress, ask them why they want that. If
it's for budgeting/governance reasons, coach them on how to empower teams to
manage it themselves (e.g., by empowering POs to own product budgets), so the
teams are in control of their own product budgets and how they spend it to add
value for the customer.

2. Scrum Master 54
55
 3. Product Owner

The one thing many POs really own

is the feeling of being powerless.

56
High-Level Estimates #14

If your funding process cannot be changed, convince your organization, sponsor

and Management that no rough, high-level estimates will be made by just one
person without the Scrum Team having taken a short, timeboxed dive (spike) into
the work to be estimated. Maybe even add this to your Definition of Ready.

57 3. Product Owner
SPoC #12

The Scrum Master and PO should encourage developers to talk to customers, end-
users and other stakeholders in order to better understand the needs of their
surrounding actors. The better they understand them, the better they're equipped to
create value-adding solutions.

3. Product Owner 58
Done #22

If a team cannot deliver end-to-end value (why is that?), their Definition of Done
should be aligned with whoever takes the increment and further develops it or
releases it.

As the team matures, the scope of their competencies should become more cross-
functional and “end-to-end”, and their DoD should be extended accordingly.
Remember that the DoD is not static, but a dynamic one that grows together with
the team.

59 3. Product Owner
Prioritization #24

If your PO is powerless (i.e., insufficiently empowered) and basically a Backlog

Administrator without any real say, you need to coach both the PO and their
leaders, so they understand the mechanisms and benefits of Scrum.

3. Product Owner 60
How to Prioritize #29

If prioritization through the Highest Paid Person's Opinion is your reality, and you
think it's not really optimal, talk to the PO and organize a workshop to try out a
more value-based prioritization technique. Let them see for themselves whether the
new order of the Product Backlog is better than with the previous way of ordering.
It probably is.

61 3. Product Owner
Story Slicing #32

Remember that, no matter which splitting approach you take, it's important that the
resulting stories not only meet the Definition of Ready, but are technically feasible.
Therefore, the PO should involve the developers in creating and slicing stories.
Remember that stories are made through conversation between the developers, PO
and customer.

3. Product Owner 62
PO from the Business #48

Even though the PO's background shouldn't play a role, understanding their
background (i.e., whether it's technical or business-oriented) can help Scrum
Masters coach the POs to better maximize the value-add of the Scrum Team by
focusing on, e.g., market-oriented activities or understanding the need for reducing
Technical Debt.

63 3. Product Owner
The Journalist PO #59

The concept of User Stories originates from eXtreme Programming and is the 'agile'
way of describing requirements that are not really requirements, but our best guess
on what work needs to be done to reach the Product Goal.

One way of making proper, understandable User Stories is by remembering the

three Cs (Card, Conversation and Confirmation) and making them INVEST
(Independent, Negotiable, Valuable, Estimable, Small and Testable).

3. Product Owner 64
Say 'No' #68

Even though POs should be empowered to be able to say 'no' when appropriate, an
even better way of responding to stakeholders is involving them in the Product
Backlog ordering process, so they can see for themselves what other PBIs would
need to be deprioritized.

65 3. Product Owner
The Goal-Oriented Roadmap #78

A Product Roadmap is neither a release plan nor an overview of commitments;

rather, it visualizes how a product could evolve over time by outlining potential
future (product) goals and functionality. Thus, it breaks down the Product Vision
and provides the team and stakeholders with concrete content and context based on
the current level of knowledge.

3. Product Owner 66
Features, Features, Features #81

Don't let your team become a Feature Factory; the number of features is rarely an
indicator of success. Instead, look into measuring the benefit realization of your
features, so you focus on what difference your work really makes. And make sure
that the features can actually be used, so they don't “pile up”.

67 3. Product Owner
Empowering the PO #92

In organizations where managers are ultimately accountable for the success of the
products, coaching is needed on a systemic level in order to enable these managers
to transfer their product accountability to a PO.

Try an experiment with a manager who "gets it", let them transfer the accountability
to the appropriate PO and share the eventual success stories of the reaped benefits
with other managers afterwards.

3. Product Owner 68
The Anatomy of Estimates #93

Don't hide anything under the rug; instead, help your PO understand the
importance of finishing unfinished (and still important) features and reducing
Technical Debt.

If the problem is getting a budget for reducing Technical Debt from a sponsor, help
the PO communicate in business terms why it's important, so they can convince the
sponsor. Down the road, reducing Technical Debt should be an inherent part of the
Product Backlog and within the PO's span of control (and interest).

69 3. Product Owner
Feature Toggling #106

Feature Toggling not only potentially increases our technical quality by "forcing" a
frequent integration in Production, it also better aligns the releases with the market
cadence, as "now" is not always the right time to release new features. By combining
Feature Toggling with A/B tests, we can also learn how different groups of users
receive and use our new features.

3. Product Owner 70
Product Discovery #119

There needs to be a direction in which the process of discovering new products or

features happens. This direction is typically set by the Product Vision. If there's no
direction, the PO will have a very hard job prioritizing customer needs. Conversely,
if someone has already decided what needs to be implemented, there's no need for
discovery (besides, perhaps, the technical type of discovery).

71 3. Product Owner
 4. Team

Let's increase the number of times

we don't disturb the developers.

72
Skateboard #3

If teams, POs and customers fail to implement the Minimum Viable Product in a
way where continued iterative development is possible afterwards, they risk
delivering too many skateboards that cannot be used when a new increment is
delivered.

To reduce the risk of this happening, ensure that the architecture of the MVP is
emergent and designed in a way that enables further development, so the
skateboard can eventually turn into a bike and car if that's what's needed.

73 4. Team
Team Velocity #18

The velocity is only for the team. If Management doesn't get that, educate them on
the purpose and nature of velocity and focus more on outcome (i.e., the positive
impact that the team's work has on the customer), which is definitely more valuable
to measure for your organization than team velocities.

4. Team 74
Technical Debt #26

If your PO doesn't get the importance of reducing Technical Debt, you need to
educate them on the subject; explain that spending some time now on reducing the
technical debt will most likely decrease our overall, general time-to-market of new
features going forward.

75 4. Team
Retrospective #31

If people external to the team (especially, managers) wish to participate in your

Retrospectives, do two things: 1) understand why this person wants to participate
and 2) bring the suggestion to the team, so they can take the decision.

A risk of having external participants is that the team dialogue will be inhibited
because of the lack of trust to the externals. In general, avoid it; it's the team's
session.

4. Team 76
77 4. Team
Jira vs. Azure DevOps #30

Having the right tool is essential for building the appropriate agile culture and
mindset. If you sense that this is lacking, and everyone's attention is drowning in
tooling, try to use a simple tool like Trello and intentionally over-simplify your way
of working by taking a just-enough approach to your tooling, so you “free up”
energy to focus on the needed behavioral changes.

4. Team 78
DevOps #38

When introducing DevOps, and being part of a bigger organization, you might
already have a centralized 24/7 first-level support function, who you should
continue to leverage on. Just make sure that the DevOps teams can act as second-
level support while continuously educating the first-level support on using the new
monitoring tools as well.

And remember that DevOps is not just about tools, testing and CI/CD pipelines; it's
much more about culture, breaking down silos and aligning cross-functional teams
to the paths of value delivery.

79 4. Team
WIP Limit #45

If you limit your team's WIP by introducing a WIP limit, you'll create a pull system
in the team's flow. This should then bring about a conversation about collaboration
and the knowledge sharing needed to ensure that the team can actually swarm
around each PBI eventually.

4. Team 80
Test-Driven Development #46

One simple way of including the Refactor step is to explicitly state in the Definition
of Done that, when applicable, refactoring must have been done before a PBI can be
considered 'done'. Though this doesn't necessarily lead to refactoring happening
every time, it'll remind you to at least assess whether it makes sense to refactor or
not.

81 4. Team
Mob Programming #63

Mob Programming is about working collaboratively in groups of three or more

developers to deliver software of high quality and/or to share knowledge between
the developers in the mob.

One person called the Driver will be controlling the keyboard and mouse and doing
the actual typing, while the others are Navigators and spend their time thinking,
discussing, reviewing and reflecting. Frequently, the roles are interchanged, so
everyone gets to type and think. And yes, you can also do this virtually with a
shared screen.

4. Team 82
Delegation Poker #71

For Delegation Poker to really work, make sure to prepare for the session by
identifying relevant scenarios to discuss in the team prior to the session.

Additionally, if the responsibility split between manager, PO and SM is unclear,

doing a simple exercise with placing responsibilities and tasks on a Venn diagram
with a circle for each role can do wonders.

83 4. Team
Ready #75

The question of how much refinement is enough can, somewhat, be answered by

looking at your DoR. Conversely, the DoR is not a gate; you can still plan non-ready
stories, but just remember that they could pose a risk to your Sprint Goal. So, ensure
to plan for sufficient time for refinement and/or Spikes (e.g., by including this work
on the Sprint Backlog).

4. Team 84
The Stable Team #77

Stability is the foundation for building the trust needed to become high-performing
(i.e., high-value-adding) teams. If teams keep changing, they'll have difficulties
moving up Tuckman's phases (forming, storming, norming, performing), so a team
(and not an individual) should be the atomic unit in your organization.

And if your leaders don't get that yet, make them get it. Now.

85 4. Team
Reasons for Reorganization #105

Reorganization is a natural part of the life of an enterprise, but we're not quite fond
of some of the most popular reasons for doing them.

However, a positive motivation for reorganization is the case where dependencies

can be removed by, e.g., organizing around Value Streams or products and enabling
the teams to deliver end-to-end value. Unfortunately, we don't often see this being
the reason for reorganizations.

4. Team 86
The Self-Managing Team #79

Empowering teams to be self-managing is not just a team exercise, but certainly also
a systemic, organizational one. This becomes exceptionally clear if the existing
teams have dependencies to other teams. So, agree on an enterprise level what 'self-
managing teams' really means and whether your company is actually ready for it.

87 4. Team
Sprint Planning vs. Hackathon #82

Let's turn all sprints into Hackathons, or, at least, bring the mindset with us into our
sprints. It's all about creating a shared focus, doing experiments and accelerating
our learning. Just remember to not throw your quality standards out the window.

4. Team 88
The Story #85

The different types of work needed to be done in your sprint, such as new features,
maintenance, technical debt reduction, can be represented as PBIs or Non-
Functional Requirements.

If you want to control how much time and effort you spend on the different
categories, you can categorize and allocate capacity explicitly to the different types
of work. If the work is not in your backlog, make sure to reduce your team's
capacity accordingly at Sprint Planning and plan for a lower velocity. Or, just add all
the work to your backlog.

89 4. Team
Ideal Developer Days #87

If you start out with Ideal Developer Days with your new team, for the following
Sprint Planning, remember to identify a new Reference Story based on Story Points
(or any other unit) and use it for estimating the rest of your stories.

Another approach is to use your throughput (i.e., number of delivered stories) as a

measure for planning an appropriate number of stories for your sprint. In the latter
case, remember to aim for creating stories of, approximately, equal size.

4. Team 90
Team Topologies #89

Massive props to Matthew Skelton and Manuel Pais' book, “Team Topologies”, for
accelerating the talk about how to slice and improve the collaboration between
different types of teams.

Though our depiction of the teams is caricatured heavily, understanding the

potential stereotypical weaknesses of each team type can help us coach them into
increasing their value-add.

Just don't use the different types of teams as an excuse for not removing
dependencies, sharing knowledge or creating more Stream-Aligned feature teams.

91 4. Team
Bottleneck #91

It's a great idea to disperse Platform Team members into the other teams, so
dependencies are removed, and those teams become more end-to-end.

However, if it's not followed up with the needed knowledge sharing sessions (e.g.,
collective refinement or Pair/Mob Programming), the person-specific knowledge
will just become an internal dependency.

4. Team 92
Team Sunshine #96

For us, it's not a goal, in it self, to play the game of Scrum as perfectly as possible;
rather, it's a (very good) means to increasing the happiness of employees and
customers. Thus, many organizations take a, somewhat, pragmatic approach to
Scrum.

However, if the Scrum Values and agile principles don't align with your company
culture, maybe it's a good excuse to change it—or the place you work.

93 4. Team
Agile Budgeting #98

If your organization allocates funds once a year, work towards making it acceptable
to change the allocations as everyone gets wiser, and towards not planning in detail
exactly what needs to be delivered the next year.

One solution is allocating funds on a sufficiently high level (e.g., Value Streams or
products) instead of specific epics or features. Thus, the teams (of teams) will be
funded as per their costs, but their exact work is kept open to the market needs and
will be planned as they go.

4. Team 94
95
 5. Scaled Agile

Why remove dependencies when you can add more overhead?

96
The Program Board #1

Use the overview of your many dependencies as fuel for reducing and, ideally,
eliminating them by organizing around Value Streams or products, creating teams
capable of end-to-end value delivery, and slicing features more vertically.

We know; it's easier said than done, but so is everything else in life.

97 5. Scaled Agile
PI Objectives #13

Features aren't necessarily mapped directly to PI Objectives, as one team in the ART
can potentially only deliver a part of a feature while other teams deliver the
remaining parts.

All of these team-specific goals need to be communicated to Business Owners in

non-technical phrases through PI Objectives. The goal here is for the team and ART
to have a shared focus in the form of PI Objectives and Program PI Objectives and to
align these upcoming business objectives with the Business Owners.

5. Scaled Agile 98
99 5. Scaled Agile
The Scaled Agile Showdown #10

“Scaling agile” is not a solution to a one-dimensional problem; before settling on

SAFe, LeSS, Scrum@Scale, Nexus, DAD or anything else, identify the 'why' of
wanting to scale agile before choosing a framework.

In the spirit of learning, initiate pilots for several scaling frameworks to identify
which one fits your enterprise the best before making the choice.

And try to descale before all of this. More about how to descale (and, especially,
how not to) in our next book.

5. Scaled Agile 100

New Silos #21

When launching ARTs, be attentive to the risk of each ART, itself, becoming its own
silo and adopting silo-like behaviour (e.g., only focusing on own goals, being
inflexible to cooperate with others, etc.).

One way of mitigating this risks is by properly training the Portfolio-level and
Program-level roles to understand Systems Thinking in order to realise how ARTs
are inherently a part of a larger connected context (a Value Stream, Portfolio and
Enterprise).

101 5. Scaled Agile

Guide to Scaling Frameworks #28

No matter your motivation to scale, if you can avoid scaling, avoid it. However,
adopting a scaling framework can often work as a very good “excuse” to start
continuously improving and removing the larger, organizational, systemic
impediments that single Scrum teams couldn't. Just remember to continuously
assess if all the overhead of scaling is still necessary, and how dependencies can be
removed.

5. Scaled Agile 102

Agile Consultancy #34

We, as agile practitioners, coaches and managers, must find the right balance
between being overly sceptical and believing that these consultancy firms can
actually help us. Just because these companies used to focus on more business
school-oriented topics doesn't necessarily disqualify them from knowing anything
useful about agile; remember, their world-renowned company reputation is on the
line.

And, if they turn out to be all Dougs, go find a smaller, specialized agile consultancy
(like AgileBS Consulting).

103 5. Scaled Agile

The System Team #39

As there are really no good reasons to keep the competencies of the System Team in
a specific team, remember to have as goal to, eventually, disperse the System Team
members into the other agile teams of the ART in the spirit of removing
dependencies by building end-to-end competencies in all teams.

When you're ready for it, start doing shared refinement with the “target” Feature
Team and the System Team, let a System Team member join the Feature Team, and
do Mob and Pair Programming during development.

5. Scaled Agile 104

The SAFe Requirements Model #44

Though the SAFe Requirement Model is great for modeling or configuring your
tools to support the SAFe way of working, have a think about whether it is possible
to simplify your setup, and whether you really need Epics and/or Capabilities, and
whether you can add the same value with proper, vertically sliced Features or even
just Stories.

105 5. Scaled Agile

Agile PMO #49

If you go for an Agile PMO, get rid of the old mindset, unless you want to replicate
the usual behavior of a traditional PMO; instead, have the Agile PMO drive the
funding of products or Value Streams, ensuring that product development efforts
and portfolio are aligned with the company strategy, and take on the responsibility
of driving the (scaled) agile transformation.

5. Scaled Agile 106

Descaling and POs #64

After embarking on a scaled agile journey, many companies can benefit from
descaling again. Here, the descaling will probably require the POs to return to true
Product Ownership and engage more with end-users and think more strategically
about the product.

So, see this as an opportunity for POs to get back to their empowered PO roots and
coach them accordingly.

107 5. Scaled Agile

Spotify #72

There's no Spotify model.

5. Scaled Agile 108

The Program Backlog #73

If the ART teams cannot work on all features in the Program Backlog, it's really a
collection of individual Team Backlogs, so there's no need to have it.

Therefore, when initiating your SAFe journey, start by agreeing on the purpose of
the Program Backlog; it's for ensuring that the ART works on the globally most
important features, so have the teams share competencies with each other, so any
team can eventually work on any feature.

109 5. Scaled Agile

Value Streams #76

Many organizations tend to over-complicate how they fund their solutions and
product development efforts. If you can create a clear product definition, fund the
product directly based on the cost of its number of teams and developers. If you
have multiple related products with several teams, and you don't want to descale,
fund the Value Stream (and create feature teams across its products). Just don't
create Cost Centers.

5. Scaled Agile 110

The Force #80

SAFe and Scrum are not opposite forces; in SAFe, Scrum(XP) is the way of working
in the teams, along with Kanban, and SAFe then adds some (i.e., a lot of) value-
adding structure on top of the teams. What we generally need is a nuanced
discussion on the trade-off of SAFe, as it can both introduce organizational overhead
as well as improve the flow across dependent teams.

Therefore, as you go, remember to reduce the need for the overhead by eliminating
dependencies. Remember that SAFe is just a stop on the agile journey of continuous
improvement of our enterprises, so, at I&A, reflect collectively on which elements of
SAFe you should keep and which you should eliminate entirely.

111 5. Scaled Agile

The SAFe PO Prison #86

In a SAFe setup (and any other setup with a hierarchy above the PO, really), there's
the risk that POs become powerless Backlog Administrators because Product
Management potentially drives much of the discovery and high-level work.

If that's the case, try this: 1) Make SAFe POs accountable for products, 2) Help teams
take ownership of their products, 3) Get rid of the Program Backlog and place
features in the Team-specific Product Backlogs, 4) Keep SAFe Product Management
on a strategic level, 5) Make PI Planning about removing product dependencies, and
6) Have POs align as needed throughout the PI.

5. Scaled Agile 112

The Background of RTEs #101

Remember that an RTE is more of a Scrum Master than a Project/Program Manager.

An RTE's most valuable task is doing for the ART what the Scrum Master does for
the team, namely coaching it to continuously improve itself. And, in both cases,
don't forget to coach the organization in order to improve systemically.

113 5. Scaled Agile

Business Owners #104

It's not enough to send your Business Owners on a Leading SAFe course; you need
to educate and coach them as well afterwards. Help them understand how they're
going to be more involved than ever, not just at PI Planning and PI System Demo for
rating the PI Objectives, but throughout the whole PI from discovery through
refinement to Iteration/Sprint Reviews with the teams.

5. Scaled Agile 114

115 5. Scaled Agile
The Unagile Release Train #108

Don't make commitments that stretch too far into the future. Instead, only the PI
Objectives of the next PI should be communicated to the stakeholders as committed
to by the ART. The rest of the roadmap is just our current best guess, so the ART is
able to make turns towards newly discovered opportunities (“being agile”, you
know?).

Furthermore, remember that your Architectural Runway should be indicative and

not a detailed plan of all upcoming enablers for the next couple of years. Instead,
align the A.R. with your roadmap and encourage an emergent architecture based on
the continuous feature discovery work.

For this to succeed, have Product Management and the System Architect align with
each other frequently. Also, have the RTE coach the BOs on understanding that
having tracks that reach all the way into the horizon is probably not what's best for
their business. So, instead of giving them a feeling of “control” by showing a
committed delivery plan, build their trust in you as an ART by involving them often
in what direction to take—not just at PI Planning and PI System Demo, but also
during both discovery, refinement and development.

5. Scaled Agile 116

117 5. Scaled Agile
An UnSAFe Protest #55

If implementing SAFe hasn't made your company more agile (whatever that
means), the blame is not with SAFe, but with yourself and the people who
implemented it for you without driving the needed systemic changes in your
company.

So, instead of complaining about how SAFe has skewed the purpose and dynamics
of agile, let's appreciate how the work of Dean Leffingwell, et. al., has actually
helped large companies to start working with integrated increments, different levels
of feedback loops, business value, a common way of prioritizing, managing
dependencies, etc.—stuff that Scrum doesn't (and shouldn't) cover.

And remember: SAFe is not the end state, but rather a means to start or continue an
agile journey. You should always consider the trade-off between the overhead of
SAFe and its benefits, and when it's the right time to descale and stop running SAFe.

5. Scaled Agile 118

119
 6. Miscellaneous

Different stuff that doesn't have anything in common

besides being stupid.

120
Agile at Home #17

In the spirit of openness, you don't have to wait for the Retrospective to bring up
potential improvements to your ways of working. If it's important enough, put it
into the Sprint Backlog and agree with the team what its priority is (it's fine to
change the Sprint Backlog, but not the Sprint Goal).

121 6. Miscellaneous
The UX Specialist #25

Avoid taking a waterfall approach to User Experience where the UX-ers, on their
own, identify, design and mock-up exactly how the frontend should look and
behave and then hand it over to the development team.

Instead, in the spirit of cross-functionality, and as with any other specialized skill
set, the ambition should be for the UX-ers to join the teams and share their
knowledge and competencies, as well as learn from the other team members, thus,
improving everyone's T profiles.

6. Miscellaneous 122
Agile Meetup #52

Even though not all agile consultancies are evil maniacs, we've seen too many that
host so-called knowledge sharing and co-creation meetups, which are, in reality,
sales meetings.

So, be critical and look for events that are run by people who are not trying to sell
you their services, or look for more community-driven sessions.

123 6. Miscellaneous
Diversity #33

According to the HBR article, “How Diversity Can Drive Innovation” from
December 2013, companies with a diverse leadership team are 45% more likely to
grow their market share and 70% more likely to capture new markets compared to
companies with “non-diverse” leadership.

However, it's not enough with “inherited” diversity; behavioral diversity is the
other half of the equation, which includes: ensuring that everyone is heard, making
it safe to propose novel ideas, giving team members decision-making authority,
sharing credit for success, giving actionable feedback, and implementing feedback
from the team. Sounds an awful lot like working agile, doesn't it?

6. Miscellaneous 124
125 6. Miscellaneous
Return to Snowbird #50

Here, more than 20 years after the 17 thought-leaders met in The Lodge in
Snowbird, Utah, we thought it was time to revisit the agile manifesto.

On the following pages, we elaborate on our humble suggestion on an updated

Agile Manifesto.

6. Miscellaneous 126
The Comic Agilé Manifesto

Empiricism over methodologies

In the world of (software) development, we realize, accept and embrace that
everything we do comes with learning, since we don't know much upfront.
Therefore, the only thing we can confidently predict is that something unpredictable
will happen. The way to add value, steer in the right direction and reduce risk in
this world is by focusing on empiricism, i.e., basing decisions on facts, experience
and evidence. No matter what agile methodology is used, if observations of reality
aren't happening, we won't overcome.

Growing people over certifying them

As in many other disciplines, motivated people with a compatible “right” mindset
are the key to creating success in the agile world. However, many companies believe
that their employees will magically understand the agile ways by taking a
certification.While many certifications are great, what should be our focus is
growing people by broadening their professional horizon, helping them understand
the value-add of customer-centricity and empowered teams, and building their
ability to connect theoretical frameworks to business challenges. Certifications can
be a means to this, but definitely not the end.

127 6. Miscellaneous
Culture change over transformation programs
The words 'transformation' and 'program' imply something temporary with a start
and an ending. In the spirit of continuous improvement, the end state is a dynamic
one rather than an static one where “agility” has been reached. Therefore, a kick-off
of a such culture change should be part of any agile transformation. Make sure to
not create too many “doing agile” KPIs or OKRs, such as number of established
teams, certified people, events held or CoPs created, but rather on more “being
agile” behaviour measurements, such as the team members challenging the PO, the
teams having the competencies to bring PBIs from backlog to done, etc. Only when
the behavior has changed, the culture change is properly kicked off.

Product-centricity over scaling frameworks

With the emergence of the numerous scaling frameworks for enabling agility
between related teams and even across the enterprise, the idea of descaling before
scaling is typically a useful ambition. Here, descaling can mean clearly defining the
products in the organization and establishing product-centric cross-functional teams
that can do whatever work is needed for that product. So, instead of having a
portfolio of work that spans across products and teams, mapping teams to products
could reduce the overhead, narrow the focus of each team and improve the
engagement, ownership and value-add.

6. Miscellaneous 128
The Scrum Guide #51

According to the Scrum Guide, the Scrum Guide (sic!), maintained by Ken Schwaber
and Jeff Sutherland, contains the definition of Scrum. However, it is deliberately not
a precise prescription on how you should adopt Scrum in your organization.

For help with that, you can ask some (probably over-priced) consultants or in one of
the many agile communities around the world. The Scrum Guide, however, is more
of a… Guide, but you still need to follow its basics if you want to see the magic of
Scrum unfold.

129 6. Miscellaneous
How to Become an Agile Coach #53

The best way to get ready to become an (Enterprise) Agile Coach is by getting
experience with having different roles in different agile and non-agile companies in
different industries.

While on that journey, take a quality Agile Coach certification (e.g., with ICAgile),
find an experienced mentor and start coaching your organization (you don't need
the job title to start doing it).

6. Miscellaneous 130
PRINCE2 Agile #62

PRINCE2 Agile seems more like a desperate attempt to tap into the agile winds than
actually wanting to support agile behavior. Axelos even describes PRINCE2 Agile as
“a set of behaviors and practices rather than the use of an adaptive lifecycle [nor are
we] providing a complete integration between the PRINCE2 process model and
Agile lifecycle.”

So, bottom line is that you shouldn't expect to be agile with this framework. But,
then again; if you're using it, being agile isn't exactly your goal, is it?

131 6. Miscellaneous
Waterfall Shaming #74

Instead of bullying people, help them become even better at this agile thingy. If they
want your help, that is.

6. Miscellaneous 132
Conway's Law #85

Named after programmer Melvin Conway, Conway's Law states that organizations
design systems that mirror their own communication structure. This is a problem
because most organizations still are very silo-oriented, and when the processes
typically span across functional areas, there are going to be quite some handovers as
well as lack of process ownership and accountability.

Instead, the Inverse Conway Manoeuvre, where we design our organization based
on the high-level architecture of our applications, could be a better approach (if the
architecture is good enough, that is).

133 6. Miscellaneous
The Distributed Monolith #90

Service-enabling your monolith doesn't remove the dependencies nor the monolith,
it self. Instead, invest time in refactoring its architecture entirely. And remember to
take an agile, emergent approach to doing that.

6. Miscellaneous 134
Afterword

Congratulations. You made it to the end of the first ever Comic Agilé book.

We hope you were entertained, learned something and, most importantly, feel
motivated to challenge the agile status quo at your workplace.

The fact that your context is unique is not an excuse to avoid improving systemically
with the help of the agile ways of working. The limitations of your company is not a
good reason to not empower POs properly. The organizational boundaries of your
enterprise are not grounds for keeping the dependencies between your teams. And
the number of Line Managers in your organization is not an excuse to only view
Scrum Masters as meeting facilitators.

We hope we have inspired you to accelerate the continuous improvement journey of

your company and harness the real benefits of agility. And remember: being agile is
not the goal, but rather a means to an end—namely that of increasing employee
happiness, customer satisfaction, stakeholder engagement and the overall value-add
of your organization.

And if this book didn't do it for you, we'll see if Volume Two will.

135
About the Authors
Mikkel Noe-Nygaard holds an MA in Architecture with a
background in sustainable buildings and a speciality in
Communications Design, but has always been working with user
experience in software. Mikkel designs both hyper-complex
cloud-based expert tools and simple mobile applications with the
same pride, and always puts the user first in aesthetic, efficient
solutions.

After 20 years of software enterprise experience, spanning

diverse areas such as public health care and insurance, pension
fund investments, tax and property registration and, at the time
of writing, sustainable energy at Vestas, Mikkel has found his second calling as a
cartoonist!

Fun fact: Mikkel is a multiple times Danish Champion in underwater photography

and has participated in the sinking of a 55 metres long 220 tons ferry in order to make
it an artificial reef.

Luxshan Ratnaravi holds an MSc in Software Engineering and is

an Agile Coach with the Danish financial software solutions
provider Bankdata. He's constantly on a mission of improving
the status quo from his position between being an agile
ideologist and a pragmatic problem-solver.

Luxshan's professional mission in life, which has taken him

through jobs as, e.g., IT Business Analyst, Product Owner,
Release Train Engineer and Agile Coach, is to relentlessly
improve companies by challenging their worn-out habits,
reinforcing their purpose and helping them in continuously
improving their practices through the awesome values, principles and practices from
the agile space.

Fun fact: Luxshan has freestyle battle rapped in front of 10,000 people at Roskilde
Festival and founded a league for pre-written rap battles in Danish.

136
Acknowledgements

We would like to extend our sincere gratitude to:

• Our families – for putting up with our absence when inspiration hits on all hours
of the day.

• Kent Beck and Dave Snowden – for writing two wonderful forewords.

• PST Andy Hiles of AgileRocks and ProKanban.org – for donating his time and
competencies to review our book.

• Our employers – for not recognizing themselves in our strips.

• The many organizations who try to become “agile” – for inspiring us to depict
their miseries.

• All our followers – for supporting us since our launch in March 2020, urging us
to turn our web comics into a book, giving us tonnes of feedback, and donating
loads of cups of coffee to us through BuyMeACoffee.com/ComicAgile

137
 Comic Agilé, Volume One
Luxshan Ratnaravi & Mikkel Noe-Nygaard

Aarhus, Denmark, 2021

ISBN 978-87-973238-0-9

Reproduction allowed
(and highly encouraged)
with attribution to either
Comic Agilé or comicagile.net

138
Comic Agilé depicts the magical, depressing, funny and potentially
educational moments that occur when agility meets reality. Through the
form of short comic strips, Comic Agilé brings to a head the challenges,
misunderstandings and ill-intentioned behavior that makes it so difficult to
put the agile mindset into practice.

Besides the tragicomic storytelling of the agile comic, accompanying texts

describe how to avoid, manage or improve the illustrated situations, so the
readers are left with a burning desire to return to their contexts and
improve their agile practices and organizations. For the sake of humanity.

“Brilliant, witty and sublime. “A roller coaster of feelings from

A hilarious take on the subject. laughter through realization of how
To quote Robert Burns: Oh, the gift sadly true those comics are to
that God could give us, to see laughter again.”
ourselves as others see others.”
Ilya Sakharov
Gary W Director of Software Engineering
Product Manager
“It's all true—unfortunately! “An insightful Dilbert and as
And that's what makes it relevant philosophical as Calvin & Hobbes.”
and useful.”
Daryl Akino
Jeff Grieg Senior Account Manager
Senior Implementation Architect
“It's about time people had the “Great antidote to the agile
courage to take the product of an fetishists and process perverts
old white man retreat lightly.” of the world.”
Joe Auslander Simon Kus
Podcast host and consultant Growth PM

Reproduction allowed (and highly encouraged)

with attribution to either
Comic Agilé or comicagile.net 9 788797 323809