BLAST is a framework pattern used to coordinate the work of 3-9 teams. Each team can be using any Agile method (e.g., Scrum, Kanban, eXtreme Programming). BLAST provides teams the guidance to work together in either a flow or timeboxed manner. These teams can be from the same part of an organization needing to coordinate to create or enhance a new product or when teams from different parts of an organization need to work together.
BLAST integrates Flow, Lean, and the Theory of Constraints within the perspective of value stream management. Doing so makes coordinating multiple teams straightforward to accomplish. BLAST can be taught as a stand-alone technique but is also presented in Lean-Agile Teams Master Class since few teams work in isolation.
BLAST is called a framework pattern because it is not immutable but rather a suggested way for teams to work together. As all patterns do, it provides for tailoring its implementations to achieve the desired result for the context at hand.
The Key Points of BLAST
Value stream management provides valuable insights for BLAST. By taking a value stream perspective, all of the steps and components of BLAST fit into place and describe the relationship to each other. BLAST teams take an end-to-end view of their customers’ value streams, from taking a concept (idea) through the processes and activities necessary to deliver the intended value. The goal is to discover and remove the constraints and wastes that impede the delivery capabilities of the targeted value stream.
The primary role of BLAST-oriented executives, managers, and leads is to create and sustain a value-delivery-oriented mindset, removing the impediments that arise from organizations organized and siloed around business domains or functions.
1. Use the customer journey to improve the customers’ operational value stream. How customers interact with your services and systems is called the customer journey. The entire workflow of the customer is called the customer’s operational value stream. By attending to the customer journey, we can positively influence the customers’ operational value streams and provide value to them.
2. Have a business value backlog focused on our products and services. This backlog uses minimum viable products (MVPs) for when we need to discover if a new product will be valuable and minimum business increments(MBIs) when we’re enhancing existing products. Both focus on delivering the highest value in the shortest amount of time. This business focus also provides the opportunity to create a test plan based on Acceptance Test-Driven Development or Behavior Driven Development.
3. BLAST Planning. The BLAST teams work together to create a plan for future work. It can be timeboxed planning or flow-based planning. If timeboxed, the iteration length will be no more than two weeks. The result is a sequence of slices for the teams to pull from and build together.
4. A near-term backlog. This backlog contains the items that the teams will work on over the next week or two. BLAST allows for teams to either pull from this shared backlog or for each team to have its backlog. In this latter case, it is useful to refine the near-term backlog by splitting items into vertical slices. The appropriate part of these slices can then be given to the teams to work on in a coordinated fashion.
5. The BLAST pulls work from the near-term backlog to improve flow and delivery of value. Planning, acceptance criteria, development, test, review, and delivery activities operate at an accelerated pace to create realizable value. The coordinated pull of items from the Product and Iteration Backlogs as capacity becomes available, not pushed as batches of work items into the development streams, reduces waste while facilitating an alignment of teams.
6. The BLAST value creation structure and workflow. The BLAST consists of 3-9 teams working together. The BLAST itself is cross-functional regarding building the desired product/service. But each team in the BLAST does not necessarily need to be fully cross-functional. They operate at the same cadence, but each can work in a way that works for them. Each team is responsible for the non-functional requirements for what they build. BLAST retains the notion of having small, autonomous, and competent teams pulling the highest priority work items off a single, definitive product backlog. However, BLAST also incorporates small value creation structure patterns that are needed when one or a few individuals’ skills are required across multiple teams.
BLAST takes advantage of CI/CD and DevOps pipelines. The iterative and incremental development practices of Agile have been supplanted by the highly accelerated pace of Lean-oriented continuous flows, as exemplified in modern CI/CD and DevOps software delivery pipelines. BLAST simplifies integration by providing teams work in a coordinated manner, allowing all teams to work on related items together.
7. Daily review. Short, pre-scheduled meetings to review where we are. The intent is also to enhance a sense of the team. Each team reviews their board by stating, for each appropriate item: 1. here’s what we’re working on, 2. here’s where we are blocked, 3. here’s what we’re going to work on next
8. Continuous review and refinement of the backlog. Members across the teams need to coordinate the following: 1. the test-plan for non-functional requirements, 2. how to integrate across teams, 3. ensure a coordinated workflow takes place, and 4. attending to how the teams are working together.
9. Integrated Increment. These increments can be produced on a cadence basis or as MVPs or MBIs are created
10. Review. While it’s best if customers frequently review work being done, each integrated increment must be reviewed when released.
11a. Review to improve how we are working. Improving how we are working is a continuous process. In addition, Agile Retrospectives are a planned event to have teams evaluate and implement short-term improvement opportunities. BLAST teams also look at how they can deliver a series of MBIs that incrementally improve their customer’s value stream delivery capabilities from the Lean-oriented perspective of improving work and information flows. In addition, BLAST incorporates Deming’s Plan-Do-Study-Act cycle.
11b. Review to pivot on what’s being built. Use the feedback from the integrated increment review to adjust the business value backlog.
How Users of Scaling Scrum approaches (LeSS, Scrum-of-Scrums, and Nexus) can improve with the lessons of BLAST
Basing BLAST on Flow, Lean, Theory of Constraints, and using the value stream perspective enables holistic thinking. The focus is on the entire group of people involved and does not require fully cross-functional teams. While these are ideal, they are often difficult to achieve. Unfortunately, LeSS, Scrum-of-Scrums, and Nexus don’t provide alternatives when cross-functional or feature teams are not achievable. Concepts in BLAST can be used to adjust how the teams work together when ideal team formation is not possible.
It is recommended to users of these methods to consider adding the following to their approach:
- Attend to the value stream
- Use MVPs and MBIs
- Attend to the customer journey
- Strive for continuous, not just iterative, learning using the PDSA cycle.
- Incorporate CI/CD and DevOps Pipelines
- Allow for flexible value creation structures
- Have a role for management to help improve the overall environment within which the BLAST works.
See the case study that led to BLAST: Coordinating Teams with Backlog Management