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

The Disciplined Agile Enterprise (DAE) Layer

Disciplined Agile (DA)'s Value Streams Layer

The Disciplined DevOps Layer

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

The Team Lead Role: Different Types of Teams Need Different Types of Leaders

We are often asked why Disciplined Agile (DA) has a team lead role instead of  Scrum master or project manager.  The answer is three-fold: different types of teams require different types of leaders, leadership responsibilities vary based on the type of team they are leading, and DA strives to be agnostic wherever possible.  Let's explore the implications of this strategy.  

Team lead is what is known as a meta role.  What we mean by this is that there are different types of team lead depending on the situation, as depicted in Figure 1.  Think of team lead as a place holder for a more specific type of lead.  So, a scrum master is a team lead of a Scrum team, a project leader is a team lead of a project team, a sales manager is a team lead of a sales team. At times, the team will choose to stick with the name “team lead” for the role due to their way of working best fitting that description. 

Figure 1. Types of team leads.

Disciplined Agile Team Lead Role

As I said above, there are three reasons for taking this approach with the team lead role:

  1. Different teams require different types of leads.  A Scrum team needs a scrum master, or better yet a senior scrum master, as team leader. Similarly, a project team needs a project manager or project leader.  A finance team or a sales team need a function manager such as a chief financial officer or a sales manager respectively as the team lead. Each type of team needs a team lead that is fit for purpose. Because all these teams (and many more) are part of Disciplined Agile, we cannot prescribe a single type of team lead.  
  2. Leadership responsibilities will vary across teams. The responsibilities of team leads will vary depending on the type of team they lead. For example, when leading a team a project manager takes on different responsibilities compared to a scrum master.  Similarly, a sales manager leading a team would have responsibilities around educating business leaders on the sales strategy that a project leader typically wouldn't have.   
  3. Being agnostic.  Let’s imagine for a moment that it made sense to have a single set of responsibilities for the team lead role. Which one should it be? Adopting the scrum master role would only fit Scrum teams. Similarly, adopting the project manager role would only fit project teams. In the end, either choice ends limiting the applicability of the Disciplined Agile tool kit. Remember that DA is a hybrid approach that opens your options by combining great ideas from a wide range of sources: some agile, some lean, and some traditional. Ultimately, leading teams appropriately to a better way of working.  

The end result is that you may see some DA teams with a senior scrum master as the team lead, some DA teams with a project leader as a team lead, some DA teams with a functional leader in the role of team lead, and some teams with someone who is simply the team lead. Just like your way of working (WoW) should be fit for purpose, so should your approach to roles and responsibilities.

Posted by Scott Ambler on: July 07, 2020 09:13 AM | Permalink | Comments (7)

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)

How Do You Choose Between Software Lifecycles?

 

Confused

As you know the Disciplined Agile (DA) toolkit supports several delivery lifecycles – Agile, Lean, Continuous Delivery: Agile, Continuous Delivery: Lean, Exploratory, and Program.  We do this because solution delivery teams face different situations, so one lifecycle will not fit all.  This begs the question of when would a team adopt each lifecycle?  That is the focus of this blog.

This blog explores the following topics:

  1. What lifecycles does DAD support?
  2. What criteria should you consider when choosing a lifecycle?
  3. Who chooses?

What Lifecycles Does DAD Support?

The delivery lifecycles we will explore are:

  1. Agile. DAD’s Agile lifecycle which extends Scrum’s construction lifecycle. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re taking an agile project approach.
  2. Advanced. The Lean lifecycle encompasses lean strategies such as minimizing work in process, maximizing flow, a continuous stream of work (instead of fixed iterations), and reducing bottlenecks. New work is pulled from the work item pool when the team has capacity.
  3. Continuous Delivery: Agile.  The Continuous Delivery: Agile lifecycle  is a natural progression from the Agile lifecycle. Teams typically evolve to this lifecycle from the Agile/Basic lifecycle, often adopting iteration lengths of one-week or less. The key difference between this and the Agile lifecycle is that the continuous delivery lifecycle results in a release of new functionality at the end of each iteration rather than after a set of iterations.
  4. Continuous Delivery: Lean. DAD’s Continuous Delivery: Lean lifecycle is basically a leaner version of the Continuous Delivery: Agile lifecycle where the product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too.
  5. Exploratory/Lean Startup.  DAD’s Exploratory lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.
  6. Program. DAD’s Program lifecycle describes how to coordinate a team of teams.  It is very similar to the LeSS lifecycle although does not prescribe that the subteams/squads need to be following Scrum.  It can also be thought of as a simplified version of the SAFe lifecycle.
  7. Waterfall/Serial.  Although this is not supported by Disciplined Agile, we do recognize that some teams will still follow this more traditional way of working.  For more thoughts on this subject, please see the blog posting When Does Traditional Software Development Make Sense?

 

What Criteria Should You Consider When Choosing a Lifecycle?

The following table compares the lifecycles, suggesting when you would choose to follow each one.

Lifecycle Team Type Time to Market Advantages Disadvantages When to Use
Agile Project Medium
  • Straightforward lifecycle based on Scrum that is easy to learn due to its prescription
  • Iterations (sprints) motivate teams to build functionality in multi-week batches
  • Releases into production typically months apart
  • Tends to fall apart when requirements change often
Teams new to agile
Lean Project Fast
  • Functionality is released into production when it`s ready to go
  • Work can be prioritized via a variety of criteria
  • Small batches of work lead to quick flow
  • Requires greater skill and discipline compared to the Agile lifecycle
Disciplined teams with quickly evolving requirements
Continuous Delivery: Agile Product (long lived) Fast
  • Functionality is released into production regularly at a steady flow (typically weekly)
  • Requires significant skill and discipline
  • Requires automated testing, integration, and deployment
Long-running teams
Continuous Delivery: Lean Product (long lived) Very Fast
  • Functionality is released into production continuously, typically one or more times a day
  • Requires significant skill and discipline
  • Requires automated testing, integration, and deployment
Long-running, disciplined teams
Exploratory/Lean Startup Experimental Fast
  • Quick and inexpensive way to run business experiments
  • Low-risk approach to validating potential new business strategies
  • Requires a way to target a subset of your (potential) customer base
  • Often not applicable in regulatory compliance situations
  • Often perceived as a strategy for startup companies only
Identification of a new product or service offering for the marketplace where there is a high risk of misunderstanding the needs of potential end users
Program (Team of Teams) Project Medium
  • Enables you to organize a large team of teams (yes, some problems require this)
  • Subteams/squads can choose their own WoWs
  • Coordination required between subteams
  • Requires solid experience with small teams first (if you can’t succeed with a small agile team, you have no hope with a large one)
When you have a very large agile project team that is organized into a “team of teams”
Waterfall/Serial Project Slow
  • Comfortable approach for experienced IT professionals who have not yet transitioned to an agile or lean way of working
  • Tends to be very high-risk in practice due to long feedback cycles and delivery of a solution only at the end of the lifecycle
  • Associated risks are often overlooked by management due to façade of predictability and control provided by the paperwork produced
Low-risk situations where the requirements are stable and the problem has a well-known solution.  For example, upgrading the workstations of a large number of users or migrating an existing system to a new platform

 

Who Should Choose the Lifecycle?

The team.

They will often do this with the guidance of an experienced Disciplined Agile coach, particularly when they are new to DA.  It’s tempting to have your portfolio management team to make this choice, and they may often make a (hopefully solid) suggestion when the first initiated an endeavour, but in the end it needs to be the choice of the team.  As you see in the table above there are common considerations for when to use each lifecycle, but the primary considerations are always the skill and preferences of the team itself.

 

Related Reading

Posted by Scott Ambler on: August 03, 2017 11:37 AM | Permalink | Comments (0)

Disciplined Agile Terminology

Argument

This brief article explains our thinking around our terminology choices in the Disciplined Agile (DA) toolkit. It overviews the terminology principles that we follow, discusses why Scrum terminology isn’t appropriate, and maps common Scrum terms to DA terms.

 

Our Principles Around Terminology

The following three principles drive our terminology decisions:

  1. Terms must be clear. If you need to explain the term, it likely isn’t the best. For example, how many times have you had to explain what a Scrum meeting is? Call it a coordination meeting instead, and people have a much better idea of what’s going on.
  2. Terms must be method neutral. Every team is unique and owns its own process. Part of owning your process is choosing the overall method, or lifecycle, that you’re following. Because the DA toolkit is a hybrid that leverages a variety of methods, were we to adopt one method’s terminology over another it would only make sense for people following that lifecycle. For example, Scrum terminology makes sense if you’re following the Scrum-based Agile/Basic lifecycle but not the Lean Continuous Delivery lifecycle.
  3. Terms should already be in use elsewhere. We are not in the business of creating new terms when existing ones are perfectly fine.

 

The Problem with Scrum Terminology

Many people ask us why we don’t simply use Scrum terminology. We originally wanted to, because that would be the easy thing to do, but we quickly realized that Scrum terminology just doesn’t get the job done for three reasons:

  1. It doesn’t apply in all situations. For example, the term “sprint retrospective” doesn’t really make sense when you’re following a lean lifecycle that doesn’t have the concept of sprints/iterations. Furthermore, it breaks principle #3 above in that the Scrum folks tacked “sprint “onto the front of the existing term “retrospective” to brand it with Scrum marketing.
  2. It was motivated by marketing reasons. The Scrum originators purposely chose unusual terms such as sprint, Scrum Master (later concatenated to ScrumMaster), and Scrum meeting to signal to people that Scrum was different. Well, in DA we’re purposely choosing pragmatic terminology to signal to people that it’s time to up our game as software professionals.
  3. It reflects 1990s thinking. There’s nothing wrong with that per se, other than the fact that we have learned a lot the following decades that we can apply.

 

Mapping Scrum to Disciplined Agile Terms

The following table maps common Scrum terms to the terms that we prefer in DA. As you can see, the mapping is very straightforward.

 

Scrum Term DA Term DA Source Observations
Backlog refinement/grooming Look-ahead modeling
  • “Modeling” is common IT terminology.
  • “Look-ahead modeling” is an existing Agile Modeling practice
  • Not all teams have backlogs.
  • The term isn’t clear (one reason why it evolved from backlog grooming to backlog refinement a few years ago)
Mapping Modeling
  • Common IT terminology
  • Agilists really need to get over their cultural issues around modeling and documentation
  • There is a wealth of material about effective modeling strategies that many agilists are unaware of because they search on terms such as mapping or grooming instead of modeling
Scrum Master Team Lead
  • Common IT terminology
  • Only Scrum teams have Scrum Masters
  • The term “Scrum Master” isn’t descriptive of what someone in that role does
  • The responsibilities of a Team Lead are a bit more robust than those of a Scrum Master, so this mapping isn’t perfect
Scrum meeting Coordination meeting
  • Common terminology
  • Coordination meeting is a much clearer term
Sprint Iteration
  • Iteration is used as a term in XP, Agile Modeling, Unified Process and many others
  • The term sprint is ok, but it doesn’t reflect the agile principle of maintaining a steady pace (you don’t sprint through a long race)
Sprint demo Demo
  • Common IT terminology
  • You can hold a demo at any time, not just at the end of a sprint
Sprint Retrospective Retrospective
  • Original term for the technique
  • You can hold a retrospective at any time, not just at the end of a sprint

 

Parting Thoughts

There is no standard terminology in the agile world, nor will their ever be. Your team, as part of owning your process, will need to decide which terms they prefer to use. We’ve seen many DA teams choose to use Scrum terminology (e.g. sprint instead of iteration) because they originally started with Scrum and that’s what they’re familiar with. That’s their decision and as always our advice is for a team to do what they believe to be right for the situation that they find themselves in.

Posted by Scott Ambler on: September 05, 2016 07:29 AM | Permalink | Comments (0)

Disciplined Agile Extends Scrum

Categories: Scrum

Written by Kaushik Saha, Certified Disciplined Agile Coach (CDAC)

Many people focus on Scrum process framework when they talk about Agile because of several reasons:

  1. Scrum is a lightweight method
  2. Scrum is an improved process framework
  3. Scrum is a very focused approach and event-driven
  4. Scrum is easy to understand

But we must extend beyond Scrum wherein agile can be implemented in lean way and the Scrum could be one approach for the execution the construction phase.  Disciplined Agile Delivery (DAD) takes a “hybrid” approach and beginning-to-end approach that extend Scrum’s Construction lifecycle to explicitly address the full delivery lifecycle.  Disciplined Agile calls out three light-weight phases:

  1. Inception –> Inception is a pre-Sprint phase in terms of Scrum which can talk about envisioning and planning where you  develop a common vision with stakeholders ; initial release planning; initialize the environment and infrastructure; identify initial risks; and adopt a goal-driven, non-prescriptive approach to development.
  2. Construction –> During Construction the team incrementally and iteratively builds business value in the form of a potentially shippable, or better yet consumable, solution each iteration.
  3. Transition –> During Transition you ensure that the solution is ready to be shipped and then ship it.

 Comparing Scrum and DAD:

  1. Scrum delivery is focuses on “working software” but DAD goes further for a “complete end-to-end solution“.
  2. Scrum is prescriptive, but DAD is pragmatic.
  3. DAD is easily tailored.
  4. Scrum focuses only on “Construction” phase; but DAD includes Inception. Construction, and Transition phases.
  5. Scrum is targeted from single team to multiple teams. DAD goes further to be scalable at both the tactical and strategic levels.
  6. Scrum is one approach process framework, but DAD is a Hybrid Framework that includes several lifecycles:  Agile (Scrum-based), Lean (Kanban-based), Continuous Delivery:Agile, Continuous Delivery: Lean, Exploratory (Lean Startup), and Program (team of teams).

The DAD Approach brings Agile and Lean Practices under one umbrella:

  • DAD applies Lean development principles to enable scaling, wherein system can be optimized as whole by eliminating non-value added activities and build the quality inside with amplifying learning.
  • DAD also adopts visualization of Kanban workflow to measure & manage flow of work by limiting work-in-progress.
  • DAD’s Agile lifecycle applies the Scrum process framework in the Construction phase.
  • DAD brings XP engineering practices in the Construction phase to reduce feedback cycle and develop quality code faster.

 

Posted by Scott Ambler on: March 29, 2016 04:35 PM | Permalink | Comments (0)
ADVERTISEMENTS

"Failure is unimportant. It takes courage to make a fool of yourself."

- Charlie Chaplin

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events