Scaling Agile Series Part 3: Diving into Disciplined Agile (DA)
This is post 3 of 4 in the series “Scaling Agile Series”
- Scaling Agile Series Part 1: Can you Scale Agility?
- Scaling Agile Series Part 2: A look at Two of Four Popular Agile Scaling Frameworks: SoS and LeSS
- Scaling Agile Series Part 3: Diving into Disciplined Agile (DA)
- Scaling Agile Series Part 4: Does Scaled Agile Framework (SAFe) Lead to Agility at Scale?
In my most recent post, I reviewed Scrum of Scrums (SoS) and Large Scaled Scrum (LeSS). Both are lightweight and provide tools for cross-team communication, but only at the delivery layer (see diagram below). SoS and LeSS don’t provide direction for agility throughout an entire organization. In this post, I will dive into Disciplined Agile, which is more complex than SoS and LeSS and provides additional layers of direction. My intent is not to describe the entire framework since it is very extensive, but to introduce some of the main topics and determine whether this framework will help or hinder an organization’s agility.
Because of Disciplined Agile’s increased complexity, I wonder, can DA teams and organizations remain true to the definition of Agility?
A Bit about Disciplined Agile (DA)
Disciplined Agile is a thorough framework, considering all levels and functional areas of the organization. DA focuses on the whole solution, which starts with Delivery teams and expands outward to include DevOps and further yet to include the whole IT organization.
Figure 1- Disciplined Agile 2.1
Disciplined Agile – The Delivery View
Disciplined Agile is flexible. At the delivery level, DA does not prescribe the framework teams must use. Instead, it recognizes that one process does not fit all so provides four iterative development options. DA’s founders Mark Lines and Scott Ambler believe as organizations become more efficient at delivery they should evolve and try new things in order to increase team productivity and time to market.
Figure 2: Disciplined Agile Delivery
The following are the four delivery frameworks recommended by Disciplined Agile:
DA recommends starting out with the framework that provides the most direction and only when teams mature should they consider moving to a less prescriptive, more flexible framework.
Delivery Lifecycle – Three Phases
Regardless of the delivery framework an organization selects, the following lifecycle should be followed:
Figure 3 – Disciplined Agile Delivery Lifecycle, Source: Disciplined Agile Consortium
- Inception: Some amount of upfront planning is important, therefore practitioners are encouraged to do lightweight inception prior to starting development. During this time, focus on building teams, creating work items, reviewing high-level architecture, identifying risks, and developing initial release plans.
- Construction: Once out of inception, teams focus on building the solution, addressing stakeholder needs, improving quality, and getting to a deployable solution.
- Transition: Once construction is complete, the transition is made to solution release. Teams focus on ensuring production deployment succeeds and supporting the newly released code.
There are no explicit methodologies for inception and transition. DA encourages organizations to do what works as long as these phases remain goal driven.
Disciplined Agile – DevOps
Disciplined DevOps is the next layer in the Disciplined Agile Scaling Framework. This area is not covered in either SoS or LeSS frameworks.
Disciplined DevOps defined: “DevOps is the streamlining of the activities surrounding IT solution development (dev) and IT operations (ops).”
Figure 4: Disciplined Agile DevOps
DevOps is a critical part of IT Operations and combines release management, data management, support, and operations. In the Disciplined Agile view, these areas are not fully removed from the development effort inasmuch as developers do not simply throw code over the wall to release management teams. In the image, you can see the arrows going into and out of the delivery and DevOps areas which depict the collaborative efforts of these areas.
Disciplined Agile DevOps framework provides numerous options for implementation depending on the organization’s structure and level of maturity. For example, DA outlines levels for release management strategies:
- Release Windows (Slow Cadence): A period of time in which teams can release to production. These release windows are fairly infrequent (weekly, monthly, quarterly) and have a limited number of release slots.
- Advantage: Provides a known, consistent cadence
- Disadvantage: Potential bottlenecks due to limited number of release slots
- Release Train: Same release cadence for every team on the “train” (more on SAFe release trains in my next post). Commonly used when many teams are working collectively on a large product.
- Advantage: Having a common release time frame provides a rallying point for teams as well as a consistent schedule for stakeholders.
- Disadvantage: As the train metaphor implies, a team missing the train must wait for the next one to come along and depending on the time between releases and the dependencies among teams, there will likely be bottlenecks especially with slow cadence release windows.
- Release Windows (quick cadence): Quick cadence, especially across many teams, means the organization will need multiple release windows with many release slots.
- Advantage: More release times and spots provides support for continuous delivery
- Disadvantage: Increases the complexity of release management.
- Continuous Release Availability: The only strategy which supports continuous delivery. Teams release to production whenever they need to, effectively extending the release window to 24/7.
- Advantage: No bottlenecks to production, however in order to effectively manage continuous delivery, teams must have fully automated deployment, regression testing, feature toggles, self-recovering components, to name a few.
- Disadvantage: No real disadvantages other than the time it takes to become efficient in this practice.
Data Management, Operations, and Support also have several strategic options for implementation. Similar to Delivery, DA recommends starting with the most optimal implementation and build as the organization matures.
Disciplined Agile I.T.
Disciplined Agile IT refers to the strategy for the IT organization as a whole and builds upon the Disciplined DevOps layer. (See Figure 1) The strategies include guidance and options for the following IT ecosystems:
- People Management
- Product Management
- Portfolio Management
- Enterprise Architecture
- Reuse Engineering
- IT Governance
- Continuous Improvement
One example of Disciplined Agile IT is advice to effectively govern teams. According to a 2017 Agile Governance survey compiled by Scott Ambler (founder of Disciplined Agile), Agile/Lean governance helps teams and likewise, traditional governance hinders teams whether agile or traditional. See Agile Governance 2017.
Agile/Lean governance refers to the following:
- Leading by example – People take cues from their leaders. If teams are governed in a lightweight, streamlined manner, they will tend to work in a lightweight, streamlined manner.
- Being a servant leader – Help the teams prevent and remove roadblocks.
- Motivating over managing – Motivate the team to do the right thing vs. telling them what to do. Ask tough questions, and ensure the team understands why they are building what they are building.
- Enabling over auditing – Provide teams with the tools they need to do their job right. Help them rather than hinder them with lengthy processes. Sometimes audits are required, especially in heavily regulated environments, but only do so when absolutely necessary.
- Communicating clearly, honestly, and in a timely manner – Communicate priorities in an open and honest manner. Set realistic expectations and be present.
- Streamlining collaboration – Help teams collaborate effectively with others.
- Trusting and verifying – Trust should be earned and goes both ways. Good governance means asking people what’s going on, automated metrics (via team dashboards), looking at information captured by information radiators, attending team demos, and as a last resort asking teams to produce status reports to address questions that can’t be answered via automated metrics.
- Focusing on mitigating risk, not just reviewing documents – Rather than relying on documentation, look at what is really going on. Talk to people in the know. Reviewing a document just means the document was created, not that a positive outcome was achieved.
- Learning continuously – Learn as much as possible about the thing being governed so that good decisions will be made now and in the future.
- Considering both the long and short term – balance short-term needs with the long-term strategy of growing and enhancing the organization
- Being a great host – Think of governing as hosting a party. You want your guests to have a great time. Likewise, if your employees are having fun, the enjoyment will be reflected in their work and you will retain great people!
A Worldly View
Disciplined IT teams are enterprise aware, which means while they are concerned with their own goals, they are driven to do what is best for the full solution. In a large environment, the teams do not work in a vacuum. Their world exists as part of the whole organization. Business owners, architects, and finance all work together and move in the same direction.
Level of Scaling Agility:
Disciplined Agile encourages practitioners to be goal driven and is not as prescriptive as some scaled frameworks (more on this in my next post). Success comes by ensuring all teams are in step with the entire organization.
DA provides tools at the individual, team and department levels that enable organizations to scale successfully. But DA teams need guidance. I highly recommend starting small perhaps by bringing all development teams into iterative development or transitioning to DevOps from traditional operations and support. Because Disciplined Agile does provide pathways to build and transition the full organization to Agile, a coach or team of coaches is a great option to support this transition
From a “Can you Scale Agility?” standpoint, the more I study DA, the more I am convinced that if an organization chooses to adopt this framework, invests in coaching, and allows for flexibility and learning, they should be able to spread agility throughout the organization. I suspect individual teams in a Disciplined Agile framework may feel constraints and growing pains, but overall productivity should increase along with time to market and product and project success.
In Scaling Agile Part 4 I look at SAFe in depth and provide some final conclusions on my search for Agility at Scale! Don’t forget to catch up on the series by reading Scaling Agile Part 1 and Scaling Agile Part 2.
—
