Disciplined Agile

Process Blades

A process blade encompasses a cohesive part of your overall organizational way of working (WoW). Each process blade addresses a specific organizational capability, such as Data Management, Continuous Improvement, or Vendor Management. Process blades are sometimes called process areas, key process areas (KPAs), or business functions.

This page is organized into the following topics:

Process blades are represented as hexes in the Disciplined Agile (DA) tool kit, overviewed in Figure 1. The blades appear in the top three layers: Disciplined DevOps, Value Streams, Disciplined Agile Enterprise (DAE). There is a fourth layer, Foundation, which captures non-blade aspects of DA.

The Disciplined Agile Process Blades

Process blades are represented as hexes in the Disciplined Agile (DA) tool kit, overviewed in Figure 1. The blades appear in the top three layers: Disciplined DevOps, Value Streams, Disciplined Agile Enterprise (DAE). There is a fourth layer, Foundation, which captures non-blade aspects of DA.

Onion diagram of the Disciplined Agile tool kit

Figure 1. The Disciplined Agile (DA) tool kit (click to enlarge) 

The Scope of a Process Blade

The scope of a process blade is a business function, such as Finance, Asset Management, or Data Management. Each of these functions have deep histories, going back decades and in some cases centuries, in many cases comprehensive bodies of knowledge and industry associations supporting them. We’re not trying to repeat that good work.

The aim of a process blade is to:

  1. Provide an overview for people unfamiliar with the topic. We often find that we need to collaborate with people who have fill different roles, yet we may know little about their job function. The process blade descriptions provide an overview of a given business function, why it’s important, how it fits in to the overall organization, and what it focuses on. You can quickly gain a better understanding of another group within your organization as a result.
  2. Provide a range of options for experienced practitioners. The agile and lean communities have been developing new ways of working in a very wide range of areas for years. Experienced practitioners may not know of these new techniques, nor realize how their existing strategies can be modified for agile teams. The process goal diagram for each blade provides a quick reference to new and old techniques, pointing the way to improvement opportunities.
  3. Provide a starting point for a Disciplined Agile way of working (WoW). Each blade is described in terms of mindset, flow, people (roles), and practices, providing a basis from which to start improving an existing business function or to initiate one if you don’t already have it.
  4. Put the blade into context. Your organization is a complex adaptive system (CAS) of interacting people and teams. Teams within your organization will provide supporting capabilities to others. For example, finance professionals will collaborate with vendor management people, solution delivery practitioners, legal professionals, and many others. What services, what help, will they provide?  How will they do so? A process blade will put these potential interactions into context.
  5. Point you to more detailed sources. While the content of a blade doesn’t go deep, DA provides references to quality sources where you can learn more if you so desire.
  6. Enable people to improve cross-team ways of working (WoW). Having a better understanding about what another team does and what their priorities are enables you to have better conversations with them as to how you’re going to work together. Disciplined Agile Coaches (DACs) and Disciplined Agile Value Stream Consultants (DAVSCs) focus on helping teams improve their collaborations with other disparate teams. 

Process Blades and the Architectural Views

Each process blade addresses the four architectural views:

  1. Mindset. Each process blade extends the principles, promises, and guidelines of the Disciplined Agile (DA) mindset with philosophies that are specific to that blade. For example, the Sales process blade explores concepts that are specific to being successful at selling.
  2. People. Each process blade addresses specialist roles, and sometimes potential team structures, which are specific to that blade. For example, the Sales process blade includes specialist roles such as Sales Manager, Salesperson, and Sales Support Engineer.
  3. Flow. Each process blade describes the business process, or business flow, that is a common starting point for organizations new to agile WoW in that area.
  4. Practices. DA provides a collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner. These process options are overviewed by process goal diagrams.

Why “Process Blade”? 

Given our philosophies around terminology, in particular our preference for existing terminology, it is admittedly strange that we created a new term rather than stick with something like key process area (KPA), process area, or business function. There are several reasons why we believe these existing terms are insufficient for DA:

  1. Scope. A process blade addresses all four architectural views - mindset, people, flow, and practices - whereas that isn’t always true of how the existing terms are usually addressed. Basically, terms like KPA tend to imply a connotation that isn’t sufficient for our needs.
  2. Cohesion. You can think of a process blade as a cohesive slice of way of working (WoW), that addresses a specific part of your organizational process.
  3. Straightforward updates. Our original thinking was that we wanted to get across the idea that a blade could be updated or even replaced, just like a server blade in your operational infrastructure. As the situation that a team faces evolves, it should be possible for the team to update their configuration of a process blade, or even replace it entirely, with little or no impact to the teams around them.