Author Archives: Mark Lines

Why Companies are Choosing DAD over SAFe

Scalability - canstockphoto19089920Not a week goes by where we are not asked to contrast DAD to SAFe.  In this short blog I would like to point out some things to consider as you decide whether to implement SAFe, DAD, or both.  First of all, a review of some quick facts about DAD:

  • DAD is a process decision framework, not a methodology.  It is a hybrid of leading agile and lean methods with guidance on how to make better choices when applying strategies for the situation that you find yourself in.  DAD can be summed up as “pragmatic agile“, giving you the flexibility to adapt your approach for your unique context.
  • DAD is not a scaling framework per se.  Indeed it can be equally effective on one small team as it is for agile at scale.  However mastering the DAD fundamentals of agile and lean in the enterprise dramatically increases your probability of sustainable success at scale.
  • Unlike other frameworks, DAD supports four lifecycles:  Agile/Scrum, Lean, Continuous Delivery, and Exploratory/Lean Startup.  Most if not all large organizations will find each of these lifecycles to be necessary in some situations.

SAFe provides a largely prescriptive approach to decomposing large initiatives into smaller streams of work which can be implemented by a number of teams in parallel with periodic integrations of their work and delivery to stakeholders.  SAFe does fill a need as our industry had been lacking such a pattern for scaling these large initiatives.  In our opinion, it is suitable for situations for large agile teams (say 100+) and are working on a cohesive product ideally based upon a shared architecture.  The teams should also be very competent and can be depended on to reliably deliver functionality on a common cadence with the other teams in their release train.  SAFe is definitely not a good fit for teams new to agile.

In the last few weeks I reached out to a couple of our customers at very large organizations to find out in their words why they selected DAD over SAFe.  In the first company, although they had been doing some agile in pockets over the last eight or so years, they were lacking consistency in their approach and struggling to achieve the promised benefits of agile.  They initially chose to rollout SAFe.  However, after training 120+ practitioners they stopped the training and chose to pivot to DAD.  They realized that SAFe was a poor fit for their organization for the following reasons:

  • The level of disruption required to roll out SAFe across the organization was not palatable
  • The investment in training and the overhead associated with running the SAFe program would be too high
  • SAFe would not be applicable to all types of projects so they would need another framework anyway.

In the second example, we spoke with a Fortune 100 company that is farther along in their agile journey with many highly advanced agile teams.  Their agile community of practice has over 1,700 members and they use many flavours of agile and lean.  They made a choice to go with DAD across the company rather than SAFe.  They do use SAFe in one area of business that has a large yet highly cohesive development team working on a common product.  But beyond this line of business they have a vast array of projects, technologies, and skill sets.  They chose DAD for the following reasons:

  • Enterprise practicality
  • A choice of four lifecycles supporting all flavors of agile yet having some consistency that a framework provides
  • Built-in, lightweight agile governance
  • Most of their development teams are geographically dispersed which would make SAFe impractical
  • Support for projects using more traditional approaches (Note: In the majority of large enterprises agile teams need to collaborate with traditional teams)

We of course understand DAD’s value proposition but it is particularly useful to hear it from real customers.  While we are pleased that SAFe has given us a pattern for scaling agile initiatives albeit in a largely rigid and prescriptive fashion, we encourage you to consider the following points before rolling it out aggressively across your organization:

  • Do you really need to have large projects?  A large organization does not necessarily equate to large development teams.  In fact you should try to reduce the size of your projects and product teams whenever possible to reduce overall risk.  In short, your first approach should be to “descale” to whatever degree possible because large projects typically fail.
  • DAD provides the foundation for scaling.  Without a solid base of enterprise agile capability it will be difficult to successfully adopt scaling frameworks such as SAFe or LeSS.  If you’re still struggling to succeed consistently on small agile teams, what makes you think you can succeed on large agile teams?
  • Agile governance built in.  Your sponsors don’t care what agile “religion” you follow.  They would however like to see consistent views on the health and status of your projects regardless of the implementation approach.  DAD provides guidance on lightweight governance in a consistent fashion.
  • DAD is pragmatic agile.  The framework provides rich and flexible guidance for the vast array of situations that your organization faces.  DAD does this through its process goal driven approach.  Choice is good.
  • One process does not fit all.  Beware the hype.  There is no silver-bullet process.  Even if you find a place to utilize SAFe, you will need other approaches.  So beware of hitting all projects with the SAFe sledgehammer.  It simply doesn’t fit in many if not most situations.

In a nutshell, our recommendation is to adopt the DAD framework to support the diversity of people, processes, and technologies found in any large organization.  Then apply the SAFe scaling pattern if and when it makes sense.  Not the other way around.

In an upcoming article we will be describing how you could apply DAD to help you be more successful in your SAFe implementations.

Reduce Agile Project Risk with Light-Weight Milestones

1380920263rwpocDAD incorporates a number of milestones into its lifecycles to gauge the progress and health of your DAD projects/releases.

Why does DAD have milestones?

Governance is largely absent from mainstream agile methods and many believe that agile does not need milestones.   Scrum orders its backlog with highest value work at the top of the stack.  At the end of each sprint (iteration) a decision is intended to be made whether or not the next sprint of work in the backlog provides sufficient value to fund another sprint.  If not, the project stops.  While in principle this strategy makes sense, as a replacement for governance it is flawed for several reasons:

  • Not sufficient.  There is much more to effective governance than deciding when to cease the funding of a project.  How did it get started in the first place for instance?
  • Not realistic.  In reality most organizations tend to fund releases comprised of many iterations rather than make explicit funding decisions at the end of each sprint.
  • Effectively a milestone.  While Scrum claims to not have milestones, pausing to consider if sufficient functionality exists to deploy, and to determine a go-forward strategy is implicitly a milestone.  DAD makes them explicit with guidance for how to effectively apply them.

Why do we need agile governance?

Contrary to what many believe, the need for governance does not disappear for agile initiatives.  Sponsors and other stakeholders deserve and indeed demand periodic updates on the status of their investments.  They want answers to questions like:

  • What will I get from my investment and will it be worthwhile?
  • Is what is being delivered consistent with the initial funding request?
  • What is the status of the outstanding risks and what is being done to mitigate them?
  • Is the current release timeline consistent with the original projection?
  • When will we have sufficient functionality to go live?
  • Are all stakeholders prepared to receive the release?
  • When will the project be finished?

Claims that agile is “different” and does not need to provide these answers is one of the reasons that agile is sometimes seen as being undisciplined.  In fact these claims are often used by some as an excuse why agile won’t work for them.  Fortunately, since DAD has built in mechanisms to facilitate answering these questions many organizations are extending their agile implementations to incorporate DAD’s guidance.  Indeed DAD is very appealing to those looking for a way to govern projects while still remaining agile.

Milestone Reviews Should Be Kept Informal

Consistent with the strategy recommended in the DAD goal Fulfill the Team Mission milestone reviews should be done in a lightweight manner.  They typically coincide with the end of iterations or phases when when using the Agile/Basic lifecycle.  If you are unsure why DAD has phases you might find the blog posting on the rationale interesting.

Milestone Dates Should Be Communicated

It is a good practice to provide a calendar to stakeholders with milestone dates for each DAD project so that they can plan to attend iteration reviews that coincide with milestone reviews that they are interested in.  While milestone dates may change, it is very useful to have target milestones across a portfolio of projects visible as a roadmap to all stakeholders.

The DAD Milestones

Milestones

Stakeholder Vision.  The goal of the Inception phase is to spend a short yet sufficient amount of time, typically one to four weeks in order gain stakeholder agreement that the initiative makes sense and to therefore continue into the Construction phase.  By addressing each of the DAD Inception goals the delivery team will capture traditional project information related to initial scope, technology, schedule, budget, risks, and other information albeit in as lightweight a fashion as possible.  This information is consolidated and presented to stakeholders as a Vision statement as described by the Develop Common Vision goal.  The format of the vision and formality of review with vary according to your situation.  A typical practice is to review a short set of slides with key stakeholders at the end of the Inception phase to ensure that everyone is on the same page with regard to the project intent and delivery approach.

Proven Architecture.  Early risk mitigation on a project is a part of any good project management discipline.  As the Prove Architecture Early process goal indicates, there are several strategies you may choose to adopt to do so.  The most effective of which is to build an end-to-end skeleton of working code that implements technically risky business requirements.  A key responsibility of DAD’s Architecture Owner role is to identify risks in the Inception phase.  It is expected that these risks will have been reduced or eliminated by implementing related functionality somewhere between one and three iterations into the Construction phase.  As a result of applying this approach early iteration reviews/demos often show the ability of the solution to support non-functional requirements in addition to, or instead of functional requirements.  For this reason it is important that architecture related stakeholders are given the opportunity to participate in these milestone reviews.

Project Viability.  An optional milestone to include in your release schedule is related to project viability.  At certain times during the project stakeholders may request a checkpoint to ensure that the project is progressing consistent with the vision agreed to at the end of Inception.  Scheduling these milestones ensures that stakeholders are aware of key dates wherein they should get together with the team to assess the project status and agree to changes if necessary.  These changes could include anything such as funding levels, team makeup, scope, risk assessment, or even potentially cancelling the project.  There could be several of these milestones.  If the stakeholders agree to changes the Vision may be updated at this time.  Scrum implicitly has this milestone at the end of each sprint.  DAD makes this an explicit choice and makes it’s frequency optional.

Sufficient Functionality.  While it is worthwhile pursuing a goal of a consumable solution (what Scrum calls a potentially shippable increment) at the end of each iteration, it is more common to require a number of iterations of Construction before the team has implemented enough functionality to deploy.  While this is sometimes referred to as a minimally viable product (MVP) this not technically accurate as classically an MVP is meant to test the viability of a product rather than an indication of minimal deployable functionality.  The more accurate term to compare to this milestone would be “minimum feature set”.  Regardless, many use the acronym to mean the latter.

DAD’s sufficient functionality milestone is reached at the end of the Construction phase when a sufficient functionality is available plus the cost of transitioning the release to stakeholders is justified.  As an example, while an increment of a consumable solution may be available every two week iteration, it may take two weeks to actually deploy it in a high compliance environment so the cost of transitioning the functionality may not be justified until a greater amount of functionality is completed.

Production Ready.  For non-trivial situations a formal Transition phase is often required to do final preparations as part of delivery of the solution to stakeholders.  Once sufficient functionality has been developed and tested, transition related activities such as data conversions, final acceptance testing, production and support related documentation normally need to be completed. Ideally much of the work has been done continuously during the Construction phase as part of completing each increment of functionality. At some point a decision needs to be made that the solution is ready for production.  Of course, if you’re following the continuous delivery lifecycle then the “Transition phase” has evolved into a “Transition activity” – regardless, someone still needs to ensure that the solution is consumable before you deploy the solution.

Delighted Stakeholders.  Governance bodies and other stakeholders obviously like to know when the initiative is officially over so that they can begin another release or direct funds elsewhere.  The initiative doesn’t end the day after deploying a solution to stakeholders.  There are often project closeout activities such as training, deployment tuning, support handoffs, post implementation reviews, or even warranty periods before the project is considered completed.  Lean has a term “delighted customers” which suggests that “satisfied” customers is setting the bar too low.  While DAD agrees, there are more stakeholders than just customers such as production support that we need to delight before we consider the project complete, thus the milestone name “delighted stakeholders”.

Give Milestones a Try

Agile promotes transparency and accountability to our stakeholders.  Take this to the next level by sharing and celebrating achievement of key milestones on your projects.

New DAD YouTube Channel

youtube

Looking for some great DAD video content?  Trying to find just the right video to show your boss why moving beyond Scrum to DAD makes sense?  Well we are happy to announce that there is now a DAD YouTube Channel which can be found here:  https://www.youtube.com/channel/UCcWJ20C86Mzxcsqb73AReHQ  Subscribe to keep up to date on the latest DAD talks and webinars.  There is also a new link to this channel at the DAD blog website on the sidebar.

We are looking for multilingual presentations so if you are aware of any let us know.  For now we have added a talk in Russian.

There is more to Agile Transformations than Implementing Scrum

SuccessFailureWith some basic agile training and help from an agile coach it can be relatively straightforward to enable several teams to be able to produce increments of consumable software every two weeks.  Unfortunately many organizations stop there, believing that they are “now agile”.

For enterprise agile adoptions starting a few agile teams is the easy part and is just the beginning of your agile transformation.  Proving the benefits and sustaining the change is significantly more challenging.

For illustration purposes, let’s assume that over a six month period we have conducted a series of Disciplined Agile workshops and kickstarted twelve teams.  The teams have separate product owners with their own work item lists.  Some of the teams use the DAD basic Scrum-based lifecycle while others use the DAD Lean lifecycle.  The Scrum teams adapt their lifecycle for their context with the simpler projects having a one week Inception phase while the more complex projects use a two week Inception.  For the Construction phase novice Scrum teams use two week iterations while the more advanced teams chose one week iterations.  The teams vary in size from four to twelve team members.  By rolling out the teams in an incremental fashion, with some coaching the teams have learned the key DAD practices for being effective on both the Scrum and Lean teams.  Word is spreading that the teams are impressing stakeholders with regular demonstrations of new functionality.

However, after the honeymoon period is over, people start to ask some interesting questions such as:

  • What are the limits of self-organization?  I understand that teams are free to customize their own processes but isn’t some consistency good across teams?
  • What are the key milestones for each team?  What is the release schedule for each team?  Are the teams on track for delivering the solution consistent with their Inception vision?  How do I see this information?
  • How do I know which teams have the greatest risks outstanding?
  • What is our product roadmap strategy across teams?
  • How do we measure the effectiveness of one team vs. another?
  • How do we measure the effectiveness of individual team members?
  • What is the new career path for agile team members?
  • How to we adjust compensation plans to encourage effective team behavior and reward individual contributions?
  • Has our quality assurance group adapted for agile to have the appropriate mix of embedded vs independent testers?
  • Do we have less technical debt than before agile?  How do I know if our quality is improving?
  • How do I know that teams are effectively engaging with enterprise authorities such as architecture, data, and quality assurance?
  • How can management use agile and lean principles themselves?

These are all fair questions.  For your agile adoption to be effective and sustainable you need a strategy to address all of these issues.  The Disciplined Agile Manifesto adds a principle to the Agile Manifesto regarding the need to adapt your organizational ecosystem to be effective for enterprise agile adoptions:

The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams
 

The need for good governance doesn’t go away with agile.  Your stakeholders deserve the right to gauge the health of their investments in your agile initiatives just like any other project.  There are indeed answers and various strategies for all of the above questions which will vary depending on the context of your situation.  Like it or not, the reality is that effective and sustainable agile transformations can take several years in order to achieve the level of capability and maturity that you expect.  A transformation is a journey, not a destination.  Make sure that your agile coaches have answers to the questions above and know what to do after your Scrum honeymoon period is over.  We will outline some DAD strategies for the questions above in future posts.

For a more detailed discussion of how DAD extends Scrum, please read the whitepaper Going Beyond Scrum.

DA103 – A Customized 1-day DAD workshop

One of our popular workshops is DA103  Disciplined Agile Delivery for Executives.  The workshop is not run from a preset agenda but rather one that is created by the class itself.  The format is:

  • One hour DAD overview
  • 15 minutes question brainstorming
  • 15 minutes topic identification
  • 5 hours of topics in priority order
  • 30 minutes wrap up
We may change the title of the workshop based on a recent experience.  A few months ago I facilitated the workshop in Belgium with Julian Holmes of Agile Mentors.  After brainstorming topics that the class was interested in, the workshop moved from being executive focused to one more for advanced agile practitioners.  Rather than spending too much time talking about agile governance and metrics, we explored advanced topics such as test-driven development and the subtleties of effective Product Ownership.

Shown below is the affinity diagram that drove the agenda for the day.  The workshop counts for credit towards DAD certifications.  For more information on DAD workshops contact a DAD Certified Instructor.

DA103 Exec brainstorming topics

Disciplined Agile Delivery is “Pragmatic Agile”

When we describe DAD we remind people that it is not another agile method as we clearly have enough of those already.  Rather, DAD is a process decision framework that enables better decision making when customizing approaches for adopting agile within the context of your organization and projects.  Popular agile methods can be quite prescriptive.  Sometimes their agile rules – work collocated in one room, use teams less than nine people, or don’t do fixed price projects – are not practical.  Rather than discounting such projects as not agile, why not take a pragmatic approach to dealing with these realities while striving to still be as agile as possible?  DAD provides the guidance that enables you to easily tailor, and later evolve, your agile approach to effectively address the context of the situation that you find yourself in.  Hence the term process decision framework.

Another way to look at DAD is that is “pragmatic agile”.  In their book The Pragmatic Programmer, Andrew Hunt and David Thomas describe the need for programmers to be inquisitive, critical thinkers who are realistic and jack-of-all-trades (what we call generalizing specialists).  These qualities are consistent with those we describe for all team members on DAD projects.  This pragmatism reflects the need for agilists to abandon dogmatic, purist approaches to implementing agile and recognize the need to adapt for the complexities of most enterprise projects.  We often encounter management that is frustrated with agile teams that ignore organizational standards and resist compliance with any sort of governance that seeks measure things such as the health, risks, and return on investment for these agile projects.  In return, agile teams often say that management just doesn’t get it.  Surely there is a compromise here.  Management needs to understand that they need to adapt their approach to governing agile projects and agile teams need to be flexible in dealing with the realities of building software solutions for the enterprise.

Why is DAD pragmatic agile?  We feel that it is pragmatic to:

  • Take a goal-driven approach which describes the agile strategies available to you, the advantages of disadvantages of each, and when to consider using each one.
  • Invest a small amount of time prior to beginning construction to get going in the right direction.  We frame this endeavour in terms of the goals described below in the Inception phase section of Figure 1.
  • Plan to spend some time after completing the construction of the solution to properly deploy it to your stakeholders.  This is described via a goal-driven strategie as shown in the Transition phase section of Figure 1
  • Do some lookahead planning and modeling, often referred to as backlog grooming, on a just-in-time basis to be more effective when implementing work items during each iteration
  • Leverage the existing organizational ecosystem to reuse existing services, patterns, templates, code, guidelines and other assets
  • Govern the project teams in an agile manner
  • Encourage project specific process improvement through self-organization within the constraints that make sense for the organization
  • Adapt the types and formality of work products produced for the context of the projects

We have seen that DAD is certainly resonating with companies that have been struggling to create their own flavour of agile with Scrum, Extreme Programming (XP), and other approaches.  This roll-your-own approach can be difficult and expensive for companies to develop and then maintain.  DAD provides a complete and flexible framework that enterprises have been looking for, enabling them to get on with the actual job of delivering business value to their stakeholders.

How do we apply the framework to make better decisions and be pragmatic?  DAD is goal-driven.  Figure 1 shows the goals that are consistent with any type of software development effort regardless of type,  whether it be custom development or implementing a package for instance.

Figure 1.  The Process Goals of Disciplined Agile Delivery.

Lifecycle Goals

Figure 2 shows an example of a process goal diagram to show how to fulfill a particular goal.  To address the Explore The Initial Scope process goal we need to consider various issues or factors in order to be most effective for the context that we find ourselves in.  This goal is an important part of the Inception phase so that we can move towards obtaining stakeholder consensus that it makes sense to move into the Construction phase and begin building the solution.  For each issue there are a number of choices.  Some choices, such as work item stack, are bolded and italicized indicate good choices as a place to start for a typical DAD project.  Some issues show an arrow beside the options which is an indication that the choices at the top are typically the most effective and the better alternatives to strive for.  A typical project will make hundreds of process decisions and these diagrams can be used to ensure that the various options are considered.  An example of a decision might be what view type might I use to depict my scope?  DAD recommends starting with a combination of usage modeling, domain modeling, and non-functional requirements.  For usage modeling, user stories is the most popular agile approach, but you could also create use case diagrams or personas as needed.  The DAD book describes each of the alternatives, as well as their advantages and disadvantages of each.  In this way, DAD helps us make better decisions.

Figure 2.  Process Goal Diagram: Explore the Initial Scope.

Explore Initial Scope

Is pragmatic agile an excuse for taking shortcuts?  Although the DAD philosophy seeks to be as agile as possible, it is not an excuse for being lazy.  We use the term disciplined for a reason.  We often see organizations that are struggling with Scrum, and the root cause turns out to be that the teams are skipping some of the core Scrum practices.  For instance they may have decided that they have a good process and no longer need to do retrospectives.  In situations like these, the teams have abandoned one or more of the goals of a DAD project.  Referring back to Table 1, we can see that an ongoing goal is to Improve team process and environment.  Another example might be that the team does not do regular, end-of-iteration demonstrations.  Here they are not fulling the goal of Produce a potentially consumable solution.  Perhaps the teams says that they always have working software, but how do we know it is consumable?  Who as seen it?  Have the operations and support staff seen it?  Are end users actually eager to work with it?

As you can see, we can refer to the goals table and ask ourselves, “how are we fulfilling each of these goals?”.  Using this goals driven approach can help to ensure that you do not have gaps in your approach to implementing pragmatic agile.

New Blog for the Japanese version of the Book

dad-japan cover

Mark met the team that just finished the translation of the DAD book into Japanese here at IBM Innovate in Orlando.  They have created a Japanese version of the DAD Blog.  A link has been added on the main page to the Japanese blog in the Blogroll links section.  A big thank you goes out to the DAD community in Japan.  Perhaps we will run a DAD workshop there soon!

Mark interviewed on DAD

Mark being interviewedMark was interviewed on DAD at the IBM Innovate conference:

http://www.youtube.com/watch?feature=player_embedded&v=lkDBs1Gf4TA

2012 in review

This has been a very active website in 2012.  Thank you all for your interest and participation.  We are looking forward to some great discussions again this year.

Mark & Scott

Here’s an excerpt:

4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 36,000 views in 2012. If each view were a film, this blog would power 8 Film Festivals

Click here to see the complete report.

DAD process template for TFS

RDA is a Gold certified Microsoft Partner and four time winner of Microsoft partner of the year located in the Eastern US.  They have standardized their agile delivery model on DAD and have recently created a DAD process template for Team Foundation Server (TFS).  John O’Hara has written an excellent article about it here…