Disciplined Agile

We have recently posted an update to The Disciplined Agile Manifesto.  In particular, we simplified the wording of the three principles (reduce technical debt, visualize workflow, multi-modal organizations) that we added to extend the original Manifesto for Agile Software Development.  We describe the updates to each of the three principles, and our thinking behind them, below.

Reduce Technical Debt

Original: #13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.

Update: #13. Leverage and evolve the assets within your enterprise, collaborating with the people responsible for those assets to do so.

The primary change here is the use of the term enterprise instead of organizational ecosystem. Over the years we had several people point out that they weren’t comfortable with that term or that they found it overly complex.

Visualize Workflow

Original: #14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.

Update: #14. Visualize work to produce a smooth delivery flow and keep work-in-progress (WIP) to a minimum.

This principle was reworded to make it more action oriented and to clearly point out the term WIP.

Multi-Modal Organizations

Original: #15. 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.

Update: #15. Evolve the enterprise to support agile, non-agile, and hybrid teams.

As you can see we simplified this principle greatly, using enterprise instead of organizational ecosystem as above and going straight to the point of supporting multiple ways of working.

A process blade encompasses a cohesive part of your overall organizational way of working (WoW). Each process blade addresses a specific organizational capability, such as Data Management, Continuous Improvement, or Vendor Management. Process blades are sometimes called process areas, key process areas (KPAs), or business functions. 

In September 2016 InfoQ published an interview, Benefits of Agile Transformation at Barclays, with Jonathon Smart and Ian Dugmore of Barclays in the UK.  The interview summarizes the experiences of adopting Disciplined Agile (DA) strategies within Barclays.  Some of the key points made in the interview include:

• Barclays is a large financial institution with over 130,000 employees that has been in operation for over 325 years
• Barclays is taking a holistic approach to their agile transformation, it is not just a technology thing, linking up their various “islands of agility” to reduce the impedance mismatch between them
• Barclays has the equivalent of over 800 agile teams that have adopted DA approaches in progress
• They considered SAFe, LeSS and DA and settled on DA as it is not a “one-size fits all” approach
• They needed to change both their funding and measurement strategies
• Results include: A 300% increase in throughput (note: measured in terms of story delivery); 50% reduction in code complexity; test code coverage increase by 50%; More than half of teams are deploying into production at least monthly; Improved team happiness/morale; Improved business outcomes such as quicker time to market

The source article is definitely a very interesting read.  

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

Our Principles Around Terminology

The following three principles drive our terminology decisions:

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

The Problem with Scrum Terminology

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

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

Mapping Scrum to Disciplined Agile Terms

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

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.

One of the things that a delivery team needs to do, often in collaboration with product management, is choose the release cadence of their product. This is an important aspect of, you guessed it, release planning.  Your release cadence defines how often you release your solution both internally and externally into production (or the marketplace). The issue is how to determine how often the product should be released into production. In this blog we explore:

1. Where are you deploying to?
2. What affects release cadence?
3. What release cadence choices do you have?
4. What do we recommend?

Where Are You Deploying?

There are several target environments that you might choose to deploy to. These environments include:

1. Demo environment(s). Many teams maintain a demo environment for their solution so that their stakeholders can see what has been developed to date at their leisure. Demo environments support transparency with your stakeholders, reduce the number of “one-off” requests by stakeholders for demos (because they can simply see the solution for themselves), and of course they provide a stable environment in which your teams can run demos.
2. Testing environment(s). Many teams have their own testing environments, or they work with independent test teams with their own testing environments, or both. You should strive to test as often and early as possible, an implication being that want to deploy into your test environment(s) as often as you possibly can.
3. Production/marketplace. Some teams will release their solutions into their production environments (or to someone else’s cloud) where end users will use the systems. In the case of commercial software companies they will release their solutions into the marketplace where they are then sold to customers. Throughout this blog whenever we use the term production we also mean the marketplace.

For the sake of terminology, deploying into demo or testing environments are often referred to as internal releases and into production as an external release.

What Affects Release Cadence?

There are several factors that affect the choice of release cadence:

1. Stakeholder needs. How often do your stakeholders, and in particular your end users, want your solution to be released? This can be a difficult issue because very often your stakeholders might not be able to perceive what is appropriate for them. We’ve seen stakeholders ask for quarterly releases, be delighted when then get monthly releases, and then start asking for weekly releases once they realize the potential of modern agile strategies.
2. Stakeholder capability to accept change. We like to think that more often is better, and in the vast majority of situations it is. As difficult to believe as this may seem, at the far extreme we’ve also seen some systems where the natural release cadence is once every three or four years because that’s the rate at which stakeholders are able to accept change. In this case the product was a transaction processing (TP) system infrastructure product, but we’ve heard similar stories about major database management systems (DBMSs) products too. Granted, a release cadence this long is very rare but it does happen in a small number of situations. Far more common is the mistaken belief by IT professionals that their stakeholders are unwilling or unable to accept shorter release cycles. We’ve seen numerous organizations where the IT people tell us that their stakeholders can’t handle anything more regular than a quarterly or bi-annual release, yet these same stakeholders regularly use commercial software that is updated several times a week.
3. Your organizational culture. Some organizations, particularly those with an existing traditional release management team, often have release cultures that lean towards larger and less frequent releases. These organizations often have significant investments in legacy systems and insufficient investments in automated regression tests/checks. As a result releasing solutions into production tend to be seen as a risky endeavour. At the other extreme we’ve seen companies with more of a continuous delivery mindset that have a “release as swiftly and often as you can” culture. These organizations have typically invested heavily in code quality, automated regression testing, and automated deployment thus making deployment a simple and virtually risk-free effort.
4. The team’s ability to deliver. Of course a primary determinant of your release cadence will be how often you’re able to actually produce a potentially consumable solution. This is affected by the skills of your team members, your ability to collaborate, your ability to vertically slice functionality into small features, and your delivery infrastructure.
5. Your delivery infrastructure. How easy it is to release a potentially consumable solution into production is determined in part by your technical environment. This includes the extent of your automated regression tests, your automated deployment scripts, and your capability to monitor production. In general, the greater the level of automation the more often you can release.
6. Your solution architecture. Is your solution architected to be released incrementally? Is it possible to enable/disable functionality at a granular level (perhaps via feature toggles or a similar technique)?
7. The cost/risk to release.   Cost and risk tend to go hand-in-hand when it comes to releasing solutions into production. This is because the more manual your release/deployment processes the more expensive they become and the more likely there are to be problems somewhere in the process. Conversely, the more you automate the overall deployment effort the cheaper it is to deploy and the less risky it becomes as you’re more likely to run into, and then automate a solution to, deployment problems. The less expensive and less risky it is to release your solution the more viable it becomes to release more often.
8. Release cadence of other teams. Like it or not your team is likely dependent on the work of other teams. For example you may need web services being built by another team, and you can’t fully release your solution until those web services are available in production.  We’ve written detailed articles about how to manage dependencies between agile/lean and traditional teams, dependencies between agile teams, and dependencies between agile and lean teams.

Release Cadence Choices

Table 1 lists many common release cadences, from more than annual to several times a day. It also lists the potential tradeoffs of each approach and indicates when you may want to adopt each one.

Table 1. Comparing external release cadence options.

Our Recommendations

When it comes to releasing your solution, we have several recommendations for you to consider:

1. Automate, automate, automate. The more you have automated, the lower the cost of deployment and the lower the risk. This enables you to release more often with confidence.
2. Release internally very often. This is your opportunity to get good at releasing your solution, at squeezing out the cost and the risk.
3. Release externally as often as possible. The faster and more often you can release into production the more competitive your organization will be.
4. Always look for ways to release more often. Impressed with your ability to release once a month? Aim for bi-weekly. You’ve now releasing bi-weekly? What’s stopping you from releasing weekly? Weekly releases? Meh! Release daily! Your team is releasing daily grandpa? How about automatically releasing many times a day every time you have a working build?

Further Reading

• The Release Management Process blade describes the issues surrounding releases in a multi-team enterprise environment.