Disciplined Agile

We used to say that software is eating the world, but the fact is today software is the world. Gone are the days where IT could be treated like a utility, one that more often than not was outsourced in the belief that you needed to focus on your core competencies and IT didn’t make it onto that list. These days being competent at IT is mere table stakes at best, you need to excel at IT if you hope to become an industry leader. Today business executives must focus on disruptors, new competitors entering their market space using technologies in new ways. Becoming an agile business – an adaptive, responsive, and learning organization – is the true goal. Business agility requires true agility across all of your organization, not just software development, not just DevOps, and not just IT. There isn’t a single industry now that either isn’t dominated by agile businesses or isn’t under threat of disruption by new agile competitors.   

The Disciplined Agile (DA) tool kit was created to apply agile in complex enterprise agile implementations. DA has been well received and implemented in organizations around the world. According to Gartner, Disciplined Agile is also the only available agile process explicitly allowing enterprises to customise agile for their unique enterprise challenges at both the organization and project levels.  In their research report, Adopt Disciplined Agile Delivery for a Comprehensive and Scalable Agile IT Approach, Gartner reported: 

“Success with agile development is important, but comes in different forms across enterprises. Technical professionals responsible for application development can use Disciplined Agile Delivery to tune agile processes and practices, including SAFe, to their specific needs."

In this article, we address several common questions executives have about Disciplined Agile (DA):

1. What is DA?
2. Why should I consider DA?
3. Where is DA being used?
4. Are there any DA success stories?
5. How can we get started?

What is Disciplined Agile (DA)?

The Disciplined Agile (DA) tool kit provides straightforward guidance to help organizations streamline their processes in a context-sensitive manner, providing a solid foundation for business agility. The figure below provides a high-level overview of the scope of DA (click on the diagram to zoom in).

DA provides a foundation for business agility does this by showing how the various activities such as Finance, Portfolio Management, Solution Delivery (software development), IT Operations, Enterprise Architecture, Vendor Management and many others work together. DA also describes what these activities should address, provides a range of options for doing so, and describes the trade-offs associated with each option.

DA also provides a straightforward strategy for implementing value streams, overviewed in the following diagram (click on it to zoom in).

You can read more about DA in Introduction to Disciplined Agile.

Why should I consider Disciplined Agile (DA)?

There are several reasons why your organization should adopt the Disciplined Agile (DA) tool kit:

1. DA enables you to become a learning organization. Rather than helping you to adopt the “best practices” of a specific agile framework, the DA tool kit instead gives your team the tools they need to learn and to improve their ways of working (WoW). 
2. DA enables you to increase your rate of process improvement. The DA tool kit provides straightforward guidance for identifying potential improvements that are likely to work in the context that you face, enabling your teams to reduce the number of failed experiments and thereby increase their rate of improvement.
3. DA supports the entire range of complexities faced by your teams, not just team size. Every person, every team, and every organization is unique. The implication is that you need a tool kit that provides you with choices so that you can tailor, and later evolve, an approach to address the situation that you face in practice. 
4. DA is agnostic and hybrid. DA adopts pragmatic techniques from a wide range of sources – agile sources, lean sources, and even traditional sources – and does the work of putting them into context so that you don’t have to. 
5. Support all types of teams, not just software teams. As you saw earlier, there are over twenty process blades/areas within the DA tool kit. Only one of them, Disciplined Agile Delivery (DAD), is focused on software development teams.  
6. Consistent governance across disparate teams. Luckily, it’s not only possible but highly desirable to have a light-weight, lean governance strategy in place. In fact, the DA tool kit builds lean governance strategies into most process blades and has an overarching, enterprise-level process blade called Governance. 
7. DA is the foundation for business agility. We’ve been talking about teams a lot, but it’s not just about teams. It’s really about how your organization can become more competitive, how it can regularly delight your customers, and how it can continue to evolve and improve over time. It’s really about business agility, and the DA tool kit shows how it all fits together.

You can read more about why you should consider DA at Why Disciplined Agile?

Where is Disciplined Agile (DA) being used?

DA is being used in numerous organizations, in a wide range of industries, around the world.  You can see a list of a subset of the organizations using Disciplined Agile.

Are there any Disciplined Agile (DA) success stories?

Yes. We have published several Disciplined Agile success stories with more on the way.

How can we get started with Disciplined Agile (DA)?

The answer to this question depends on what you're trying to achieve:

• Getting personally started 
• Getting a team started
• Getting your organization started 

Getting personally started with Disciplined Agile

There are several ways that you can learn more about DA, and we recommend following the one(s) that seem best for you:

1. Online reading. If you want to start with some online reading, then our Start Here article is a great option.
2. Online eLearning. If you prefer eLearning options, our Basics of DA online course is a nice overview to get you going.
3. Read a book. If you're looking for a quick read, the Introduction to Disciplined Agile Delivery 2nd Edition is it.  If you'd like a more in-depth understanding of the tool kit, then Choose Your WoW! is recommend (and it's free to PMI members). 
4. Take some training. We have a variety of instructor led training (ILT) as well as online learning options to choose from, which are important parts of an agile certification journey.

Getting a team started with Disciplined Agile

There are also several options for getting a team going with Disciplined Agile, we recommend considering all three:

1. Get a few individuals started with DA.  The easiest strategy would be to point them to the options for individuals above. Your goal is to have several people be sufficiently informed about DA so that you can determine if it's right for you.
2. Get some training. PMI's agile certification journey includes training options for all team members at all levels of agile expertise. 
3. Hire one or more Disciplined Agile Coach (DAC) or Disciplined Agile Value Stream Consultant (DAVSC). DACs can help you learn how to apply the DA tool kit with teams and across teams to improve their effectiveness.  DAVSCs help you to streamline your value streams so as to enable you to effectively delight your customers.  You can search for people who have earned their DAC accreditation here.

Getting your organization started with Disciplined Agile

Our fundamental advice is to start where you are, do the best that you can given the situation that you face, and always strive to get better.  To succeed, there are three key concepts to understand:

1. Context counts. Your strategy to get started will vary based on your context - an organization that is new to agile will take a different path than one that has already (mis)adopted an agile framework.  An organization that has successfully adopted agile within their IT department and is now focusing on other parts of their organization will need a different strategy than one that is focusing on the entire organization at once.  As you can see in the following diagram, there are multiple paths that you can take to become a learning organization.
2. The goal is to become a learning organization. Many organizations hope that adopting an agile framework such as Scrum or SAFe is what they need to do. That may be a good start, but it isn't your real end goal, instead you want to become a learning organization that is capable of evolving and improving beyond the confines of an agile framework/method. When you successfully adopt a framework, you typically find that the framework doesn't address all of the situations that you face. Nor do frameworks offer more than platitudes about how to evolve your WoW beyond what they prescribe, The aim of the DA tool kit is to teach you how to improve effectively, not prescribe one set of "best practices."
3. There is no quick, easy fix. Improvement is a life-long journey, not a short-term project. To become a learning organization you must adopt a mindset and some tools that enable your people to experiment, learn, and improve.

Although every organization's journey is unique, we have found that at a high-level they all follow a similar 3-step transformation path:

1. Align. Fundamentally, you always start where you are. Because every organization is different, you must assess your situation, identify your challenges that you need to overcome, and then select an appropriate improvement path and strategy to journey on that path.
2. Improve. Follow an improvement strategy that is fit-for-purpose, tailored to address the challenges that your organization faces.  This strategy will evolve over time as challenges are overcome and new challenges appear. The DA strategy is to improve in place, addressing your immediate needs while teaching you the skills and providing the tools to help you evolve into a true learning organization.
3. Thrive. You will thrive when you've become a learning organization, one that is able to learn from and evolve with their changing environment. One that is focused on improving their way of working (WoW) so that they delight their customers.

By Jeev Chugh, CDAP | CDAI and Joshua Barnes CDAC | CDAI

Enterprise agile transformation roadmaps using Lean Change are often fueled by the desire to deliver value faster with increased flexibility.  They start with replacing traditional (waterfall) delivery methods with an Agile way of working, using pilot teams to validate early decisions on how to experiment with aspects such as team formation, lifecycle (agile, lean, continuous delivery, etc.) practices and techniques, and so on.  What team members and business and technology leaders alike quickly glean is that the mind shift to collective ownership of the work, decentralized decision making, and all the energy to shift to self-organizing teams is just the first step.  A big step, but one in a long journey.

To truly achieve the sizable outcomes from these enterprise transformations, many aspects beyond that of individual agile teams achieving a good level of maturity in “their” agile ways of working are needed.  One of the shifts that enables such outcomes is adopting a Product Portfolio operating model.  In this model, we transition from assembling a team to deliver a fixed scope via a project and then disband as the project ends to a long-lasting stable team delivering business outcomes via continual improvement of a product.

Along with this change comes the realization that traditional waterfall methods of budgeting and project cost accounting that requires upfront plans and budgets, is in inherent conflict with Agile ways of working; especially so when the agile approach uses a Lean Kanban-based lifecycle (very small batches) or Lean Continuous Delivery (no batches) lifecycle. Thus, to successfully scale Agile, enterprises must work with business and Finance partners to move beyond traditional project-centric funding models and adopt a product-centric funding model that enables rolling-wave planning, dynamic resource allocation, and accelerated delivery.  Moving from funding project scope to funding teams is a seminal part of product centric funding.

However, a clear understanding and alignment on “Product” and “Product Portfolio” terminology is imperative before delving into the product-based funding model and financial governance.  It is often surprising to agile team members through all levels of leadership how hard it can be to all agree on what a “product” is.  We often start by getting an agreement on what a product isn’t, such as a platform or other part of the technology stack or a corporate function such as marketing.

What is a Product?

A product is designed to continuously create business value for the customer by solving their problem or providing a benefit. Products have more permanence, and are living entities that we continuously iterate to meet market needs and finally are retired when the demand for it diminishes.

On the other hand, a project is a temporary endeavor, with a clear definition of the work that needs to be delivered, within a defined budget and by a specified date in time.

Key characteristics of a Product and a Project are elaborated below:

So, what are the benefits of pivoting to a product mode?

High Performing Teams

Standing Projects up and down is Inefficient and runs the risk of disbanding teams just as they enter the norming or performing phase. Organizations often underestimate the staff onboarding costs and ramp up time. Most product-centric organizations try to keep the same people working on a product through the lifespan of the product. Overtime, these teams build the stakeholder relationships and business domain knowledge, being stable and long-lived can benefit from a long performing phase.

Maintain Strategic Focus

Projects are funded independently and investments tend to be quite scattered and fragmented. Often, this leads to executives not having enough confidence that much of their investments are committed to top strategic priorities. Moreover, it really slows the organization’s response to change in business priorities.

Product Roadmaps are aligned with business capabilities and deliver measurable business outcomes. Further, funding is continuous with frequent checkpoints, allowing to dynamically reposition investments should the business priorities change

Ability to Truly Iterate

Projects are funded in one go, the entire agreed upon scope is funded to deliver the projected benefits. These un-validated hypotheses of benefits in the business case are based on a lot of assumptions, and it is often not feasible to clarify the entire scope upfront, despite the significant investment routinely made with traditional approaches. The reality is that many projects regularly miss the mark in terms of delivering benefits, and organizations often don’t have an effective process in place to validate actual benefits post every release.

On the other hand, product funding is continuous and flow based on validated learning of short timelines. This is a truly iterative approach that allows to pivot or preserve strategy to maximize the value delivery.

Customer focused

Project teams measure success as the delivery of agreed up-front scope, on time and in budget. This often means that they get too solution focused and lose sight of whether appropriate value is being delivered to the stakeholders. There is no point in delivering the entire upfront agreed scope if it doesn’t cater to the stakeholder needs anymore.

We all work to create value for our stakeholders as well as the organization. Business outcomes allow us to define value in a measurable way, thus focusing on what matters most from the customer perspective. For product teams, success equals improvement directly related to a business outcome. Hence, rather than seeing their job as delivering a task, product teams focus on delighting and adding value for their customers (internal or external).

Knowledge Retention

Project teams ramp up quickly to build a solution over one or more releases, hand it over to an operations team in the “run” organization and are then disbanded, and the members move on to other project teams. With project teams being continually dragged onto new things, it gets very difficult to retain knowledge in legacy systems and often results in unmaintainable code, making it much harder to support such systems.

On the other hand, knowledge grows in product teams that allows team members to focus on a given business area for much longer. Overtime, these teams build strong stakeholder relationships and business domain knowledge, and can better understand the stakeholder problems and serve to their needs.

System Integrity and Continuous Improvement

Project teams are in constant pressure to deliver the agreed scope in defined timelines. This often leads to cutting corners and applying tactical fixes, increasing technical debt and neglecting long term architectural integrity in favor of short-term feature delivery. As the project team doesn’t face the long-term consequences of these tradeoffs, they are more likely to take such decisions for short-term gain. Over a period, this phenomenon compromises stability of systems, lowering quality and worsens the seed of value delivery.

On the other hand, Product teams have complete and collective ownership of the code and systems. There are no handovers, BAU or Operations team. The same team builds, runs and fixes any defects over the lifespan of the product, allowing them to evolve the system continuously and in a more sustainable manner.  This also fosters a mindset that promotes taking responsibility for their product and the decisions they are empowered to make.

Making the shift to a Product Centric Organization Model

According to a recent Gartner survey, 85% of the organizations have adopted or plans to adopt a product-centric organization model.

To enable accelerated value delivery, adaptive planning, and flexibility required to achieve the digital priorities, many organizations are shifting towards a product centric model. In a product centric model, organizations align funding & resources to product portfolios that support their key business capabilities.

A business capability is the ability of an organization to do things effectively to achieve desired business outcomes and measurable benefits. Each business capability is independent from other business capabilities and realized by combining different functions of an organization to fulfil one functionality. Example, for an FMCG, key business capabilities are often: Direct to Consumer, Wholesale and Retail.

The key primary constructs of translating Enterprise Strategy into traceable User Stories, via Features and Business Outcomes are:

• A Product Portfolio, also known as a Product Line, solely exists to fulfill its contribution toward realizing the overall enterprise strategy. Each Product line is tied to a distinct business capability with end to end accountability to deliver measurable business outcomes.

• The Portfolio Management board allocates funding across each of the Product Lines based on the importance of the business capabilities they support and the business outcomes they are expected to deliver. The Product Line budget is then split into individual product streams by the Product Line Council, which is then further split into individual feature teams by the Product Council.

• The business outcomes communicate aspects of strategic intent from the enterprise to the product line. Business outcomes are a means of concisely capturing business needs in a measurable way. Business outcomes most often require product functionality as well as supporting business activities (sales, marketing, promotions, delivery chain, etc.). The product teams work with leadership to establish measurable product outcomes tied to those business outcomes, which are then further split into Key Performance Indicators (KPIs) for each Product Feature team, who will then breakdown those features into user stories, establishing a clear line of sight from enterprise strategy to user stories.

Adaptive Funding of Products and Product Portfolios: From Annual to Quarterly Cycle

Organizing work by Products and Product Portfolios is a good starting point to accelerate the delivery of value to one’s customers. However, that enough won’t suffice if the work is still funded through projects on an annual basis.

An annual investment process simply can’t keep up with the pace of change. Under an annual planning approach, entire funding is allocated at the start of the fiscal year. Significant effort is spent upfront to create a detailed business case required to win the funding approval. Changes in stakeholder priorities or market demand often render a lot of early requirements captured in the business case as obsolete, creating a lot of waste and requiring significant rework.

Thus, to achieve their digital ambitions, enterprises must work with business and Finance partners to move beyond traditional project-centric funding models and adopt a product-centric funding model that enables rolling-wave planning, accelerated delivery of value, and validated learning to make much more informed decisions.  Moving from funding project scope to funding teams is a seminal part of product centric funding.

(Re)allocation of Funds across Product Portfolios

Initial annual funding allocations to individual product portfolios are based on un-validated hypothesis of benefits, which must be tested over the course of the year against changing priorities and proven value. The Portfolio Management Board meets on a recurring basis (Quarterly plus any market triggered event) to assess the allocation at the product-line level and reallocating funds as necessary to reflect changes to strategic enterprise priorities.

(Re)allocation of Funds within a Product Portfolio

The Product Line Council has the autonomy and the empowerment to reprioritize and reallocate funds across all products within the product line.  Each product team within a product line are allocated funds on a quarterly basis based on proven value (unless it’s the first quarter where funding is based on projected benefits). The business value is measured by hitting a set of KPIs tied to the business outcomes such as increasing revenues, reducing costs, and improving customer satisfaction. This level of decentralization in decision making is possible when an organization implements a consistent, standardized and predictable cadence to support governance, offering frequent opportunities for key stakeholders to provide input on the roadmap.

Impediments to adopt Product-based Funding Model

The shift from a project-based funding model to a product-based funding model requires a major cultural and mindset change, as different stakeholders will have different reservations about the new approach. Some of the challenges to adopt a product-based funding model include:

Business & Finance partners reluctant to cede control of budgets

Some CFOs and business leaders are reluctant to cede control of budgets. In response, they must be made to understand that the reality is that they are gaining a lot more control by not allocating the entire funding based on the un-validated hypothesis of projected benefits and with no benefits tracking in place most cases. Also, by offering them visibility into product portfolio performance on quarterly basis with the option to pivot or preserve funding strategy based on proven value and/or change in priorities, we can significantly reduce the risk of financial loss.

Product Managers lacking finance expertise to manage product budgets

Identifying Product Managers with sufficient expertise to manage large budgets is often challenging and requires significant effort and commitment from the organization to build the financial competencies.

Resistance to funding not” fully detailed” requirements or outcomes

Business partners feel a comfort factor with a detailed business case based on projected benefits, even if it is based on a lot of assumptions and uncertainty upfront. To get business partners fully on board, product leaders need to craft a pitch that provides tangible examples of how adaptive funding model leads to better business outcomes.

Requires structural changes to support product-centric organization

Most companies we work with are organized around functions. Organizational structure change is required to adopt a product-centric operation model. Organizations are reluctant to Org design changes as it can be very difficult and expensive to implement.

Parting Thoughts

We have endeavored to shed some light on a very complex topic, balancing the amount of context we can provide in a blog entry.  If you have any questions please do use the comments section below.

Joshua Barnes, CDAC | CDAI

Jeev Chugh, CDAP | CDAI

Mark Lines and I edited a special issue of the Cutter Business Journal in 2018 entitled A Disciplined Agile Approach to Business Agility which can be downloaded free of charge.  It contains several articles.

Itamae, the Agile Organization, and You by John Hogan

Hogan shares some insights on delighting customers. He argues for a customer-focused organizational structure, with Agile teams supported by Agile leadership. Hogan describes the importance of goal setting to focus on delighting customers, supported by incremental planning and delivery to do so. He works through the implications for:

1. People who face the customer. These people need to understand what customers need and then fulfill that need.
2. People who face each other. They need to identify their internal customers, collaborate with them, and bring business value to them at the lowest possible cost.
3. People who face suppliers. These people are effectively customers to that supplier and must collaborate with them as transparently as possible and should expect to be delighted.
4. People who are managers and leaders. They must be customer-focused and empower your teams.

The Agile Enterprise and the Division of Labor by Gene Callahan

Gene Callahan has some great advice for building awesome people. Beginning with the idea of the division of labor, Callahan walks us through the history of how traditional organizations find themselves as a collection of specialists who struggle to be responsive to the changing marketplace. He then examines the need for people who are generalizing specialists (people who can collaborate effectively and learn from one another).

The Necessities for Successful Enterprise Agile Transformation by Matthew Ganis and Michael Ackerbauer

This article describes how to build awesome teams. You want to be Agile (of course!) and adopt Agile practices. Awesome teams have the skills and resources to fulfill their mission and include the right mix of personalities. The authors argue that the organization is really a “team of teams” that needs a shared purpose and way of working to make the abstract concrete. According to them, awesome teams build on a common foundation based on the concept of Breakthrough Thinking/diversity of thought.

Business Agility: A Roadmap for the Digital Enterprise by Jaco Viljoen

In his discussion of the five levels of a digital business ecosystem (DBE), Jaco Viljoen explores the idea that“choice is good because context counts.” The five levels, each with its own set of capabilities that build one on top of another, are: waterfall/traditional, hybrid Agile (a combination of waterfall and Agile), regular delivery, continuous delivery, and continuous exploration. The five DBEs provide insight into which process-building blocks to apply. Viljoen also discusses using a frame- work to achieve business agility at scale.

Case Study: Linking Business Workflows and Agile User Stories in an SOA Environment by Gill Kent and Robin Harwood

Gill and Robin provide a case study about linking Business Process Model and Notation (BPMN) workflows and user stories. They focus on the importance of initial modeling during what they call the Discovery phase of a digital trans-formation project. In their example, they followed a pragmatic, Agile approach to modeling the business and their host systems to gain important insight into the enterprise transformation scope and a vision of the required system change for their endeavor. This enabled them to establish a business/stakeholder vision that captured a clear scope for the following phases. With an initial technical strategy/architecture identified, the team was able to name a backlog of architecturally relevant stories, mitigating the risk of late identification of system integration requirements and the potential for significant rework. In short, a pragmatic investment in initial modeling and planning paid off in huge divi-dends for their Agile team.

The Wizard of OSS: Follow the Open Space and Sociocracy Road to Enterprise Agile Transformation by Jutta Eckstein and John Buck

The principle of enterprise awareness appears in several of the articles, and Jutta Eckstein and John Buck walk us through an enterprise-aware approach that helps optimize the process flow of value streams. The authors show how to apply “Open Space” and “Sociocracy” to support enterprise Agile transformation. Open Space is a technique where everyone is invited to put forward ideas that they’re passionate about; if there is enough interest in the idea people will get behind it and make it happen. Sociocracy is a form of democracy for use in organizations, building feedback mechanisms into the organizational structure itself that ensure every voice is heard. Both strategies promote enterprise awareness, increasing collaboration between people in what would normally be disparate parts of the organization and helping optimize flow as the situation evolves.

Core Thinking Patterns for Lean/Agile Organizations by Srinivas Garapati

This article explores important philosophies and the mindset behind Agile and Lean. He starts with the thinking patterns required to be successful and then considers the nature of an Agile organization and finishes with strategies for organizational design.

The Institution of Engineering and Technology has recently published a paper entitled An Academic Approach to Transform Organizations One Engineer at a Time by Eduardo Juarez Pineda, Rocio Aldeco-Perez, and Jose Manuel Velazquez.  The DA toolkit features in this paper so I thought you’d be interested.

Paper Abstract:

Essence was created by the  Software Engineering Method and Theory (SEMAT) community and approved by The Object Management Group as a standard in 2014. The basic of Essence is that “provides the common ground for defining software development practices” (see [R1-ES]) and also is intended to build and maintain an open library and marketplace of software engineering practices and education materials (see [R3-SMMS] ).

Essence is important, (see specification [R1-ES]), because:

• “Provide a common base that is useful for software engineering endeavors of all sizes (small, medium, and large)”
• “Enable method building by the composition of practices, so that methods can be quickly assembled by a project team to match their needs, experiences, and aspirations. Allowing the method to start small and grow as needed”
• “Support method agility, so that practices and methods can be refined and modified during a project to reflect experiences, lessons learned, and changing needs”
• “Support scalability including from one product to many, from one team to many, and from one method to many”

In this article I show how to describe DAD Essentials. Essentializing DAD is different from similar endeavors because Disciplined Agile (DA) is not a prescriptive method/framework like Scrum/SAFe. Instead, DA is a toolkit based on similar goals as Essence in that it is generative – both provide building blocks from which you can tailor and evolve a process that meets your needs.

The role of this Essentials is to provide an overview of the DAD guidance and over the capabilities that could be developed for each significant aspect (“Alphas”) of an Agile & Lean process. What is really happening on Agile/Lean adoption (and in any process improvement) is developing & exercising of new capabilities. What is specific to Disciplined Agile is that it provides guidance for developing the capabilities that team & organizations needs for their specific context.

DAD Essentials are presented here in cards format using the OMG/SEMAT Essence Language constructs as Alphas, Patterns, Resources, Activities, Work Products (see Glossary section below). Each “card” has a name, a description, and a list of capabilities for your team or organization to develop.

The following terms are used in Essence.

	Alpha	An essential element that is relevant to an assessment of the progress and health of the software engineering endeavor.
	Patterns	A generic mechanism / complex concepts that are made up of several other elements
	Resources	A source of information or content.
	Activities	One or more approaches for carrying out some work to be performed and can recommend actions on alphas and/or work products in order to and relevance this work.
	Work Products	An artifact of value and relevance for a software engineering endeavor.

Full delivery life-cycles

Full, beginning-to-end, delivery life-cycle it is an explicit representation of how a software release will progress in time. The pragmatism and effectiveness of Agile (<> Waterfall) are based on realistic progress milestones with the evolution of working software toward a consumable solution.  A team could have a reference lifecycle, but in a different context, they may need to use also other types of life-cycles.

Capabilities to develop:

• A reference life-cycle
• Support for Iterative-Agile, Lean, Continuous Delivery life-cycles
• Support for high incertitude deliveries
• Support for long term roadmaps (product, business, technology)

Consumable Solution

Consumable solution is more than working software. Consumable means that we meet stakeholder needs in the context constraints and it is usable, desirable, and functional. A solution implies that, as needed, we:  

• Develop high-quality software
• Provide new or upgraded hardware/platform
• Change the business/operational processes which the stakeholders follow
• Change the organizational structure in which our stakeholders work
• Update supporting documentation

Capabilities to develop:

• Understand Consumable Solution
• Build using DAD guidance the Consumable Solution across life-cycle milestones, considering various life-cycle and practices options depending on context

Adapt to Context

DA supports two principles that motivate you to adapt your approach to your context:

• Context counts. 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.
• Choice is good. Different contexts require different strategies – teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. This is why the DA framework presents people with choices through the application of process goal diagrams.

Capabilities to develop:

• Understanding Agile Scaling/Tailoring Factors
• Tailor WoW in context using DA Guidance
  • Select life-cycles
  • Select practices per process goals in a given context and life-cycle
  • Use DAD Library of practices & context options guidance
  • Make experiments to see what works in your context

Core Agile Practices

Core Agile Practices will help you have a Lean process: they address the main sources of waste and have multiple benefits at the same time. It is not a coincidence that XP is based on some of them, Disciplined Agile and Agile Modeling refer them as critical practices. (See also references from Mary Poppendieck / Tom Poppendieck in “Lean Software Development”). Some core practices are:

• XP practices: Small Releases, Pair Programming, Simple Design, Refactoring, TDD, Coding Standards, and more.
• DA/Agile Modeling practices: Requirements/Architecture Envisioning, Architecture Handbook, Model Storming, Rolling Wave Planning, and many more.
• Method free practices: Clean Code/Architecture.

Interestingly, Essence describes in detail several dozen core agile practices in detail whereas Disciplined Agile puts several hundred agile, lean, and even traditional core practices into context. This is one of several reasons why Essence and DA are complementary to one another.

Capabilities to develop:

• Understand how and why you will eliminate waste
• Context usage: Core Agile Practices are not “best practices” and we still need to know the trade-offs and options for different context (See Adapt to Context alpha). Make experiments to see what works in your context

Teal Teams and Organizations

Optimize the whole: the Organization (and its constituents teams) represents that “whole” where the work optimization really makes sense. In Reinventing Organizations, Frederick Laloux presents the historical evolution of organizations from tribal to modern agile approaches:

• Red (Magic/Tribal): Impulsive, survival urgency
• Amber (Traditional/Agrarian): Authoritarian, formal hierarchy
• Orange (Scientific/Industrial): Task-oriented, profit/grow focus
• Green (Post-Modern/Information): Value-based, consensus/participative style
• Teal (Self-Organizing/Adaptive): Cellular organism with evolutionary purpose

Disciplined Agile use this model and propose as a goal the Teal organization (or at least Green): cellular, self-organizing, adaptive, aware, with evolutionary purposes. Most likely, your organization is a “rainbow” (e.g. Orange/Green/Teal). Context counts, different teams faced different situations and you can choose your strategy. You want to be at least Green because that will provide – through a participative & collaborative style – a solid foundation for further process improvement. Also, the DA Principle, Be Awesome has some expectations:

• Treat people with respect, honesty, be reliable and open
• Willingly collaborate with others

Capabilities to develop:

• Teams will offer psychological safety with clarity about roles and responsibilities
• Cross-functional skills teams, where T-skilled “generalizing specialist” is the most pragmatic, effective, efficient approach.
• Use collaborative work to envision, look ahead and just-in-time clarifications.
• Collaborative and continuous process tailoring and improvement, not only on retrospectives
• Inter-teams’ collaboration: Communities of Practices and Centers of Excellence, etc.
• Individual, team, enterprise and community level awareness
• Use pragmatic agile roles
• Address team and organization level scaling factors

Guided Process Improvement

The purpose of the Continuous Improvement process blade is to enable people within your organization to easily share their improvement learnings with one another in a systematic way. The technique of Guided Continuous Improvement (GCI) shows teams how to leverage the DA toolkit to speed up their process improvement efforts.

Capabilities to develop:

• Continuous improvement must be explicit and fundamental
• A base support for improvement should be running: life-cycles, collaborative work, retrospectives
• Kaizen strategy: continuous improvement should always be running in small steps and experiments. This lean strategy is fundamental for addressing problems complexity & incertitude.
• Guided Continuous Improvement (GCI)
  • apply the DAD toolkit to adapt to context (see corresponding alpha) for process goals as: selecting a life-cycle, forming the team, addressing changing stakeholders needs.
  • hire/listen experienced coaches
  • make progress on adopting Core Agile Practices
  • have explicit goal/guidance for Evolving your WoW

An Agile method such as Scrum, or a framework such as SAFe, can be a good start but it will have too few guidelines for choosing your way of working (WoW) in context or too little guidance for core Agile practices. DA provides the guidance for evolving your WoW and Essence the details regarding core practices. As Ivar Jacobson likes to say, this will enable you to break out of “method prison.”

Patterns

Resources

Work Products

Activities

I want to thank Scott Ambler who started this Essentializing DA initiative and collaborated with SEMAT from 2009. Scott helped me with feedback and review of current materials. DA Essentialization began with the example of the DB Refactoring technique earlier this year.

• [R1-ES] Essence Specification 1.2 – https://www.omg.org/spec/Essence/1.2/
• [R2-SM] SEMAT (Software Engineering Method and Theory) – http://semat.org/
• [R3-SMMS] SEMAT mission statement: http://semat.org/mission-statement
• [R4-ESSDB] Essentialize DB refactoring –  Database Refactoring
• [R5] DA approach for organizations – Teal is the New Black

Copyright statement

Use of Essence – Kernel and Language for Software Engineering Methods Specifications is the subject of Term and conditions & Notices found at https://www.omg.org/spec/Essence/1.2