Chapter 1: Enterprise Agility – Agile 4 All

AUTOR: NÉSTOR FLÓREZ. CONSULTOR SENIOR Y EXPERTO

E N A G I L E E N Q U I N T W E L L I N G T O N R E DW O O D

Some months ago, a teammate suggested that I should write something

about agility outside traditional environments (software and IT
organizations). And I thought: “It’s a great idea, it’ll take me just a couple of
hours.” My motivation was high when I started writing, but with each line written,
I realized it wasn’t going to be a short task. I therefore decided to break down
this long text into a set of (more or less) short chapters that contain my point of
view regarding agility outside digital environments. My aim is to help you
answer the main questions people have about this issue.

Let me start with a personal thought. I am a bit tired of repeatedly hearing the
typical “We are living times of quick and complex changes, Industry 4.0 is
changing everything, bla bla bla…” as easy excuses to sell or launch an agile
transformation plan. The fact that everything is changing very quickly is
obvious. The context in which companies are competing today is quite different
to that of some years ago, and in the years ahead it will change again. Digital
and business transformation are changing our way of life, our way of working
and our way of thinking. However, we need to control the panic.

Should we all go crazy and (try to) apply Agile like a magic potion that
will transform our traditional business into a blue chip organization, like a
toad becoming a handsome prince after being kissed by a princess? It´s well
known that an agile mindset – and you can find several references about it –
can be implemented in IT or digital development environments using different
frameworks (like Scrum, Kanban, XP, etc.). However, what happens when the
exotic idea of changing the entire business process is not specifically related to
the development of digital solutions?

Let’s take a step-by-step approach to such cases, bearing in mind that all these
thoughts can also be applied to an IT environment.
Do you really need to be agile?
No, this is not a trick question. We need to think about our needs. Being agile
by applying a certain methodology or tools (e.g. Scrum Events) is easy, but to
be truly agile takes a HUGE effort. Achieving genuine agility requires a big
cultural change not just new roles, processes or a methodology. The
transformation process may have a huge impact within a company. This must
be carefully analyzed because it requires investment not only in terms of
money, but also in terms of the personal effort required from employees and
collaborators.

Agile emerged due to the need to maximize the value returned by teams in a
changing context in which flexibility and speed are required to reduce time to
market. In that context, Agile really makes a difference and returns additional
value. You can redefine almost any process based on an agile approach, but
the question you need to answer is:

What will be the real ROI of the move to Agile?

You can probably start (and finish) your agile transformation plan by answering
this question using the following Agile principle:

“Simplicity – the art of maximizing the amount of work not done – is

essential”

Launching agile transformation initiatives requires the right balance between the
cost of the transformation, the impact it can have, and the sustainability of the
changes within the business affected by those changes (people, processes,
organization).

There could be solutions other than applying an agile approach that bring you
closer to the market and customers or eliminate economic restrictions. I am
referring to Lean initiatives for example, which result in improved efficiency.
Lean techniques help you to reduce the waste of processes so that you can
achieve good results. Although Lean also has an impact on a company’s
processes and culture, the changes may be a little less radical. We can’t forget
that Agile is derived from Lean. In other cases, once you have analyzed your
context and you still consider that optimizing is not enough to achieve the
results you need, you can start thinking about Agile.

I need to be agile – how do I start?

Once you understand what investments are required to become agile, the
expected benefits, and if it is worth it, it is time to analyze what exactly you need
to do and how you can do it. You can then start the transformation.

I am trying to explain how to do this outside traditional IT processes. So, forget

everything about IT, we will not be focusing on it – and there are thousands of
articles addressing it on the internet. In my opinion, almost any business
process that requires agility can be transformed. But to do it right you have to
keep in mind the Agile Manifesto and Agile Principles. These values and
 principles involve several concepts, but in terms of agility outside IT I would like
to focus on the following:

 Prioritize work based on expected value delivery.

 Plan and execute small chunks (think big, act small).
 Deliver value with excellent quality in a short pace of time and ask for feedback.
 All the people required to deliver value are part of the team: respect them!
 Collaboration supports the full process.

If you want to become agile in your business, but don’t want to become another
group of people doing things the wrong way and calling it Agile practices (sticky
notes everywhere), you will have to keep the above concepts in mind.

Perhaps your business needs to be agile, but your organization requires deep
changes in terms of cultural behavior, reorganization, etc. Maybe a business
process needs to be agile, but the company or your department is not willing to
provide the resources and context needed to achieve agility. In such cases, you
can start looking for the right sponsor/s to empower the initiative. If you think
that the department, functional area or company where you want to start
the transformation is not ready, the best thing you can do is to work on building
the required environment before continuing with the next step. Trying to
develop an agile transformation plan without the right context is frustrating and
self-defeating. Working on top-management awareness, looking for a strong
leader to support the transformation, and acquiring the necessary resources are
the best suggestions I have for you.

Great! I can be agile! So now what?

Well, here we are, exactly where things happen. You know that you need the
transformation and, fortunately, you are empowered to realize the needed
environment. Now what? Before starting to change anything, you need to
identify some concepts within your business processes:

 No value, no party: Agile practices focus on enhancing the value delivered.

You therefore need to analyze your current processes in order to understand
the existing tasks and activities, what the purpose of each one is and how
efficient they all are.
 Finding and managing business process boundaries: Sometimes there are
limitations on your own processes, and you need to establish and control the
boundaries of the agile implementation. Those boundaries should give you
independence from external influencers and full autonomy without the
product/service losing value.
 Help me help you: Who is going to buy, pay or use the results of the process
you want to improve? Who knows the real value of your team’s work?
 Agile teams, those who make the things happen: Do we have in our team all
the people needed to deliver (real) value to our client/user at the end of the
process? How can we help to build a truly agile team?
 Prioritization – taking an economic view: How are you going to return the
investment to the company and maximize the benefits?
 Collaboration as a key success factor: Any Agile/DevOps transformation
requires a high level of collaboration between various individuals and teams.
How to facilitate collaboration and make it grow is a good question you have to
answer.
 Product adaptation: An agile team should not be bigger than a pizza team (8-
10). For that reason, you may have to consider your product and processes
design. Products or services developed under the Agile philosophy involve
loose coupling and high cohesion.
 Performance: We are used to saying that if something cannot be measured, it
cannot be improved. You therefore need to have metrics to identify
improvements and the effectiveness of your teams – these metrics are to help
them, not to control their work.
 Continuous improvement: There is no agile or lean transformation without the
aim to continuously enhance and improve our way of working; to provide better
and faster value to our customers.
 Agile leadership: Unleashing an agile mindset requires leadership from
everyone within the company, regardless of their role. Agile leadership pays
attention to the behavior of the current bosses and managers, as well as the
behavior of everyone else, from team members to product roles and top
management.

In the following weeks, I will share my thoughts about these topics, one by one.

Next chapter: Enterprise Agility – No value, no party!

 Chapter 2: Enterprise Agility – No value, no party!

Apply Agile techniques to build something useful, tangible and valuable to

someone on the user or business side. An agile approach is based on the
continuous delivery of value in order to verify the “sense” of what we are
building and adapt the product as soon as possible, and thus guarantee that
we are investing in the right place.

If we were talking about the software industry, it would be quite easy to identify
the concept of “value”. However, what about HR processes, marketing
campaigns, commercial funnel management or other activities where we would
like to apply an agile approach? My opinion is that there is no single answer. I
can only suggest a question that you can ask yourself when you are thinking
about part of a big process that you want to transform:

Can I deliver something that could be paid for or appreciated by my client

or user?

If you don’t get “Yes” as the answer, you need to reconsider how to organize
the work. Applying Agile techniques, tools or methodologies to deliver
something for which you cannot receive feedback (in terms of its value) from the
business side, in my opinion, makes no sense. The power of Agile is to reduce
(or remove) the distance between the people who build all the stuff and
those in charge, in order to address the needs of our users or our clients.

The concept of value has been addressed by project and program management
methodologies for a long time (for example, EVM – Earned Value Management
by PMBOK) with good intentions. However, in my opinion, it has been defined in
a way that makes it difficult to improve the quantitative value of ongoing projects
and, moreover, to map the real value along a long chain of activities and tasks
required to return something “tangible”. As we know, this set of work activities is
not necessary allocated within a project.

When working with an agile mindset, our concern should be to identify how we
can verify the real value of the work units delivered along the delivery chain
from two aspects:

 Who? Request and define the need. This should validate the understanding of
the requirement, and the realization of the work delivered – always with the
actual end user in mind.
 What? The request should be designed with the purpose of returning
something tangible.

Sometimes, the customer journey or value stream where we are thinking about
implementing Agile is so big that it requires a huge effort to imagine how to
structure the teams in such a way that they can deliver real value in a middle
step of the process. Don’t be afraid, this is normal and common, and there are
some tips for dealing with the problem. You could start by thinking about an
escalation approach, or an agile strategy for the entire organization.
You can check the internet for information on “agile escalation” and “agile
organization” and you can find lots of frameworks, or you can try to define your
own way to scale thought experimentation based on Agile principles. Because
no one knows your business, your organization and your people better than
you, and you know who will make it work!
 Chapter 3: Enterprise Agility – Finding and managing
business process boundaries
Agile works fine when teams have full autonomy to take control of the product
they are building and to commit to the delivery of an agreed scope. To this end,
you have to analyze your own production line or business service in order to
redefine its scope, split it, or create value flows. Some tools, like customer
journey identification, can help you in this task.

Reducing or removing any external activity which you do not have the capacity
to influence is one of the best Agile practices. However, it is also one of the
biggest challenges when trying to transform big organizations or complex
business processes that involve multiple stakeholders. This means that
to reduce cross-team dependency you will need to include that capability
within the team, or apply synchronization practices to ensure that the teams
have the highest autonomy within their context. How can I introduce into my
team some decision makers that are traditionally found in other functional
areas, departments or teams? There is no single solution. Based on the type of
activity, you can follow different strategies:

 Dependency caused by lack of knowledge:

o Include different capabilities in your team through training courses.
o Reorganize your team, introducing people that used to be in other functional
areas to fill the gap.
 Dependency caused by a need for formal approval or validation:
o If possible, reduce or eliminate these types of activities. If not possible:
o Introduce validation activities into your work packages, and be disciplined
regarding compliance.
o Compliance by design!
o Delay validation activities after user acceptance of the product delivered to
ensure value-driven work, before investing in non-value-adding efforts.
 Dependency caused by regulatory bodies, the market, etc.:
o Prioritize your work plan according to the dates or milestones of external actors
(from outside your organization).
o Take risks in small chunks: use evolutionary design in your product /service, in
order to anticipate external decisions, without putting the full value stream at
risk.

To sum up: analyze your business processes, and try to find internal or
external clients at different stages, or in different layers. In this regard, look to
the people involved in each layer or stage of the process. Gather all this
information and think about the way to build autonomous teams, with the higher
capacity to deliver value quickly. This is the way to change traditional
organizations and to change traditional culture into new ones.
 Chapter 4: Enterprise Agility – Help me help you!

Imagine a big financial or telecommunications company with thousands of

employees based in typical centralized services offices with hundreds of
branches, and dozens of companies around them acting as clients or suppliers.
In this regard, I once heard the following Tom Northup quote:

“All organizations are perfectly designed to get the results they are now getting.”

The organizations he was referring to were rarely designed based on:

 Growth of their departments (not always at the same pace)

 Aim of managers to acquire more power within the company
 Acquisition of other companies
 Services being outsourced
 Etc.

Although I admit there are some exceptions, it’s rare to find a company that is
both big and old that has grown and expanded its business around an internal
reorganization with the purpose of maximizing customer happiness.
Efficiency, specialization, optimization and economies of scale are some of the
most common concepts used to justify how and why companies today are
creating big groups of people commonly called functional areas or departments.
Like me, you have probably been at the end of this chain, and how easy would
you say it was to think about your client/customer? Not very easy, right?

What I mean is that real Agile works fine. It provides the best results when your
people and your organization are aligned with your client, and when see your
client as more than a revenue stream. Agile really works well when you are able
to put your client’s requirements, concerns, and behavior in the same room as
the people who are doing the work.

Nowadays, it is easy find business analysts/partners who are very proud

because they are using an innovative technique like design thinking to come up
with product innovations. However, when you closely examine this innovative
way of working, sadly you realize that they use the output of workshops as the
basis for spending weeks or months writing a brilliant specification of an
“innovative” product to be realized in several months (hopefully not years) by
the delivery teams. This is definitely not Agile.

In most of current companies, we have many people with high capabilities, skills
and amazing talent writing – alone or within their own silos – tons of papers
and presentations of product specifications based on, for example, knowledge,
experience, market trends, etc. What would happen if we were to sum up all
these skills and translate them into the capacity needed by agile teams to
deliver short-term commitments – that could be verified by real users – faster?

We are not talking about understanding or misunderstanding the specifications,

we are talking about the capacity to be part of product definition, validation, and
experimentation within a safe environment (open and direct communication with
the autonomy to take decisions also in respect of failing). This environment
allows us to have people within the teams who share the same values.

True agility needs real value-driven teams, not groups of people who send
emails or enormous specification documents from the building of the “business
people” to the “production line”, those people working in a dark and sad
basement. Well, maybe I am being a bit pessimistic, but just to sum up:
remember that one of the main reasons (if not the main reason) to use an agile
mindset in the software industry was the need to bridge the gap between the
people asking for a system and the people building the system. The language
used by these two worlds was so different that the idea of building mixed teams
worked really well. I think the language in other industries or functional areas is
not so different. Bringing together the people involved is just the first step;
making them work like a real team is the next challenge.
Chapter 5: Enterprise Agility – Agile teams, those who
make the things happen

I have enormous respect for teams: they build value from nothing. They are
able to align a group of people with different personalities, experiences and
lives into a self-organized cell with a single purpose and shared commitment.
Teams can turn a challenge or a risk into an opportunity; they can turn the
differences between them into productive discussions; they transform their
professional and personal diversity into a complementary and rich vision that
enhances the options and adds value to the things they work on.

I think I have described some of my ideas and opinions about how amazing
agile teams are, but maybe you don’t recognize yourself or your team in my
description. Well, don’t worry, it happens often and it’s not your fault. These
kinds of teams are rarely found. Moreover, it is difficult to find them because it is
extremely hard to become an agile and high-performing team in a given
context in which hierarchies, silos, and command and control management
behavior are the norm. Teams (not only agile teams) require certain conditions
to grow and become the kind of teams that can be described as agile.

Teams, not individuals, are the key to everything. And to me, talking about them
in a general way is wrong by definition. I should start by saying that in my
experience, agile teams are too complex to be described in a couple of lines. I
recommend reading some post or books about the maturity stages of teams
working within an agile organization and about the leadership style that
managers or leaders should have in each moment, etc. Background information
is very useful in understanding the process of growing teams and facilitating this
growth.

Anyway, what I would like to talk about is why agile teams have a new key
role in an agile organization. Team members are the minimum unit of value
production, so to speak. I see no difficulty in using this concept within the
context of any enterprise (despite its size) to describe how a single person can
add real value.

I referred to a minimum unit of value production because nowadays, I feel

that the concept of a “team” is not being used properly. Managers, directors
and HR use this word in reference to how the organization is designed. They
refer to “teams” when what they are really talking about is management and
top-management hierarchies, and how they distribute the people assigned to
each manager.

Agile teams are awesome because you can trust them. Agile teams will not just
give you a solution to your question, they will ask you about how to maximize
value, and they will give you alternative options that you never imagined. They
can give you enormous added value, but it does not come for free.
You need to respect the decisions of agile teams. And they need the
capability to set their own rules; they need a safe-fail space with no blaming or
penalties; they need to be part of the “what”discussion not just the “how” and
“when”; they need to celebrate their successes; they need to be able to share
their experiences with others; they need transparency in everything related to
their activities, etc.
Chapter 6: Enterprise Agility – Prioritization, taking an
economic view

In previous articles about agility outside IT, I spoke about the value-driven
approach needed and the key role of the voice of the customer inside the team
in creating the most valuable product in an agile organization. I would now like
to share my understanding of “prioritization”, one of the most relevant activities
when you are establishing a “pull-driven” method of working in an agile
environment and why I think it is so relevant when you are thinking about
applying some agile approach within your business.

Prioritization, or sound and clever prioritization I should say, makes a difference.

There is no big advantage in having a high-performing team build a high-quality
product/service in a short time if the product’s features have not been
prioritized. Agile takes care of a team’s health, and it enhances respect,
collaboration and autonomy. However, the purpose is always to build better
products, and to constantly think about the client with the idea of being able to
provide the client with a reliable product as soon as possible. Moreover, the
product should deliver business value (revenue, efficiency, etc. depending on
the purpose of the team) to your organization.

If your assignment is to define and establish priorities, your main concern

should be to ensure that the effort of the people that will execute the task
has an economic cost, and therefore there is nothing that involves costs that
is more important than what they are going to do. I like to view the assignment
(or self assignment) of any task in a business environment from the perspective
of the investment that the company is making. The idea is then to obtain a
return on that investment (don’t forget that most of us are paid according to the
time we spend on work activities). In an agile environment, there should
(hopefully) be somebody with a clear vision to transmit an economic and
pragmatic view of the priorities at any time.

This doesn’t mean that the priorities cannot be discussed and negotiated.
Rather, it means that when you draw up an ordered list of things to do, you
can share your list and explain clearly the ideabehind your prioritization to
the people in charge of realizing the task in question. This will probably allow
them to better understand your business view and they will be able to suggest
other requirements or adjust your requirements in order to maximize the return
on the investment.

There are several techniques you can apply when prioritizing activities, just take
a look around the internet, consult the sources and start with the technique that
fits best with your business/industry. Starting to work with Agile means that your
priority should be to try and adjust your prioritization method in a short space
of time with real results, and adjust it if the results were not the expected ones.

My last suggestion: don’t become paralyzed by looking for the magic

formula for work prioritization – it probably doesn’t exist.
 Chapter 7: Enterprise Agility – Collaboration as a key
success factor
I would like to mention one of the main characteristics of an agile enterprise as I
understand it, a characteristic that differentiates an agile enterprise from a
traditional bureaucratic company: the radical culture of collaboration among the
people within the company. Do not forget that companies are built by people,
not by teams, departments, functional areas, etc.

A culture of collaboration implies breaking with some traditional behaviors

promoted by old-school managers. I am going to mention just a few of them to
provide you with some context:

 Micromanagement: if you want a thing done well, do it yourself.

 Hierarchy is law: ask for permission and validation for everything you do!
 Protect what you know: sharing knowledge means losing power.
 Tell the people what to do and how and when: “why” is too important for
them.
 Failure is a bad practice: it must be hidden and those responsible blamed.
 Be aware of your own goals even if they are in conflict with the company’s
goals.

Agility fights against all such previous behaviors and looks to create an open-
source culture with the following characteristics:

 The more you share, the more recognized you are.

 People are empowered to talk with anybody in the company, regardless of who
is their boss.
 People’s goals are aligned throughout the entire organization, giving priority to
global goals over individual goals.
 Failure is part of the job and it is accepted as an opportunity to learn and share
better ways of doing things.

It is well known that cultural change is the main challenge during agile
transformation initiatives. However, resistance to change is an impediment to
achieving anything that involves a movement from the current way of
working/living to a new one. Therefore, when focusing on the collaboration
between people that is essential to making any agile initiative a success, we
should be patient with people and give them the time and support they need to
adjust their current behaviors to the new ones.

There are several ways to face cultural change, but I prefer to make it happen
as part of the daily activities, not force it as a goal in itself. Collaboration can
be improved through sensitization workshops, team-building/team-growing
activities, etc. However, in my opinion, all these initiatives are a waste of
time/money and are quite frustrating for people if they don’t agree with a real
collaboration approach to their daily activities.
I prefer a pragmatic approach, based on real assignments that have to be
handled in a different way and that require open collaboration between
individuals. People should be supported during the journey until they achieve
success (or failure) at the end of the process when the pros and cons of the
new way of working can be analyzed. When trying to work in this way, we need
to analyze the delivery process – what teams/functional areas/departments
are involved, how many decision makers are in the flow, what are the silos,
what issues are related to a lack of communication/information, what are the
individual and group goals of the people involved in the process, etc.

A tool that can help us to identify and gather all this information is Value
Stream Mapping (VSM). I use it to build a value stream with all the people
involved in the same room, and it is amazing to see how simply being together
and sharing thoughts and concerns with the purpose of doing things better has
an impact by itself, before anything is changed.

Anyway, not changing things is not the purpose of VSM. Rather, its purpose is
to define the process and identify the people that add value to the
product/service and those who do not, and in this way, empower them to make
things work better. Sometimes, a change in the process can help, but the
biggest changes will come once empowered people start to work together.