Category Archives: Scrum

Disciplined Agile Terminology

Argument

This brief article explains our thinking around our terminology choices in the Disciplined Agile (DA) framework. 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 framework 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.

Disciplined Agile Extends 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 four lifecycles:  Basic Agile (Scrum), Lean/Kanban, Continuous Delivery, and Exploratory (Lean Startup).

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.

 

Right-sizing your agile process? Start in the Middle

Is your organization concerned with the cost and time required to adopt agile strategies?  Are you just starting out with agile and hoping to improve your chances of success by learning from the experiences of those who have gone before you?  Are you part way into your agile transformation but struggling to figure out how it all fits together?  If you answered yes to any of these questions please read on.

In this blog posting we discuss what it means to “right size” your software process to meet the needs of the unique situation that your team finds itself in.  We discuss two common anti-patterns: starting with a process framework that is much too large for your needs and starting with one that is far too small for your needs.  We argue that it’s much better to avoid these extremes and instead take a middle-ground approach by starting with a framework that is much closer to your actual needs.

Extreme #1: Large process repository

The first process right-sizing anti-pattern is to start with a large process repository, the classic example being IBM’s Rational Unified Process (RUP).  Although RUP is much maligned within the agile community the fact is that if you were to examine it with an open mind that there are many very good ideas promoted by RUP.  Be that as it may. The basic strategy with RUP is that you need to tailor down the process, often dramatically, to meet the unique needs of the situation your team finds itself in.  To do this requires significant process expertise, time, and money.
Right Sizing RUP
In practice, however, many organizations ran aground with RUP when they tailored it to be something similar to the waterfall-style processes from yesteryear that they were familiar with.  This is often referred to as RUPifall.  Another common mistake was to say to themselves “wow, there’s a lot of great ideas here, we need to do them all” and as a result they would create a process that was far too heavy to meet their needs.  In either case the problem was that they often didn’t have the process expertise required to right-size their process.  We also see this with organizations starting from frameworks such as ITIL, COBIT, and CMMI so this clearly isn’t just a RUP problem.

Extreme #2: Small methodology

At the other extreme is the right-sizing anti-pattern of starting with a small methodology, the classic example in this case being Scrum.  Although there is significant support for Scrum within the agile community, or at least among people who are new to agile, we’ve been seeing for a long time now that organizations are also running into trouble with this approach too.  With Scrum the idea is that you add in the techniques that Scrum doesn’t address to right-size your process.  Because Scrum proves to be only a very small part of the overall picture, to do this requires significant process expertise, time, and money.
Right Sizing Scrum
In practice organizations run aground with Scrum because they don’t have the process expertise to expand it to meet their needs.  One only has to count the number of “How does X fit into Scrum?” conversations occurring in agile discussion forums online, or at user group meetings or conferences, to see that this is true.  Step back for a moment and ask yourself how much time and effort has your organization invested in trying to adopt Scrum.  Could it not have been more streamlined?

A few years ago Forrester Research discovered that the majority of organizations “doing Scrum” had actually tailored it into what they called Water-Scrum-Fall (others call this Scrumifall).  As we describe in Going Beyond Scrum this occurs for several reasons.  First, Scrum doesn’t address the full delivery lifecycle, instead choosing to focus on the construction portion of it.  As a result organizations tend to stick with what they know, a heavy project initiation phase and a heavy solution deployment phase.  Second, Scrum only addresses only a small portion of what you need and explicitly leaves technical issues up to you.  These issues include topics such testing, programming, architecture, governance, documentation, deployment and many others.  As a result teams are left to piece together a process strategy that works for them, at the very same time that they’re struggling to understand the fundamentals of agile and lean software development.  They rarely have the process expertise to do that and as a result end up having to hire hordes of expensive Scrum coaches, few of whom seem to understand the enterprise-class realities that your teams actually face.  This is a risky and expensive proposition indeed.

The Effective Middle Ground

Both of these anti-patterns represent extremes: start with something large and cut it down to size, or start with something small and build it up to meet your needs.  Why not start with something much closer to what you actually need?  Doesn’t that make a lot more sense?  Why do you need to do all this process work?  Because someone wants to sell you tooling?  Because someone else wants to sell you expensive coaching and questionable certification strategies?  Isn’t it time to consider a more pragmatic strategy?

The Disciplined Agile Delivery (DAD) framework is a more effective middle ground.  It addresses the full delivery lifecycle, as does RUP (but not Scrum), and even gives you several choices from which to select.  Sometimes a Scrum-based lifecycle is appropriate, sometimes a Lean lifecycle is, other times a continuous delivery lifecycle is best, and sometimes an exploratory “lean start up” lifecycle is.  Different teams, different situations.  DAD starts with a lightweight approach, as does Scrum but not RUP, helping you to avoid the bloatware of RUP and filling in the numerous blanks left by Scrum.  DAD also gives you lightweight tailoring advice in the form of process goal diagrams, in many ways a cross between mind-maps and decision trees, that make your process choices explicit.  The RUP process tailoring advice, if you bother to read it at all, is rather heavy handed and the Scrum tailoring advice boils down to “you’re smart, you can figure it out and if your run into trouble hire a coach.”  Isn’t it time to abandon the extremes?

Right Sizing Disciplined Agile Delivery
This middle ground strategy isn’t without its faults.  A challenge with DAD is that it explicitly reveals that agile software development, or as we prefer to say agile solution delivery, is complex.  This is particularly true in enterprise-class situations where teams are often facing combinations of scaling factors such as larger team size, geographic distribution, and regulatory constraints.  DAD makes it explicit that teams need to invest a bit of time up front to perform initial scoping, initial architectural modeling, and initial planning (all in a lightweight manner of course).  This sort of pragmatic thinking can be inconvenient for less-experienced developers who just want to jump in and start coding.  Because DAD promotes the philosophy of enterprise awareness it purposely bakes in strategies for governance, DevOps, and working with IT-level groups such as your enterprise architects and data management team to name a few.  This can also prove to be inconvenient for developers who want to narrowly focus on doing what’s convenient for their team as opposed to what’s best for their organization.

In Summary

The following infographic summarizes the main points in this blog posting.
Right Sizing Your Agile Process
We hope that you’ve found this blog posting enlightening.  Even if you are well along the way of your Scrum adoption, or of evolving your RUP-based approach, you can still benefit from switching over to DAD.  Scrum teams will find that it addresses many of the issues that you’re still struggling with, and RUP teams will find that it shows how to work in a far more lightweight manner.  Organizations will find that it provides a much better foundation from which to scale agile strategies.

Potentially Shippable Software Isn’t Sufficient: The Glass of Water Analogy

Waterglass

At the end of July I spoke at the Agile 2014 conference in Orlando about what it means to be an agile enterprise.  Part way through that presentation I spoke about the differences between producing potentially shippable software, one of the mantras of the Scrum community, and potentially consumable solutions as promoted by DAD.  To do this I walked people through what I call the glass of water analogy.  Here’s how it went:

I had a glass of drinking water.  I took a sip from the glass to verify that the water was clean and the right temperature for drinking.  The water was very refreshing and was something that I thought others would enjoy.  It was my opinion that this glass of water was potentially shippable.  I took another sip and then offered the water to the audience, there was over 200 people in the room, yet nobody was willing to drink from my glass.  Shocking! I even singled someone out and tried to bully him into drinking my water (oops, I mean I aggressively marketed the wonderfulness of the water to him).  Still, nobody wanted to drink the water.   I took another sip and verified that it was in fact still refreshing.  It was clear to me that my glass of water was potentially shippable.  I could very easily have walked over to anyone in the room and they could easily have drunk from the glass.  But everyone chose not to.  It was potentially shippable from my point of view, but from the point of view of every single audience member it wasn’t consumable.  In a venue where drinks are easily available, not a single person was willing to drink from my water glass (I assume due to a fear of catching my cooties).  Had the venue been different, perhaps a desert with no other sources of drinkable liquids,  someone might have been interested.

The point is that creating potentially shippable software isn’t sufficient.  It needs to be something that people actually want to use, to consume.  It must be a true solution that adds real value for them given their current situation.  Cootie-laden water isn’t attractive when other drinks are readily available.  Similarly, software that is difficult to use compared to other options, that isn’t well supported as other options, or that doesn’t enhance the way that people want to work isn’t going to be very attractive either.

Disciplined agilists focus on producing potentially consumable solutions.  High-quality software is clearly part of this, but that software needs to be usable and something that people want to use.  It needs to be supported with sufficient documentation.  It needs to be supported with adequate hardware.  It may even be part of an overall change to the business process and even organizational structure of the people using that software.  

“Potentially shippable software” is a wonderful slogan, but we need to do a lot better than that. 

Successful Agile Software Development Requires a Hybrid Approach

Hybrid

Disciplined Agile Delivery (DAD) is a hybrid framework that builds upon the solid foundation of other methods and software process frameworks.  The DAD framework adopts practices and strategies from existing sources and provides advice for when and how to apply them together.  In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DAD the mortar to fit the bricks together effectively.

The DAD framework adopts strategies from the following sources:

  • Scrum.  The Scrum method focuses on team leadership and requirements change management during the construction portion of the delivery lifecycle.  Scrum captures some really great ideas that have become commonly adopted by agile teams.
  • Extreme Programming (XP). XP is an agile method that focuses primarily on construction-oriented practices such as continuous integration (CI), test-driven development (TDD), pair programming, sustainable pace, small releases, simple design, and many others.  Although XP’s practices appear straightforward on the surface, many of them require significant technical skill and discipline on the part of practitioners.
  • Lean software development.  Practitioners of agile development are increasing looking to adapt ideas from lean thinking.  Lean software development is based on seven principles: Eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole.
  • Kanban.  Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is visualized and team members pull work from a queue or work item pool.
  • Unified Process (UP).  The UP is an iterative and incremental process framework for software development.  Although often instantiated as a heavy-weight approach, it has in fact been instantiated in a very light weight and agile manner, particularly in the form of Agile Unified Process (AUP) or OpenUP.  The DAD framework adopts and enhances several critical governance strategies from the UP.
  • Agile Modeling (AM).  AM is a practice-based methodology for effective modeling and documentation of software-based system. AM was purposely architected to be a source of strategies which can be tailored into other base processes, something the DAD framework takes explicit advantage of.   AM strategies adopted by DAD include initial requirements and architecture envisioning, just in time (JIT) model storming, continuous documentation, and several others.
  • Agile Data.  The Agile Data (AD) method defines a collection of strategies that IT professionals can apply in a wide variety of situations to work together effectively on the data aspects of software systems. Practices for evolutionary/agile database development include database refactoring, database regression testing, agile data modeling, and continuous database integration.
  • Enterprise methods. DAD is starting to adopt strategies from enterprise IT methods such as Scaled Agile Framework (SAFe) and Enterprise Unified Process (EUP).  These strategies address enterprise architecture, product management, portfolio management, operations and support, release management and other important IT disciplines. These strategies reflect the DAD philosophy of enterprise awareness.
  • Other methods.  DAD adopts techniques and practices from other methods such as Dynamic System Development Method (DSDM), Feature Driven Development (FDD), Evo, Outside-In Development (OID), and Crystal Clear.
  • Agile development practices.  There are many practices that are not specific to agile methods that have been developed within the agile community, and DAD leverages many of them.

One of the great advantages of agile and lean software development is the wealth of practices, techniques, and strategies available to you.  This is also one of its greatest challenges because without something like the DAD framework it’s difficult to know what to choose and how to fit them together.

Whitepaper: Going Beyond Scrum

Going Beyond Scrum

This paper describes, step-by-step, how to evolve from today’s Scrum vision of agile software development to a disciplined agile solution delivery.  It begins with a brief overview of the agile software development movement and its implications.  We then overview the Scrum method with its associated benefits and drawbacks, and then how to move beyond Scrum to a full delivery process framework called Disciplined Agile Delivery (DAD).  DAD is a governed, hybrid approach that provides a solid foundation from which to scale agile solution delivery within enterprise-class organizations.    The steps to do this are:

  1. Focus on consumable solutions, not just potentially shippable software
  2. Extend Scrum’s construction lifecycle to address the full delivery lifecycle
  3. Move beyond method branding
  4. Adopt explicit governance strategies
  5. Take a goal-based approach to enable tailoring and scaling

You can download the paper here.

Good Practices Are Small, Cohesive, and Loosely Coupled

lego1

A few people have commented that Disciplined Agile Delivery (DAD) promotes a wide range of practices, which they like because it makes their options explicit but which they also potentially dislike because there’s so many practices to choose from.  This then leads to the question of why do we need so many practices?  First, there are a lot of practices out there to begin with and our philosophy is to help people know that they have options and help them to select the right ones.  Second, our experience is that for a practice to be easily consumable it should be:

  1. Small.  Small practices are generally more straightforward than larger practices.  As a result they’re easier to understand and to adopt.
  2. Cohesive.  A good practice addresses one issue and one issue only.
  3. Loosely coupled.  Good practices, like good software modules, have minimal dependencies on other practices.

Practices that are small, cohesive, and loosely coupled are easier to configure into more interesting solutions.  For example, the practice of test-first programming (TFP) is combined with refactoring to form test-driven development (TDD).  The practice of (writing) executable specifications can be combined with TDD, or TFP for that matter, to give you behavior driven development (BDD) or acceptance test-driven development (ATDD).  The combination of iteration modeling, model storming, look-ahead modeling, and BDD can give you a strategy for addressing emergent requirements and design during an iteration.

Of these three aspects, we’ve found that coupling has the greatest impact on your ability to tailor your approach to meet the unique situation you find yourself in.  Just like highly coupled software is difficult to maintain and enhance, processes built from highly-coupled practices are too.  For example, consider the way that Scrum describes product backlogs.  A product backlog is one of several strategies that agile teams may use to manage their work.  In the case of Scrum, the strategy is to prioritize requirements by business value and then focus on implementing the highest priority work at all times.   Unfortunately Scrum has coupled many important practices to the product backlog concept.  For example, initial requirements modeling is often referred to as populating the backlog.  Prioritization of new requirements and exploring upcoming requirements is referred to as grooming the backlog.   There are several potential problems to consider:

  1. The term “populating the backlog” masks the fact that not only are you writing initial functional requirements (for example user stories or features) as part of your initial requirements modeling efforts you’re also sketching things (processes, screens, data structures, …), identifying non-functional requirements, holding modeling sessions, and many other things.
  2. It makes it harder for people new to agile to understand how it works.  Think of it like this, what’s a more descriptive term, “populating the backlog” or “initial requirements modeling”?
  3. It makes it harder to combine practices.  If you wanted to swap out the product backlog for something a bit more sophisticated, such as a work item list, or something leaner like a work item pool, what do you do with the practices coupled to product backlog?  Do you  rework “backlog grooming” to be “work item list grooming”?  Do you rework “populating the backlog” to be “populating the work item pool”?  Even if these things are easy to do, seems like needless effort to me.

In conclusion, we have found that adopting small, cohesive, and loosely coupled practices enables you to adopt and tailor a process strategy that better reflects the context of the situation that you face.    Not only is high cohesion and loose coupling great strategies for software, their great strategies for software process too.