Introduction to DAD

Many organizations start their agile journey by adopting Scrum because it describes a good strategy for leading agile software teams.  However, Scrum is only part of what is required to deliver sophisticated solutions to your stakeholders. Invariably teams need to look to other methods to fill in the process gaps that Scrum purposely ignores.  When looking at other methods there is considerable overlap and conflicting terminology that can be confusing to practitioners as well as outside stakeholders.  Worse yet people don’t always know where to look for advice or even know what issues they need to consider.

To address these challenges the Disciplined Agile Delivery (DAD) process decision framework provides a more cohesive approach to agile solution delivery.  To be more exact, here’s a definition:  “The Disciplined Agile Delivery (DAD) process decision framework  is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.”

There are clearly some interesting aspects to the DAD framework.  DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods.  DAD is a non-proprietary, freely available framework.  DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users.  It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all.  DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP.  But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach.  In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you.

People First: Roles in Disciplined Agile Delivery

The DAD framework suggests a robust set of roles for agile solution delivery.  These roles are overviewed in the following figure:

DAD Roles

A common question that we get is what is the difference between primary and secondary roles?  Primary roles will occur on all DAD projects regardless of scale.  Secondary roles, however, typically occur only at scale and sometimes only for a temporary period of time.  Another common question that we do get is why are there so many roles?  For example, Scrum has three roles – ScrumMaster, Product Owner, and Team Member – so why does DAD need ten?  The primary issue is one of scope.  Scrum mostly focuses on leadership and change management aspects during Construction and therefore has roles which reflect this.  DAD on the other hand explicitly focuses on the entire delivery lifecycle and all aspects of solution delivery, including the technical aspects that Scrum leaves out.  So, with a larger scope comes more roles.  For example, because DAD encompasses agile architecture issues it includes an Architecture Owner role.  Scrum doesn’t address architecture so doesn’t include such a role.

For more detail about these roles, see the blog posting Roles in Disciplined Agile Delivery.

A Hybrid Framework

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.

Hybrid

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.

A Full Delivery Lifecycle

The focus of DAD is on delivery, although how other aspects of the system lifecycle affect the delivery lifecycle are also addressed.  A full system/product lifecycle goes from the initial idea for the product, through delivery, to operations and support and often has many iterations of the delivery lifecycle.  The following diagram a high-level view of the DAD lifecycle.  It is a three-phase lifecycle where you incrementally build a consumable solution over time.

Disciplined Agile Lifecycle - High Level

Obviously there’s more to it than what the high-level diagram shows.  DAD, because it’s not prescriptive and strives to reflect reality as best it can, actually supports several versions of a delivery lifecycle.  Four versions of the lifecycle follow:

  1. An agile/basic version that extends the Scrum Construction lifecycle with proven ideas from RUP;
  2. An advanced/lean lifecycle;
  3. A lean continuous delivery lifecycle;
  4. An exploratory “Lean Startup” lifecycle.

Disciplined Agile Lifecycle Basic

Disciplined Agile Lifecycle Advanced

Disciplined Agile Lifecycle Continuous Delivery

 

Disciplined-Agile-Lifecycle-Exploratory.jpg

 

DAD teams will adopt a lifecycle that is most appropriate for their situation and then tailor it appropriately.  For more about this topic, read A Full Agile Delivery Lifecycle.

Goal-Driven

DAD’s goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods.  For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs.  DAD then indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so.  DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for.  Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.

In the DAD book we described goals in a non-visual manner using tables which explored the advantages and disadvantages of the techniques associated with an issue.  In the second half of 2012 we began expanding on this approach and developed a way to represent goals in a visual manner using what we call a goals diagram (see Disciplined Agilists Take a Goal-Driven Approach for a detailed discussin of the notation).

Let’s work through some examples.  The following figure depicts the goal diagram for Explore Initial Scope, a goal that you should address at the beginning of a project during the Inception phase (remember, DAD promotes a full delivery lifecycle, not just a construction lifecycle).  Where some agile methods will simply advise you to populate your product backlog with some initial user stories the goal diagram makes it clear that you might want to be a bit more sophisticated in your approach.  What level of detail should you capture, if any (a light specification approach of writing up some index cards and a few whiteboard sketches is just one option you should consider)?  What view types should you consider (user stories are one approach to usage modeling, but shouldn’t you consider other views to explore the data or the UI)?  Default techniques, or perhaps more accurately suggested starting points, are shown in bold italics.  Notice how we suggest that you likely want to default to capturing usage in some way, basic domain concepts (e.g. via a high-level conceptual diagram) in some way, and non-functional requirements in some way.  There are different strategies you may want to consider for going about modeling.  You should also start thinking about your approach to managing your work.  In DAD we make it clear that agile teams do more than just implement new requirements, hence our recommendation to default to a work item stack over Scrum’s simplistic Product Backlog strategy.  Finally the goal diagram makes it clear that when you’re exploring the initial scope of your effort that you should capture non-functional requirements – such as reliability, availability, and security requirements (among many) – in some manner.

Goal - Inception - Explore Initial Scope

There are several fundamental advantages to taking a goal driven approach to agile solution delivery.  First, a goal-driven approach supports process tailoring by making process decisions explicit.   Second, it enables effective scaling by guiding you through tailoring your strategy to reflect the realities of the scaling factors which you face.  Third, it makes your process options very clear and thereby makes it easier to identify the appropriate strategy for the situation you find yourself in.  Fourth, it takes the guesswork out of extending agile methods and thereby enables you to focus on your actual job which is to provide value to your stakeholders.  Fifth,  it makes it clear what risks you’re taking on and thus enables you to increase the likelihood of project success.  Sixth, and this may not be a benefit, it hints at an agile maturity model.

Disciplined Agile Teams are Enterprise Aware

Enterprise awareness is one of the key aspects of the Disciplined Agile Delivery (DAD) framework.  The observation is that DAD teams work within your organization’s enterprise ecosystem, as do all other teams.  There are often existing systems currently in production and minimally your solution shouldn’t impact them.  Better yet your solution will hopefully leverage existing functionality and data available in production.   You will often have other teams working in parallel to your team, and you may wish to take advantage of a portion of what they’re doing and vice versa.  Your organization may be working towards business or technical visions which your team should contribute to.  A governance strategy exists which hopefully enhances what your team is doing.

Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you. Teams developing in isolation may choose to build something from scratch, or use different development tools, or create different data sources, when perfectly good ones that have been successfully installed, tested, configured, and fine-tuned already exist within the organization.  Disciplined agile professionals will:

  • Work closely with enterprise professionals, such as enterprise architects and portfolio managers.
  • Adopt and follow enterprise guidance.
  • Leverage enterprise assets, including existing systems and data sources.
  • Enhance your organizational ecosystem via refactoring enterprise assets.
  • Adopt a DevOps Culture.
  • Share learnings with other teams.
  • Adopt appropriate governance strategies, such as the ones described here, including open and honest monitoring.

Enterprise awareness is important for several reasons.  First, you can reduce overall delivery time and cost by leveraging existing assets.  In other words, DAD teams can spent less time reinventing the wheel and more time producing real value for their stakeholders.  Second, by working closely with enterprise professionals DAD teams can get going in the right direction easily.  Third, it increases the chance that your delivery team will help to optimize the organizational whole, and not just the ”solution part” that it is tasked to work on.  As the lean software development movement aptly shows this increases team effectiveness by reducing time to market.

DAD Provides The Foundation for Scaling Agile

The following figure overviews the basic strategy that I led the development of when I was with IBM Rational.  The fundamental observation was that many organizations were struggling with how to scale agile methods, in particular Scrum.  We felt that the first step was to identify how to successfully develop a solution from end-to-end.  Although mainstream agile methods clearly provided a lot of great strategies, there really wasn’t any sort of glue beyond consultantware (e.g. hire me and I’ll show you how to do it) putting it all together.  This is where the DAD framework comes in, but that’s only a start as you also need to tailor your approach to reflect the context in which you find yourself.

Scaling Agile

The DAD framework provides a better foundation for scaling agile in several ways.  First, it promotes a risk-value lifecycle the riskier work early in an endeavor in order to help eliminate some or all of the risk, thereby increasing chance of project success.  Some people like to refer to this as an aspect of “failing fast” although we like to put it in terms of  succeeding early.  Second, DAD promotes self organization enhanced with effective governance based on the observation that agile project teams work within the scope and constraints of a larger, organizational ecosystem.   As a result DAD recommends that you adopt an effective governance strategy that guides and enables agile teams.   Third, DAD promotes the delivery of consumable solutions over just the construction of working software.  In addition to producing software DAD teams also create supporting documentation, they need to upgrade and/or redeploy the hardware the software runs on, they potentially change the business process around the usage of the system, and may even affect changes to the organization structure of the people using the system.  Forth, as described earlier DAD promotes enterprise awareness over team awareness.  Fifth, DAD is context-sensitive and goal driven, not prescriptive.  One process size does not fit all, and effective teams tailor their strategy to reflect the situation they find themselves in.

Now let’s examine what it means to scale agile.  When many people hear “scaling” they often think about large teams that may be geographically distributed in some way.  This clearly happens, and people are clearly succeeding at applying agile in these sorts of situations (see some of the more recent evidence I’ve gathered that agile scales, as well as some of the older evidence), but there’s often more to scaling than this.  Organizations are also applying agile in compliance situations, either regulatory compliance that is imposed upon them or self selected compliance (such as CMMI and ISO).  They are also applying agile in a range of problem and solution complexities, and even when multiple organizations are involved (as in outsourcing).  The following figure summarizes the potential scaling factors that you need to consider when tailoring your agile strategy.

SDCF Scaling Factors

Parting Thoughts

The Disciplined Agile Delivery (DAD) process decision framework provides a pragmatic approach from which to scale agile strategies to address the unique situations team find themselves in.  DAD explicitly addresses the issues faced by enterprise agile teams that many agile methodologies prefer to gloss over.  This includes how to successfully initiate agile teams in a streamlined manner, how architecture fits into the agile lifecycle, how to address documentation effectively, how to address quality issues in an enterprise environment, how agile analysis techniques are applied to address the myriad of stakeholder concerns, and many more.

Follow

Get every new post delivered to your Inbox.

Join 571 other followers