Disciplined Agile

The Disciplined Agile (DA) Tool kit is a tremendous resource to be used in every Lean-Agile adoption / transformation effort, from team-level to enterprise-level. The DA Tool kit, now with more clarity on choosing your way of working (WoW), offers new and established teams an opportunity to evolve further through consideration of their context and the many goals, factors, and options available to them.

Disciplined Agile Delivery (DAD), with its focus on delivery has provided a solid foundation for building high performing delivery teams. As enterprises come to value the benefit of these team-level improvements the desire to leverage these improvements throughout the enterprise, scaling these improvements, is a common enterprise strategy today. Of course, DAD Teams are enterprise aware and ready to work with the enterprise to reduce overall delivery time and cost.

There are many scaling factors to consider as an enterprise seeks Agility at Scale. Additionally, the DA  tool kit provides straightforward guidance for scaling into Disciplined DevOps and then into value streams. Finally, the toolkit provides guidance for a Disciplined Agile Enterprise. It is here that I want to focus on Principle 6, Optimize Flow.

DA recognizes that enterprises are complex adaptive systems. The solutions they are providing are also complex solutions. Gone are the good’ol days of simply being complicated!

The challenge, as stated by the principle to Optimize Flow, is how to ensure collaborating teams do so in such a way as to effectively implement our organization’s value streams? And, how do we optimize our overall workflow?

I’ll take the liberty here to rephrase and combine the two questions. How do we organize long-standing teams to support the delivery of value for the enterprise in a way that allows for ongoing optimization experiments (as in Lean Change)?

To ‘implement’ the organization’s value streams for delivery of solutions, we must first identify and visualize the operational value stream of the enterprise and then determine the nature of the solution being delivered.

To the sharp-eyed reader, you’ve noticed that I’ve qualified the use of value stream with a reference to operational value stream. Yes, I believe there is a value stream that is characterized by the enterprise: The value stream through which it delivers value to its customers, clients, members, or whomever external to the enterprise is paying for the value delivered. This is the operational value stream, the flow from order to cash.

Well, there is no reason to qualify the use of value stream if not for at least a second type of value stream. That second type is a development value stream. The development value stream is where we can fully leverage the wealth of resources available from the DA Toolkit. This is not to say that we can’t use various ideas and principles from the DA Toolkit to improve the operational value stream. Only that the sweet spot for considering the Disciplined Agile Enterprise (DAE) is from the point of view of the development value stream.

So, what is a development value stream? A development value stream is responsible for implementation and maintenance of solutions that provide for business capabilities that are in turn needed to support to operational value stream. Here, in the development value stream, is where we are better able to apply the Optimize Flow strategies of delivery at a sustainable pace, optimization of the whole, making work flow, and using experiments to eliminate waste and to gain an understanding as those long-standing teams participating in the development value stream use validated learning through metrics to continuously improve.

A development value stream is implemented by way of establishing and organizing DAD teams in alignment with the flow of idea to solution for improvements of business capabilities within the enterprise.

Sustainable pace

For a team of teams aligned to enable business capabilities the continuous generation of business capability improvement ideas can easily exceed the capacity of the delivery teams to implement each idea. It is important the leaders within the enterprise understand that more can be accomplished with the people they have when they limit the amount of work requested of them to their capacity to do the work. Exceeding that capacity ultimately results in less work being accomplished overall as we lose productivity though excessive multitasking. Yet, each team will want to be responsive to the perceived demand of the enterprise. In their efforts to self-organize to improve on what they can accomplish it is important to keep the next strategy in mind, optimize the whole.

Optimize the whole

Within a team of teams each team is typically striving to contribute a smaller outcome that, together with the outcome of other teams, contributes to a larger outcome needed to improve a business capability. Teams should seek to optimize around the delivery of the larger outcome rather than only their own contribution. It is important to be aware that the optimization of a component of a system may, in fact, cause a sub-optimization of the larger system. Focus on the flow of the larger value delivery to make work flow better overall.

Make work flow

The principle to visualize work enables teams to identify and remove bottlenecks. Kanban is a great method for this visualization. But, the idea of a Kanban board is not limited to being applied only for a Kanban team. Scrum, and indeed, anyone or team can borrow from Kanban. An overarching visualization of the work is our need. For a team of teams, that visualization to optimize the whole needs to encompass the effort of the team of teams. While the individual teams may focus on the flow of user stories, the team of team should be visualizing the flow of the large outcomes that the team of teams is striving to delivery.  With that visualization the team of teams can work together to eliminate waste that, from their team point of view, might not be visible, or might not have been within their ability to influence improvement experiments that required the support of the team of teams.

Improve continuously

Everyone familiar with Scrum understands the value of periodic retrospectives. These retrospectives allow for the self-organization of the team to streamline their processes. This same approach should be considered for a team of teams. Periodically, perhaps once a quarter, the team of teams should collective gather to consider experiments that will streamline the more overarching issues they all face.

Experiment to learn

Consider the ‘implementation’ of all improvement ideas as experiments. Just as we can no longer provide concrete implementation plans for the complex technical solutions delivered today, we can not develop a concrete process/behavior/culture improvement plan for today’s enterprises that are themselves complex adaptive systems. Also, we’ve learned that small changes are better than big changes. Choose to learn with small Minimal Viable Changes (MVC). Advance your learning by leveraging the learning of Lean Change.

Measure what counts

For each experiment to learn determine the measures of success before starting the experiment. What is the goal of the change (experiment)? What questions need to be answered to know if the outcome of the experiment is likely to realize that outcome? What measurements can be used to obtain the information needed to answer those questions? Don’t waste time and money on vanity metrics.

Prefer long-lived stable teams

Where is the value once you optimize flow when you throw out that value by disbanding your high-performing team of teams? By aligning your team of teams, your development value stream, with business capabilities that enable your operational value stream you have created an organization that can be long-lived because the business capabilities of an enterprise tend to be persistent for the life of the enterprise.

The bottom line

When you find yourself coaching a larger number of teams for an enterprise with the vision to become more agile overall, I propose that you expand upon the principle of the Disciplined Agile Toolkit to Optimize Flow. The principle to Optimize flow applies at the larger scale of a team of teams. This article has hopefully helped you map the Optimize Flow principle to a larger number of teams, a team of teams, organized as a development value stream when you consider the transformation/adoption needed for a Disciplined Agile Enterprise.

The results of the 2018 State of Agile survey (StateOfAgile.com) have just been released.  This survey, while not particularly scientific in its approach, is a widely read and frequently quoted survey of what people are actually doing on a variety of agile topics.  It is good to see that Disciplined Agile continues to grow in popularity, up from 5% marketshare to 7%, behind only  SAFe which commands a 30% market share and is the clear leader (Scrum of Scrums is ahead of DAD, but it is just a practice, not a method).  While we are very pleased that people are finally starting to understand what DA is and how it can help them, I am not particularly fond of the way the question is framed in the survey and would like to share my thoughts for how it could be improved, and my interpretation of the findings.

1. Disciplined Agile (DAD) is listed as an option in the “Which scaling method/approach do you use?”.  People who understand DA know that it is actually not specifically a scaling framework.  It is rather a toolkit of strategies, a hybrid of practices from many methods and frameworks which can help you optimize your way of working (WoW) regardless of which approach you use.  It can be used on one small Scrum team, or dozens of SAFe teams.  Whatever approach you use, DA can help you to become even more awesome! #beawesome
2. As I said above, Scrum of Scrums should not be one of the choices as it is simply a coordination practice for Scrum at scale, not a method.
3. “Don’t know” is interesting as an option.  It puzzles me that people that are answering this survey aren’t aware of their organization’s approach.  My suspicion is that many of the people picking this selection actually mean “Not applicable” as many organizations do not scale agile.  I think that this should available as a selection.
4. The question really should be a multiple choice, rather than single.  Most organizations use a variety of approaches.  It would be more useful to ask “What percentage of your IT spend uses each of the following approaches?”
5. Spotify is actually not a framework.  It is how a Swedish music company circa 2014 had adapted agile at that point in time, to optimize their WoW for their unique context.  If you copy their approach you are copying an old approach of a company in a situation unlike yourselves, and for which they have evolved away from significantly.
6. I find “Internally created methods” intriguing as a choice.  We think that this is what all companies should aspire towards.  Start with either where you are currently, or one of the other methods (recipes), and then use the DA Toolkit to either evolve away from, or to improve your approach for your unique organization and team context.
7. Spotify actually embodies this approach.  They have continually evolved, improving, and optimizing their way of working.  Menlo Innovations also has done the same thing, starting with Extreme Programming (XP) as their core method, and then optimized for what works for them.  Rather than copying other companies approaches we should “learn how to learn” about what works best for us. We describe this approach of leveraging proven fit-for-context practices in our Choose your Wow! book as “Continuous Guided Improvement”.  Starting with some basic scaffolding of an existing method (what we refer to as “lifecycles” in DAD) provides a jumpstart on your WoW optimization.

We would recommend that you do not aspire to “be Spotify”, but rather “be like Spotify”.  Start with a basic method/lifecycle (recipe), then spice it up with the help of proven strategies from the DA Toolkit (ingredients).

Become your own Spotify or Menlo, not somebody else’s.

Thoughts?

Not 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 toolkit 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 DAD 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.

DAD 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 Govern Delivery Team, milestone reviews should be done in a light 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

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.

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

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