Disciplined Agile Applied

Winston Churchill once said “Plans are of little importance, but planning is essential.” What Churchill meant was that the value is in thinking something through, in planning it, before you do it. So this leads to some interesting questions: How much planning should we do?  How can we get the most value out of our planning efforts? I wish I could tell you that there is solid research evidence to answer this question but sadly I haven’t been able to find any (if you know of any, I’d love to hear about it). Luckily though, we do have a lot of experience and observational evidence to fall back on.

From an accounting point of view we know that value is calculated as benefit minus cost. The implication is that all we need to do then is calculate the benefits of planning, and the costs of doing so, apply a bit of math and there you go.  How hard could that be? As we know it’s very difficult to calculate the benefits because some are qualitative, requiring a bit of creativity to turn them into a monetary figure. The bigger challenge is that planning is just one activity of many that go into achieving a benefit making it difficult to tease out the planning portion of the benefit earned. Calculating the true costs of planning isn’t much easier when you start to consider the downstream implications of the work required to gather the inputs that go into the planning process.  This is a particular problem in creative domains such as software development, more in this in future blogs.  The implication is that in practice there isn’t an easy way to determine the actual value of planning, which explains the dearth of research evidence around this issue.  

Because there are no hard and fast rules to determine the value of planning, practitioners rely on belief systems to guide their thinking.  Figure 1 overviews two common belief systems, the traditional (sometimes inappropriately called “predictive”) belief system and the agile belief system.  We’ve labelled the latter as undisciplined because we will distinguish this from a Disciplined Agile (DA) strategy later.  The traditional belief system tells us that the more effort that you put into planning the more value that you will gain from doing so.  This belief system tells you to think things through in detail before you do them.  This increases value by avoiding mistakes in the future, thereby reducing costs. At the other extreme the (undisciplined) agile belief system tells us that there is very little value in planning, that you are better advised in focusing on being able to react to feedback.  This enables you to deliver sooner and thereby earn the actual benefits sooner and longer, thereby increasing value.  The obvious downside of course is that mistakes will be made, sometimes serious ones, thereby increasing both costs and risks. 

Figure 1. What our belief systems tell us about the value of planning.

The methodologist in me tells me that extremes are generally a bad thing, that for most situations the answer lies somewhere in between.  The easy answer would be to simply draw a dashed line in between the two curves in Figure 1, or get really fancy and introduce some sort of range between the two lines, but the easy answer is wrong.   What we really need to do is look at what actually happens in practice, something that we did in the Agile Modeling (AM) community in the early 2000s.

In AM we needed to determine the value of modeling so as to provide coherent advice around when to model and to what extent to model. To make a long story short, we observed that the value of modeling followed the law of diminishing returns as you can see in Figure 2.  A little bit of modeling offered a lot of value.  So did a bit more, then a bit more, then a bit more.  But very quickly we reach a point of diminishing returns, the total costs of modeling soon exceeds the total benefits of modeling – once a model is sufficient for the situation that you’re thinking through with it, you reach a point where any more modeling removes overall value.  This point is what we called the just barely good enough (JBGE) point, although others prefer “sufficient” as a term.  So why am I talking about the value of modeling? Because modeling and planning are slightly different flavors of the same thing: Thinking something through before you jumping into doing it.

Figure 2. The value of planning/modeling.

JBGE?  What?

Many people, particularly those who follow a traditional “predictive” lifecycle approach, tend to be taken aback when they’re told the most effective plans are those that are just barely good enough.  The problem is that they often interpret JBGE as insufficient, yet by definition that is clearly not the case.  If your planning efforts haven’t been sufficient then you can still benefit from more planning, or to be accurate you can benefit from good planning at the right time.  But, if your planning efforts have been sufficient, or more than sufficient, then more planning is only going to remove value.  From a lean point of view over-planning is a waste.  

To summarize, the DA belief system is that the value of planning and modeling follows the law of diminishing returns. There is significant anecdotal evidence that bears this out but as I indicated earlier the research evidence is sparse.  I’ve actively prodded researchers along when I could for the past 15 years to get this evidence, but these efforts have always floundered when they discovered that this research is very difficult long-term work.  

In the next blog in this 3-part series we explore how to determine when your planning efforts are sufficient.  Following that we work through how to be efficient at planning.

In my blog Disciplined Agile Principle: Optimize Flow I wrote the following:

Measure what counts. When it comes to measurement, context counts. What are you hoping to improve? Quality? Time to market? Staff morale? Customer satisfaction? Combinations thereof? Every person, team, and organization has their own improvement priorities, and their own ways of working, so they will have their own set of measures that they gather to provide insight into how they’re doing and more importantly how to proceed. And these measures evolve over time as their situation and priorities evolve. The implication is that your measurement strategy must be flexible and fit for purpose, and it will vary across teams.

Based on that I received the following question:

Regarding number 7 above: Measure what counts. I think that's really important. How would you handle the need for some larger organizations to compare teams, directorates, divisions etc. with uniform metrics? Each effort is so different and will require different metrics.

This is a great question that deserves a fairly detailed answer, so I thought I'd capture it as a new blog posting.  Here are my thoughts.

1. Using metrics to compare teams, directorates, ... is a spectacularly bad idea. The problem is that when you start using metrics to compare people or teams you motivate them to game the measures (they make the numbers appear better than they are).  Once people start to game their measures your metrics program falls apart because you're now receiving inaccurate data, preventing you from making informed decisions.  Even if you're not using metrics to compare people all it takes is the perception that you might be doing so and they'll start to game the measures where they can.  Luckily many measures are now collected in an automated manner from the use of our tools, making them much harder to game.  But you can't measure everything in an automated manner and any manually collected metric is at risk of being gamed, so sometimes you just need to accept the risks involved. BTW, using metrics to compare people/teams has been considered a bad practice in the metrics world for decades.   
2. Use metrics to inform decisions.  I'm a firm believer in using metrics to make better-informed decisions, but that only works when the quality of the data is high.  So focus your metrics program on providing you with operational intelligence to enable your staff to better manage themselves.  Furthermore, metrics can and should be used to provide senior management with key information to govern effectively.  This implies that you need to make at least a subset of a team's metrics visible to other areas in your organization, often rolling them up into some sort of program or portfolio dashboard. We can choose to be smart about that.
3. Applying uniform metrics across disparate teams is a spectacularly bad idea. The DA principle Context Counts tells us that to be effective different teams in different situations will choose to work in different ways. To enforce the same way of working (WoW) on disparate teams is guaranteed to inject waste (hence cost and risk) into your process.  Either teams will work in a manner that isn't effective for the situation that they face or they will work in an appropriate manner PLUS perform additional work to make it appear that they are following the "one official process."  Agile enterprises allow, and better yet enable,  teams to choose their own WoW and evolve it over time as their situation evolves (and it always does).  
4. You can apply common categories or improvement goals across teams.  Having said all this there is always a desire to monitor teams in a reasonably consistent manner.  Instead of inflicting a common set of metrics across all your teams you should instead tell them that you want them to measure a common set of issues that you hope to improve and provide a mechanism to roll up a score in a common way.  For example, say your goal is to improve customer satisfaction. You could inflict a common metric across your teams, say net promoter score (NPS), and have everyone measure that.  That will make sense for some teams but be misaligned or simply inappropriate for others. There are many ways to measure customer satisfaction, NPS being one of them, and each one works well in some situations and not so well in others. Recognizing that once metrics strategy won't work for all teams, negotiate with them that you want to see X% improvement in customer satisfaction over a period of Y and leave it up to them to measure appropriately.  Setting goals/objectives is a fundamental concept for metrics strategies such as Goal Question Metric (GQM) and Objectives and Key Results (OKRs).   If you want to roll metrics up into a higher-level dashboard or report then you can also ask the teams to have a strategy to convert their context-sensitive metric(s) into a numerical score (say 1 to 10) which can then be rolled up and compared.  Just joking, comparison is still a bad idea, I'm just seeing if you're paying attention.  The downside of this approach is that it requires a bit more sophistication, particularly on the part of anyone in a governance position who wants to drill down into the context specific dashboards of disparate teams. The benefit is that teams can be provided the freedom to measure what counts to them, providing them with the intelligence that they require to make better informed decisions. See the article Apply Consistent Metric Categories Across an Agile Portfolio for a detailed description of this strategy. 
5. Regulatory concerns may force you to collect a handful of metrics in a uniform way. It happens.  This is typically true of financial metrics, at least within a given geography.  For example, your organization will need to identify a consistent interpretation to how to measure CAPEX/OPEX across teams, although I've also seen that vary a bit within organizations for very good reasons.

To summarize, it's a really bad idea to inflict a common set of metrics across teams. A far better strategy is to have common improvement objectives across teams and allow them to address those objectives, and to measure their effectiveness in doing so, as they believe to be the most appropriate for their situation.

One of the seven principles behind Disciplined Agile (DA) is Context Counts. Every person is unique, with their own set of skills, preferences for workstyle, career goals, and learning styles. Every team is unique not only because it is composed of unique people but also because it faces a unique situation. Your organization is also unique, even when there are other organizations that operate in the same marketplace that you do. For example, automobile manufacturers such as Ford, Audi, and Tesla all build the same category of product yet it isn’t much of a stretch to claim that they are very different companies. These observations – that people, teams, and organizations are all unique – leads us to a critical idea that your process and organization structure must be tailored for the situation that you currently face. In other words, context counts.

CONTEXT FACTORS

Figure 1 overviews the potential factors that you should consider regarding the context of the situation faced by your team.  We’ve organized them into two categories:

1. Selection factors that drive your initial choices around your high-level way of working (WoW) and in particular your choice of initial lifecycle.
2. Scaling factors that drive detailed decisions around your team’s WoW.

Of course it’s never this straightforward.  Selection factors will have an effect on your detailed WoW choices and scaling factors will also have an impact on your initial decisions.  Our point is that in general the selection factors have a bigger impact on the initial choices than do the scaling factors and similarly the scaling factors have a bigger impact on your detailed tailoring decisions than do the selection factors.

Figure 1. Potential context factors (click to enlarge).

Context factors are interdependent.  Figure 2 shows the major relationships between the context factors.  For example, you can see that:

• As domain complexity rises the skills required to address that complexity also rise (harder problems require greater skill to solve).
• As team member skills increase the size of the team required to address the problem it faces can shrink (a small team of skilled people can do the job of a larger team of lower-skilled people).
• Your organizational culture and your team culture tend to affect one another, hopefully positively.
• Your team culture will vary by organization distribution (your team will have a different culture than that of teams in a different division of your organization, or of teams in a different company).
• The more organizationally distributed your team becomes the greater the chance that it will be geographically distributed as well.  For example, if you are outsourcing some of the work to another organization the people doing that work may be in another, lower-cost country.

Figure 2. Relationships between context factors (click to enlarge).

TACTICAL AGILITY AT SCALE

Let’s explore the scaling factors a bit. As we mentioned earlier, the scaling factors tend to drive your detailed decisions around your way of working (WoW). For example, a team of eight people working in a common team room on a very complex domain problem in a life-critical regulatory situation will organize themselves differently, and will choose to follow different practices, than a team of fifty people spread out across a corporate campus on a complex problem in a non-regulatory situation. Although these two teams could be working for the same company they could choose to work in very different ways.

Figure 3 depicts the scaling factors as a radar chart, sometimes called a spider chart. There are several interesting implications:

• The further out you go on each spoke the greater the risk faced by a team. For example, it’s much riskier to outsource than it is to build your own internal team. A large team is a much riskier proposition than a small team. A life-critical regulatory situation is much riskier than a financial-critical situation, which in turn is riskier than facing no regulations at all.
• Because teams in different situations will need to choose to work in a manner that is appropriate for the situation that they face, to help them tailor their approach effectively you need to give them choices.
• Anyone interacting with multiple teams needs to be flexible enough to work with each of those teams appropriately. For example, you will govern that small, co-located, life-critical team differently than the medium-sized team spread across the campus. Similarly, an Enterprise Architect who is supporting both teams will collaborate appropriately with each.

Figure 3. Tactical scaling factors faced by teams.

ENTERPRISES REQUIRE ENTERPRISE-CLASS SOLUTIONS

The leading agile method Scrum provides solid guidance for delivering value in an agile manner but it is officially described by only a sixteen page guide. Disciplined Agile recognizes that enterprise complexities require far more guidance and thus provides a comprehensive reference framework for adapting your agile approach for your unique context in a straightforward manner.  Being able to adapt your approach for your context with a variety of choices (such as those we provide via goal diagrams) rather than standardizing on one method or framework is a very good thing.

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

RELATED READING

• Principles Behind Disciplined Agile

One of the seven principles behind Disciplined Agile (DA) is Optimize Flow.  Your organization is a complex adaptive system (CAS) of interacting teams and groups that individually evolve continuously and affect each other as they do. The challenge that we face is how do we ensure that these collaborating teams do so in such a way as to effectively implement our organization’s value streams? How do we ensure that these teams are well aligned, remained well aligned, and better yet improve their alignment over time?

The implication is that as an organization we need to optimize our overall workflow. The DA toolkit supports a large number of strategies to do so:

1. Deliver continuously at a sustainable pace. The Disciplined Agile Manifesto advises teams to deliver consumable solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. This philosophy is one of four, in this case Deliver, promoted by the Heart of Agile. Similarly it is one of four philosophies of Modern Agile, in this case Deliver Value Continuously, and it is a fundamental strategy of Disciplined DevOps. Since 2001 agilists have shown that it is possible to deliver high-quality systems quickly. By limiting the work of a team to its capacity, which is reflected by the team’s velocity (this is the number of “points” of functionality which a team delivers each iteration), you can establish a reliable and repeatable flow of work. An effective organization doesn’t demand teams do more than they are capable of, but instead asks them to self-organize and determine what they can accomplish. Enabling these teams to delivering potentially shippable solutions on demand motivates them to stay focused on continuously adding value.
2. Optimize the whole. Disciplined agilists work in an “enterprise aware” manner – they realize that their team is one of many teams within their organization and as a result they should work in such a way as to do what is best for the overall organization and not just what is convenient for them. More importantly they strive to streamline the overall process, to optimize the whole as the lean canon advises us to do. This includes finding ways to reduce the overall cycle time, the total time from the beginning to the end of the process to provide value to a customer, is a key part of doing so.
3. Make work flow. The 14th principle of the DA Manifesto is to visualize work to produce a smooth delivery flow and keep work-in-progress (WIP) to a minimum. This strategy enables teams to identify and then remove bottlenecks quickly and is adopted straight out of Kanban.
4. Eliminate waste. Lean thinking advocates regard any activity that does not directly add value to the finished product as waste. Waste includes time waiting for others to get something done, creation of unnecessary work artifacts or product features, and collaboration churn resulting from crossing organizational boundaries. To reduce waste it is critical that teams be allowed to self organize and operate in a manner that reflects the work they’re trying to accomplish.
5. Improve continuously. As a leader you want to promote a culture of continuous improvement, including the sharing of skills and knowledge between people and teams, within your organization. This is seen as a fundamental philosophy of agile – The 12th principle behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly” and both Improve and Reflect are principles of the Heart of Agile. A key technique that supports continuous improvement is “double-loop learning” that promotes the idea that you modify your approach based on what you learn from your experiences.
6. Experiment to learn. Probably the most significant impact of Eric Ries’ work in Lean Startup is the popularization of the experimentation mindset, the application of fundamental concepts of the scientific method to business. This mindset can be applied to process improvement following what Ries calls a validated learning strategy. From a process point of view, the strategy is to first identify an improvement hypothesis along the lines of “We think doing X will improve Y”. Second, run a short experiment by trying it out in a controlled manner, with measurements in place to see the effect of the change. Third, observe what happens to determine the efficacy of X and whether you need to evolve X and run a follow up experiment (double-loop learning). An experimentation mindset reinforces and often speeds up the strategy of continuous learning. As we pointed out earlier, to enable an experimentation mindset within your organization as a leader you must establish a safe environment where experimentation is encouraged and rewarded.
7. Measure what counts. When it comes to measurement, context counts. What are you hoping to improve? Quality? Time to market? Staff morale? Customer satisfaction? Combinations thereof? Every person, team, and organization has their own improvement priorities, and their own ways of working, so they will have their own set of measures that they gather to provide insight into how they’re doing and more importantly how to proceed. And these measures evolve over time as their situation and priorities evolve. The implication is that your measurement strategy must be flexible and fit for purpose, and it will vary across teams.
8. Prefer long-lived stable teams. A very common trend in the agile community is the movement away from projects, and the project management mindset in general, to long-lived teams. Such teams evolve over time, people occasionally join the team and people occasionally leave the team, but the team itself may run for years. For example, Microsoft has had a team developing and sustaining Microsoft Word since 1981 with no end in sight.  It’s important to note that this move away from project management in the agile community is not a move away from management but instead from the inherent risks and overhead of projects.

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

RELATED READING

• Principles Behind Disciplined Agile

Enterprise awareness is one of the key principles behind Disciplined Agile (DA).  The observation is that DA teams work within your organization’s enterprise ecosystem, as do all other teams.  There are often existing systems currently in production and minimally your solution shouldn’t impact them.  Better yet your solution will hopefully leverage existing functionality and data available in production.   You will often have other teams working in parallel to your team, and you may wish to take advantage of a portion of what they’re doing and vice versa.  Your organization may be working towards business or technical visions which your team should contribute to.  A governance strategy exists which hopefully enhances what your team is doing.

WHAT IT MEANS TO BE ENTERPRISE AWARE

Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you. Teams developing in isolation may choose to build something from scratch, or use different development tools, or create different data sources, when perfectly good ones that have been successfully installed, tested, configured, and fine-tuned already exist within the organization. Disciplined agile professionals will:

• Work closely with enterprise professionals. This includes working closely with enterprise technical architects and reuse engineers to leverage and enhance the existing and “to be” technical infrastructure; enterprise architects and portfolio managers to fit into the overall business ecosystem; senior managers who should be governing the various teams appropriately; operations staff to support your organization’s overall development and operations (DevOps) efforts; data administrators to access and improve existing data sources; IT development support people to understand and follow enterprise IT guidance; and business experts who share their market insights, sales forecasts, service forecasts, and other important concerns. In other words, teams should adopt a “whole enterprise” mindset.
• Adopt and follow enterprise guidance. Your organization may have, or hopes to one day have, a range of standards and guidelines (guidance) that it wants delivery teams to adopt and follow. This may include guidance for coding, user interface development, security, and data conventions to name a few. Following common guidance increases the consistency and maintainability of your solutions, and thus your overall quality.
• Leverage enterprise assets. There may be many enterprise assets, or at least there should be, which you can use and evolve. Disciplined agile teams strive to work to a common infrastructure; for example, they use the enterprise-approved technologies and data sources whenever possible, and better yet they work to the “to be” vision for your infrastructure. If your organization uses a disciplined architecture-centric approach to building enterprise software, there will be a growing library of service-based components to reuse and improve upon for the benefit of all current and future solutions. To do this DA teams will collaborate with enterprise professionals throughout the lifecycle and particularly during Inception during envisioning efforts. Figure 1 summarizes the Inception phase goal Align with Enterprise Direction which summarizes the strategies you may choose to follow. Read Disciplined Agilists Take a Goal-Driven Approach for more information on DA’s goal-driven strategy.

Figure 1. Inception Goal: Align with Enterprise Direction.

• Enhance your organizational ecosystem. The solution being delivered by a DA team should minimally fit into the existing organizational ecosystem – the business processes and systems supporting them – it should better yet enhance that ecosystem. To do this, the first step is to leverage existing enterprise assets wherever possible as described above, often working with enterprise architects or other enterprise professionals to do so. A Disciplined Agile Delivery (DAD) team, one that is focused on software development, will also work with operations and support staff closely throughout the lifecycle to ensure that they understand the current state and direction of the organizational ecosystem. DAD teams will often be supported by an additional independent test team that will perform production integration testing (amongst other things) to ensure that your solution works within the target production environment which it will face at deployment time. Furthermore, experienced DAD teams will even fix problems that they run into via proven refactoring techniques. Figure 2 summarizes the general goal Leverage and Enhance Existing Infrastructure which summarizes strategies for how DAD teams may accomplish this.

Figure 2. General Goal: Leverage and Enhance Existing Infrastructure.

• Adopt a DevOps Culture. DAD teams will work with operations and support staff closely throughout the lifecycle, particularly the closer you get to releasing into production. DevOps culture and strategies are baked right into DA.
• Share learnings. Disciplined Agile teams are learning oriented, and one way to learn is to hear about the experiences of others. The implication is that DA teams must also be prepared to share their own learnings with other teams. To do this organizations might choose to support agile discussion forums, informal presentations, training sessions delivered by senior team members, and internal conferences to name a few strategies.
• Adopt appropriate governance strategies. Effective governance strategies should enhance that which is being governed. An appropriate approach to governing agile delivery projects, and we suspect other types of efforts, is based on motivating and then enabling people to do what is right for your organization. What is right will of course vary, but this typically includes motivating teams to take advantage of, and to evolve, existing corporate assets following common guidelines to increase consistency, and working towards a shared vision for your organization. Appropriate governance is based on trust and collaboration. Appropriate governance strategies should enhance the ability of DA teams to deliver business value to their stakeholders in a cost effective and timely manner. Unfortunately many existing IT governance strategies are based on a command-and-control, bureaucratic approach which often proves ineffective in practice. Our book, Choose Your WoW!, explores appropriate governance, the impact of traditional governance strategies, and how to adopt an appropriate governance strategy in detail. The article Adopting Agile Governance Requires Discipline also provides greater insight.
• Open and honest monitoring. Although agile approaches are based on trust, smart governance strategies are based on a “trust but verify and then guide” mindset. An important aspect of appropriate governance is the monitoring of project teams through various means. One strategy is for anyone interested in the current status of a DA team to attend their daily coordination meeting and listen in, a strategy promoted by the Scrum community. Although it’s a great strategy we highly recommend, it unfortunately doesn’t scale very well because the senior managers responsible for governance are often busy people with many efforts to govern, not just your team. Hence the need for more sophisticated strategies such as an “development intelligence” approach supported via automated dashboards.

WHY IS ENTERPRISE AWARENESS IMPORTANT?

Agile has done a great job of helping the IT profession refocus from individual to team awareness. But if we want to be effective as professionals we at least need to promote the philosophy of enterprise awareness, so that we’re optimizing the work that we do for our organization. Agile teams that are enterprise aware will work closely with enterprise professionals, such as enterprise architects and operations staff, to ensure that they are leveraging and better yet enhancing the existing infrastructure. Their architectures will reflect their organization’s technical roadmap and similarly the scope of their effort will reflect their organization’s business roadmap. They will follow existing development guidelines and enhance them where appropriate.

By working in an enterprise aware manner DA teams enjoy:

• Higher levels of productivity because they are less likely to reinvent the wheel
• Quicker times to deployment/market because they have less work to do
• Higher return on investment (ROI) because they have less work to do
• Higher levels of quality through following common conventions and reuse

CHALLENGES TO ENTERPRISE AWARENESS

Unfortunately there are two main challenges to supporting enterprise awareness on agile teams. First is the cultural challenge within the agile community that some “agile purists” perceive this as unnecessary overhead. Reasons for this misunderstanding include a lack of understanding of the overall enterprise picture or some agilists who have previous experiences with enterprise professionals who struggle to work in an agile manner. This points to the second challenge that enterprise professionals often don’t understand how to work effectively with agile teams. Sometimes this is because the agile teams they’ve been working with until now haven’t been sufficiently disciplined to work with them effectively, but more often than not it’s because they still choose to follow older, more traditional approaches to their craft.  With Disciplined Agile we are actively working on describing an agile/lean workflow for enterprise IT.

These challenges are cultural in nature, and thus difficult to overcome. Agilists and enterprise professionals need to respect one another and strive to learn more about what the other group is trying to accomplish. They must strive to work with one another and thus learn from each other. Furthermore, they must build a culture of shared commitment and responsibility to the organization. Not only is this possible it is highly desirable.

SUMMARY

Disciplined agile teams and more importantly DA practitioners are enterprise aware. They recognize that enterprise aware strategies improve their ability to provide value to their stakeholders both within the scope of a solution as well as at the organizational level. To coin an environmental cliché: Disciplined agilists act locally and think globally.

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

RELATED READING

• Principles Behind Disciplined Agile