Doing more in half the time

2. For all the agile spirits who keep fighting
to improve their organizations

4. 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 (contact@comicagile.net) 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.

5. Foreword by Kent Beck
Photo: Rob Ao Opyo
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.

6. 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.

7. Foreword by Dave Snowden
Photo: Cognitive Edge
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

8. 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 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

9. 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 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.

10. 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

11. working agile. Our way of doing that is by creating comic strips with
accompanying advice.

12. 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

13. 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.

14. Transformation
The misery begins.

15. 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…

16. 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.

17. 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

18. agile pilots and have leaders, teams and customers communicate how
this has improved the way they work together to deliver value.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. Scrum Master
The translator of Story Points into hours.

30. 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.

31. 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.

32. 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).

33. 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.

34. 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.

35. 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).

36. 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.

37. Root Cause Aanalysis / #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.

38. The Scrum Values / #40

39. 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.

40. 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.

41. 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.

42. Agile Metrics / #60

43. 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

44. members. If you focus on these two metrics, all other metrics don't really
matter.

45. 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).

46. 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.

47. 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.

48. 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.

49. 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.

50. Improvement Kata / #69
Improvement Kata is a structured approach to continuous
improvement through experiments. Here, it's important to continuously re-

51. assess the relevance of your current challenge and target condition in
order to keep the experiments relevant.

52. 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.

53. 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.

54. 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.

55. 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.

56. 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.

57. 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.

58. Product Owner
The one thing many POs really own
is the feeling of being powerless.

59. 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.

60. 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.

61. 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.

62. 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.

63. 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.

64. 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.

65. 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.

66. 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).

67. 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.

68. 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.

69. 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

70. really makes. And make sure that the features can actually be used, so
they don't “pile up”.

71. 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.

72. 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).

73. 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.

74. 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).

75. Team
Let's increase the number of times
we don't disturb the developers.

76. 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.

77. 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.

78. 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.

79. 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.

80. Jira vs. Azure DevOps / #30

81. 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.

82. 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.

83. 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.

84. 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.

85. 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.

86. 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.

87. 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).

88. 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.

89. 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.

90. 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.

91. 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.

92. 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.

93. 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.

94. 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.

95. 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.

96. 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

97. 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.

98. 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.

99. Scaled Agile
Why remove dependencies
when you can add more overhead?

100. 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.

101. 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.

102. 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.

103. 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.

104. 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).

105. 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.

106. 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).

107. 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.

108. 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.

109. 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.

110. 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.

111. Spotify / #72
There's no Spotify model.

112. 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.

113. 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.

114. 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.

115. 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.

116. 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.

117. 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.

118. 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.

119. 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

120. 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.

121. Miscellaneous
Different stuff that doesn't have anything in
common besides being stupid.

122. 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).

123. 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.

124. 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.

125. 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?

126. Return to Snowbird / #50

127. 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.

128. 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.
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

129. 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.

130. 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.

131. 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).

132. 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?

133. Waterfall Shaming / #74
Instead of bullying people, help them become even better at this agile
thingy. If they want your help, that is.

134. 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).

135. 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.

136. 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.

137. 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

138. 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.

139. 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.

140. Comic Agilé, Volume One
Luxshan Ratnaravi & Mikkel Noe-Nygaard
Aarhus, Denmark, 2021
Reproduction allowed
(and highly encouraged)
with attribution to either
Comic Agilé or comicagile.net