Many medium sized development groups (100-1000 people) are using SAFe’s Program Increment Planning Event as the basis of their Agile approach. This is a good thing since the planning event is one of the best aspects of SAFe and can readily be used with a combination of a few Lean practices to create a lightweight framework. But much more than the planning event is necessary. At mid-scale, attending to managing the work to be done can achieve agility much more easily than adding many ceremonies and roles.
What’s Needed for Agile at Mid-Scale
The key to an effective Agile at scale approach is to work on the right things of the right size with the right people. This means we have to:
- Have a method of identifying and sequencing the most important work to be done
- Control how that work is initiated so that we don’t overload technology
- Get quick feedback and value realization so we need to work on small batches of work
- Create clarity on what needs to be created so that a test-first mentality is created
- Organize our talent around the products and services we create
While the planning event is useful, it must be used towards the bigger goal of achieving business agility – the quick realization of value predictably, sustainably and with high quality. Mid-size companies are often in the dilemma of wanting to use SAFe in a lightweight manner while still needing guidance on portfolio management.
This dilemma can be resolved by using an effective Agile Product Management system to guide portfolio management and use the planning event to control the intake process. The solution requires discipline, but not necessarily a lot of ceremonies.
Consider figure 1 below and discuss it from a systems-thinking point of view.
Figure 1: What it takes to have effective lightweight Agile at mid-scale
All of these aspects contribute to the system as a whole and interact with each other. The “intake process” is put on the top because it is a good starting point. By “control the intake process” we mean to ensure that there is a disciplined way of getting work started. Clearly this work must be what provides the most value and for which we have the capacity to build quickly.
Overloading teams will slow down realization of value so we must keep work within capacity. Just as important, we must verify that we are working on the most important items. This is best done through the use of small batches of work, such as a minimum viable product (MVP) approach of building just enough to validate the hypothesis that what is being built has the value we think if does.
But the use of MVPs are not enough. They are about validating a hypothesis of value. They are not necessarily the value itself. For this, the concept of the minimum business increment (MBI) must be used. Minimum business increments have two essential aspects to them:
- They are the smallest chunk of work that will enable value to be realized from a business perspective
- They contain all of the work (non-technology work as well) that is needed to realize value (e.g., marketing, ops)
The key to MBIs is to define what value can be delivered and realized as quickly as possible that has the greatest value. This provides us small pieces to work on while creating a focus on the most important increments of value. The idea of an MBI is not to just go small, but to deliver value quickly. In other words, a sequence of small MBIs, each achieving value realization quickly is better than one large chunk of value down the road. In other words, MBIs are not about delivering less but about delivering faster. As a side-note to those using SAFe, this concept would be similar to looking at the smallest solution that could be built and realized.
Small batch size is a key tenet of Lean and underlies all Agile methods. What’s sometimes not appreciated is that smaller batches not only let us focus on value but they make the system easier to manage as Eli Goldratt (creator of the Theory of Constraints) observed – “Often reducing batch size is all it takes to bring a system back into control”
How to Manifest the Points so Far
An excerpt from Aligning Organizations at Scale tells us to:
- Create clarity on what represents value for the Business and its customers
- Create strategies with clear objectives based on these
- Define initiatives to implement these strategies
- Craft Minimum Business Increments (MBIs) based on these initiatives
- Sequence these MBIs based on cost of delay (a popular approach to use is Weighted Shortest Job First).
The artifacts generated by this approach are shown in Figure 2:
Figure 2: Artifacts of Agile Product Management
It is easier to see how these relate to each other if we overlay them on our value stream as shown in Figure 3:
Figure 3. Workflow of an organization.
By looking at the value stream it becomes much easier to do workflow management. Perhaps more importantly, the concept of multiple groups of teams (trains in SAFe) working together must be handled whether you have one portfolio or many. In other words, Lean Portfolio management is important even at mid-scale. By focusing on Agile Product Management we can have both a consistent and simple model to use to manage our workflow.
Getting Clear Requirements
Agile software development provides us with a great method for validating if we are building the right thing. By incrementally creating value, we can get feedback on whether we are building the correct items. The key is to be able to get thin slices to build. This is part of the process of looking at initiatives and creating MBIs from them to deliver. Each MBI is small. But we need to go further and slice off small pieces of the MBI to build and validate.
The best way to do this is to use Acceptance Test-Driven Development (ATDD). People often get confused by the term “test-first.” Test-first means to create acceptance criteria that are testable (non-ambiguous) before writing code. For an MBI, feature and story items this involves a representative of the customer (e.g., stakeholder, product manager, product owner) with people who will be implementing the item. For an MBI this may be a stakeholder, a business architect and team leads having a discussion. At the team level it could involve the product owner, developers and testers getting together. But without clear acceptance criteria, much effort is going to be wasted. Note: see Test-Driven Development: ATDD and UTDD for more clarity on the types of “test-first.”
Reorganizing the Talent Using the Intake Model
Scrum and eXtreme Programming have demonstrated the value of cross-functional teams. At scale we need teams working together in an effective manner. It is best to do this based on the work that needs to be done. Complete stability of teams is neither achievable nor even desirable. Growing companies will need to start new teams and they will require old hands. But people should be organized as groups around the series of MBIs that come through technology. MBIs provide guidance here because all of the roles related to delivering an MBI will be needed.
Agile Product Management and Big Room Planning
By using Lean principles to guide us we can identify the most important work to be done and then coordinate it with big room planning. But “big room planning” does not mean we have to plan out quarterly. Ironically the purpose of MVPs in SAFe is to validate the hypothesis of an epic. But if we find the hypothesis to be wrong in the first or second sprint of the program increment, pivoting will require re-planning several sprints. On Running Effective Planning Events we discuss how planning events should be about collaboration and management. The planning is more important than the plan.
The key to a great planning event is not just to get clarity and agreement on the dependencies. Items should be completed as quickly as possible to get value out the door, or at a minimum, quick feedback. In other words, we want to flow within the time-box for which we are planning. Keeping this in mind we want to:
- Try to have shorter planning events than 10-14 weeks
- Within the plan, ensure we focus on completing items as quickly as possible in order to manage work in process.
Some Ramifications of This Approach
The key here is, of course, Agile product management with discipline. This means clarity on where the organization is going is necessary. It also means that understanding Acceptance Test-Driven Development is critical.
Summary
Coordinating mid-size organizations based around the work being developed is much effective than having set roles and a slew of artifacts that mean different things depending upon how many levels you have in your organization. By taking a system-thinking view, we can:
- Have a method of identifying and sequencing the most important work to be done
- Control how that work is initiated so that we don’t overload technology
- Get quick feedback and value realization so we need to work on small batches of work
- Create clarity on what needs to be created so that a test-first mentality is created
- Organize our talent around the products and services we create