Disciplined Agile

Remote agile teams typically use more video conferencing and extra written communication than collocated teams to stay synchronized. While perhaps not as effective as direct face-to-face communication, these approaches make up some of what is lost from sitting together and provide the advantage of being easily recorded for later access.

This asynchronous access to information is especially valuable for globally remote teams that may not share the same work hours. By accessing content on-demand, people can contribute when works best for them and sync up with the rest of the team at preset events.

Remote Onboarding Challenges

Onboarding new team members can be a challenge for remote teams. Introducing team members, explaining agreed to norms around process and tools are traditionally done in-person. Writing all of this information down along with the justifications and discussions around the decision process is a significant undertaking.

GitLab, one of the most successful all-remote agile development organizations, has onboarding materials that would occupy over 8,000 pages if printed. As organizations transition to more remote-friendly structures, documenting how teams work is becoming more critical.

Disciplined Agile for Onboarding

Fortunately, Disciplined Agile (DA) can help. It contains a vast tool kit of approaches accompanied by industry vetted analysis of when they add value when they do not, along with the pros and cons of implementing them. Teams can use the DA tool kit as the starting point for describing their way of working.

Using the upcoming DA Profiler tool, teams can debate, discuss and decide on their ways of working. The tool captures the goals, decision points and trade-off tables of each selected process or technique. Then, when new team members join, they can be pointed to the saved profile representing the team’s way of working. This saves creating lengthy onboarding materials and descriptions of processes.

Of course, processes should not remain static but instead, continue to evolve as teams and businesses learn and develop. So, at regular intervals, teams are encouraged to review and update their way of working and create a new definition. DA provides a robust strategy to support this and the goal “Evolve Way of Working.”

Keeping it Real

A strength of DA is its realism and pragmatism towards how organizations work. Not all organizations are fully agile yet, nor perhaps want to be. So, if some traditional, serial practices are still in use, that is OK; DA supports it. If Team A uses Scrum with two-week Sprints, Team B uses Kanban with continuous flow, and Team C uses SAFe, that works too.

DA is approach agnostic and capable of supporting a variety of popular techniques along with custom hybrid solutions. It also embraces a set of principles that make building guidance for remote agile teams more successful. These include: “Be pragmatic,” “Context counts,” “Choice is good” and “Enterprise awareness.”  These principles provide practical advice teams can apply to define their remote ways of working.

Mind Your Toes

Returning to the GitLab onboarding process, they promote a fun principle called “Short toes,” which comes from when people join the company and frequently say, “I don’t want to step on anyone’s toes.”

At GitLab, they aim to be accepting of people taking the initiative in trying to improve things. They recognize that as organizations grow, their decision-making speed often slows since more people are involved. However, this can be counteracted by having short toes and feeling comfortable letting others contribute to their domain.

Short toes is a great concept that is required if organizations are to scale and evolve successfully. It aligns well with another of DA’s principles, “Be awesome,” which is all about striving to be the best that we can and to always get better.

Summary

Adapting to the challenges of more remote team members and new all-remote teams creates the need for better onboarding resources.

DA provides great scaffolding to build onboarding handbooks that document how teams have selected to work without making manuals with thousands of pages.  It supports group-based discussion and selection of techniques, ongoing refinement and offline access. Perfect for onboarding today’s increasingly remote workforce.

The Disciplined Agile (DA) tool kit is organized into four layers: Foundation, Disciplined DevOps, Value Streams, Disciplined Agile Enterprise (DAE).  This blog focuses on the Foundation layer, the purpose of which is to provide the underpinnings of the DA tool kit.  The foundation layer itself is organized into four distinct topics:

1. The DA mindset
2. Fundamental concepts
3. People
4. Choosing your WoW

The DA Mindset

The Disciplined Agile (DA) mindset is captured in the form of principles, promises, and guidelines. Disciplined agilists believe in the DA principles, so we promise to adopt these behaviours and follow these guidelines when doing so. There is a purpose for each aspect of the mindset:

• Principles. The principles provide a philosophical foundation for business agility. They are based on both lean and flow concepts.
• Promises. The promises are agreements that we make with our fellow teammates, our stakeholders, and other people within our organization whom we interact with. The promises define a collection of disciplined behaviours that enable us to collaborate effectively and professionally.
• Guidelines. These guidelines help us to be more effective in our way of working (WoW) and in improving our WoW over time.

Fundamental Concepts

Disciplined Agile (DA) is a hybrid in that it adopts ideas and strategies from a wide range of sources. DA encompasses three categories of fundamental concepts:

1. Agile. Agile is both a mindset and a skillset. As a mindset Agile is the manner in how you look at your environment; it is the desire to collaborate with and to learn from others; and it is the willingness to share your skills and knowledge with others.  As a skillset Agile varies based on the domain in which you operate.  For example, an agile skillset for a marketing professional may include experimental strategies such as minimum viable products (MVPs) and marketplace sensing strategies, whereas an agile skillset for a software professional may include test-driven development (TDD) and chaos engineering techniques. Agility is the ready ability to move with quick and easy grace to respond to changes in your operating environment.  
2. Lean.  Lean produces value for customers quickly through a focus on reducing delays and eliminating waste which results in increased quality and lower cost. Lean philosophies and strategies infuse DA, and in fact much of the DA mindset reflects lean thinking. This includes ideas such as optimizing flow, making all work and workflow visible, keeping workloads within capacity, and attending to relationships throughout the value stream to name a few. 
3. Serial. DA adopts great ideas from serial - often referred to as traditional, waterfall, or even predictive - ways of working (WoW). There are many strategies and concepts from the past which are critical to our success in the future, and DA chooses to leverage them where they make sense. For example, DA's project-oriented lifecycles have explicit, named phases which are clearly serial in nature. DA recognizes that inception efforts, sometimes called  project initiation or simply initiation activities, such as initial planning, initial scoping, and initial design can be critical to your success.  These efforts are very different than the construction/realization efforts that happen after this, and different yet again than the transition/delivery efforts that then follow, and different again than the operational efforts that bring actual realized value to your customers.

People

The people portion of the Foundation layer addresses two key aspects of agility:

1. Roles (and responsibilities). The DA tool kit captures a wide range of roles that people may fill.  This includes common agile roles such as Team Lead/Senior Scrum Master, Product Owner, Architecture Owner, and others.  It also includes function-specific roles such as Program Manager, Financial Specialist, Governor, Security Engineer, Sales Manager, and many others.  All of these roles have associated responsibilities, and of course there are common rights and responsibilities that everyone has.
2. Teams. Every team is unique and faces a unique situation.  As a result, DA supports several team structures which your teams can adopt and evolve to meet their needs.  There are suggested structures for small, medium, and large (program) teams.  There are team structures that support geographic distribution.  There are team structures that support learning teams such as communities of practice (COPs)/guilds and centres of excellence (CoEs), and structures that support common services teams.

Choosing Your WoW

A fundamental philosophy of agile is that teams should own their own process, or as we like to say in Disciplined Agile (DA) teams should choose their way of working (WoW). Of course this is easier said than done in practice. The challenge is that every team is unique and faces a unique situation – in other words, context counts. Furthermore, there are no “best practices,” rather, every practice has tradeoffs and works well in some situations and poorly in others. Worse yet, you really don’t know how well a technique will work for you until you actually try it out in your environment. Given all of this, how can a team choose its WoW?

While working with organizations to help them to learn how to improve their WoW, we’ve developed a technique that we call guided continuous improvement (GCI). GCI extends the kaizen-based continuous improvement approach, where teams improve their WoW via small incremental changes, to use proven guidance to help teams identify techniques that are more likely to work in their context. This increases the percentage of successful experiments and thereby increases your overall rate of process improvement.

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

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

The results of the 2018 State of Agile survey (StateOfAgile.com) have just been released.  This survey, while not particularly scientific in its approach, is a widely read and frequently quoted survey of what people are actually doing on a variety of agile topics.  It is good to see that Disciplined Agile continues to grow in popularity, up from 5% marketshare to 7%, behind only  SAFe which commands a 30% market share and is the clear leader (Scrum of Scrums is ahead of DAD, but it is just a practice, not a method).  While we are very pleased that people are finally starting to understand what DA is and how it can help them, I am not particularly fond of the way the question is framed in the survey and would like to share my thoughts for how it could be improved, and my interpretation of the findings.

1. Disciplined Agile (DAD) is listed as an option in the “Which scaling method/approach do you use?”.  People who understand DA know that it is actually not specifically a scaling framework.  It is rather a toolkit of strategies, a hybrid of practices from many methods and frameworks which can help you optimize your way of working (WoW) regardless of which approach you use.  It can be used on one small Scrum team, or dozens of SAFe teams.  Whatever approach you use, DA can help you to become even more awesome! #beawesome
2. As I said above, Scrum of Scrums should not be one of the choices as it is simply a coordination practice for Scrum at scale, not a method.
3. “Don’t know” is interesting as an option.  It puzzles me that people that are answering this survey aren’t aware of their organization’s approach.  My suspicion is that many of the people picking this selection actually mean “Not applicable” as many organizations do not scale agile.  I think that this should available as a selection.
4. The question really should be a multiple choice, rather than single.  Most organizations use a variety of approaches.  It would be more useful to ask “What percentage of your IT spend uses each of the following approaches?”
5. Spotify is actually not a framework.  It is how a Swedish music company circa 2014 had adapted agile at that point in time, to optimize their WoW for their unique context.  If you copy their approach you are copying an old approach of a company in a situation unlike yourselves, and for which they have evolved away from significantly.
6. I find “Internally created methods” intriguing as a choice.  We think that this is what all companies should aspire towards.  Start with either where you are currently, or one of the other methods (recipes), and then use the DA Toolkit to either evolve away from, or to improve your approach for your unique organization and team context.
7. Spotify actually embodies this approach.  They have continually evolved, improving, and optimizing their way of working.  Menlo Innovations also has done the same thing, starting with Extreme Programming (XP) as their core method, and then optimized for what works for them.  Rather than copying other companies approaches we should “learn how to learn” about what works best for us. We describe this approach of leveraging proven fit-for-context practices in our Choose your Wow! book as “Continuous Guided Improvement”.  Starting with some basic scaffolding of an existing method (what we refer to as “lifecycles” in DAD) provides a jumpstart on your WoW optimization.

We would recommend that you do not aspire to “be Spotify”, but rather “be like Spotify”.  Start with a basic method/lifecycle (recipe), then spice it up with the help of proven strategies from the DA Toolkit (ingredients).

Become your own Spotify or Menlo, not somebody else’s.

Thoughts?