Johann Botha

Agile, a Manager’s
Guide
Unlocking Business Value Using
Scrum

ELIBRARY
JOHANN BOTHA

AGILE, A MANAGER’S
GUIDE
UNLOCKING BUSINESS
VALUE USING SCRUM

2
Agile, a Manager’s Guide: Unlocking business value using Scrum
1st edition
© 2021 Johann Botha & bookboon.com
ISBN 978-87-403-3817-1

3
AGILE, A MANAGER’S GUIDE Contents

CONTENTS
Author Bio 6

Foreword 8

1 What is Agile? 10
1.1 Agile as a value delivery approach (Agile with a big ‘A’) 10
1.2 Origins 11
1.3 Agile as a way of thinking and acting (agile with a small ‘a’) 12

2 Making a case for Agile 15

2.1 Exploring reality with a simple example 15
2.2 Questions to the business 18

3 Critical Success Factors for getting Agile right 20

3.1 Leadership and behavior, culture, ethics, and trust 20
3.2 Low-trust 21
3.3 High-trust 22
3.4 Agile and its impact on organizational structure 24

4 A very quick look at a typical Agile Method (Scrum) 25

4.1 The basics of Scrum 26
4.2 Scrum Values 27

5 The Three Scrum Accountabilities 29

5.1 The Product Owner 29
5.2 Developers 30
5.3 Scrum Master 31

6 The Five Scrum Events 32

6.1 Why are events important 32
6.2 Sprint Planning 34
6.3 The Daily Scrum 36
6.4 The Sprint Review 37
6.5 The Sprint Retrospective 37
6.6 The Sprint itself 38

7 Three Artefacts and associated commitments 39

7.1 The Product Backlog and the Product Goal 39
7.2 Sprint Backlog and the Sprint Goal 40
7.3 Increments and the Definition of Done 40

4
AGILE, A MANAGER’S GUIDE Contents

8 How do the theory help you – the manager? 41

9 Scrum in complex environments 44

9.1 Portfolio Planning 45
9.2 Envisioning your Products 46

10 Conclusion 47

Endnotes 48

5
AGILE, A MANAGER’S GUIDE Author Bio

AUTHOR BIO

Johann Botha is CEO of getITright®, a consulting and training practice operating from
South Africa and the Netherlands, focusing on digital transformation, business agility, service
management, governance, and cybersecurity.

Johann was one of the subject matter experts tasked to re-write COBIT in 2009, one of
the Lead Authors of VeriSM™ and the Architect Agile ADapT™ digital transformation
method for incumbent organizations. He also wrote the official handbook for the EXIN
Agile Scrum professional certification scheme and authored or co-authored a further nine
books dealing with technology management and governance. 2021 will see an additional
four books appear by publisher Bookboon.

He frequently speaks internationally about his passion – business agility and excelling in a
digital world!

6
AGILE, A MANAGER’S GUIDE Author Bio

Johann cut his teeth in the IT industry as a mainframe & network engineer in the mid-
’80s. He held leadership positions in large publicly listed and private IT companies the
following decade before deciding to help others get it right in 2002. He often does so in
partnership with some of the big names in the industry, internationally.

Johann is then Service Management lecture at Nelson Mandela University, and his subject
is as part of the MPhil IT Governance Degree.

In 2014 the itSMF honored Johann for his contribution to the IT service management
profession and body of knowledge with a Lifetime Achievement Award. The HDI has
nominated him as one of the top 25 though industry leaders internationally in January 2021.

Johann holds several professional certifications and academic qualifications in IT and Business
Management. Professionally he is a Chartered IT Professional, Certified in the Governance
of Enterprise IT, a Lean IT and VeriSM Professional , ITIL Managing Professional, Scrum
Master & Product Owner, and a Certified Professional Management Consultant.

You can contact Johann on the following social media platforms:

LinkedIn: https://www.linkedin.com/in/johannhbotha/

Twitter: @JHBotha_getIT

Facebook: https://www.facebook.com/johann.botha3

7
AGILE, A MANAGER’S GUIDE Foreword

FOREWORD
This book is sort of a second edition. I say sort of, because in the 1st version of the book,
‘Agile: a manager’s guide to unlocking business value’ (published in 2019), I included content
that went beyond the book subtitle and also exposed the reader to a more detailed practice
of Scrum as an Agile method. This time around, I decided that it is best to focus on the
subtitle and publish another book entitled ‘Scrum: a manager’s guide to getting value faster’
to cover the specific and practical Scrum content.

Neither of these books is academic textbooks (although they can be used in academia). The
intent is to have a practical conversation motivating why agile is a good choice for your
organization (this book) and a simple introduction to applying a simple, agile method,
called Scrum (book 2).

Many people get hung-up with the details of a specific agile method. Still, I would argue
that it’s not very agile to do so. Organizations would be better off if they explore what
each method brings and create something fit-for-purpose for their specific organizational
context. That being said, some fundamental principles and practices need to remain to call
any method agile.

These two books will help you understand the fundamentals of agile project and program
management and to be able to make informed decisions about agile methods and how
you could apply them in your organization. In fact, this book (the first one) is specifically
written to prepare managers for the fundamental organizational and cultural shifts that
accompany the decision to make your organization more agile! Agile is more of a cultural
and behavioral shift than it is changing project methods! This is the most fundamental
lesson organizational leaders and managers need to get – and I really mean, get!

We used the countless questions we were asked during the last two decades since we started
teaching people how to be and use agile. It also draws on nearly two decades of practical
experience using Agile and Lean, mostly in IT and transformational projects.

This book was written so that a busy executive or manager can finish it over a weekend of
casual reading or if they are stuck for a few hours on an airplane. We tried to make it as
easy as possible to understand and used examples to make the experience painless.

Like any method, Agile and Scrum have specific terms and terminology, and to be able
to be involved in a discussion or the practice of Agile, you need to know the basic lingo.
After reading this book, you should have a good idea of how agile projects and program
management work, and you should be able to use what you have learned here, as is,
immediately.

8
AGILE, A MANAGER’S GUIDE Foreword

This book is the perfect tool to start your agile journey, but don’t stop here. Learning and
evolving is part of every agile journey. The second book in this series: ‘Scrum: a manager’s
guide to getting value faster’ is an obvious second read!

Much of the book’s content was borrowed from previous writing, especially our courses on
DSDM and Scrum, but also borrowed from our agile, lean, DevOps and Agile ADapT™
consulting practice. That also means that you may also find some of my other books
interesting and helpful, especially the Agile ADapT™ series on Digital Transformation and
Innovation (available as BookBoon titles).

All the best, and a pleasant agile journey.

Johann Botha,
February 2021, Johannesburg South Africa.

9
AGILE, A MANAGER’S GUIDE What is Agile?

1 WHAT IS AGILE?
Big ‘A’ Agile (noun): relating to or denoting a method of project management, often used
for software development, the division of tasks characterizes that into short phases of work
and frequent reassessment and adaptation of plans.

Small ‘a’ agile (adjective): able to move quickly and easily; able to think, understand and
respond quickly.

I love the simplicity of these definitions to be found on PM-partners website in Australia,

as it sets the scene perfectly.

1.1 AGILE AS A VALUE DELIVERY APPROACH

(AGILE WITH A BIG ‘A’)
Agile project management approaches are ideal for empirical value delivery programs like
software design and development. In fact, that would be true for any project in a complex
system, subject to a constant state of flux where the organization must continually unlock
value for customers. The number of variables and unknown factors in these initiatives makes
a traditional waterfall project management approach impractical.

You may ask why we wrote project management in italics. It will become evident as you will
come to realize that Agile is not about delivering value in the form of projects (projects have
a start and end-date), but rather as a means to continually deliver and unlock new value for
customers in an ongoing and incremental fashion. Agile emphasizes the notion of discovery,
and as a consequence, experimentation is an acceptable means to create and deliver value
in an ongoing and continually evolving fashion. This radical departure from what we know
about projects as the only way to create new and complex things may be disturbing in the
beginning. Getting to grips with the essence of Agile requires a mental reset!

This book is called Agile, a manager’s guide to unlocking value for a very specific reason. The
intent is not to teach you an agile ‘project management’ method; it helps you understand
how you, as a manager, can use Agile as a means to unlock value. But don’t worry; the
confusion and doubt will dissipate as you progress through the book!

10
AGILE, A MANAGER’S GUIDE What is Agile?

1.2 ORIGINS
The concept of “Agile” was first defined in 2001 at the Snowbird ski resort in Utah’s
mountains. The outcome of this seminal meeting was the Agile Software Development
Manifesto, known today as the Agile Manifesto (and accompanying principles).

The reasons for developing the Agile Manifesto by the seventeen visionaries present included
the frustration with long delivery cycles, vast amounts of planning that proved worthless,
and the continually changing requirements (as the world changed around them during a
project). These frustrations led to the creation of the manifesto and the twelve associated
principles that explain how Agile will help organizations deliver better value faster and with
exceptional delivery quality.

It was soon realized that what works well for software development projects could work
well for any project where the requirements are unclear or constantly evolving. This level of
uncertainty in projects is pervasive. Virtually all of the projects I was involved in during my
nearly forty-year career, I had to deal with ambiguity, changing requirements, and learning
from mistakes as the project progressed.

Agile and agile methods are, therefore, the only way to go if you are faced with an environment
where the future is unclear, deliverables cannot be clearly defined from the beginning of a
project, and where you need to learn as you go along. An empirical approach is the most
sensible approach when dealing with uncertainty, ambiguity, and the constant change that
happens on complex adaptive systems like organizations (and their projects). What makes
using conventional project management (we call it the waterfall approach) so limiting is the
assumption people make that detailed project planning could and should (always) precede
project execution. I have not been involved in a single Agile ‘project’ where some time was
not spent pre-planning. The difference is that with an agile approach, you plan based on
what you know, you record what you don’t, and you allow people who need to deliver
to answer the questions while they are busy with delivery. To those who assume that
they can make a perfect detailed plan at the beginning of a project, I say this, “no-one is
smart or lucky enough to be able to plan and predict everything, especially not up-front.”

The next thing that we need to remind ourselves of is that projects are much more about
customer expectations than specifications. No matter how well we try to define specifications
up-front, we will never be able to capture and quantify customers’ and users’ expectations.
What makes it more difficult is that expectations change over time! We quite often say that
the output (what you deliver) doesn’t matter to customers; it is the outcome (what they
can do or achieve with what you deliver) that does. This means that customers are satisfied
when ‘what’ the project delivers (the output specified) enables them to achieve what they
want or need (the outcome). Value is, therefore, always co-created by the supplier and the
customer – something worth remembering.

11
AGILE, A MANAGER’S GUIDE What is Agile?

So let me ask you a question:

How many times were you involved in a project where the delivery was very close to the specification
agreed with the customer, but they were still unhappy?

My answer to this question is many, if not most of the time (before we started doing
things the agile way).

OK, we have just confirmed that the normal way in which projects are delivered normally
leaves customers wanting!

There are two reasons for higher levels of customer satisfaction when Agile is used:

Agile engages users and customers by making them part of the project, which allows them to
provide feedback early on.

Agile gives us the ability to deliver against a two-week-old expectation rather than a two-year-
old one.

The world changes, and so do the needs of our customers.

1.3 AGILE AS A WAY OF THINKING AND

ACTING (AGILE WITH A SMALL ‘A’)
It is worth remembering that much of the initial discussion at Snowbird was around a
different way of working and how using techniques from TQM (the Plan Do Check Act
cycle) and Lean (or the Toyota Production System) applies to software development.

It is no wonder that if we look at the twelve principles of agile, there is a striking resemblance
to the principles found in Lean. The discussion focused on how project teams should
value certain things (this over that) and translate this into a set of principles to apply in
software development. It is only natural that the Agile Methods were developed as a result
of practitioners needing to move from principle to practice. Today, all the Agile Methods
use the twelve principles as guidance or a moral compass.

Now is a good time to remind you of the four things agile ‘teams’ value and the twelve
principles themselves.

Value 1 - Individuals and interactions over processes and tools

Value 2 - Working software (or whatever it is that your project needs to deliver)
over comprehensive documentation

12
AGILE, A MANAGER’S GUIDE What is Agile?

Value 3 - Customer collaboration over contract negotiation

Value 4 - Responding to change over following a plan

Just looking at the values, it is clear that it’s more important to help customers get value
than all the other things we do in projects. Please note that these statements do not say the
processes, tools, documentation, contracts, and plans are not important. The values merely
state that talking and working with people, giving them something that satisfies their needs,
involving them in the process of delivering value, and knowing when their circumstances
and needs have changed are more important.

The principles build on the above-stated values and make them actionable; they are
(paraphrased and removed of the software development jargon):

1. The highest priority is to satisfy the customer through early and continuous delivery.
2. Welcome changing requirements, even late in development.
3. Deliver something that frequently works, with a preference for the shorter timescale.
4. Business people and developers must work together daily to figure out what is
essential now!
5. Motivated people always perform better, create a supportive environment, and trust
them to get the job done.
6. A face-to-face conversation is always more efficient and effective.
7. Delivering something that works is the primary measure of progress.
8. Work at a sustainable pace because you want to continue indefinitely.
9. Being good at what you do means you can be more agile.
10. Simplicity is the art of maximizing the amount of work not done. Do just enough.
11. Self-managing teams come up with the best plans.
12. Teams should regularly reflect on how to become better.

By now, you should see why we say agile with a small ‘a’ is a mindset. It is guided by
principles of which customer centricity is probably the most important. Agile with a small
‘a’ is about developing a deliberate set of cultural, organizational, and behavioral changes,
starting at the leadership echelon in an organization.

No amount of using the Agile project techniques, producing the artifacts, renaming or
creating new roles, or practicing new rituals will make Agile with a big ‘A’ succeed in your
organization unless you become agile with a small ‘a’. Becoming agile with a small ‘’’a’ is
not an easy thing to do.

13
AGILE, A MANAGER’S GUIDE What is Agile?

If you ask me why so many Agile initiatives fail – my definitive answer is that you must
be agile with a small ‘a’ before the Agile with a big ‘A’ would work for your organization.
However, it is human nature to get fixated on a model or method that seems to work and
then start advocating that method. These methods are all Agile with a big ‘A’. However, only
if you use the twelve principles in your organization to achieve business agility, regardless
of method, you are practicing agile with a small ‘a’. This is more likely to bring success and
is closest to the spirit of the agile manifesto.

You may then ask why I include content surrounding methods such as Scrum in this book.

The content surrounding the Scrum method described here is valuable as examples. They
are helpful aids, and they will serve you in good stead, but never let any Agile method
(including Scrum) dictate what and how you do things. Because then you have lost true
organizational agility. Agile with a big ‘A’ should always serve agile with a small ‘a’, and
not the other way round.

14
AGILE, A MANAGER’S GUIDE Making a case for Agile

2 MAKING A CASE FOR AGILE

Selling the benefits of Agile is difficult at first, and it is best done on a personal level. In
this short chapter, we will share one possible approach for you to consider. It has proven
to work well.

The approach taken is an interactive story/roleplay with the skeptic and the advocate as
the two main characters. Since we work predominantly in IT environments, our story is
an IT project story, but it can quite easily be adapted to any environment by changing
the scenario and some of the parameters used. Our chosen story is about ten years old,
but because most people have seen online initiatives succeed and fail, it seems to be an
appropriate example to use.

You may also say that the company has other options today, and that is true, but we
specifically chose the story to illustrate a point, not to debate strategy.

2.1 EXPLORING REALITY WITH A SIMPLE EXAMPLE

The following serves as some background to set the scene:

Buy-it-all Inc. is a thriving retailer in the fast-moving consumer goods (FMCG) market. They
have achieved success in the last ten years and have grown their retail operation from two to
fifteen outlets situated in the nation’s largest ten metropolitan areas. Recently Buy-it-all has come
under pressure from online retailers. Although the company has an extensive online marketing
presence, management realizes that they rapidly need to develop online retail capabilities. If
they can do this successfully, they can leverage their existing market position and relationships to
out-compete the new competition.

Two options can be presented for consideration to achieve the desired goal. After each, you should
ask business role-players for feedback. The aim is that they convince themselves that an agile
approach using an agile method is the preferred solution.

Option 1 – Conventional (waterfall) project approach (typical in incumbent organizations).

Research what the competition does (2 months – done by IT)

Research technology available (2 months – done by IT)

15
AGILE, A MANAGER’S GUIDE Making a case for Agile

Define detailed specifications for an online retail capability and create a business case (4 months -
collect requirements from the business by a BA (from IT)

Design an online retail capability (4 months - done by IT)

Develop that online retail capability (12 months - done by IT silos, development, testing, Release
management, IT operations)

(Total project time – 24 months)

Now ask your audience the following questions

• Would you say the above is a reasonable representation of projects of this nature
in your business?
Normally the answer is yes.

• In the competitive scenario described above, could you wait two years for a
solution?
Normally the answer to the above is no.

16
AGILE, A MANAGER’S GUIDE Making a case for Agile

• What would happen if you had to wait two years?

Normally the answer spells out doom and gloom.

• What do you consider a reasonable time to be able to compete with this new
entrant?
Answers normally range from 4 to 6 months.

• Do you think the requirements defined and agreed in month 5 of the scenario
above would be the same 19 months later (when the project is completed –
hopefully)?
Normally the answer to the above is no.

• Do you think the business case submitted for approval in month 8 of the
project would be valid 16 months later?
Normally the answer to the above is no.

• In your experience, do projects of this nature complete within budget and on

time?
Normally the answer to the above is no.

• What compromises would you rather settle for?

Answers here vary, but in general, the following crops up (not in order of importance):
a. A lesser product in a shorter time
b. Outsourcing the shop to another party
c. Utilizing an existing platform
d. Spending more money to get it done sooner

Although b. and c. are valid options and should be explored, they both have distinct
disadvantages - i.e. loss of control, customer, and lower margins. Spending more money
may be feasible if the company is cash-rich, but our experience is that this option is often
not viable or at least not popular.

Option 2 – An Agile project approach

• Identify general high-level requirements based on the organization’s own needs
and what competitors do (1 month – done by business, with the help of IT)
• Identify one or two product ranges that would most likely sell well online (2
weeks – done by business, with the help of IT)
• Identify and investigate the minimum capability required to offer these products
online (2-week design Sprint – done by IT with the help of business)
• Build basic shopping cart capability (4-week Sprint – done by IT)

17
AGILE, A MANAGER’S GUIDE Making a case for Agile

• Build & test user interface (4-week Sprint – done by IT)

• Refine solution (2-week Sprint – done by IT)
• Launch basic capability
• Enhance the capability of the online shop to include all products eventually
deemed viable to sell online (4-week Sprints for the next year – done by IT
based on feedback from the business on buyer/customer behavior)

(Total time to have the online capability – 4 ½ months. Time to have a refined and
feature-rich online capability - +/- 18 months)

2.2 QUESTIONS TO THE BUSINESS

OK, we have seen two alternative approaches, and we also by now know the reality we face
when doing projects. Now, let us ask the business (normally senior and middle managers)
some questions:

• Are you happy that on the launch date, the online shopping capability did not
meet all your requirements?
Normally the answer to the above is no.

• Would you rather have all the requirements met if it meant waiting for another
19 months?
Normally the answer to the above is no.

• Do you think requirements (or your understanding of requirements) would

change in the 18 months following the launch?
Normally the answer to the above is yes.

• Have all of the upfront requirements defined in the past (for typical two-year
projects) proven to be all required or valid?
Normally the answer to the above is no.

• Thinking back to your experiences with past projects, after the two-year period
between project definition and project delivery, have you asked for the system to
be updated and why?
Normally the answer to the above is yes, new requirements emerged, changing markets,
customers, competitive situation etc.

• How many new requirements emerged during the two-year period (as a
percentage)?
This answer may vary from industry to industry; on average, the answer is quite a few.

18
AGILE, A MANAGER’S GUIDE Making a case for Agile

• What percentage of current features would you consider to be essential?

This answer may vary from industry to industry; on average, the answer is most, but
not all.

• Of the two scenarios given, if you were the management of Buy-it-all Inc.,
which option would you have chosen?
Most of the times, the answer is Option 2

Like money, time also has value, and if one compares the value/time equation, Agile is a
no-brainer. Agile is potentially suitable for every organization. Some will face more challenges
in changing organizational mindsets and ways of working than others, but everyone can.
Those who do not will most likely not survive to fight another day in this fast-changing
digital age. Culturally, however, Agile will not work in all environments, and unless there
is at least some willingness by top management to embrace agile concepts, it is best not
to pursue them. The question top management needs to ask themselves is, ‘can we survive
if we don’t embrace the concept of business agility?” This implies a willingness to face the
facts. Becoming agile is not an easy task, nor is it an easy decision. It takes boldness and
bravery to see it through. But fortune favors the brave.

Oct 2019 Jan 2020 Apr 2020 Jul 2020 Oct 2020 Jan 2021 Apr 2021 Jul 2021 Oct 2021

TRADITIONAL WATERFALL
Requirements Gathering
Requirements Analysis
Requirements Definition

Requirement 1 Planning Build Req.1 Build Req.2 Build Req.3 Build Req.4
Requirement 2
Requirement 3
Requirement 4

VS
AGILA APPROACH
Value Unlock
Requirement 1 for Customer
No Longer Needed Req. 7 Overtime
Requirement Req. 6
Req. 1 Req. 3 2 Changed Req. 4 Req. 5 7
7
6
Req. 2 6
4 5
3 4 5
2 2
2
1
1

X = Sprint

Figure 1 Agile creates more value sooner than the traditional project management approach (Agile: a
manager’s guide to unlocking business value, © JH Botha.)
Note: White-space represents value unlocked over time

19
AGILE, A MANAGER’S GUIDE Critical Success Factors for getting Agile right

3 CRITICAL SUCCESS FACTORS

FOR GETTING AGILE RIGHT
Agile is an approach to deliver value to customers using short iterative delivery cycles, with
high customer involvement by cross-functional teams who take ownership of the quality
of deliverables.

To describe anything more than this would be to start delving into a specific agile method.

Unfortunately, you can’t get a consultant to make your organization agile or even implement
an Agile method - You have to do it yourself! If any consultant tells you they can, run!

The only way to get this right is for the organizational leadership and management to
play a central role in what will be quite a substantial organizational change initiative.

We did not write this book by change – we wrote it because, as consultants and agile
coaches, we understand how important managers are to get organizations to be agile!

Generally speaking, some critical success factors can be defined regardless of which Agile
method you use.

3.1 LEADERSHIP AND BEHAVIOR, CULTURE, ETHICS, AND TRUST

Although any or part of an organization can use agile methods, Agile works best if the right
environment is created through leadership.

Agile, like Lean, is a cultural and behavioral phenomenon before anything else. In essence,
the changes in behavior it advocates work best if the organization’s leadership understands
and commits to enabling them. These changes in culture are impacted quite significantly
by the leadership style in the organization.

In the last 20 years, people have talked a lot about servant leadership, but very little has
changed in the way management behaves, acts, and manages. What makes the implementation
of Agile successful in organizations more than anything else is a change in managers’ attitudes
at all organizational levels.

20
AGILE, A MANAGER’S GUIDE Critical Success Factors for getting Agile right

The reason why this is so important is that autonomous, self-regulating, cross-functional

teams execute agile projects. For this to work, a fundamental shift in the management and
leadership style has to occur.

In Michael Shota’s words, the leadership must understand that it is not about Doing Agile;
it is about Being Agile, and being agile starts with the leadership of the organization.

Leaders in organizations where successful adoption of Agile occurs show a genuine interest
in how employees execute their tasks and inspire employees to develop and act as coaches,
teachers, and enablers rather than supervisors.

Successful Agile implementations require trust and openness, meaning an unwavering

commitment from management towards all staff and a genuine desire to enable people in
the organization to become the best that they can be. It also requires communication to be
open, frank, and fair, and employees being able to trust when engaging with leadership and
its structures in the organization.

When asked, how do you create an environment of trust and openness? We say that
management needs to learn to trust their people to do the right thing.

Employees will never exhibit the required open and frank communication to make Agile and
Lean work unless they know that they can trust management. Leadership will not punish
them if they try something new, speak the truth, and are honest about what happened.

Ernest Hemmingway defined it as, “The best way to find out if you can trust someone is to
trust them.”

An example of why high-trust environments are so much more beneficial to organizations

than low-trust ones is as follows.

3.2 LOW-TRUST
Management doesn’t trust staff to do their work well, and therefore they prescribe to
employees how to do their jobs.

Often, the methods specified by management are impractical, outdated, or cumbersome, and
to get their work done, staff do the work to facilitate the required output. The danger in
this scenario is that the safety net and controls that formed part of the prescribed method,
process or procedure, now also fall by the wayside.

21
AGILE, A MANAGER’S GUIDE Critical Success Factors for getting Agile right

If something goes wrong, no-one will acknowledge that they did not follow the process, and
mistakes are often hidden by employees trying to ‘escape’ punishment for their misdeeds.

The result is that the environment becomes even more unstable until, eventually, a major
breakdown occurs.

As part of root cause analysis, a witch-hunt is started to find and punish the guilty party.

The problem is that even if the guilty party was discovered and punished, the organization
and management lose, the damage is done, and what’s lost is lost. Surprisingly, this toxic
behavior is the modus operandi in many organizations.

Richard DiPilla said that “It does not make sense to hire chess players and then to treat them like
chess pieces. It does not make sense to hire smart people and then have them follow stupid rules.”

Now let’s explore the behaviors expected in an agile environment in contrast to the above.

3.3 HIGH-TRUST
Management employs professional people and expects them to use their skills and talents for
the betterment of the organization. Staff working together in small teams (3 to 9 typically)
are given a goal and decide amongst themselves how it will be achieved and how the work
will be structured to accomplish the goal within the set time frame.

Because the team members are closer to work done, they have a much better understanding
of how things work practically and what needs to be done.

They design their own work using heuristic controls1 (defined by the management) to ensure
risk is minimized while optimum performance is achieved.

If something goes wrong, the team openly communicates and tries to find a permanent fix
to ensure reoccurrence does not happen.

Management supports the team with advice by rolling stones out of the way and becoming
a facilitator and intermediary between teams.

Because failure is accepted as part of life but not tolerated if it continues, problems are
solved continually and hardly ever build up to catastrophic failures. In this scenario constant,
organizational learning occurs, and performance continually improves.

22
AGILE, A MANAGER’S GUIDE Critical Success Factors for getting Agile right

Which of the two work environments do you regard as the most desirable? Where would you
rather work? If you are a manager, imagine that you are not and honestly answer the question. If
you choose a high-trust environment, surely your people also deserve to work in an environment
like that?

From the above example, you may have realized that one of the significant cultural and
behavioral shifts that need to occur in an agile organization is becoming a “learning”
organization. The second significant shift is to transformation to a high-trust environment,
where people are not afraid to tackle problems when they see them and solve problems
before it becomes an issue for or in the organization.

Peter Senge popularized the idea of a learning organization in his book The Fifth Discipline,
and it is well worth taking a leaf out of the book. Senge proposed the following five
characteristics of a learning organization:

• Systems thinking, meaning that everyone should understand the organization as

a system. The better everyone understands the system, the more they will learn
and the better the organization will become as a consequence.
• Systems thinking also implies an individual commitment to learning and
personal mastery becoming the norm in the organization. Learning becomes
more than just acquiring knowledge but instead a focus on the ability to
be more productive. Individual learning is the individual’s responsibility
and not exclusively that of the organization, and “personal mastery”
should be practiced daily.

Assumptions held by people (mental models) need to change. These assumptions can only
change if an open culture that promotes inquiry and trust replaces confrontational attitudes.

The development of a shared vision is an essential self-learning motivation for staff, as it

creates a collective identity that provides focus and energy for learning. Applying the practices
of a shared vision creates a suitable environment for the development of trust through
communication and collaboration within the organization. It encourages the staff to share
their own experiences and opinions, thus enhancing the effects of organizational learning.

Team learning occurs through sharing accumulated individual knowledge. The benefit of
the team or shared learning is that staff grow more quickly. The problem-solving capacity
of the organization is improved through better access to (cross-functional) knowledge and
expertise. Individuals are engaged in using dialogue and discussion to achieve shared meaning
and understanding. The individuals must have concrete ways of sharing knowledge.

23
AGILE, A MANAGER’S GUIDE Critical Success Factors for getting Agile right

3.4 AGILE AND ITS IMPACT ON ORGANIZATIONAL STRUCTURE

Theoretically, Agile can be used in any organization. If done well, Agile will inevitably
start to change the organization’s fabric, impacting on the structure and how roles and
responsibilities are defined the most.

Because Agile requires that autonomous cross-functional teams execute projects, this inevitably
leads to flatter organizations and multi-skilled, multi-talented employees who require less
supervision.

We sincerely believe that the organization of the future will be just that. As more and more
people in the workplace become knowledge workers, the need for complex management
structures is becoming less important.

24
 A VERY QUICK LOOK AT A TYPICAL
AGILE, A MANAGER’S GUIDE AGILE METHOD (SCRUM)

4 A VERY QUICK LOOK AT A

TYPICAL AGILE METHOD (SCRUM)
In the foreword, we said that we will not describe a specific method in this book but rather
lift the conversation to a higher level. However, we must focus on how the use of a method
to delivers value.

However, the way agile project management works are so radically different that we need to
give a high-level overview of what that different way of works looks like and, while doing
so, highlighting why this way of work is so different, why it works better, and impact for
you as a manager.

Do not see this chapter as a mini-course on Scrum (the method that we will use to
illustrate the concepts), for that it would be better to read Scrum: a manager’s guide to
getting value faster.

We used Scrum as an example of how agile methods work for two reasons; it’s really simple
and easy to learn how to use Scrum. Secondly, we are in love with the simplicity of Scrum
and honestly believe that it works well in any context, and if you know how, it scales

25
 A VERY QUICK LOOK AT A TYPICAL
AGILE, A MANAGER’S GUIDE AGILE METHOD (SCRUM)

exceptionally well to even the largest organization. So with Scrum, you can start small in
a team and eventually scale the use of Scrum to an entire global enterprise. Some skeptics
will argue the facts, but it’s just a matter of understanding how to scale (unfortunately,
most people don’t!)

4.1 THE BASICS OF SCRUM

Scrum defines three accountabilities (let’s call them roles for now), five events (main activities),
and three artifacts (outputs) with associated commitments. We will briefly describe them,
not to learn how to do them, but to understand how Scrum works to create value and why
working this way can help your organization to do so also.

SPRINT
RETROSPECTIVE

Product Improved
Refinement way of work

SPRINT PLANNING
Product
Backlog DAILY
Sprint Backlog
SCRUM
Product Sprint
Goal Goal
Increment 1
Task 1 Definitions of Done
Task 2
Task x
DoD
SPRINT
Increment 1
REVIEW
Delivered
Backlog Refinement Increment/s

THE SPRINT

Figure 2 Scrum simply depicted. Events in red, artifacts in green, and commitments in yellow.

To do this properly, though, we will have to also talk about a few other things in Scrum.

In Scrum, we define a high-level list of requirements. The organization will not do any
detailed planning until someone starts works on delivering the requirement. The business
decides which of these requirements should be worked on first, normally based on the
feature’s immediate value

Secondly, Scrum does work in short (no longer than four weeks) Sprints (projects) to finish
something useful. You will never get all the requirements; Scrum delivers against requirements
and is more like making continual improvement than running projects. At first, this seems
senseless, as we are used to getting a fully-fledged product after a project, and now you will
get just part of a product or features of a product every four weeks.

26
 A VERY QUICK LOOK AT A TYPICAL
AGILE, A MANAGER’S GUIDE AGILE METHOD (SCRUM)

Before you get upset, I would like to remind you of our Buy-it-all example earlier. What
did you say again? You would rather get part of the value now (soon) than everything two
years later.

Unless your project is building a bridge or a road, you can break it up into small bits that
can either be used as soon as it’s done or, in a worst-case scenario, can be tested to make
sure it will work once combined with other bits. So you can either get immediate benefit
or have the luxury to try it out properly, and tell the development team that that is not
quite what you wanted!

That brings us to the next important thing. If what was delivered is not to your liking, you
can give the team making it to change, new or changes requirements and in a short period
see if that works. Because the list teams work from contains all the things you want, and
not everything is worked on simultaneously, it makes it a very flexible approach!

And that brings us to the next thing that is great about Scrum (Agile); you can always add
new requirements to the list of things you want, and since you (the business) decides on
what gets done first, you don’t have to wait 12 months, you can often have it in as little
as four weeks – with one humongous proviso. The business needs to decide what will take
the backseat if the new requirement is pushed-in, into the list of things to be done.

Quite honestly, this sounds more-and-more like the business reality than the old way of
doing things!

Let’s zoom in a bit to the Scrum 3/5/3 (three accountabilities, - five events, and three
outputs and associated commitments) structure we talked about earlier.

IMPORTANT NOTE: If you are familiar with Scrum and don’t like the language we use
because it is not Scrum, bear with us; we are not writing this for Scrum Experts. This book
intends to make sure that everyone, especially those who have never been exposed to Scrum,
will understand the ideas shared here!

4.2 SCRUM VALUES

By making the Scrum values explicit and transparent, these values highlight the power of
Scrum and provide true north (direction) for Scrum Teams and the decisions they need to
make. The Scrum values help teams adopt and practice Scrum and create a great place to
work and deliver stunning results to the business and customers.

The Scrum Guide lists five values that all successful Scrum Teams share: commitment,
courage, focus, openness, and respect.

27
 A VERY QUICK LOOK AT A TYPICAL
AGILE, A MANAGER’S GUIDE AGILE METHOD (SCRUM)

COMMITMENT OPENNESS

RESPECT COURAGE

FOCUS
PEOPLE

Figure The core values of Scrum revolve around people

When the values of commitment, courage, focus, openness, and respect are embodied
and lived by the Scrum Team. In doing so, the Scrum pillars of transparency, inspection,
and adaptation come to life. Successful use of Scrum depends on people becoming more
proficient in living these five values.

The Scrum Team (the three accountabilities combined) commits achieving the defined
goals and supporting each other in this endeavor. The team’s primary focus is on the work
defined for a Sprint and to ensure that progress towards set goals is achieved. As a team,
they are open and honest about their work and the challenges they face; the bad news is
never hidden but immediately shared with the team, allowing other team members to help
where they can. They respect everyone they work with and show that in how they behave
and act towards each other. In this vein, they acknowledge that every member is a unique
individual with unique capabilities offered by every member to one another. Scrum Team
members show courage by speaking up when something is wrong or bothering them,
without blame, and doing the right thing, and they always address the problem and don’t
make conversations personal.

Just by looking at how team members behave in Scrum Teams, you can already see that
living the Scrum values will need a substantially different way of managing an organization.

28
AGILE, A MANAGER’S GUIDE The Three Scrum Accountabilities

5 THE THREE SCRUM

ACCOUNTABILITIES
We will not go into the choice of words used in Scrum now; you can read more about that
in the second book. Let us say that we use the word accountabilities like you would use the
word roles traditionally in an organization.

There are three accountabilities: the Product Owner, the Scrum Master, and Developers.
Combined, we will talk about them as a Scrum Team.

5.1 THE PRODUCT OWNER

To my mind, the Product Owner is the most important of all three of these accountabilities
because that is the name that we give the person that will represent the will of the customer
or business. Ownership in itself implies accountability for what eventually gets done and
delivered to the rest of the organization – yes, correct, but with a twist!

Product Owners own the list of requirements of the business for a specific product. Every
product has its own Product Owner.

Product ownership is a business role; it is not a project role!

Product Owners will order the list of things to be done, starting by listing the most critical
items to the business at the top of the list and the least important requirements at the
bottom. Remember, this is for a specific product and not for the entire business. The list
should be kept as short as possible and should preferably not exceed 100 items. We call
this list a Product Backlog!

As Product Owners will be accountable for the order of items in the Product Backlog, they
need enough seniority to make decisions on behalf of the business. The rest of the business
should also respect their choices. They don’t make decisions in isolation but will always
consult with all business stakeholders; someone, however, needs to make the final call!

The genius of this way of work is that Scrum teams will always work on the most important
things to the business. It sounds simple, but it will be very difficult for Product Owners to
decide on the order of the list in the beginning. It is best to consult widely in the business
and with the team that needs to build product features as they will have insights into possible
problems and interdependencies between items in the Product Backlog.

29
AGILE, A MANAGER’S GUIDE The Three Scrum Accountabilities

Therefore, we can say that the Product Owner is accountable that the work done by the
team maximizes product value.

5.2 DEVELOPERS
Product Owners may work with multiple teams of Developers, to get items in their Product
Backlog done. Developers are everyone that is part of creating, building, testing, and installing
a feature or a part of a product. Developers are organized as small between two and eight-
person teams, with a broad range of skills. Developers are a curious breed of a new type
of employee. They don’t just have a specific technical skill or even a set of technical skills;
there is more to it.

Developers form cross-functional teams with all the skills necessary to take some product
backlog items and turn them into something useful and valuable. They do this every one to
four weeks, which means that the product becomes incrementally better, more useful, and
valuable to customers, and continually. Remember I said that Agile is more like continual
improvement than project management – this is why!

In our Buy-it-all example earlier, we acknowledged that business requirements are dynamic;
they keep changing over time, and the longer the time frame, the more likely they will
change substantially. In Scrum, this is not a problem because as priorities change, the
Product Owner changes the order of items in the product backlog. That means that the
most important things that Developers need to work on will always be at the top of the list!

But here is another departure from tradition. We see Developers as self-managed teams;
they not only decide who will do what, how much work can be done in a four-week
period, and who will do what, they also decide what will be worked on during the next
four-week iteration.

Now I can already hear you say – that will never work, and you just told us that the Product
Owners decides what is worked on. Well, actually, it does work, and no, I did not tell you
that the Product Owner decides what gets worked on – all I said is that the Product Owner
makes sure that the most important bits are at the top of the backlog so that Developers
can work on those items.

Developers choose work from the top of the list based on their ability to get the chosen
work done. If an item is at number one, but the team doesn’t have the ability to do the
work, why should they be assigned work if we know that they will fail?

30
AGILE, A MANAGER’S GUIDE The Three Scrum Accountabilities

Developers choose items they believe (normally based on past performance) they will complete
entirely during the next four weeks Sprint. They commit to it, and if they fail, they fail as
a team – they are accountable to get the work done!

You cannot hold someone accountable if they do not have control over what they do! That
is a recipe for disaster! However, during a four-week sprint, what is done is often based on
a negotiation between Developers and the Product Owner.

So we can say that Developers are a group of people that ensures that done-increments are
made available for use, every Sprint.

5.3 SCRUM MASTER

The last accountability is that of the Scrum Master. You may be excused for thinking that
‘ ‘it’s just another name for a project manager, but you will be mistaken.

The Scrum Master is a servant leader of the team (or teams) they support. Their role is
to keep people off the back of Developers while working. Scrum Masters also facilitate
communication, find solutions to conflicts, and find ways to remove impediments that may
impair the Developers or stop them from getting the things they promised to get done, done!

Scrum Masters is therefore accountable for establishing Scrum as a practice, as defined in the
Scrum Guide. They do so by ensuring a deep understanding of Scrum and assisting team
members with learning how to use scrum guidance. They also ensure that Scrum values are
lived and practices so that the team can unlock the maximum value.

‘ ‘I’m not going to spend much time in this book on the role of the Scrum Master, ‘ ‘it’s an
important role nonetheless, and we will deal with what Scrum Masters do in much more
detail in the next book.

31
AGILE, A MANAGER’S GUIDE The Five Scrum Events

6 THE FIVE SCRUM EVENTS

The five events described in the Sprint are Sprint planning, the Daily Scrum, the Sprint
Review, and the Sprint Retrospective.

The Sprint is a container event for the other four events.

6.1 WHY ARE EVENTS IMPORTANT

Why are events important? Well, for several reasons, but primarily one can say it’s to manage
time and quality.

Let’s talk about time first. In Scrum, all events are time-boxed, which means that they have
a pre-determined and fixed length.

But why set fixed times for events? That does not sound very Agile?

Have you ever worked on an important task, and just when you started getting into the
zone, you had to interrupt the work to go to a meeting? Your concentration is immediately
broken, and you snap out of the zone of being hyper-productive; you may be upset after
the meeting; you just never able to get back the flow, inspiration, and focus you had before
the interruption.

Time-boxing alleviates interruptions to workflow, and team members can focus on what needs
to be done and say no to competing priorities. The result is much higher task completion
rates, a better quality of work done, and a substantial contribution towards employee well-
being. Team members have a greater sense of control, accomplishment, and, dare we say,
the purpose of focusing on work and getting it done!

Productivity levels soar if people are allowed to focus and get into a state of flow, which
directly impacts business outcomes. You may also now see why we said that one of the roles
of a Scrum Master is to keep competing demands away from team members!

Task switching is the worst productivity scourge in business today. Yet, when competing
demands occur, the natural response is not to get stuff done and focus. No, people constantly
switch between tasks, desperately trying to keep everyone happy, and eventually fail to keep
anyone happy because of low productivity and low quality work resulting from a lack of focus!

32
AGILE, A MANAGER’S GUIDE The Five Scrum Events

Freeing team members to focus on what is important, using time-boxes, costs nothing to
implement and can potentially transform organizational productivity and the quality of
work and organizational outcomes!

Time-boxing also establishes a cadence in the organization. Everyone knows when things
are done when the next thing will start, and when to expect something. In short, it creates
a sense of stability and lessens anxiety!

The Second major concept connected to events is the fundamental reason for Scrum principles.
Agile and Scrum is, in fact, an empirical approach to solving organizational problems; we
can be very specific about the problem. However, in general, all organizations can say that
the status quo needs to change, and business demands change over time.

So why do we say it’s an empirical approach?

Well, as the environment changes, we continually need to find out how to respond to the
changes. There are two ways of doing it; we can spend a lot of time analyzing, planning, and
hoping to come up with s solution. This way seldom works and takes a lot of time. Fifty
years ago, the pace of change was much slower, and companies were often lucky enough
to get a positive outcome using this approach; this is no longer true today.

Today the business environment changes so fast that we cannot wait six months to respond.
Often one month is not even enough! The only way to handle this challenge is to use an
empirical approach to solve our problems.

The three pillars of Scrum are Transparency, Inspection, and Adaption. These pillars enable
organizations to respond very quickly to issues as they become observable, formulate a
response, try it out and if it did not have the desired effect, try something else.

You may question the logic of this approach but consider the following.

Your business is a complex adaptive system, and the market in which you operate is even
more complex. It is useless to try to understand all dependencies and interdependencies
today because you never will be able to do so in any case. Organizations that do this falls
into analysis paralysis and never do anything.

It is much better to use a scientific approach (that is what empiricism is) to formulate a
hypothesis (idea or theory), test it. If it’s not the solution, develop the next hypothesis to
try out. We learn as we go along, but we do virtually respond immediately!

33
AGILE, A MANAGER’S GUIDE The Five Scrum Events

This whole approach is built into every single Scrum Event – principally, teams are transparent,
work is transparent, and communication is transparent, but to maintain this level of
transparency, managers heed to create high-trust environments. There are multiple times to
inspect what was done during each event, evaluate it, and adapt the response as necessary!

In Scrum, this inspection and adaption is a daily occurrence because it is built into every
event!

Time-boxed events help maintain a balance between what gets done and getting things
done faster and at a sustained pace!

For the first time, Agile made me see what is meant by time is money in a very practical
manner, but not how most people think about it. Time is money because the faster you
can realize benefits, even the smallest bit, it compounds into massive business benefits very
soon. In fact, using an agile approach like Scrum not only means incremental improvement,
but the increments become exponential!

6.2 SPRINT PLANNING

A central premise in Agile is that we only plan based on what we know and only plan
when it is necessary. This sounds sensible, but the moment managers hear that there is no
project plan, they see red. But think about it – if there is no project, why should there be
a project plan?

So Sprint planning is the type of planning that happens just before we do the work; this
is the best time to do planning as the specialists doing the work also do the planning, and
it also means that we only plan work that will actually get done. The alternative with the
old project management (waterfall) approach was that we did pre-planning for a year or
two years worth of work, full-knowing that we don’t know a bunch of things, will have to
make many assumptions, and even if we were lucky enough to guess right, by the time we
actually get to do the work, the business requirements have most likely changed, and most
if not all of the planning is worth nothing, so it needs to be done again!

Once again, thinking back to the Buy-it-all Inc. example, at the beginning of the book, the
traditional way of doing things makes no sense. We all know it, and the only reason we
want detailed pre-planning to be done is because we have always done it that way; it gives
us a sense of comfort even though we know that it’s worth precious little.

34
AGILE, A MANAGER’S GUIDE The Five Scrum Events

The intent here is not to explore Sprint Planning in detail because as a manager, you will
most likely not be involved in it unless you are a member of the Sprint Team (a Product
Owner, Scrum Master, or a Developer). This may bring you a huge amount of discomfort;
surely you need to be involved, and who will check the decisions?

Well, remember the Product Owner represents the business, and if they or the rest of the
team is unsure, they will ask stakeholders for clarity. They know what to do, they know
what is important, they are a self-managed team and don’t need to be micromanaged by a
manager, or two, three, four…

Although Sprint Planning’s detail is not important in this book, it is one of the most
important activities if your organization is using Scrum. In essence, the Developers will see
how they can incrementally improve the current state of a product or service by delivering
components that add value to the business. More than one incremental improvement can
be delivered during a Sprint. It may be four or five small things or one bigger deliverable.
Each of these deliverable increments also has an associated commitment (quality criteria)
called the Definition of Done (DoD). If not meeting the DoD, the increment fails!

There are two new realities that managers need to deal with in this regard. Countless examples
and tons of data show that the further the person making the decision is from doing the
actual work, the worse the outcome will be! You, as a manager, employ specialists, trust
them to do the job right. I love this quote from Richard DiPilla; It does not make sense
to hire chess players and then treat them like chess pieces. It does not make sense to hire smart
people and then have them to follow stupid rules.

To my mind, this behavioral change in managers is the single most significant shift that will
determine agile success. It will be difficult at first to accept your changing role as managers
in the organization, and some of these new agile rules will certainly be far outside of our
comfort zone!

You may, at this stage of the book, want to say that it is not for you. You also know that
the pace of change in organizations and markets today is relentless; you also know that the
old way of doing things takes too long and fails too often; otherwise, you would not have
had the conversation in the first place!

Tom Peters once said that The greatest difficulty in the world is not for people to accept new
ideas, but to make them forget old ideas, and I think he is right.

Here are the facts though, yearning back to simpler days will not solve problems now, and
neither will the methods employed way back, then!

35
AGILE, A MANAGER’S GUIDE The Five Scrum Events

Here is some good advice from W Edwards Deming It’s not necessary to change. Survival is
not mandatory

You have to deal with it for your organization to not only survive but thrive; you will have
to change or go!

Just by the way, it sounds more daunting than what it is. Organizations embracing Agile still
do a lot of pre-planning; it is done at a strategic level, at a portfolio level, and a product
level; this last level of planning is just the last iteration of planning, however!

Plan just enough to make the decision you need to make at the time, based on the
information you have and not based on assumptions. Plan just enough! The challenge is
to unlearn doing lots of worthless planning that bear no resemblance to the conditions on
the ground at the time the decision needs to be executed!

Incidentally, in complex environments where lots of teams need to work together to deliver
value-generating outcomes, we introduce another level of planning. In this event, teams
can co-ordinate and think about dependencies and interdependencies between teams’ work
specifically. It is often called Scaled Scrum, or my preference Nexus, but more on that in
book two.

6.3 THE DAILY SCRUM

The Daily Scrum is a 15-minute time-boxed event for Developers to realign work being
done. Although we may talk about the progress of the Sprint, the intent is for every team
member to know what is happing this day and the issues impairing work so that they can
be better dealt with!

Scrum Masters facilitate the meeting, but mature teams often don’t even need external help.

The focus is really the team managing themselves and dealing with issues head-on!

The meeting is normally conducted while standing; this helps ensure that the 15-minute
timeline set for this event is adhered to.

As a manager, you should not get involved in this event at all!

36
AGILE, A MANAGER’S GUIDE The Five Scrum Events

6.4 THE SPRINT REVIEW

In traditional projects, there is normally a formal demonstration, handover, and sign-off
of project deliverables. In Scrum, none of these are done. I say this upfront because many
organizations want to use Sprint Reviews for this purpose.

The reality is that an increment is made available or release the moment Developers and
the Product Owner agrees that it is Done. That may well be two days into a Sprint, at
the end of the Sprint, or anywhere in-between. Because the Product Owner represents the
business, they fulfill this role.

So what is a Sprint Review all about then?

Remember we said that the three pillars of Scrum are Transparency, Inspection, and Adaption.
The Sprint Review is one of the instances where we see these three pillars in action. Developers
show stakeholders what they have done, get feedback, learn and improve as a result.

The Sprint Review is the opportunity for Developers to understand stakeholder needs better,
share ideas, and get feedback. Please do not see the Sprint Review as a stage-gate or sign-
off point – its just an opportunity to be transparent about what we do (scrum team), for
stakeholders (especially users) to understand the better what, why, and how of the increments
delivered during the Sprint.

6.5 THE SPRINT RETROSPECTIVE

The Sprint Retrospective is a Developer Event, often the whole Scrum Team attends, but
in essence, this is an opportunity for introspection by Developer members of the Scrum
Team. Once again, the three pillars of Scrum are important.

By openly and safely talk about what happened during the Sprint will help the team to
identify what went right, what went wrong, what did not go according to plan, and as a
result, identify underlying causes and then discussing how the team can improve in future.

Lessons learned and actions for future Sprints are the main outcome of this event.

Once again, in this book, we will not discuss this event in detail as it is a closed meeting,
and managers would most likely not be part of the team.

37
AGILE, A MANAGER’S GUIDE The Five Scrum Events

6.6 THE SPRINT ITSELF

The Sprint itself is also an event (remember we said a four four-week time-boxed event
preferably).

The reason Sprints themselves are defined as an even is because overarching coordination
between events and the (self )management of the event should also get attention; otherwise,
it would result in stand-alone activities, with no coordination, and chaos will ensue.

The principle of self-management is extremely important when adopting Scrum (or any
agile method). Managers of members of the Scrum Team have, therefore, no role to play
in a Sprint! The Scrum Master is also not the Sprint Team manager, and neither is the
Product Owner.

Product Owners make sure that teams work on important work. Important because either
other important things depend on it for it is directly important to the business. They do
this by explaining, educating, and negotiating with teams when they select items to work
on during a Sprint; they do not tell the team what to do.

Similarly, the Scrum Master also doesn’t tell the team what to do in a Sprint, but their
role is to teach and coach the team on the use of Scrum and to support the team in any
which way they can.

So who then runs the Sprint? The team as a collective!

38
AGILE, A MANAGER’S GUIDE Three Artefacts and associated commitments

7 THREE ARTEFACTS AND

ASSOCIATED COMMITMENTS
An artifact is something that is created or used in the endeavor to get something done.
Artifacts in Scrum can also be seen as output because it is something created as a result of
doing Scrum.

The latest guidance also now associates a commitment to each of the artifacts; these
commitments are defined as the desired outcomes the team needs to achieve to create value
for stakeholders!

7.1 THE PRODUCT BACKLOG AND THE PRODUCT GOAL

The Product Owner is accountable for creating both the artifact (Product Backlog) and the
commitment (Product Goal). However, it is best to work with Scrum Teams when doing
so. This will ensure that everyone understands what needs to be done to relate their work
and role to what needs to be done.

The Product Backlog is a Scrum artifact that consists of an ordered list of the work to be
done in order to create, maintain and sustain a product.

A Product Backlog is managed by a Product Owner and is not s static list of things to be
done, as business requirements and priorities are in a constant state of flux. The Product
Backlog, therefore, needs constant refinement to reflect the status quo.

Product Backlog refinement is how Product Owners ensure the product backlog is always fit
for purpose. This is done by adding new requirements to the backlog, changing the order
of items in the backlog so that the order of items reflects the business’s current priorities,
and by working with Sprint Teams, ensuring that interdependencies are noted and used
when planning work to be done.

The Scrum Guide says that Product Backlogs must be ordered and don’t use the word priority,
as other factors (e.g. interdependencies) may influence the order in which work is done.

We will not go into detail on how product backlogs are created or refined in this book, so
if you want to know more, read book 2.

To ensure that the Product Backlog is a correct representation of the organization’s current
needs, Product Owners also define a true-north statement; the Product Goal.

39
AGILE, A MANAGER’S GUIDE Three Artefacts and associated commitments

The Product Goal describes a future state of the product that can serve as a target for the
Scrum Teams when planning work.

As such, the Product Goal is in the Product Backlog. The rest of the Product Backlog
emerges to define what needs to be done to fulfill the Product Goal.

You can only have one Product Goal, so a new one would be created when the current
Product Goal is achieved. If there is a significant change in context and the current Product
Goal has not been achieved, then the Scrum Team would replace the Product Goal with
a more fitting one.

7.2 SPRINT BACKLOG AND THE SPRINT GOAL

The Sprint Goal is a short statement of the purpose of a Sprint. Often Sprint Goals relate
to a business requirement or problem that will be addressed during a Sprint. It also services
as a true north during a Sprint as all work performed during a Sprint must support the
Sprint Goal and help the team to achieve this goal.

Work planned during Sprint Planning may be adjusted during the Sprint if the team finds
that it is not aligned to the goal, but the Sprint Goal is never adjusted during a Sprint.

If a team is halfway through a Sprint and the Sprint Goal is no longer valid, the Product
Owner can cancel the Sprint, and the team can start a new Sprint

7.3 INCREMENTS AND THE DEFINITION OF DONE

During a Sprint, one or more increments creating value can be delivered, made available,
or released. An increment is a Scrum Artefact that defines a complete package of work
produced by the Development Team during a Sprint, which can be used by and adds value
to a customer. We can say that sum of all Increments form the complete product.

One or more increments can be made available for use during a Sprint, and increments
should be released for use as soon as completed. The quality criteria used to judge if an
increment is complete is defined in the Definition of Done (teams often talks about a done
increment).

In this context, the increment is the artifact and the definition of done is the commitment.

All increments must be aligned to the Sprint Goal.

40
AGILE, A MANAGER’S GUIDE How do the theory help you – the manager?

8 HOW DO THE THEORY HELP

YOU – THE MANAGER?
OK interesting but how does this help you as a manager?

By now, you have realized that the way work is done in Agile is radically different to the
way we normally do things. Managers are often tempted to say that they will adopt part
of agile and keep on working in the old way in other aspects.

Will this work?

Most likely not, and ‘ ‘here’s why.

Scrum and other Agile methods depends on a very different way of management, thinking
about work and culture. The events and artifacts will not work if the above does not
change in an organization. Now you may say, but we will never be able to …. (whatever
the guidance are) in our organization. Our answer is that that is true until management
is willing to change and adopt the new way of work and, dare we say, the new way of
thinking and behaving.

Remember in the beginning we said that adopting Agile is a significant organizational and
cultural change, and that is the most important thing managers need to understand. If you
do not support the changes needed, ‘don’t attempt to use any Agile method. It will not
only fail, but you may well be worse off because neither the old way nor the new way will
end up working!

The benefits of adopting Scrum or any other Agile method are huge! We would say making
this decision is the one decision that will determine of your organizational succeeds in the
digital age, where change is rapid, customers are fickle, and competitors out-innovate each
other at a rapid pace.

So what are these cultural changes you need to embrace?

1. Creating an environment of trust. We spoke about high trust environments

early in the book, and for me, this is the most important change you need to
embrace because so much of what is done in Agile will only work if people
believe that the traditional punitive management style of the command and
control management paradigm will not apply. You will most probably say that
your people will then do what they want and fail, and in some cases it may be
true, but those will be the rare exception. People who feel they are trusted to
do a good job, normally do one.

41
AGILE, A MANAGER’S GUIDE How do the theory help you – the manager?

2. Create fail-safe environments. What do we mean by this? Make sure that

if changes are made, that they can relatively easily be reversed quickly. The
likelihood that Scrum Teams will deploy faulty increments is small, because of
the built-in checks and balances in Scrum, driven by openness, inspection, and
adaptation. Also, remember that Scrum Teams makes frequent small changes
that is usually simple and therefore easy to roll back. Your teams will fail from
time to time; we all do. Your job is to make sure they feel safe enough to try
their best and to push the boundaries of innovation because they will not get
into trouble if something they do ‘don’t work as planned.

3. Agile teams are cross-functional, with multidisciplinary skills, which means that
teams will be recruited from various silos based on their skills. Team leaders and
managers will instinctively resist this practice and try to keep the best skills in
their team. That is the worst thing that can happen – if a skill is needed in an
agile team, it should be the best skill the organization has to offer. We found
that the only way to change skills hoarding by team leaders and managers is to
incentivize them not to do so. Make a substantially large performance metric of
the manager and the team about how well they support the agile initiative. It
must be weighted significant enough that they cannot ignore it!

4. Adopt a method and stick with it for some time before you try and modify it
for use in the organization. Agile methods were put together with great care,
and the reasons why things are done in a certain way is not always evident at
first. I promise you, though, that you will have ah-has moments often about
the wisdom built into agile methods like Scrum. I still nearly 20 years later just
observe in wonder how smartly Scrum was defined. It is best if you employ an
experienced coach to get you going when you start.

5. Push-back is inevitable, ‘ ‘it’s an organizational change, remember. ‘Don’t

give up too soon. Here is where demonstrable and unwavering management
commitment is required. ‘Don’t tell them – show them, by being willing to
follow the new rules yourself!

Agile is different and works differently from what you are used to. For instance, you may
also have to change the way you fund projects (projects strictly speaking no longer exist).
Funding is now given to the perpetual improvement of products and services. The goal is
to create as much value as possible with a fixed budget, fixed resources (including time and
people) as possible.

42
AGILE, A MANAGER’S GUIDE How do the theory help you – the manager?

FIXED

AGILE

FIXED
FIXED COST
DURATION
FIXED
REQUIREMENTS QUALITY
(Change
Discouraged)

FLEXIBLE FEATURES
DELIVERED
QUALITY (Change
Encouraged)
ESTIMATED ESTIMATED
COST DURATION
(Budget Overruns (Projects Often
Frequent) Late)

WATERFALL

ESTIMATED

Figure 3 Agile turns everything on its head - but do so for better!

To us, this is a far smarter way of working, resources in organizations are finite, and the
reason why many projects are so complex is that everyone wants everything for as little
as possible; clearly, that equation cannot work. Eventually, no-one gets everything they
wanted, and the company suffers because projects are over budget, almost always longer
than planned, and by the time they deliver – requirements have changed.

In an agile context, though we acknowledge that we have finite resources, including time
and money, we constantly reprioritize what we can do with it. Always working on what
creates the best value for the business, and in the process, making the business better with
every increment deployed or made available for use.

The key here is to make sure that the accountability of the Product Owner is a business
role. The business, not the project team, is in charge of re-prioritization. Something must
be first on the list of things to do, and something must be last. The business, though the
accountability of then Product Owner decides where the requirement fists – it just makes sense!

43
AGILE, A MANAGER’S GUIDE Scrum in complex environments

9 SCRUM IN COMPLEX
ENVIRONMENTS
Scrum does not give Portfolio Management guidance; the guidance provided by Scrum
starts at the product level. The reality is that Products do not appear out of thin air. We can
say that there is a cascade of event horizons where key decisions need to be made in any
organization, including the associated planning, to ensure decisions are appropriate within
the organization’s context and decisions made are informed decisions.

There is a cascade of planning activities and related decisions within organizations. Planning
starts at a strategic level, and then at a product management level, and then eventually to
where work is done in operations (Developers). Note that the operations environment can
be divided into operations run (ongoing activities) and operations change (projects). Scrum
mainly concentrates on the latter.

Portfolio

Product

Nexus

Sprint

Day

Figure 4 The cascade of decisions that are used in Scrum

For Scrum to work and be scaled, we need to understand the basics of the event-horizons
or the level of the cascade from strategy to operations run. In a Scrum context, it may look
something like this:

• Organizational Goals
• Portfolio decisions
• Backlog creation
• Backlog refinement
• Scaled Delivery Planning (Nexus or Scrum@Scale or even Release planning), and
• Sprint planning

44
AGILE, A MANAGER’S GUIDE Scrum in complex environments

Although it is useful to talk about decisions, in an agile environment, these decisions are
not sacrosanct, and changing decisions or plans should never be an issue (responding to
change over following a plan, remember).

To ensure that no time is wasted on unnecessary planning. Do the minimum amount of

planning at each level of the cascade. Doing this will be so much easier to change plans as
you learn more (empiricism) about circumstances, customer needs or as your understanding
of reality changes over time.

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

So focus on planning, not the plan, encourage change and learning, and make it as simple
as possible to change the plan.

9.1 PORTFOLIO PLANNING

For many large organizations, work done is managed in a broader portfolio. The portfolio
in question could be around products or systems, or value streams, or supply chains, or
investments, or even programs.

The goal of portfolio management and planning is to determine which products support
the organization’s goals and objectives.

Based on organizational priorities, we can then understand in what order the organization
needs to work on products and under which conditions they are met.

Portfolio planning should involve a broad stakeholder landscape and should also involve
Product Owners. The planning horizon for portfolios is longer-term and could be for the
next 6 to 12 months.

The question should be; how will products in the portfolio bring the organization closer
to its goals and objectives? And sticking with agile methods, the organization’s view of the
portfolio can be expressed by creating a portfolio backlog consisting of product roadmaps
for each product in the portfolio.

45
AGILE, A MANAGER’S GUIDE Scrum in complex environments

9.2 ENVISIONING YOUR PRODUCTS

Envisioning the essence of a potential product and creating a rough idea of how a product
can be created is the starting point. The Product Owners and stakeholders gather to envision
a new product at a high level, with a planning horizon that can stretch over more than a
year. We would recommend sticking to shorter planning horizons if you can because the
world changes far too quickly and frequently.

The primary outputs for envisioning should be to define a Product Goal, develop a high-
level product backlog, and create a view of how the backlog will be converted into value
by defining a high-level product roadmap (a living and evolving document). These outputs
become inputs for the higher-level portfolio planning.

The initial high-level Product Backlog provides a broad starting point for Product Owners
to identify that overall and large/broad features or benefits stakeholders are expecting from
the product so that detailed requirements gathering can commence.

In Book 2 we will expand on how Product Backlogs are created. For now, it is important
to understand that Scrum fits into the bigger picture of the organization, and a definitive
cascade of decisions exists.

46
AGILE, A MANAGER’S GUIDE Conclusion

10 CONCLUSION
We hope you are convinced that using Agile method like Scrum to create business value
perpetually is the better choice than the traditional waterfall way of doing projects.

We concede that changing approach is not an easy one, but we also know that if the
management team is committed to the change and willing to make sure that new ways of
work are made part of the organization’s fabric, it works and works well.

However, using an agile method like Scrum is not a technically difficult transition due to
the simplicity of design. It is easy to learn and easy to do. The hard bit is the people side
of change, and as you have realized by now, this is especially true of managers.

I would encourage you to immerse yourself in the change and stay the course.

I would also encourage you to read ‘Scrum: a manager’s guide to getting value faster’, which
will deal in a bit more detail, specifically how Scrum works. The book is full of practical
advice, tips, and tricks, which will make your Agile and Scrum journey much easier!

47
AGILE, A MANAGER’S GUIDE Endnotes

ENDNOTES
1
Heuristic controls commonly define rules of behaviour in certain circumstances and not actions. If you know
how to behave and what outcome is expected you can decide on the most appropriate cause of action.
If however the control defines an action, the action will always be taken, whether appropriate or not!

48