Becoming a Responsive
Enterprise
Growing step by step by using the Agility Ladder
1
Introduction
The Responsive Enterprise promise
In an ever faster changing and more dynamic world,
companies have no choice whether to become responsive
or not. Survival of the fittest is key in a competitive
environment. And it will not be the largest of organizations
that survive, neither the most intelligent ones, but those
most responsive to change. Adapting to fast changing
environments and to agile and evolving customers is crucial
for survival. Look at the Standard & Poor’s Index: the average
lifetime for a company in the index has dropped by 80% since
1937, and profitability has dropped by 75%. Being big and
respectable is hardly an asset, probably it is a handicap.
After you’ve transformed to a Responsive Enterprise, you can:
• Embrace market opportunities and be disruptive in your
market segment;
• Lower cost of change needed to stay competitive,
allowing you to respond quickly to changing context;
• Lower operational cost due to embracing software for
your day-to-day process.
At Prowareness we help organizations to increase their
responsiveness. The first wave (early adopters) of becoming
responsive consisted of relatively small, eager companies in
new markets. The last years also large corporate companies
felt the urge to become responsive, because their customers
expect them to be. Customers expect large companies to be
as responsive as small ones.
The past years initiatives often started at the software
department level, mostly by creating self-organizing teams
with growing end-to-end responsibilities. However, the
dot on the horizon is making the complete organization
responsive, no exceptions.
Responsiveness means that adapting to change is in the core
DNA of an organization. The most important primary process
is not doing what you do, but needs to be fast discovery of
how to delight your customers and deliver that to them even
faster.
What about the end-user?
Many employees in big companies have an agenda stacked
with meetings with no link at all towards adding value to
customers. These meetings are about coordinating and
optimizing the process, not about getting feedback from endusers to improve the products value proposition. This leads
to employees that are compliant towards the internal process
instead of being committed to the benefits of the products
towards the end-users. For example; did you recently ask in
one of these meetings what the impact of the current agenda
item will be towards the end-users?
You probably have the idea that the answers to these
problems can be found in the Agile mindset. But only
introducing an Agile framework like Scrum isn’t enough.
You need a lot more change company wide to become a
Responsive Enterprise.
The urgency for company wide Agility
Every company needs to increase their Agility. The words
of Charles Darwin are now more relevant than ever for
companies: “It’s not the strongest of companies that will
survive, neither the most intelligent ones, but those who are
most responsive to change!”. In a fast moving world, that
is strongly software driven, and where innovation has such
a pace that it takes days or hours to bring new products
to millions of users, agility is required. For sure plans are
needed, for sure companies need a strategic view on the
market, for sure a vision is required. However, the times in
which a plan was made and simply followed, are long gone.
We need plans for common understanding, but not to stick to
them, but to deviate from whenever needed.
No change is made without a burning platform. The “Why”
question is however determined by the market nowadays.
Survival of the fittest, or better: survival of the agilest, is
in many companies a good reason to change. And if it is
not now, it will soon become one. Besides, it is not a bad
characteristic for an organization to be agile. Being flexible,
being able to respond to change, is a quality that most
companies can benefit from. It will help in serving your
customers better. And what can be wrong about that?
Please refer to the appendix for a more elaborate description
of the need for responsive enterprises.
Reading guideline
In this paper we present the perspective of the Responsive
Enterprise, but even more important we present the map and
the strategies towards fully responsive enterprises. We do
this twofold:
•
Firstly by explaining our Agility Ladder (the map):
a model consisting of practices that increase the
responsiveness of an enterprise. The ladder has two
sides: the IT-value side and the Business-value side.
The model presents a logical order in which companies
increase their agility in their business as well as agility
2
in their IT delivery. These need to grow side by side,
accompanied by culture and governance initiatives in
order to deliver value to customers faster.
•
Secondly by explaining the tools and strategies needed
to move up on this ladder (we call this: the Trusted
Advisor Framework). This is a change management
approach that is driven by measurement, target setting,
practice implementation and evaluation. It supports
companies in step-wise improvement towards becoming
more responsive. As such it is a Plan-Do-Check-Act
variant deliberately focused on implementing increased
responsiveness.
Stated differently, in this paper we present a map (Agility
Ladder) and the tools and strategies (Trusted Advisor
Framework). The combination of these two is sufficient
to make change happen in organizations and presents
a pragmatic approach for controlled growth towards a
responsive enterprise.
Agility Ladder
The analogy for explaining our transition approach is that
of a traveler. The traveler needs to know his destination. To
arrive at the destination, the traveler needs to have a map,
determine his position and know where to go next. Moreover,
he needs to use tools and strategies to move, to cross
bridges, climb hills and descent valleys.
In transferring the analogy towards software organizations,
the destination is the Responsive Enterprise, as described
above. The map is the Agility Ladder we developed based
on experiences at numerous medium to large sized
organizations. The tools and strategies part is the Trusted
Advisor Framework. The remainder of this chapter will be
used to introduce both the Agility Ladder (the map) and the
Trusted Advisor Framework (the tools and strategies).
Having a map such as the Agility Ladder prevents
re-inventing the wheel over and over again. It increases
transition speed due to proven-practices usage. It may also
help in setting ambitious but reasonable expectations by
choosing in what to do next and what to do later. In this
ladder, both Business and IT are taken into account. In doing
numerous transformations, we participated in successful
transitions only when Business representatives were steering
the transition. After all, becoming agile is much more than
just doing Scrum. The holistic view of the Agility Ladder takes
user, customer and business perspective into account in
order to spend the money where it delivers the most.
3
What is the Agility Ladder
A short introduction into the levels.
IT VALUE
BUSINESS VALUE
Responsive Enterprise
Is the whole company Agile, are your clients Agile and do you
give each other constant feedback? Then you are ‘cutting
edge Agile’. This is the ultimate level of responsiveness.
Responsive Enterprise
Is the whole company agile, are your clients agile and do you
give each other constant feedback? Then you are ‘cutting
edge agile’. This is the ultimate level of responsiveness.
Company wide Agility
You use Agility in your software development/it department
to respond to change quickly.
Company wide Agility
Agility in the business sides of the company. Responding to
change without IT impacts.
Continuous Delivery
Fast value delivery through delivering small releases in an
increasing fast frequency.
Value Steering
Delivered and measured value gives evidence about the next
steps (impact on product backlog).
Scaling
Scaling is ensuring security, performance and design when
more teams need to be aligned and work intensively
together to deliver a result.
End to End value
Concrete evidence and insight into the extent in which value
is delivered throughout the full chain.
Automated QA
Automated quality assurance ensures a continuous validation of quality through full automation and eliminating all
manual testing.
Direct customer feedback
A continuous feedback loop with the customer is in place
and real collaboration with customer(s) is installed.
Code quality
Mature software quality delivery by an organization through
quality practices such as pair programming, code review
standards+ process, automated code review/audit and gated
check-ins.
Involve end users/customers
End users and stakeholders are included in the process of
creating value. Customers feel treated seriously resulting in
fewer customer escalations.
Basic Scrum
Have the core scrum processes, artifacts and meetings installed and stick to them automatically.
Backlog Management
Product Backlogs are established well and are used in the
right way by an established Product Owner. Grip and output
steering is in place.
Governance
Going from level to level in the Agility Ladder has the risk of falling back and losing practices. As such, a governance discipline
is needed. This governance discipline is based on frequently auditing the organization, collecting KPI’s and installing a
heartbeat. As such frequent reporting and discussion with senior management is required to track process and discuss
impediments and next steps. This reporting should ideally been done each sprint, but at least on a monthly basis.
Culture
Going from level to level in the Agility Ladder does not only mean that a governance discipline is needed. But it also means
that the culture within the team or the company needs to change. It should be clear what culture you need at each step and
how this can be maintained.
4
How to use the Agility Ladder?
Is the Agility Ladder the only way to go? Is it the one and
only way to build a Responsive Enterprise? Are there no
alternatives? Is this the single right plan that each company
just needs to execute?
Of course not! There are multiple ways to build a Responsive
Enterprise and it is up to each specific situation to decide
how to approach this. However, proven practices from others
are more than useful. It is not necessary to make every
mistake yourself. Life is too short for that. In the analogy of
the traveler, earlier travelers have walked the paths in many
organizations and can provide a map for you to use. So, we
have captured all our experiences and learning efforts from
building responsive enterprises. We have captured them in
a stepwise ladder that guides larger organizations in making
themselves responsive. Doing this in a ladder helps in taking
one step at a time, keeping an eye on the progress and
having clarity on what to do now and what to do next.
As such, organizations can really use the ladder as a stepby-step map in transforming themselves into a responsive
enterprise.
One way to use this and getting clarity on what to do next is
the following order:
•
Where are we now? An assessment can really help
to distinguish the current status and have a concrete
marking of where the company is on the Agility Ladder.
•
Where do you want to go finally? What is the desired
state you are striving for? We recommend to have the
Responsive Enterprise as objective, but that could differ
for specific settings. Furthermore, it makes sense to
make that desired end-state more concrete: how does it
look like? What does it mean? Some do this by making a
detailed description of “Awesome”: what does awesome
look like?
•
What will we achieve the coming months? Setting a
next target on your way to awesome. The Agility Ladder
will help in identifying which intermediate step between
the current state and end-state makes most sense. Such
target conditions should be both realistic as ambitious.
•
What do we need to do now? What are the first and
second concrete steps towards the next target condition?
What do we really need to do now? Agility ladder and its’
practice give concrete guidance in doing exactly that.
Figure: How to use the Agility Ladder? [Source of Awesome
picture: Henrik Kniberg - Spotify’s engineering culture part
II - YouTube]
Climbing the Ladder
Climbing the Agility Ladder could be approached as a
project, or as a program. A manageable way of working in
which progress is tracked, impact is measured, stakeholders
are aligned, etc. The Ladder itself does not contain such a
transition management method. For that purpose we defined
TAF: The Trusted Advisor Framework.
In the analogy of the traveler on his journey, we already
discussed the destination (Responsive Enterprise) and the
map (Agility Ladder). The tools and strategies part is the
Trusted Advisor Framework. These are the instruments and
tactics a change initiative need in order to climb the Agility
Ladder.
A structured approach for changing an organization brings
clarity around goals and expectations. It provides a steady
rhythm in improvement and collaboration. It helps in
being together and aligned in the journey and provides
transparency, which enables inspection, which is the
empirical basis for improvement by adaptation.
We have learned that the only way in making clear and
distinct transformations possible, one needs to be a trusted
advisor. A trusted advisor of the management, a trusted
advisor of the teams, a trusted advisor of the organization.
By being a trusted advisor you facilitate in a controlled way
of change, carefully tracking progress and planning next
steps and a managed transformation. We have learned that
such a way of working is crucial if you want to establish a
deeply grounded change in an organization. That is why we
developed the Trusted Advisor Framework (TAF): To become
5
a trusted advisor in guiding an organization, its people and
its management, towards a responsive enterprise! The ride
can be a bumpy one, so trust is one of the most important
foundations for making such a change.
What is the Trusted Advisor Framework?
5. Practices
Change and improvement is in what is really done
implemented on day-to-day basis. By implementing the
practices and being transparent on it making sure the
new way of working is normalised.
6. Relation with the Customer
Change is intense. The relation with the customer needs
to be solid to overcome the inevitable challenges that
will be faced. We are in it together!
Conclusion
Becoming a responsive enterprise is not a choice. It is what
it takes to be successful in the coming decades of the digital
revolution. The only way to survive and deliver value is by
being able to react fast, by being able to focus to changing
demands of customers and business partners and by
embracing the full potential of software.
The Trusted Advisor Framework is an approach for managing
change in a plan-driven organization. It helps an organization
that is used to concrete plans and predictable outcomes,
to take stages in their journey to become more and more
responsive. TAF consists of six core elements:
1. Weekly reporting
With a weekly reporting cycle on the activities made,
it provides transparency on activities and day-to-day
progress.
2. Targets and KPI’s
Creating a shared vision and agreed intermediate result
measurements helps in keeping everybody’s eye on the
goals.
3. Steering Committee
A clear cadence in alignment, inspection and adaptation
is necessary to make sure everybody is on the same page
and impediments that need management mandate are
addressed as soon as possible
4. Picture before and after
By creating a clear and agreed picture of how the current
situation is, we create an objective measuring point of
where the organization stands. The tools used here are
electronic surveys, management workshops, interviews
and observations.
The path towards a Responsive Enterprise can be a bumpy
road. On the one hand it is a transformation that each
organization needs to go through by itself. It is as such an
unique challenge. On the other hand, lessons learned from
others are useful to make the ride less bumpy and to prevent
driving into dead-end streets.
Based on our experiences in numerous transformations and
our own experiences in building our company as a responsive
enterprise, we have developed a structured approach for
such transformations.
Our approach consists of a reference-guide, a map, for
building a responsive enterprise step-by-step: the Agility
Ladder. This ladder provides guidance in building agility
into the genes of an organization, starting from a division
between IT and Business. By doing the right things in the
right order, organizations can bootstrap themselves from the
plan-driven deadlock they are often stuck in.
The way to use the map and the way to walk the path in
a specific situation is not on the map. For that purpose
we defined a change management approach that fits to
management-driven organizations. In iterations it defines
the current status, makes a plan for the next period and
implements the short-term actions that create the highest
value, given the current state. This approach to change is
our Trusted Advisor Framework (TAF), as we have learned
that the only way to really guide change is by being a trusted
advisor.
6
The combination of TAF and the Agility Ladder is intended
as a guide for companies and organizations in their path to
ultimate responsiveness. We will update our experiences and
lessons-learned, but this whitepaper captures what we know
today. We are eager to learn more and will share our future
lessons as well.
For now, we continue to guide our customers in their
transformations towards ultimate responsiveness and are
happy to hear your lessons learned, your questions and your
experiences.
And if you are still in doubt whether or not to take the
necessary steps to become more responsive, our advise is
simple. You don’t have to do this.
Survival is not obliged...
The Authors
This whitepaper is written by the following Prowareness
“propassionals” (alphabetic order):
•
•
•
•
•
•
•
•
•
•
•
•
Charlotte Bendermacher
Ron Eringa
Henk Jan Huizer
Vikram Kapoor
Peter Koning
Rob van Lanen
Jeroen van Menen
Rahul Sah
Rini van Solingen
Robert van Vark
Paul Weghorst
Edwin de Werk
7
Appendix 1: The need for Responsive
Enterprises
As of July 2014 Facebook, founded in 2004, is in the top 20
of the most valuable companies in the S&P 500, putting
the 10-year-old software company in the same league as
IBM, Oracle, and Coca- Cola. Of the top five fastest-growing
companies with regard to market capitalization in 2014, three
are software companies: Apple, Google, and Microsoft (in fact,
one could argue that Intel is also driven by software, making
it four out of five). Hot and upcoming companies such as
Über, Tesla and Airbnb, which are disrupting the traditional
taxi, car, and hotel markets, respectively, are also all
fundamentally software companies. Conversely, the bottom
five companies, which lost market capitalization in the first
half of 2014, are mostly traditional enterprises in business for
decades. Given this information, the logical question to ask
is: Why are software-based companies taking over the world?
The answer is simply that powering companies by software
allows them to be responsive and data-driven and, hence,
able to react to changes quickly.
Digital Revolution - How Uber and Netflix unlock
growth
In the next decade every large scale business will be digitized
and effectively become a software company. Leveraging
software, and, in general, computational thinking, to make a
business responsive to change, using a closed loop feedback
system will be crucial to surviving in this new world where
business = data + algorithms. Some examples of responsive
companies follow. Unlike traditional cab companies, Über
does not own its fleet. Its value is in the realtime data and
algorithms Über uses to transform this data into decisions.
In a few years, Über will likely automate away all humans in
the equation by replacing drivers with self-driving cars, which
themselves are possible only because of advances in software
technology. Netflix does not operate its own data centers
but runs its whole operation on public cloud infrastructure.
Simply stated, cloud computing virtualizes hardware into
software. Instead of dragging in a physical computer or
storage device, cloud computing achieves the same effect
with a few lines of software code that in the blink of an eye
allow companies to add compute and storage capacity, or to
release surplus. Software promotes agility by dramatically
speeding up the feedback loop between output and input. In
the past, companies could measure their performance every
quarter, making it difficult to adjust quickly to changes in the
environment. But who cared, the competitors had the same
problem. Nowadays disruptive competitors do not have
your problems! For example, Facebook ships new versions
of its product multiple times a day, with enhancements and
fixes determined by realtime feedback from actual use of
the Web site. Companies such as Amazon and Booking.com
continuously perform A/B testing (evaluating alternatives)
or multi armed bandit experiments on users to optimize
purchase rates on their Web sites. Amazon even makes its
A/B testing technology available to third-party developers for
free (https://developer.amazon.com/public/apis/manage/
ab-testing). The same holds for other companies such as
Facebook and Netflix, which make most of their internal
software available as open source. Continuous software
delivery and A/B or multi armed bandit testing not only
require new products to be rolled out quickly, but also mean
that wrong decisions can be rolled back quickly. Accepting
that decisions can be wrong, and acknowledging the errors,
requires courage that traditional risk averse enterprises tend
to eliminate by introducing process.
Embrace Fail Fast - making mistakes is
mandatory
Responsive enterprises accept that failures will always
happen and guard themselves from cascading failures by
purposefully causing failures. Just the thought of creating a
deliberate failure to make a system more robust immediately
sends many traditional middle managers over the edge. At
Netflix, however, it is common practice to “let an army of
monkeys loose” in the data center to pull out virtual cables
and wreak havoc. Many agile development methods propose
writing tests before writing code. It is impossible, however,
to faithfully model the complexities of the environment in
which deployed code runs in the test environment. Instead,
software application failures should be treated like any other
failures, deploying code in production immediately and
rolling it back when problems occur. Elementary psychology
teaches us that in order for humans to learn (i.e. improve),
feedback about their actions must be immediate. Smokers
keep smoking because lighting up gives them immediate
satisfaction, but the feedback effect of lung disease comes
years later. Developers are humans, too, and, hence, can
be stimulated to write better software by providing them
immediate and physical feedback about the quality of their
code. Companies can implement this feedback loop by
making developers wear pagers that wake them up in the
middle of the night in case problems arise and by making
them responsible for the “whole stack” (also known as the
DevOps model). Decoupling the development process from
the operations side removes a valuable (recursive) feedback
loop in the system and thus reduces the responsiveness of
the system as a whole.
8
The employees
From a people perspective, running a company powered
by software is totally different from running a traditional
enterprise. Responsive enterprises are powered by software
to a high extent. The daily process is completely executed
by software. Registering a new user, ordering and shipping
a book at Amazon, watching a movie with Netflix is done
completely by software, without human intervention. The
employees of a Responsive Enterprise are committed to
continuously increase the value of the product. People create
new business models, but software executes them!
Therefore software developers become the primary
workforce, nothing like traditional white or blue collared
employees, and it is this aspect that is often the hardest for
traditional bosses to understand. Perhaps the difference is
most succinctly expressed here: “You cannot race sheep, and
you cannot herd racehorses;” and “Domesticate developers
like beekeepers domesticate bees.” The new employee will
be completely focused on the external product, continuously
increasing the value proposition and making the customer
successful.
Sooner than you may think, every large company will be a
software company. The winning bank will be that one that
transforms himself into a financial Amazon. The winning
car manufacturer delivers the same user experience as a
company like Spotify.
To make this transformation for growth successful, you need
a structured approach with a high guarantee for success.
9
Appendix 2: The Agility Ladder in detail
Each step of the Agility Ladder is detailed in this appendix
section. The first part is the business side of the ladder, the
second part is the IT side of the ladder.
The Culture and the Governance foundations of the ladder
are not detailed in this Appendix. The reason is that we
learned that these dimensions are so context specific
that it seems impossible to provide generic steps. This
might change over time when we gain more and more
experience, but for now we remain by stating that Culture
and Governance are crucial dimensions and steering tools for
Agile transformations.
Stories, Defects & Tasks.
•
Implementing different scenarios for different users
Since the Product Backlog is the single source for
maintaining all product changes, a lot of people will be
interacting with the Product Backlog, each with their
own interest and requirements. The Product Backlog
needs to be transparent and should facilitate the
collaboration between the Stakeholders, Product Owner
and Development Team. The scenarios to implement:
•
Development Teams tend to focus on the highest
priority User Stories on the top of the Product
Backlog. Together with the Product Owner it is
their task to breakdown large Epics, that don’t fit
in a Sprint into smaller User Stories that are ready
to be picked up in a Sprint. The Development Team
helps the Product Owners to elaborate the details.
•
Stakeholders tend to focus on larger Epics and
only a subset of the Product Backlog (the part that
represents their Business representation). Most
of the times they want to see the progress of the
stories a Development Team is focusing on.
•
The Product Owner is the most intensive user
of the Product Backlog. He should be the one
accountable keeping it lean and mean, so that
everyone understands the content. The Product
Owner is responsible to make the Product
Backlog reflect the latest status of all requested
functionality from the Stakeholders. He uses the
Product Backlog refinement sessions as an input
for this.
•
Visualize the Product Backlog content
Business Value
Level 1: Business Value - Backlog Management
Summarizing Backlog Management
Product Backlogs are established well and are used in the
right way by an established Product Owner. Grip and output
steering is in place.
What you will get with Backlog Management:
•
•
•
•
Reliable forecasting of releases based on actual data
An increased ability to give promises you are likely to
keep
Transparency in plans, to support in managing
stakeholder expectations
Transparency in where budget is spent on
Backlog Management consists of the following practices:
One of the most important artifacts in Scrum is the Product
Backlog. The Product Backlog is owned by the Product
Owner and should be the single source for any changes that
you make to your product.
When implementing the Product Backlog there
are different techniques that you can use to
represent the content of your Product Backlog. A
common practice is to have some kind of central
repository (differing from a simple spreadsheet
to a complex Agile ALM tool) to store the actual
Product Backlog Items. On top of that you can
use different techniques to represent the content
of this repository like:
What Scrum Guide doesn’t tell us is how to implement this
Backlog and how it is used on a day to day basis. This chapter
contains a number of best practices on how your Product
Backlog can be implemented:
•
Implementing Product Backlog Item types
A Product Backlog typically contains small items with
high priorities on the top and big chunks with low
priorities on the bottom. There are a number of good
practices that can be used to make the definition of a
Product Backlog Item more explicit: Themes, Epics, User
• Hierarchical trees
• Tree Mapping
• Story Mapping
10
•
Visualize the Product Backlog progress
A Release Burndown is a great tool to keep the
Stakeholders informed of the progress in your Product
Backlog. Once you have planned a Release, the Release
Burndown keeps you up to date on the progress towards
the Release. Many Agile ALM tools have a default, built-in
possibility to visualize the Release Burndown, each with
their own features and configurable options.
We see that more and more dialogues are taking place in
this step. The stakeholders and the Development Teams
are more aware of how to interact with each other in a
semi-structured way and find the dialogue, sometimes
still facilitated by the Product Owner, yet often also
without the Product Owner and outside the Sprint
Review.
•
Skipping Backlog Management is risky, because then:
•
•
•
•
•
•
•
•
We measure how happy/awesome they feel about the
latest changes to the increment, presented in the Sprint
Review. The Scrum Team takes steps in improving
the happiness of the customer towards ultimate
awesomeness.
You will never be able to make credible promises
You do not get the ability to make concrete choices
You will never have the feeling of being in control
IT will remain a black box for you
Measuring successful implementation of Backlog
Management can be done through:
NPS of stakeholders
Delivery reliability
Forecast reliability
Budget expenditure transparency
•
•
•
•
•
•
•
Early indications of opportunities and value
propositions
Abilities to manage and meet end-user
expectations
Abilities to manage and meet deadlines and
budgets
End-users that feel heard, listened to and who feel
part of the team
A better understanding and agreement of endusers for decisions
Involve End-Users/Customers consists of the following
practices:
•
Stakeholder – Development Team dialogue
Release workshops
There are frequent workshops moderated by the
Product Owner. The stakeholders and Development
Teams interact in these workshops in order to generate
and adjust release plannings.
•
End users and stakeholders are included in the process of
creating value. Customers feel treated seriously resulting in
fewer customer escalations.
What you will get with Involve End-Users/Customers:
Reliable forecasting (Tighter cone of uncertainty)
In time, the team becomes more predictable and the
difference between best-case and worst-case release
forecasts is getting lower. The cone of uncertainty then
becomes obviously tighter.
Level 2: Business Value - Involve End Users Customers
Summarizing Involve End-Users/Customers
Stakeholder Awesomeness at Sprint Reviews
Customer visits
Development Team member visit the customer in their
surroundings, where they use the software. They see the
value added and get to know the context and customer
of the customer.
•
Stakeholder Analysis
Product Owners spend time analysing the stakeholder
community and finding ways to serve the several
stakeholder groups.
Skipping Involve End-Users/Customers is risky, because
then:
•
•
•
•
You will waste much money by making wrong
investments
You will receive feedback way too late
You will deliver based on assumptions instead of
facts
End-users will get unwanted surprises that give
you hassle
11
Measuring successful implementation of Involve End-Users/
Customers can be done through:
•
•
•
•
NPS of stakeholders
NPS of end-users
ROI of investments
Delivery reliability
Level 3: Business Value - Direct customer
feedback
Summarizing Direct Customer Feedback
A continuous feedback loop with the customer is in place and
real collaboration with customer(s) is installed.
What you will get with Direct Customer Feedback:
•
•
•
•
Continuous validation of the vision WITH your
customers
Clarity of what works and what doesn’t
Clarity of the extent in which the customer is
served
Ability to validated assumptions in real-life
Direct Customer Feedback consists of the following
practices:
•
Voluntary sprint review attendance
Stakeholders that are intrinsically motivated to come
to Sprint Reviews start to see the value of being able
to steer what a Scrum Team is delivering. We want
stakeholders to interact with Scrum Teams so that the
value delivered is maximized.
•
Customers attend refinements (on invitation)
A practice concerning stakeholder-team interaction in
which we like to see that stakeholders/users interact
with the team in such a way that developers really
grasp what the customer wants and that way can
deliver the most value instead of just develop software
from specifications. When doing that do not forget the
non-functional requirements and the value they have
towards customers.
•
Customer happiness @reviews
A good practice to use is measuring the happiness of
your customer for which you are delivering software.
Although it is not a very concrete measure the value is
in the trend and any big deviations from that trend. You
can use for instance either a happiness metric or NPS
scoreboard measure happiness.
•
Releasable increment
Every increment that is delivered at the end of a sprint
needs to be done in such a way that it can be released
to a customer. The increment should be completely
done so the PO can make the decision to release the
increment without any technical difficulty or bugs.
•
Shared vision
To be able to give valuable feedback it is good to
know which goal the product owner wants to achieve.
Therefor it is advisable that the Product Owner shares
his vision about the product not only with the team
but also with stakeholders preferably at the same
moment so the development team can get a better
understanding of the stakeholders way of thinking. We
advise in coming up with a metaphor that sticks with
the people involved. Everybody then knows what we are
talking about.
Skipping Direct Customer Feedback is risky, because then
you:
•
•
•
You will not be able to measure the value you
deliver
You will not know if you deliver value or not
You will be confronted with unhappy customers
too late
Measuring successful implementation of Direct Customer
Feedback can be done through:
•
•
•
•
NPS of customers
ROI of investments
Business value clarity
Business value delivered
Level 4: Business Value - End to end Value
Summarizing End-to-End Value
Concrete evidence and insight into the extent in which value
is delivered throughout the full chain.
What you will get with End-to-End Value:
•
•
Value Streams and product chains are aligned
Customer Services, Marketing, Finance and Sales
are cooperating to maximize the outcome of the
product(s)
12
End-to-End Value consists of the following practices:
•
•
•
End2End Product Owner
Combined Refinement
Summarizing Value Steering
The teams working on the same end2end value have
also combined refinement meetings where they
brainstorm the breakdown to smaller team features.
Delivered and measured value gives evidence about the next
steps (impact on Productbacklog).
Integrated product review
Team members act as end-users
End2End planning
What you will get with Value Steering:
•
•
•
•
Skipping End-to-End Value is risky, because then you:
•
•
•
Run the risk of delivering components when
combined have no value.
Delivered components do not give you the
feedback about the combined value and therefore
you do not know if you are doing the rights things.
Don’t mobilize the intrinsic motivation of people to
deliver a valuable holistic solution.
Identify Value, Goals & KPI’s Hypothesis
Value Driven Product Development starts with a clear
goal on what should be achieved with the next version
of the product. Impact Mapping is a technique to
make an explicit translation from Objectives towards
Features. This translation helps the Product Owner and
Stakeholders to group idea’s towards a defined goal.
•
Identify hypothesis
Before Product development starts there are many
assumptions about the expected Value. Do customers
really have this problem, do they want us to solve
their problem, do they like our proposed solution? Are
they willing to pay money? There are also technical
hypotheses, can we build this feature and what does it
cost? First items on the backlog should answer the most
dangerous assumptions.
SAFe - Scaled Agile Framework
The SAFe model explains a best practice to align
the different teams to create a combined integrated
product.
Validated Value
Backlog Updated by measuring success
Live Data
Value Steering consists of the following practices:
The relation between team features and product
features is clearly visualized. The corresponding
planning is aligned to improve the time to market of
product features. Product Owners meet at least weekly
to keep the planning aligned.
•
NPS of customer
ROI of investment
Business value clarity
Business value delivered
Level 5: Business Value - Value Steering
Team members are regularly sent to be end-users of the
product delivered. They really understand what it is to
be an end-user and to use the product in practical daily
usage. They experience the difference between the focus
of their own team and the value of the total integrated
product.
•
•
•
•
•
An end2end Product Owner is assigned who is responsible for maximizing the delivered total value. He has his own backlog of integrated product
features. He understands the customer and stakeholders
needs. He manages the scope of the Minimal Viable
(Integrated) Product.
The review shows the integrated product. Not the
individual results of different teams, but the combined
result of all the teams. After the review, the stakeholders
work on the next features to maximize the value of the
total integrated product.
•
Measuring successful implementation of End-to-End Value
can be done through:
•
Value Estimations on Product Backlog Items
The Product Backlog is ordered based on Expected
Outcome. Could be the most risky items, or the most
impact on market, or just dependencies, stuff that is
prerequisite to deliver any product or feature. Value
Poker is a practice to make value explicit. Another
technique is to rank value across different goals like:
User Impact, Sales, Technical Scaling etc.
13
•
Minimal Viable Product
Product Development is always dealing with
uncertainties, or hypothesis. The best way to get more
things certain is to get feedback from practice, a product
in production with real End Users. The Minimal Viable
Product is the minimum set of requirements that must
be implemented to get that feedback. It’s not a complete
product, the goal is to get feedback on actual usage
rather than a sellable product.
•
Short Build, Release & Measure & Refine loop
The learning speed in product development is limited
by the Build/Release/Measure cycle. When a product
is released 4 times per year, the product owner has
to wait 3 months for valuable feedback from usage in
practice. That means, hypotheses cannot be validated in
3 months. The shorter the cycle time in Build, Release,
Measure, the faster the learning process in product
development is.
•
•
•
•
•
Run the risc of having a assumption based
functionality
Mis feedback on market opportunities
Can not validate the business case since you can
not proof that what you delivered is really valuable.
Measuring successful implementation of Value Steering can
be done through:
•
•
•
•
•
•
Measure Value
To make decisions on future development a Product
Owner can use his own expectations or follow the
opinions from others. Working with a Minimal Viable
Product and defined Hyphothesis allows data driven
decision making. When the product is extended with
functionality to gather data from usage in practice,
Future Product Development can be directed based on
data from current usage.
•
Skipping Value Steering is risky, because then you:
NPS of customers
ROI of investments
Business value clarity
Business value delivered
KPI Mean Time to Experiment
Number of experiments per client
Level 6: Business Value - Company wide Agility
Summarizing Companywide Agility
Agility in the business sides of the company. Responding to
change without IT impacts.
What you will get with Company wide Agility:
•
•
•
•
•
Aligned business and Software development
Same organisation heartbeat
Lean organisation
Organisational Adaptability
Teams Driven by Self Motivation
A/B Split testing
Company wide Agility consists of the following practices:
Product Owners often want to test hypothesis or risky
changes on small scale, before risky enhancements are
brought to the entire group of users. AB split testing is
a technique to validate changes with a limited group
of users. A limited group visitors of a website get a
enhanced version of the product so the Product Owner
can afterwards measure the difference in the normal
version and enhanced version of the product.
•
Every sprint the whole business delivers value
The whole company has the same cadence. The
heartbeat of the different teams are aligned and they
have minimized the work-in-progress. This gives the
Product Owners the possibility to pivot in a very short
time and change the direction quickly.
Visualize Validated Value
Product Owners have make transparent how much
value they do deliver. When they don’t, they will have
conversations with stakeholders about other aspects,
like cost, delivery dates, etc. Showing the value delivered
gives product owners and stakeholders the ability to
discuss value delivered and value expected in future
releases. The picture below shows a visualization of
value in different stages of development.
14
•
Value based portfolio management
The KPIs and the ROI of portfolio projects are clear
and measurable. The feedback on the success and
impact is used to change the priorities of these minimal
marketable features.
of the operation process executed with software and
a major part of the tactical decisions to be made by
software.
•
Supply and demand meet in the marketplace which
we call the economy. Prices wary between companies
operating in the same economy. The pricing of an
organization however are generally speaking static while
demand varies. Organizations should create a flexible
demand based pricing models. Customers should be
incentivised if they pull the supply demand equation at
the right time and should pay a premium price if not.
Easy Jet has understood and implemented this concept
well. The components of their (extensive) pricing model
are that the earlier you book a chair, the cheaper the
price and if the plane is not full enough, the price drops.
Skipping Companywide Agility is risky, because then:
•
•
•
Business can not deliver at the speed needed in
the marketplace
Gaps between dev (org) & o/ocr Business units
remain
Increased Waste is present
Measuring successful implementation of Companywide
Agility can be done through:
•
•
•
Predictability on planning
Predictability on output
Ratio new versus maintenance
•
Summarizing Responsive Enterprise
What you will get with Responsive Enterprise:
•
•
•
•
The following are the practices which are prevalent in a
responsive enterprise:
•
•
Creating a software driven business model
A responsive enterprise delivers more value through
software. This does not mean that the offline model has
to disappear totally but moreover that software takes
a higher proportion of value delivery. This means going
to the drawing board and putting more automation/
software in the business. The goal must be to have 100%
Open meta loop
The task of the management is to follow the data from
operational loops and see if the organization is playing
the right game while the operational loop is about
playing the game right. Management should decide
which products can be added or subtracted from the
portfolio offerings based upon concrete data, together
with gut feeling.
Seamless Integration between business demands
& supply
Ability to lead market due to rocket speed
Very high predictability
WoW customer Expectations
The level Responsive Enterprise is the highest stage in the
Agility Ladder. A Responsive Enterprise is an open system
which is ultimately flexible.
Open operational loop
Demand based pricing is an example of an open
operational loop whereby the pricing is adjusted
depending upon the demand. Next to the pricing there
are a number of other processes which can benefit
from an open operational loop. These are downstream
aspects as getting extensive implicit and explicit
operational customer feedback on aspects of products
and services.
Level 7: Business Value - Responsive Enterprise
Is the whole company agile, are your clients agile and
do you give each other constant feedback? Then you
approach ‘cutting edge agility’. This is the ultimate level of
responsiveness.
Demand based pricing
•
Asset optimization policy
Assets are important for value creation of an enterprise.
The old way of thinking is to own the assets and do not
think about optimization. This creates a mental unleanness in employees and weight for an organization.
An organization can only be responsive if it can scale up
and down depending upon the customer demand. This
starts with being flexible in the assets owned. The core
in that case becomes the optimization of assets. The
time spent on maintaining the assets is then available
to procure them externally and as efficient as possible.
15
•
Experimentation structure
creating small self-steering (economically) viable
value creating entities. Every entity needs to have as
many steps of value creation within it as possible. This
also means a presence at the central web page of the
company and measuring of the returns which come
out if it. The role of the management changes to the
one of the owner of the shopping centre which offers
the possibility of opening your own shops. This has an
implication that management should also close that
shops which are below the value creation threshold.
A responsive enterprise carries out 1000 experiments per
day. This however needs to be structured and be done
within a context. Being a data driven enterprise the
user data should be followed to a great detail and based
upon customer behaviour new experiments should be
launched. Compare it to a mind map. There should be
an experimentation map where there is a hierarchy of
experiments.
•
Developers own the whole stack
As the business model is transformed into a software
dominated one, the amount of software increases
exponentially. This not only means that the importance
of software developers improves but also that it is
clear where the responsibility of software lies. Software
developers need to take responsibility. Software
developers are responsible for creating and delivering
value. They need to create value and interact with
suppliers (such as operations) to deliver value. This
means concretely for example that if a piece of code is
created by a developer and the code breaks down in
the middle of the night that the developer needs to take
responsibility at that time of the day.
•
•
•
Website is a demo
Organizational structures of the responsive enterprise
are fundamentally different. Instead of creating
functional silos, the responsive enterprise is all about
No internal customers
Big enterprises work with a division of tasks in business
and IT. If an organization wants to reach the stage of
Responsive Enterprise, that division needs to disappear.
The above mentioned split creates a kind of opaqueness
for developers. Developers need to come out of the
basement and take over the business responsibility as
software is the business. If taxi drivers can handle their
own customers, software developers can at least do the
job of handling them as well!
•
Customer experience is leading
Every organization has a goal to service its customers.
A Responsive Enterprise is however all about giving a
customer an experience. This as a Responsive Enterprise
realizes that customers can buy a product everywhere
but what distinguishes it from the rest is the experience
they receive. The components of the experience are
service, defining the touch points to create a maximum
awe.
Beekeeping culture
The culture of the responsive enterprise is that of a
bee keeper. This means that like in the case of bees,
employees are stimulated to contribute the maximum
to the organizational goal and are steered using that KPI
in mind and not the number of hours worked or being
present during working hours. This requires creation of a
structure to quantify the amount of work to be done and
a reward system based upon output and outcome and
not input and effort.
Middlemanagement is a hackers coach
As the number of software developers increases in your
business, the management has to evolve with it. People
managing software developers should have a good idea
of the work they ideally have done themselves. This
leads to functioning software teams which delivers value
to the end users. If the team does not do its the job well,
this means that managers have not been provided the
correct context to the developers. Therefore they should
be replaced fast.
Low corporate memory
Long serving people should be valued but at the same
time they block change in the end. An agile enterprise
optimizes the stay of an employee. This should not be
too short but also not too long. During this interval the
employee should be driven to deliver maximum value
and earn a lot in all senses of the word. Only the key
and culturally fitting employees are stimulated to stay
longer.
•
•
•
Single KPI
Everybody should have one goal and one goal only. This
means that everybody is working on one thing. This as
human beings are not good at doing multiple things
and having multiple goals. These goals should be tightly
aligned to the organizational goal.
16
Skipping Responsive Enterprise is risky, because then you:
•
Create a false sense of security. If your competitor is
there faster, the very existence of the organization is at
stake.
Measuring successful implementation of Responsive
Enterprise can be done through a number of metrics. These
are:
Amount of software in your business process:
1. Optimization of own assets, compared to the
competition
2. Length of employee contracts, compared to the
competition
3. Proximity of the developers to the end users, compared
to the competition
17
IT Value
keep evolving during the course of the development.
Definition of Done (DoD) helps the team to deliver a
potentially shippable product ensuring high quality.
Definition of Ready (DoR) helps the team to completely
understand the stories. Story Point Definitions helps the
team by acting as a guideline in Sizing the stories.
Level 1: IT Value - Basic Scrum
Summarizing Basic Scrum
Have the core Scrum processes, artifacts and meetings
installed and stick to them automatically.
•
What you will get with Basic Scrum:
•
•
•
•
•
•
Backlog refinement is done to have prior vision, clarity
on the goals for the upcoming Sprint. The Product
Owner to presents the prioritized stories complying with
DoR the team. The team provides it’s feedback in terms
of estimates and clarifications. Pokering can be used for
providing the estimates.
Predictability on: Planning, Output, Costs
Fail early, learn fast
Scrum team ownership
Efficiency increases with 20%, due to: Creating
focus and Less waste
Everyone business driven, knows why we are
working on stuff
Easy to change priorities
This works as follows. The team calculates it’s capacity/
velocity. They then use poker cards (or a better method)
to come up with the estimates for the stories that need
to be relooked at (already estimated in refinement). The
variations can be discussed till everyone agrees to a
common number.
Basic Scrum consists of the following practices:
•
Sprint Planning
Requires the entire team to be present. The moment the
backlog is consumed with enough story points for the
sprint, part 2 of planning is taken care of. This is where
the team splits every story into multiple tasks.
•
•
Daily scrum is for the team to be on the same page and
should not be like reporting.
Awareness of DoD, DoR, Story point definition
In-sprint Demos & Pre Demo
In-Sprint Demonstrations acts as a feedback loop for
the team. It is recommended that the team has in-sprint
demos frequently to get earlier feedback. Pre-Demo acts
as another level of a feedback loop and generally is done
with the team and the Product Owner. This ensures that
there are no surprises during the Sprint Review.
•
Sprint review
The team (or a representative) presents to the PO and
the stakeholders, what they’ve accomplished in the
sprint. They demo working software. Is a ground for
discussion and provides stakeholders/PO with inputs
that can act as a feed for future sprints. The sprint
review should be crisp, to the point and interesting for
the stakeholders. And there should be more focus on the
why part and not into the intricacies.
Daily Scrum
Happens at the same place and same time everyday.
Sync up on three points :
1. What the team members accomplished the previous day?
2. What’s the plan for the day?
3. Impediments
•
•
Release planning
Should be done by the Product Owner and the team
keeping in mind the vision of the stakeholders. It is
based on the forecasted velocity for the sprints that
would be required for completion of the release. Also,
take into account the business priority for various
epics/stories. This benefits the team to have clarity,
scope and plan towards getting there. Also, it helps the
stakeholders in better decision making.
Backlog Refinement
•
Retrospective
The retrospecive is done with the intent of helping team
inspect, learn, adapt, improve and try out new stuff. The
team discusses what went well, what can be improved,
impediments and new things to try. Must result in action
items and owners (possibly). Can be used as a platform
to measure overall happiness within the team and the
customers.
Definition of Done, Definition of Ready and Story point
definitions are part of the Team artifacts. These artifacts
18
•
Kaizen
are developing. By taking advantage of code metrics,
developers can understand which types and/or
methods should be reworked or more thoroughly
tested. Development teams can identify potential
risks, understand the current state of a release, and
track progress during software development. This
measurement includes the following metrics: Cyclomatic
Complexity, Depth of inheritance, maintainability Index
and class coupling.
Should be a part of every team’s sprint backlog. This
helps teams to get better, one step at a time. It should
not be vague and therefore must have an acceptance
criteria/deliverables. It should force teams to think
about genuine improvement areas.
Skipping Basic Scrum is risky, because then you:
•
•
•
•
•
Ignore quality as a KPI of projects
Spend a lot of time on resource management
(bringing the people to the work instead of the
work to the people)
Get no feedback on the delivered quality
Will learn slow
Experience gold plating
•
Code analysis provides information about the code
quality, such as violations of the programming and
design rules set forth in the Programming Language
Design Guidelines. The analysis represents the checks
it performs during an analysis as warning messages
and errors. Errors and Warning messages identify any
relevant programming and design issues and, when
it is possible, supply information about how to fix the
problem. It is advisable to have the warning turned to
errors to ensure no tolerance to poor code quality.
Measuring successful implementation of Basic Scrum can
be done through:
•
•
•
Predictability on planning
Predictability on output
Ratio new versus maintenance
•
Summarizing Code Quality
•
What you will get with Code Quality:
•
•
•
•
•
Code Quality consists of the following practices:
•
Measurement of Code Metrics
Code metrics is a set of software measures that
provide developers better insight into the code they
Test Driven Development (TDD)
Test-driven development is a technique of using
automated unit tests to drive the design of software and
force decoupling of dependencies. The result of using
this practice is a comprehensive suite of unit tests. This
suite of unit tests help ensure high code quality and
provide feedback that the software is still working. TDD
requires a set of disciplines, and one of them is ‘red,
green, refactor’. It is about writing tests first, make it
pass and then refactor the code.
Constant cost for new features
High innovation rate
Stretch employee on craftsmanship
Ability to scale
Less time on bug fixing (bug searching)
Code Quality is about how mature the organization is in
practices such as pair programming, code review standard,
code review process, automated code review/audit and
gated check-in and it consists of the following practices:
Continuous Integration
The faster we can check how our changes apply to
existing code, the faster we can discover issues of any
kind, related to the change. With continuous integration
in place, we have an automated process to trigger and
execute all kinds of checks, directly after a change has
been made and/or on request. Continuous Integration
ensures good Code Quality.
Level 2: IT Value - Code Quality
Mature software quality delivery by an organization through
quality practices such as pair programming, code review
standards, code review process, automated code review/
audit and gated check-ins.
Static/Dynamic Coding Analysis Standards
•
Pair Programming
All code to be sent into production is created by two
people working together at a single computer. Pair
programming increases software quality without
impacting time to deliver. It is counter intuitive, but 2
people working at a single computer will add as much
functionality as two working separately except that it
will be much higher in quality. With increased quality
19
comes big savings later in the project.
•
The best way to pair program is to work side by side
in front of the monitor. One person codes—the driver.
The other person is the navigator, whose job is to think.
Slide the key board and mouse back and forth. Both
programmers concentrate on the code being written.
Automated regression testing helps to fully check
feature chains in existing code, therefore preventing
code changes that negatively impact existing
functionality to occur. With automated testing, this
negative impact is spotted very soon and this helps in
building reliable features.
Skipping Code Quality is risky, because then:
•
•
•
•
The cost for change will increase
You will have unreliable production
You will have unmaintainable automated tests
You will have fragile code
Measuring successful implementation of Code Quality can
be done through:
•
•
•
Down time
Number of bugs
Time spend on new feature vs. time spend on bug
fixing
•
Automated Regression testing
Code coverage management
Code coverage helps spotting code that is not covered
by unit, integration and/or regression tests. When code
is not covered by tests, this is technical debt. This code
may or may not work as expected, and with changes,
also may or may not work as expected. We want to build
high quality solutions, with less risk of negative impact.
•
Test environment setup
Level 3: IT Value - Automated QA
All tests should run on development and test
environments. These need to be setup with appropriate
hardware and test data so the tests can be run
independently from each other. This helps in identifying
issues earlier.
Summarizing Automated QA
•
Automated Quality Assurance ensures a continuous
validation of quality through full automation and eliminating
all manual testing
The correct tooling for doing automated QA should be
in place. There needs to be a Continuous Integration
dashboard, there need to be tools for all kinds of
tests. These tools need to be carefully selected and
appropriate for the challenges at hand. There needs
to be a tool for a user oriented backlog management
approach (e.g. Agile Cockpit).
What you will get with Automated QA:
•
•
•
•
Sustainable Quality
Fearless of change
Less repetitive work
Automate the boring stuff
Automated QA consists of the following practices:
•
Automated Unit testing
The value of unit testing lies in checking the quality
of the existing code, directly when making a change.
With unit testing, you can more safely make changes,
knowing that the checks of the smallest units are in
place. Therefore you are alerted ASAP of the smallest
bugs you may introduce on existing code.
•
Automated Integration testing
Tool selection
Skipping Automated QA is risky, because then:
•
•
•
•
The cost of testing (manually) increases
There will be a long feedback cycle on quality
Slow QA
No predictable scaling quality
Measuring successful implementation of Automated QA can
be done through:
•
•
•
•
Keeping track of how often you run your
automated test sets
If you use it in every step towards going live
What the amount of coverage is of your automated
test set
Keeping track of how often new automated tests
Integration testing helps in checking integration
issues earlier. Therefore your awareness of another
functionality not working after a code change was made,
is raised. This helps in functional bug prevention.
20
environments. The teams get early feedback on
the compatibility and performance of the software
in Production by simulating the deployment on a
production like environment acceptance (A). All
stakeholders (including the customer) can be involved
in the acceptance of the feature before the feature is
deployed in Production by following the DTAP street.
for each type of tests are added?
Level 4: IT Value - Scaling
Summarizing Scaling
Scaling is ensuring security, performance and design when
more teams need to be aligned and work intensively together
to deliver a result.
•
What you will get with Scaling:
•
•
•
•
•
•
Adaptability to ever rising business demands
Ready for ‘Development organizations’
improvement
Spreading the right structure to ‘Development
organizations’ (self organizing)
Better portfolio management
Share learning across ‘Development organizations’
Consistent release heartbeat across ‘Development
organizations’
Scaling consists of the following practices:
•
Architecture documentation
The architecture template is a mean of communicating
software architecture to all stakeholders. It should be
done in a way that is understood by the development
team, QA, Ops, performance engineers, security
analysts, etc. so that they can build systems from it,
analyze it, maintain it, and learn from it. It should
cover the details of architectural element’s and their
behaviors. It should define the criteria for what views
should be documented. The blueprint of the system
is defined in the documentation. Every change in
the system should be updated in your architecture
document as well (living document).
•
Measuring Architecture debt
It is defined as a situation/ debt where the current
architecture cannot suffice the needs of the evolving
business requirements. Architecture debt can be
measured by checking whether the current architecture
cannot meet the needs of meeting the requirements
for standards like security, robustness, changeability,
performance efficiency and maintainability.
•
Unified technology stack
A unified technology stack helps seamless software
integration. It also provides the flexibility to partner with
the vendor to upgrade the architectural requirements
based on the current market trends.
•
Have a scaling model
Define an agile scaling model for effective agile adoption
and tailoring of principles to meet the unique challenges
faced by the teams of any size. Consider factors of
team size, distributed teams, standards and metrics,
discipline etc.
•
Scrum of Scrums
Scrum of scrums can be used to scale the Daily
Scrum meeting when multiple teams are involved.
Its purpose is to support agile teams in collaborating
and coordinating their work with other teams. All
the impediments are discussed and owners of the
impediments are also identified and progress is tracked.
Skipping Scaling is risky, because then you will have:
•
•
•
•
A chaotic/Unmanageable structure
No collective vision
Micromanagement
Inefficiency/Waste due to inconsistent way of working
Measuring successful implementation of Scaling can be
done through:
•
•
•
•
Net promotor score (NPS) of stakeholders
Delivery reliability
Forecast reliability
Budget expenditure transparency
DTAP - Development, Testing, Acceptance and
Production
Creating and maintaining a DTAP (DevelopmentTest-Acceptance-Production) environment helps the
project teams and IT department to ensure faster
(quality) delivery at a lower cost. It also reduces the
risk of breaking other applications when side by side
deployment of components is facilitated in higher
21
Level 5: IT Value - Continuous Delivery
code, it will be very easy to rollback to an earlier working
configuration of the machines.
Summarizing Continuous Delivery
Fast value delivery through delivering small releases in an
increasing fast frequency.
•
The smaller the changes we can bring to production,
the faster we receive feedback. Small changes inhibit
the need for roll backs. Whenever a small change breaks
existing functionality, it can be easily fixed and released
with another small change: rolling forward instead of
rolling back.
What you will get with Continuous Delivery:
•
•
•
•
Early Feedback
On demand delivery (Automated)
Reliability
Maximize ROI on developed features
Continuous Delivery consists of the following practices:
•
•
The configuration should contain all software
components and settings that make up the application/
database/testing/build environments. E.g.: you could
maintain the compiler version needed for the build
system and have a configuration management system
that installs the same if and when a build system needs
to be provisioned.
•
•
Roll back mechanism
Software development is never perfect and there are
occasions when new changes break down the entire
system. A proven rollback mechanism enables the
company to minimize the effect of downtimes for their
customers and be up and running in a relatively shorter
amount of time. If the infrastructure is maintained as
Feature toggling
One way to avoid branches is to have feature toggles
for code enabling business and technical folks alike to
switch on and off features depending on the confidence
and requirements of customers.
•
Orchestration Manager Solution
The Orchestration manager solution is a console that
gives everyone the exact state of all the environments
that the code is deployed to and also has controls
in place for enabling build promotion that satisfies
regulatory requirements.
•
Pipeline checks and metrics
At any point on the Continuous Delivery pipeline, it
is vital to measure the health of each environment
using essential KPI’s and metrics. Results of tests like
functional tests, performance tests, soak tests etc also
are important criteria that needs to be represented
for business decisions to be made. Lead time for
provisioning and monitoring metrics should also be
maintained.
Infrastructure provisioning and maintenance
The Agility of an organization depends on how quickly
an organization is able to respond to changes. Having an
automated infrastructure provisioning and maintenance
system helps in making an organization agile. This also
helps organizations to scale up/down as and when
needed, as well as manage disaster recovery scenarios.
Mainline development
Continuous Delivery does not work well with multiple
branching strategy and hence an organization needs
to restrict the number of branches it deals with, ideally
down to one.
Environment definitions (infrastructure as code)
Environment definitions (configurations) should be as
configuration objects in the source code management
system. It helps to find out the present state of each
environment, further enabling us in the rollback process
if errors occur.
•
•
Automated Deployment
Deployment of applications can be automated and it
should be! Because of Automated Builds you receive
faster feedback and increase speed.
Roll forward mechanism
Skipping Continuous Delivery is risky, because then you:
•
•
•
•
Increased shelf time of developed features
Late feedback for developed features
Stressful releases
Poor customer satisfaction due to delayed, low quality
releases
22
Measuring successful implementation of Continuous
Delivery can be done through:
•
•
•
Shelf time
Installed version index
Net Promotor Score (NPS )
Level 6: IT Value - Company wide Agility
Summarizing Company wide Agility
You use agility in your software development/IT department
to respond to change quickly
What you will get with Companywide Agility:
Your IT organization is at this level when it is structured and
organized in such a way that knowledge is shared across
the whole IT organization. All IT work is done with the end
customer in mind. Cost of change is low and shared quality
standards arise from the teams in a continuous improvement
effort.
Companywide Agility consists of the following practices:
•
•
•
•
Guilds are in place and really driving the quality
Corporate wide product backlog implemented with the
right detail for right purpose
Deepdive workshops are held on a regular basis
Ownership is transferable between teams
Skipping Company wide Agility is risky, because then you:
•
Have not finished the installation of agility in your
department to make the implementation sustainable in
the future when making the whole organization agile.
Measuring successful implementation of Companywide
Agility can be done through:
•
•
•
Release frequency
Delivery reliability
Cycle time
Level 7: IT-Value - Responsive Enterprise
Please refer to business value-Reponsive Enterprise.
23