Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

PMI and Disciplined Agile at Agile20Reflect

Disciplined Agile: An Executive's Starting Point

Start

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).

The scope of Disciplined Agile

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).

Value stream workflow

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 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:

Disciplined Agile Transformation

 

  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.
Posted by Scott Ambler on: March 26, 2021 05:29 AM | Permalink | Comments (5)

A Disciplined Agile Approach to Business Agility

A Disciplined Agile Approach to Business Agility

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.

Posted by Scott Ambler on: July 16, 2019 03:30 PM | Permalink | Comments (0)

Transform One Engineer at a Time

Scotty

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:

Every year software development industry requires a higher number of trained software engineers who are not only skilled programmers but also talented software projects managers. To deliver high quality software projects, engineers require of the application of sound engineering competencies along with discipline. Obtaining those practices usually require years of experience. Companies are not prepared to invest this time on engineers resulting in a high percentage of deficient projects. In this paper we present a bachelor level competency-based approach that develops and evaluates such competencies during a challenge-based learning experience. In this way, the rate of successful projects where software engineers are involved will be higher, as they have obtained the appropriate competencies to deliver such projects.

Posted by Scott Ambler on: July 14, 2019 06:50 AM | Permalink | Comments (0)

The Agile Enterprise Coach

When your organization chooses to transition to more agile and lean ways of working you quickly discover that this effort needs to address all aspects of your organization, not just your solution delivery teams.  Many transformation efforts invest in agile team coaches, which is a very good thing to do, but will often shortchange other areas of coaching in the belief that they’ll figure it out on their own.  It may work out that way, but even when it does this is an expensive, slow, and error-prone approach.  In our experience it’s far better to get help from an experienced Enterprise Coach.

An Enterprise Coach coaches “beyond the team” to help senior managers and leaders to understand and adopt an agile and lean mindset.  As you will soon see, this requires a similar yet different skill set than what is required for team coaching. In this blog we work through three key concepts:

  1. The types of agile coaches
  2. Skills of an Enterprise Coach
  3. Supporting other coaches

Types of Agile Coaches

As you see in the following diagram we like to distinguish between several types of coaches:

  1. Team coach. As the name suggests, a Team Coach coaches solution delivery teams through improvement efforts. The focus is usually on improving the performance of individual teams. This is the most common type of coach, and our guess is that 95% or more of agile coaches fall into this category.
  2. Specialized coach. A “specialized coach” is someone who focuses on non-solution delivery aspects of your organization.  They are typically senior team coaches who have a deep background in one or more process blades.  For example, you may have a specialized coach focused on Enterprise Architecture and Reuse Engineering for example; or one that is focused on Finance, Portfolio Management, and Control; or one that is focused on Enterprise Architecture and Data Management.  The people who are working in non-solution delivery areas need coaching just like people on solution delivery teams do.  More on this in a future blog posting.
  3. Enterprise coach.  Sometimes called Transformation Coaches or Executive Coaches, these coaches work with senior and executive management to help them to understand new ways of working and organizing themselves.  Enterprise coaches will often focus on executive coaching, of which there are three types: IT executive coaching, business executive coaching and manager coaching.  All are equally vital to your agile transformation and continuous improvement efforts.  An area often ignored in coaching is the role of managers as agile leaders and coaches of your agile teams.  Executive Coaches can help guide managers from a style of “managing” to leadership.  Enterprise Coaches often find that they also need to take on the role of a Specialized Coach too. A key responsibility of an Enterprise Coach is to support the other coaches when they need help. The focus of this blog is on Enterprise Coaches.

Agile Communities of Excellence

 

Skills of An Enterprise Coach

The skills of an Enterprise Coach include:

  1. Coaching skills. First and foremost, enterprise coaches are coaches.  They require all the people, collaboration, and mentoring skills of other agile coaches.  They should have many years of hands-on coaching of individual agile and lean teams in many types of situations, from the simple to very complex.
  2. Domain knowledge. An enterprise coach must have knowledge of the domain that they are working in.  There are unique challenges in financial organizations that you don’t see in automotive companies, similarly pharmaceutical companies are different from retailers, and so on.  Yes, it is possible for Enterprise Coaches to quickly learn the fundamentals of a new domain, but you’ll find that in the beginning the executives that the Enterprise Coach is helping to learn agile will have to help them learn how the business runs.
  3. Understanding of how IT works. Enterprise Coaches need to understand how a Disciplined Agile IT (DAIT) department works so that they can coach IT executives effectively.  Enterprise Coaches help IT groups such as Enterprise Architecture or PMOs to understand how they need to adapt to effectively support Agile teams.
  4. Understanding of how to apply agility at the enterprise level.  Similarly, Enterprise Coaches should understand how a Disciplined Agile Enterprise (DAE) works.  Enterprise Coaches should be experiences with modern agile practices related to non-IT functions such as human resources (also called People Management or People Operations), finance, and control.  Coaches bring expertise on practices in these areas such as modern compensation and reward systems, agile budgeting, rolling wave planning, agile procurement, and agile marketing.
  5. Experience and knowledge of the various IT domains. A broad understanding of IT is critical, and better yet deep knowledge of several of the IT process blades so that someone in the Enterprise Coach role can guide any specialized coaches or step into that role themselves.  This is important because people working in areas such as Data Management, Release Management, or IT Governance often believe that they are “special” and agile can’t possibly apply to them (it’s only for programmers after all).  Without a good understanding of these areas an Enterprise Coach will struggle to help the IT leaders that they are coaching to counteract these arguments.
  6. Transformation and improvement coaching.  Enterprise Coaches should understand, and be experienced at, lean approaches to organizational transformation and improvement, often referred to as Organizational Change Management (OCM).   Traditional approaches to OCM will not work.
  7. Ability to support team and specialized coaches.  See below.

Supporting Other Coaches

Enterprise Coaches support other coaches in several important ways:

  1. Transformation/improvement visioning.  Enterprise Coaches help executives to understand modern agile and lean practices used by successful agile organziations and help to create a roadmap for moving from their current to target state.
  2. Organizational structural change.  Experienced coaches can help organizations to create organizational structure to be conducive to the evolution of high performance teams.  This would include design of cross-functional, stable teams aligned to value streams or lines of business (LOBs).  They can also help design workspaces for effective collaboration between team members, and help reduce the need for separate meeting rooms.
  3. Organizational coordination.  One of the most important things that an Enterprise Coach does is help team coaches to overcome challenges collaborating with other, not-so-agile teams.  The reality is that 96% of agile teams must collaborate with one or more teams or groups within their organization at some point, 96%!  Some of those teams may very well be struggling with working in an agile manner and may even be opposed to it.  These sorts of challenges are often beyond the remit of a team coach to address, so when they occur the team coach will often ask for help from an Enterprise Coach who does have the relationships with the right people to smooth over such problems.  Enterprise Coaches can also provide advice for effective collaboration strategies with vendors and offshore teams.
  4. Resources. Enterprise Coaches will sometimes help other coaches to obtain the resources – typically time and money – required to coach the teams that they’re working with.
  5. Communication.  The Enterprise Coach will actively share the overall vision of your improvement efforts, the current status, and any organizational challenges that you’re running into with the other members of the CoE.  They will of course be actively working with the people responsible for communicating this information to the rest of the organization as well.
  6. Coordination. Enterprise Coaches will often coordinate the efforts of the various team coaches in your organization to ensure that they’re working together effectively.
  7. Mentoring.  Enterprise Coaches, being senior, will often be coaching the team and specialist coaches (all the while learning themselves).

There is of course a lot more to agile coaching that what is covered in this short blog.  Our goal with this writing was to overview the role of Enterprise Coach and show how it fits into the overall scheme of things.

Posted by Scott Ambler on: October 04, 2017 08:19 AM | Permalink | Comments (2)

Nine Reasons to Choose DAD over Scrum

Categories: Adoption, Scrum, Transformation

 

Why?

A common question that we hear a lot is “Why choose Disciplined Agile Delivery (DAD) over Scrum?”, so we’ve written this blog to summarize our response.  The short answer is that DAD addresses the myriad of issues that Scrum chooses to leave to you.  To see what we mean, the official Scrum Guide is 23 pages compared to the 500 pages of the original Disciplined Agile Delivery (DAD) book – DAD clearly goes into greater detail than Scrum, detail that your organization will need to spend a lot of time and money figuring out on your own with Scrum as your process base.  We believe you can do a lot better than that.

At a high-level, the primary reason to adopt DAD over Scrum is that you will greatly increase the chance that your process improvement efforts will be successful, and you will do so in such a way that it will be quicker and less expensive in the long run.  This is because DAD takes a holistic, context-sensitive approach to solution delivery as opposed to Scrum’s prescriptive and narrow approach.  Let’s explore the many reasons why you should adopt DAD over Scrum:

  1. DAD extends Scrum
  2. DAD addresses all aspects of agile solution delivery
  3. DAD focuses on solution delivery, not just software delivery
  4. DAD explicitly supports a full delivery lifecycle
  5. DAD provides more options than just Scrum
  6. DAD provides explicit tailoring advice
  7. DAD reflects the realities of enterprise agile
  8. DAD is scalable and provides real advice for doing so
  9. DAD certification is respectable

 

Reason #1: DAD Extends Scrum

The question “Why choose DAD over Scrum” doesn’t make a lot of sense to us because DAD extends Scrum to address all of the process issues that Scrum leaves up to you.  As we describe below, DAD addresses all aspects of agile (not just management and collaboration), it explicitly supports a full delivery lifecycle (not just Construction), and it goes beyond software development to address solution delivery.  Scrum is important, and it encompasses a lot of great ideas, but in practice it proves to be a very small part of the overall agile picture. We’d like to say that it’s the tip of the iceberg, but the tip of the tip of the iceberg would be a lot closer to the mark.

For more thoughts on this topic, see the blog Disciplined Agile Extends Scrum.

 

Reason #2: DAD Addresses All Aspects of Agile Solution Delivery

Right Sizing Scrum

The focus of Scrum is on change management and collaboration, important things but not actually sufficient for software development.  Scrum purposefully does not address architecture, programming, design, testing, governance, analysis, documentation, and many other important issues. Scrum suggests that you start with it as a core and add in what you need, which is a boatload of time-consuming work in practice because Scrum simply doesn’t address the full range of issues that you actually face.  It will take you months, and sometimes years, of effort to evolve to a right-sized process that works for your team.  Worse yet, Scrum will require more coaching (which is expensive), and more experimentation (important, but expensive and time consuming so you to be smart about it) than if you were to start with a more robust strategy such as DAD.

As you would expect, DAD takes a more intelligent approach to process right-sizing than Scrum does. DAD suggests that you start with something a lot closer to what you actually need, thereby saving a lot of time and money.  Why should you have to figure out how to take a streamlined approach to solution delivery when thousands of other organizations have already done that?  Instead, why not leverage their hard-earned learnings and start with something more robust?  DAD encapsulated those hard-earned learnings.

Right Sizing Disciplined Agile Delivery

Being empirical, DAD reflects our observations of what teams actually do in practice to succeed at solution delivery.  DAD is a hybrid framework that adopts strategies from a wide range of sources, including Scrum, XP, Agile Modelling, Kanban, Unified Process, and many others.  More importantly DAD does the “process heavy lifting” that Scrum doesn’t do and puts these things into context, showing you how everything fits together, giving you choices, and addressing important issues such as what to do when and to what extent to do it.  In short, DAD doesn’t leave you hanging the way that Scrum does. We like to say that DAD takes the mystery out of agile solution delivery.

For more thoughts on this, see There is More to Agile Transformations than Implementing Scrum.

 

Reason #3: DAD Focuses on Solution Delivery, Not Just Software Delivery

The fundamental observation is that as IT professionals we do far more than just develop software.  Yes, software is clearly important, but in addressing the needs of our stakeholders we will often:

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

DAD shows how to do all of these things in a streamlined manner, going beyond the “potentially shippable software” mantra of Scrum to the more robust concept of producing consumable solutions.  Our experience is that the focus on potentially shippable software makes it harder for teams to see the bigger picture, to work in an enterprise aware manner that results in the development of high-quality solutions that delight customers and will stand the test of time.

 

Reason #4: DAD Explicitly Supports a Full Delivery Lifecycle

DAD supports the full delivery lifecycle, supporting up to three phases (Inception, Construction, and Transition) where needed (the two project-based lifecycles, the Scrum-based Agile lifecycle and the Kanban-based Lean lifecycle need all three phases whereas the two continuous delivery lifecycles and the lean-startup-based Exploratory lifecycle do not, more on this later).  As you can see in the picture below the DA toolkit supports a full systems lifecycle that reflects the complete lifecycle from concept (idea) to eventual retirement (decommissioning).

High-level system lifecycle

The following diagram depicts the Scrum lifecycle.  There are a lot of really great ideas here, but this lifecycle clearly isn’t complete.  How do you initiate a Scrum team?  How do you release software into production (or the marketplace)?  The focus here is just on Construction, which is important, but it is not the full picture.

Scrum Construction Lifecycle

 

The following figure overviews DAD’s Scrum-based Agile lifecycle.  As you can see the Scrum Construction lifecycle is at the heart of it but DAD isn’t limited to just what the Scrum folks want to sell you.  Instead DAD takes an approach that is Enterprise Aware in that it covers from beginning to end what solution delivery teams face and it puts the delivery lifecycle into context.

DAD Agile Project Lifecycle

Note that in the DA toolkit we choose to use different, more understandable terminology than Scrum does (but feel free to use whatever terms that you like, because DAD isn’t prescriptive), and prefer to depict a more robust version of the backlog than Scrum does (many Scrum adherents now take a similar approach).  The important point is that DAD chooses to explicitly support a full, Scrum-based lifecycle that reflects the realities of enterprise-class solution delivery.  Once again, DAD strives to take the mystery out of agile solution delivery.

 

Reason #5: DAD Provides More Options Than Just Scrum

Because Scrum isn’t the only agile game in town, DAD supports five full delivery lifecycles so as to give teams viable choices.   DAD does this because solution delivery teams face different situations, so one lifecycle will not fit all, reflecting the DA principle Choice is Good.

DAD includes severa; lifecycles:

  1. Agile (Scrum-based)
  2. Lean (Kanban-based)
  3. Continuous Delivery:Agile
  4. Continuous Delivery: Lean
  5. Exploratory (Lean Startup)
  6. Program (team of teams)

Even when you start with the Scrum-based agile lifecycle you will find that a team eventually evolves away from it, as overviewed in the diagram below.  This happens because agile teams own their process, and part of that ownership is the adoption of continuous improvement strategies such as retrospectives where a team strives to identify potential improvements, communities of practice (CoP) where people explicitly share their learnings, and of course purposeful experimentation where teams discover what works for them in practice.

Agile lifecycles and continuous improvement

It’s important to note that management can become very concerned with the philosophy that solution delivery teams should choose, and then tailor as needed, a lifecycle that reflects the context of the situation that they face (see the principle Context Counts).  Many organizations make the mistake of assuming that teams must follow the same lifecycle so that management may govern them consistently.  In DAD we show that assumption to be false – DAD has the same light-weight risk-based milestones across the five lifecycles (when and if they apply to that lifecycle).  These milestones are summarized in the diagram below.  This enables consistent delivery team governance without taking on the risk (and cost) of inflicting the same processes inappropriately across teams.

 

You may find the blog How Do You Choose Between Software Lifecycles? and the article Lean IT Governance to be interesting reads.

 

Reason #6: DAD Provides Explicit Tailoring Advice

Scrum is prescriptive, giving you one way of doing things.  For example, when it comes to addressing changing requirements Scrum has a single way of doing so called a Product Backlog which is managed by a Product Owner.  This is a great approach which has its advantages and disadvantages.  But, it is only one of several ways to do so.

DAD takes a more robust approach, depicted in the goal diagram for the Address Changing Stakeholder Needs goal.  DAD supports Scrum’s Product/Requirements Backlog strategy, but it also supports the work item pool approach from Kanban, a work item list strategy (which some Scrum adherents choose to adopt, although typically still call it a backlog), and even a formal change management approach (applicable in regulatory environments).  Each of these strategies has advantages and disadvantages and each one of which makes sense in some situations and is a rather bad idea in others.  Instead of prescribing a single strategy, which may make sense for the context that you face or it may not (how would you know when you don’t know what your actual options are?), DAD instead provides you with choices and walks you through what you need to consider when making those choices.  Of course there’s a bit more to it this, you can see that there are several decision points to consider, including how you go about prioritizing work, when you accept changes (if at all), how stakeholders will interact with the team (egads!, Product Owners are only one way to do so and might not be the best way), and how you go about eliciting requirements from stakeholders.

Address Changing Stakeholder Needs process goal

DAD organizes agile solution delivery into a collection of process goals, depicted below. Each of the 23 goals are described with a goal diagram such as the one above, walking you through the choices that you have (we believe that Choice is Good).  DAD also puts each practice/strategy into context by indicating its advantages and disadvantages (we also believe that Context Counts) so that you can make intelligent choices.  Not only does this approach get you going in the right direction early on, helping you to avoid costly mistakes, it also helps you to make better decisions in retrospectives and thereby improve your ability to improve your process. Once again, DAD takes the mystery out of agile solution delivery.

The Process Goals of Disciplined Agile Delivery (DAD)

 

Reason #7: DAD Reflects the Realities of Enterprise Agile

Modern enterprises face a myriad of challenges, including having existing non-agile cultures, existing non-agile processes, legacy systems and data sources, and significant technical debt.  Furthermore, your organization likely has multiple teams that range in size, geographic distribution, organizational distribution, and other scaling factors (see DAD is Scalable for a more detailed discussion).  The point is that in enterprise-class settings, very likely the situation that you face right now, that the environment is neither pristine nor ideal.

The implication is that you might not have the luxury of taking a pure agile approach, at least not immediately, but instead you must make do the best you can in the situation that you face.  You must adopt strategies that reflect the context of the situation that you are in, and yes, you should push the boundaries whenever you can.  This is why DAD offers choices, suggesting that you be pragmatic and choose the best strategy that you can right now and be prepared to learn and improve later on.

For example, consider the process goal Address Changing Stakeholder Needs.  When you see a decision point that has an arrow beside the list of choices – in this case Manage Work Items, Accept Changes, and Stakeholder Interaction With Team – that’s an indication that the strategies towards the top of the list are generally more effective than the strategies towards the bottom.  When you first form an agile team a very common problem is that it’s difficult to find someone with the skills and authority to be a Product Owner (PO).  Many teams find that they need to make do with a business analyst at first, which in general isn’t as good as having a PO (as you can see in the goal diagram above) as Scrum prescribes.  It’s not ideal, but it’s the best that you can do right now.  Hopefully, in time, you will be able to grow someone into the PO role and thus work in a more agile manner.  Having said that, having a PO (the Scrum approach) isn’t as effective, generally, as taking an Active Stakeholder Participation approach (an Agile Modelling strategy).

In short, to address the realities of enterprise agile DAD prefers pragmatism over purism – do the best you can given the situation that you face, and be prepared to continuously improve and get better over time.

 

Reason #8: DAD is Scalable and Provides Real Advice For Doing So

Disciplined Agile Delivery (DAD) provides a foundation from which to scale agile strategies both tactically and strategically.  Tactical agility at scale is the application of agile and lean strategies on individual DAD teams.  The aim is to apply agile deeply to address all of the complexities, what we call scaling factors, appropriately.  These scaling factors are summarized in the following diagram.  It is interesting to note that Scrum is geared towards the simple end of these six scales, the ends towards the centre of the radar chart.  Although this is very good advice, why wouldn’t you want to keep things as simple as possible, as numerous agile scaling studies have found (see the November 2016 study for our most recent) agile teams do in fact commonly face situations that aren’t that simple.  Once again, the DA toolkit prefers pragmatism over purism and provides you with choices to help address these scaling challenges actually faced by agile delivery teams – DAD takes the mystery out of agile solution delivery.

Software Development Tactical Scaling Factors

 

Strategic agility at scale is the application of agile and lean strategies broadly across your entire organization.  As you can see DAD provides a base from which you can extend to implement Disciplined DevOps and Disciplined Agile IT (DAIT).  You can apply Disciplined Agile strategies even wider, across all divisions and teams within your organization to have a truly Disciplined Agile Enterprise (DAE).  Our point is that the DA toolkit provides advice across the entire spectrum of your organization, providing a real vision for business agility and more importantly concrete advice for getting there.

Scope of Disciplined Agile

 

Reason #9: DAD Certification is Respectable (Because You Need to Actually Earn It)

The Disciplined Agile Certification Program is based on the principles that certification must be earned, it must be meaningful, and must be measurable.  DA certification implements a Shu-Ha-Ri strategy in that it supports four certifications:

  1. Certified Disciplined Agilist (CDA) (Shu) – You must have a comprehensive knowledge of DA strategies and ideas.  This is verified via a comprehensive test.
  2. Certified Disciplined Agile Practitioner (CDAP) (Ha) – You must be a CDA (proven knowledge) plus have at least two years of agile solution delivery.
  3. Certified Disciplined Agile Coach (CDAC) (Ri) – You must be a CDAP (proven knowledge + experience) plus be actively sharing your skills with others through writing, teaching, or coaching.  This giveback does not need to be public, many CDACs write, teach, or coach internally within their own organizations and that’s great with us!
  4. Certified Disciplined Agile Instructor (CDAI) (Ri) – You must be either a CDAP or CDAC (that way you understand and have experience in what you’re teaching) and be able to teach (we ask CDAIs to do a co-teach so that we can see them in action first).

Many Scrum certifications, in particular the Certified ScrumMaster (CSM) designation, are questionable at best.  You’re a “Certified Master” after staying awake in a two-day (sometimes three-day, whoopdie-do) workshop and you’ve passed a test that has 99%+ pass rate?  The vast majority of CSM holders are embarrassed to admit that they have it, which is good to see, but it’s a clear indication that CSM can’t be taken seriously.  In the DA community we’ve chosen to do better.

 

Parting Thoughts

A lot of people want to do Scrum, and rightfully so because there are some great ideas there.  But even when you’re “doing Scrum” the reality is that Scrum is only a very small part of the overall picture.  A very small part.  Once you recognize this to be true, you quickly realize that you’re much better off to adopt a robust framework such as Disciplined Agile so as to help gain lightweight guidance through your process choices.  This will not only increase your chance of success at adopting agile strategies it will also reduce the cost and time required to do so because DAD takes the mystery out of agile solution delivery.

 

Further Reading

Posted by Scott Ambler on: September 05, 2017 10:08 AM | Permalink | Comments (0)
ADVERTISEMENTS

"The secret to creativity is knowing how to hide your sources."

- Albert Einstein