1

Becoming a Responsive EnterpriseGrowing step by step by using the Agility Ladder

2

The Responsive Enterprise promise 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.

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

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

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 end-users 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.

3

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

4

What is the Agility LadderA short introduction into the levels.

IT VALUE BUSINESS VALUEResponsive 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 SteeringDelivered 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 valueConcrete evidence and insight into the extent in which value is delivered throughout the full chain.

Automated QA Automated quality assurance ensures a continuous valida-tion of quality through full automation and eliminating all manual testing.

Direct customer feedbackA 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/customersEnd 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 in-stalled and stick to them automatically.

Backlog ManagementProduct 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.

5

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

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 step-by-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.

6

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

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?

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.

7

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 AuthorsThis 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

8

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.

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

9

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.

10

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 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:

• Hierarchical trees • Tree Mapping • Story Mapping

Appendix 2: The Agility Ladder in detailEach 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.

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.

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

11

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.

• Stakeholder Awesomeness at Sprint Reviews

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.

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

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

• 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

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

Skipping Backlog Management is risky, because then:

• 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

Level 2: Business Value - Involve End Users - Customers Summarizing 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.

What you will get with Involve End-Users/Customers:

• 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 end-users for decisions

Involve End-Users/Customers consists of the following practices:

• Stakeholder – Development Team dialogue

12

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)

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 feedbackSummarizing 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

13

Measuring successful implementation of End-to-End Value can be done through:

• NPS of customer• ROI of investment• Business value clarity• Business value delivered

Level 5: Business Value - Value Steering

Summarizing Value Steering

Delivered and measured value gives evidence about the next steps (impact on Productbacklog).

What you will get with Value Steering:

• Validated Value• Backlog Updated by measuring success• Live Data

Value Steering consists of the following practices:

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

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

End-to-End Value consists of the following practices:

• End2End Product Owner

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.

• Combined Refinement

The teams working on the same end2end value have also combined refinement meetings where they brainstorm the breakdown to smaller team features.

• Integrated product review

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.

• Team members act as end-users

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.

• End2End planning

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.

• SAFe - Scaled Agile Framework

The SAFe model explains a best practice to align the different teams to create a combined integrated product.

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.

14

Skipping Value Steering is risky, because then you:

• 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:

• 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

Company wide Agility consists of the following practices:

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

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

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

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

• A/B Split testing

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.

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

15

of the operation process executed with software and a major part of the tactical decisions to be made by software.

• Demand based pricing

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.

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

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

• 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 un-leanness 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.

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

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

Level 7: Business Value - Responsive Enterprise

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

What you will get with Responsive Enterprise:

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

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%

16

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.

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

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

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

• Experimentation structure

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.

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

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

• Website is a demo

Organizational structures of the responsive enterprise are fundamentally different. Instead of creating functional silos, the responsive enterprise is all about

17

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

18

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.

• Backlog Refinement

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

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

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

IT Value

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:

• 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

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.

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

• 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 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

Definition of Done, Definition of Ready and Story point definitions are part of the Team artifacts. These artifacts

19

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.

• Static/Dynamic Coding Analysis Standards

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.

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

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

• 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

• Kaizen

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

Measuring successful implementation of Basic Scrum can be done through:

• Predictability on planning• Predictability on output• Ratio new versus maintenance

Level 2: IT Value - Code Quality

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

What you will get with Code Quality:

• Constant cost for new features• High innovation rate• Stretch employee on craftsmanship• Ability to scale• Less time on bug fixing (bug searching)

Code Quality consists of the following practices:

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:

• Measurement of Code Metrics

Code metrics is a set of software measures that provide developers better insight into the code they

20

• Automated Regression testing

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.

• 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

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.

• Tool selection

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

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

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.

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

Level 3: IT Value - Automated QA

Summarizing Automated QA

Automated Quality Assurance ensures a continuous validation of quality through full automation and eliminating all manual testing

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

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.

21

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.

• 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

for each type of tests are added?

Level 4: IT Value - ScalingSummarizing 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.

• DTAP - Development, Testing, Acceptance and Production

Creating and maintaining a DTAP (Development-Test-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

22

code, it will be very easy to rollback to an earlier working configuration of the machines.

• Roll forward mechanism

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.

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

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

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

Level 5: IT Value - Continuous DeliverySummarizing Continuous Delivery

Fast value delivery through delivering small releases in an increasing fast frequency.

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:

• Automated Deployment

Deployment of applications can be automated and it should be! Because of Automated Builds you receive faster feedback and increase speed.

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

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.

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

• 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

23

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.