Brushing up on the principles of effective process frameworks

Like many enterprise agile frameworks, DA has its own set of guiding principles that are closely locked together (see Figure 6-1). These principles give you a high-level overview of what to expect when looking at the different process frameworks. Some these principles have a direct effect on each of the processes, while others are more high-level and aspirational:

• Delight customers: Successful organizations find new and better ways to delight their customers. Remember that customers are not as interested in your internal processes as they are in making sure their products are easier to use and add real value.
• Be awesome: Happy and well-functioning teams produce better products. Remember that part of the Agile Manifesto is “individuals and interactions over processes and tools.” Your organization should focus on improving the process by improving how people interact.
• Embrace pragmatism: DA sees itself as a pragmatic approach to enterprise agility. It discourages “agile purism.” Instead it encourages teams to make as many positive changes as practical within the organization. Teams shouldn’t focus on agile best practices, but look at the organization as a whole and see if it could benefit from a more agile mindset.
• Context counts: Organizations are unique; that’s why it’s difficult to have one set of prescriptive practices that will work in every enterprise. The DA framework tries to give you lots of different buttons and dials to press and twist to create a customized approach for your organization. That way you can adapt the approach to your context instead of relying on one standard set of practices.
• Choice is good, and making informed choices is better: Every organization, team, individual, and situation is unique, so DA supports several delivery frameworks and a number of agile and non-agile practices. That’s the “choice is good” part. The DA framework also provides insight to help you make the right choices for your organization and teams. That’s the “making informed choices is better” part.
• Optimize flow: Like most enterprise agile frameworks, DA emphasizes the importance of continuous improvement. You always want to look for ways to improve how work “flows” through the system, for example:
  • Deliver continuously at a sustainable pace: The team should be comfortable continuously delivering potentially shippable solutions instead of focusing on releases.
  • Optimize the whole: All individuals on an agile team should be aware that they’re working in a larger organization. That means that no matter how streamlined a team becomes, team members still need to think of how their work impacts other teams in the larger enterprise.
  • Make work flow: DA teams lean heavily on Kanban (see Chapter 8) as a way to manage their work in progress (WIP) and look for potential bottlenecks.
  • Eliminate waste: One of the best ways to improve is to eliminate waste in your process. (Waste is anything that doesn’t deliver value to the customer, including inefficiencies in processes.) When you simplify a process, it’s much easier to manage flow and find areas for improvement.
  • Improve continuously: A DA team should always look for ways to improve the process. This means taking time to learn from the team’s mistakes and being open about ways to improve.
  • Experiment to learn: This idea was popularized with Lean Startup. It’s also one of the core ideas behind Scrum’s empirical approach to delivering a product. Your team should have a scientific mindset, which encourages the team to run small process experiments. Don’t be afraid to make small changes and be transparent about the results.
  • Measure what counts: Establish early on what metrics you want to use to look for ways to improve. You may want to focus on on-time delivery, customer satisfaction, or the happiness of the team. Look for specific things to measure as the first step to improving your delivery.
  • Prefer long-lived stable teams: In most organizations it’s common to have temporary teams that are quickly assembled for one-off projects. A DA team is always working to become better optimized. The longer teams stay together, the more waste they’ll eliminate from their own process.
• Be enterprise aware: A well-run agile team can quickly deliver a high-value product. Yet these team efficiencies don’t necessarily scale to the rest of the enterprise. DA teams look for ways to improve the whole system. DA teams know that tuning your own race car doesn’t make the rest of the traffic run any smoother.

Exploring the DA process decision framework

DA is based on the premise that every organization, team, and individual is unique, so frameworks should offer choices, not prescribe solutions. It helps organizations ask the right questions, and for each question it provides a set of answers (solutions) from which to choose.

That’s much different from more prescriptive enterprise agile frameworks with clearly define processes, meetings, and roles. For example, the Scaled Agile Framework® (SAFe®) introduces the idea of the agile release train (ART), as explained in Chapter 4, and Large-Scale Scrum (LeSS) creates several new meanings for planning and conducting retrospectives (see Chapter 5). Disciplined Agile Delivery (DAD), on the other hand, doesn’t require specific meetings, and the roles involved are probably already in your organization.

DAD represents all the practices centered around enterprise agile product delivery, whereas DA casts a much wider net and is more attuned to business agility (see Figure 6-2). In addition to product delivery, DA covers marketing, sales, governance, legal, and human resources (HR). In this chapter, I discuss DAD, which focuses more narrowly on delivering enterprise products.

Think of the difference between DA and other enterprise agile frameworks in terms of baking a batch of chocolate chip cookies. A prescriptive framework such as SAFe (see Chapter 4) would provide a list of ingredients and step-by-step instructions. DA, on the other hand, would describe the size, texture, and flavor of the cookies and offer some general guidance, such as “all ingredients must be mixed in the right proportions, and the mixture divided and heated.” The pastry chef would then be free to choose the ingredients and quantities, decide how to mix them and how to divide the mixture, and figure out how to heat it to produce the desired final product.

Small- to medium-sized organizations may find the DA approach unsatisfying, but it may be the perfect fit for large organizations, where many different teams are trying out different agile ideas. Instead of telling people how to do their jobs, you set common goals and leave it up to the teams to decide how to meet them. You specify the what and let your agile teams address the how.

Unfortunately, giving people so many choices and then trying to educate them on how to make the best choices is often much more challenging than simply giving them a uniform process to follow. The sheer number of choices can boggle the mind.

DA can become agile quicksand in that the more you struggle, the deeper you get sucked into the framework. When starting with DA, take a very high-level view. Steer clear of the goals and milestones and focus on the higher-level processes — the DAD principles, primary roles, secondary roles, and the three-phase delivery lifecycle (see the later section, “Delivering in Lifecycles”).

Seeing DAD as a goal-driven, hybrid approach

DAD isn’t for micromanagers. It encourages you to identify the goals for a certain activity and then allow your teams to choose the best approach(es) for achieving each of those goals. In other words, it is a goal-driven, hybrid approach to enterprise agile:

• Goal driven: DAD lays out certain goals for you to meet to get value from any given process. For example, suppose you’re planning your project in inception phase (one of the three phases of the delivery lifecycle). You may have goals such as secure funding, form initial team, and explore the scope. DAD doesn’t tell you how to do these things; it just points out that they must be done.
• Hybrid: DAD is a hybrid approach in that it allows teams to choose various methods to achieve their goals. For example, a team can choose Scrum, Lean, Kanban, or some other approach or it can mix-and-match or develop a system of its own. As Ambler and Lines, the originators of the DA process decision framework, explain it, “methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DA the mortar to fit the bricks together effectively.”

Looking at DAD as a group of process blades

A blade server is a stripped-down version of a server computer with a modular design. The chassis of a blade server is an enclosure that provides physical space, along with services, such as power, cooling, and networking capabilities, that can be shared among the blades. Each blade is a server unto itself, complete with a processor, memory, storage, and so on that plugs into a slot in the chassis. Each blade has a specialized capability, such as file sharing, serving up web pages, or streaming audio and video content.

DA follows the blade server model through its use of process blades (see Figure 6-3). A process blade is a set of practices and strategies focused on a certain capability.

The latest version of DA has four groups of process blades:

• Disciplined Agile Delivery (DAD): The area that focuses on product delivery.

  Earlier versions of DA called the entire framework “Disciplined Agile Delivery (DAD).” The current version makes DAD a group within the larger framework called DA. That being said, most of the good stuff is still focused on delivery.

• Disciplined Agile DevOps: The area of intersection between development, operations, and quality assurance. This process blade group contains:
  • Release management
  • Operations, support
  • Data management
• Disciplined Agile IT (DAIT): The area that involves the application of agile and Lean strategies to all aspects of information technology (IT) practices, including IT operations, support, data management, reuse engineering, and other capabilities. This process blade group looks like a standard IT department process map:
  • Product management
  • Portfolio management
  • Enterprise architecture
  • IT governance
• Disciplined Agile Enterprise (DAE): The area where DA starts to bleed into business agility. It’s about taking the agile mindset and applying it to all the other areas in the organization (see Figure 6-4):
  • People must be agile
  • Optimize your value streams
  • Don’t focus solely on practices
  • Sense, respond, learn, and adapt

Each of these four process blade groups contains a set of “blade” processes. Confusingly, you can have processing blade groups within other process blade groups. Notice that the Disciplined Agile IT (DAIT) process blade group is within the Discipline Agile Enterprise (DAE) process blade group.

DA doesn’t try to reinvent the wheel. In terms of DAD, the emphasis is on making your solution delivery teams more enterprise aware, so the enterprise functions as a well-oiled machine (or a highly efficient blade server). DA is less about organizational change and more about teams building on and adding value to what’s already there.

DA gives you the option of fitting agile into your organization without making lasting changes, using the framework to effect radical change across the organization, or, when agile doesn’t fit, sticking with what you have.

Consider your organization’s existing culture (see Chapter 9). If your organization has a difficult time accepting even modest changes, then DA may be the best way to gain some benefits of an agile mindset. If your organization is more flexible, then don’t worry so much about “enterprise awareness” and instead spend more time driving widespread organizational change using some other agile framework.

Because the focus of this chapter is on DAD, consider how this works in DAD. You have a process blade called DAD that can hold several delivery lifecycles:

• Agile/Basic
• Lean/Advanced
• Continuous Delivery Agile
• Continuous Delivery Lean
• Exploratory (Lean Startup)
• Waterfall

Your organization can plug any or all of these lifecycles into the DAD process blade. One team may decide Agile is best, another may choose Lean. Your organization can choose to run everything with only one or two delivery lifecycles or use all six.

Of course, the challenge with DA’s approach is that organizations rarely function like data centers. While the concept is likely to click with employees in technology, people in other departments, such as HR, are likely to have trouble wrapping their brains around the concept of a Disciplined Agile Enterprise (DAE) process blade group. I can’t imagine an HR manager describing her department as a “people management process between the DAIT and the DAE process blade group.”

If your organization has blade-server data centers and is already using RUP, then DA makes sense. No doubt this is one of the big selling points for many large organizations. However, if the people in your organization aren’t familiar with the concept of blade servers and RUP and the language surrounding these concepts (primarily from IBM), the transition can take quite a bit of time and generate a great deal of confusion.

Navigating the three-phase delivery lifecycle

With basic understanding of the three-phase delivery lifecycle and the various roles involved, you’re better prepared to understand how the delivery lifecycle works. You’re also better prepared to start adopting DAD in your organization.

In this section, I lead you through the three-phase delivery process from inception to transition.

Choosing a DAD delivery lifecycle

DAD has a number of delivery lifecycles, and the list continues to grow. At last count, the number was up to six. All of these alternative lifecycles have three phases, and they have similar goals and milestones. The big difference is how much time they spend in each one of these phases. Here are the six current delivery lifecycles:

• Agile/Basic: The Agile/Basic lifecycle is an extension of Scrum’s construction lifecycle, and it’s a good one to start with because it’s the most prescriptive of the bunch and facilitates the transition from Scrum or RUP to DAD. It may also be the best lifecycle to start with if your teams are new to agile. Agile/Basic
  • Is more detailed than Scrum, XP, and Kanban.
  • Is iteration based.
  • Uses non-Scrum terminology (Scrum rebranded).
  • Includes inputs from outside the delivery lifecycle.
  • Uses a work item list as opposed to a product backlog.
  • Includes more specific milestones than Scrum, XP, and Kanban.
• Lean/Advanced: This lifecycle embraces Lean principles, including maximizing workflow, reducing bottlenecks, and minimizing waste. Work is pulled through the process when teams have the capacity to do it. It’s a good choice if you need to get your product to market fast and your teams are highly skilled and disciplined. It’s also a good choice when you’re working on projects that have quickly evolving requirements. The Lean/Advanced lifecycle
  • Supports continuous flow.
  • Enables teams to work at their own pace.
  • Uses a work item pool instead of a backlog.
• Continuous Delivery Agile: Agile/Basic is intended to evolve toward this Continuous Delivery Agile lifecycle, which results in a consumable product at the end of each iteration rather than after a set of iterations. The inception phase is nonexistent, the construction phase is long, and the transition phase is significantly compressed. In other words, it’s more like the agile we know and love. This lifecycle is a good choice if you need to get your product to market fast and you have highly skilled teams that have been working together for some time. It requires automated testing, integration, and deployment.
• Continuous Delivery Lean: Like Continuous Delivery Agile, Continuous Delivery Lean is meant for teams that have developed a mature set of practices around continuous integration and deployment. Its focus is on maximizing workflow, reducing bottlenecks, and minimizing waste. It has no inception phase, an expanded construction phase, and a compressed transition phase. This lifecycle is a good choice if you need to get your product to market quickly and you have highly skilled teams that have been working together for some time. It requires automated testing, integration, and deployment.
• Exploratory (Lean Startup): The Exploratory (Lean Startup) lifecycle is ideal for nailing down what a customer needs by conducting quick learning experiments. You can use this lifecycle to enhance or replace the inception phase or within the construction phase to clarify a feature or capability. With this lifecycle, a team engages in a continuous cycle of envision, build a little, deploy, and test until the team is satisfied with the result.
• Waterfall: This lifecycle is suitable for experienced IT professionals who aren’t yet comfortable with the agile approach. It’s slow and tends to carry a high risk due to long feedback cycles and delivery at the end of the lifecycle. Use it only in low-risk situations in which the vision is clear, the requirements are stable, and you don’t need to deliver a solution quickly. The Waterfall lifecycle is a linear eight-step process divided into two stages:

  Decomposition and Definition

  1. Requirements
  2. Architecture
  3. Design
  4. Construction

  Integration and Validation

  5. Unit test
  6. Function test
  7. Integration test
  8. Acceptance test

Striving to become enterprise aware and to consider the risk-value lifecycle

DA emphasizes the importance of being enterprise aware, which aligns with the principle of “Optimize the whole.” In some ways, the emphasis on enterprise awareness is an implied criticism of how agile teams tend to function in a large organization. DAD sees these teams as trying to create their own set of processes without considering the teams’ responsibilities to the larger enterprise. From DAD’s perspective, it’s fine if your agile teams deliver every two weeks, but that doesn’t offer much value to the enterprise if it’s not how the rest of the organization deploys its products.

Another implied criticism of many agile frameworks is DAD’s shift from the value lifecycle to the risk-value lifecycle. Instead of simply adding work items to a backlog and relying on iterative development to work out the imperfections, DAD insists on planning ahead to reduce the risks, such as unaligned stakeholders, inappropriate architecture, building the wrong thing, and insufficient functionality. The idea is that by identifying risks early on, you’re more likely to reduce delays and to deliver higher quality products.

Governing the lifecycle with milestones

While most agile methods deplore any hint of management planning and oversight and encourage teams to self-govern, DAD introduces a light amount of governance in the form of milestones that serve more like checkpoints to ensure that everyone involved stays on track. Milestones are placed at various points along the delivery lifecycle. DAD uses the following milestones:

• Stakeholder vision: At the end of the inception phase, you should have a vision statement that describes the agreed upon stakeholder vision for the product.
• Proven architecture: Having a proven architecture early in the construction phase helps to mitigate risk. The team’s architecture owner (described in the next section) is encouraged to identify risks in the inception phase and make sure these risks have been reduced or eliminated by implementing related functionality between one and three iterations into the construction phase.
• Project viability: Project viability milestones give stakeholders an opportunity to check progress during the construction phase, ensure that the project’s progression aligns with the stakeholder vision agreed to in the inception phase, and discuss possible changes with the agile teams. Project viability milestones are optional.

• Sufficient functionality: Sufficient functionality means that the product has the minimum feature set to satisfy the stakeholder needs. This milestone comes at the end of the construction phase. It is similar to what Scrum refers to as a “potentially shippable product increment,” but is more like what some agile teams refer to as a minimum viable product (MVP).

  This milestone is reached only when functionality is sufficient to meet the cost of transitioning the release to stakeholders. So, while a product may be viable after a two-week iteration, it may not have sufficient functionality to justify the cost of deploying it in a high-compliance environment.

• Production ready: During the construction phase, other activities must be conducted and completed as part of the final preparation to deliver the solution to stakeholders, such as final acceptance testing, data conversions, and documentation. Near the end of the transition phase, everything required for the solution to be delivered to stakeholders must come together to make the solution production-ready.
• Delighted stakeholders: The delivery cycle extends beyond the transition phase before a project can be considered completed and the team can begin on another release. These post-transition phase activities include training, deployment tuning, support, reviews, and warranty periods. The project isn’t considered complete until stakeholders feel delighted.

Meeting the lead actors: Primary roles

Five roles play a part in the delivery lifecycle: stakeholder, product owner, team members, team lead, and architecture owner. Here, I introduce you to these key players.

The team lead, team members, and architecture owner form the core of your agile team. When assembling a team, make sure each person has the qualifications required for the given role and that all members of the team are a good fit.

Many of the primary roles are influenced by both agile and traditional project management. For example, having a team lead aligns with traditional project management practices, but the team lead in DAD doesn’t exactly serve a traditional management role; the team lead doesn’t assign or supervise the work. Instead, this individual sets the direction and motivates and supports the team, serving a role that pure agile advocates may find more acceptable.

Stepping behind the scenes with the supporting cast: Secondary roles

Secondary roles come into play on an as-needed basis; for example, if a team needs expertise in a certain area that nobody on the team has, the team calls in a specialist. If the team is required to build a product that meets a certain compliance requirement that it doesn’t have the testing expertise to validate, it calls in an independent tester who’s capable of providing that service.

At the team level, these are temporary roles. A person pops in to do a specific type of work or to offer specialized knowledge or insight and then leaves the team. Because they’re temporary, they’re referred to as “secondary.”

Don’t think of these secondary roles as job titles. Think of them more as consultants or service providers. When they’re not serving a secondary role, they may work on another team or outside of the teams. They jump in when needed to provide a service and then go back to their usual jobs.

Try your best to reduce the need for secondary roles over time by having these specialized personnel educate and train your teams. Otherwise, the organization will end up doing what it has been doing and how it has been doing it all along only perhaps less efficiently.

Deciding whether DA is worth the trouble

If your organization is already following RUP, you will have an easier time transitioning to DA. For organizations unfamiliar with RUP, DA might not add enough value to justify the learning and aggravation that will, with great certainty, accompany the transition. By starting with DA from scratch, you would encounter a learning curve so steep and ideas so abstract that all individuals in your organization would spend most of their time scribbling notes in training sessions and then scratching their heads later, trying to make actionable sense of it all.

There’s an old joke about a writer who sent a letter to a friend that ended, “Sorry this letter is so long. I didn’t have time to make it shorter.” I get the same feeling when I write about DA. I keep thinking, “If only they had taken the time to strip down this framework, it could have been more useful.” Including a milestone that’s useful for only about 5 percent of adopters and irrelevant to the other 95 percent strikes me as undisciplined and impractical. Sometimes, it feels that the developers were just throwing agile processes in their cart like happy gift-card holders at a shopping mall.

Appreciating the value in simplicity

• Learning to choose is hard. Learning to choose well is harder. And learning to choose well in a world of unlimited possibilities is harder still, perhaps too hard.
• ―Barry Schwartz, The Paradox of Choice: Why More Is Less

The developers of DA argue that enterprise agile is complicated so the decision framework needs to be complicated as well. That to be an effective process decision framework you have to see all your options. However, such a perspective discounts the value in simplicity. It’s a little like that old Albert Einstein quote: “If you can’t explain it simply, you don’t understand it well enough.” Enterprise products are complicated, but it’s not theoretical physics. A large organization should look to an enterprise agile framework to help identify the best ideas and methods and not just provide an endless supply of options.

The very first language around the Agile Manifesto was about creating a “lightweight” framework for product delivery. The developers of DA would argue that “lightweight” doesn’t scale well for enterprise products. That may be true, but then you have to question whether the DA framework still fits the common interpretation of agile software development.

DA presents a number of interesting ideas, and it may be a great framework for delivering enterprise products, but whether it encourages an enterprise agile mindset is open for debate.

I have little doubt that many organizations are trying something similar to DA. They may not call it DA, but their transition from a top-down approach to agile probably mirrors the DA framework. DA would be far more valuable if it helped these large organizations pare down their choices instead of providing them with more.