Improving SAFe with the Disciplined Agile Value Stream Consultant Workshop

I suggest that 6 practices can make a big difference for SAFe implementations.

1. Looking at SAFe from a value stream perspective.??
2. Attend to improving the customer operational value stream by attending to their customer journey
3. Using MVPs and Minimum Business Increments (MBIs) in situations they were designed for
4. More useful value creation structures than ARTs
5. Using flow planning within a PI??
6. Separate the cadence of the business from development

I have listed eleven challenges I’ve seen people adopting SAFe have. These are:

1. Stagnation of value from SAFe after 2-3 PIs when SAFe devolves to a push system where ARTs take on too much work.???
2. Inability to innovate at faster than 3 months due to everyone being in the same planning cadence
3. People multi-tasking due to lack of alignment or being in multiple value streams
4. After the completion of a PI realizing that some value could have been delivered sooner but it wasn’t recognized as being possible ?
5. Difficulty in getting something that wasn’t in the planning event done during the PI (useful stuff comes up)
6. Poor innovation
7. The inability to have the development value streams operate at a faster pace than the quarterly business pace
8. Even small projects take a long time (requires smaller teams and a shorter than the 3 month PI cadence)
9. Misalignment of shared services and ops that slows down delivery of value
10. Products/projects may be funded but funding for required operations don’t necessarily happen (CapEx and OpEx funding not in synch)

The reasons for this vary. Effective Agile at scale requires attending to the following:

• The items being worked on
• The amount of work in process
• How teams are organized
• How work flows in a value stream
• How people in different value streams allocate their time to their value streams

There are a lot more in the DAVSC than these concepts, all of which are useful for those adopting SAFe. But the aforementioned concepts in particular can greatly enhance your SAFe adoptions.

Let’s go through each of these (I’m starting with #12 but will add others soon).

1. Stagnation of value from SAFe after 2-3 PIs when SAFe devolves to a push system where ARTs take on too much work.???
2. Inability to innovate at faster than 3 months due to everyone being in the same planning cadence
3. People multi-tasking due to lack of alignment or being in multiple value streams
4. After the completion of a PI realizing that some value could have been delivered sooner but it wasn’t recognized as being possible?
5. Difficulty in getting something that wasn’t in the planning event done during the PI (useful stuff comes up)
6. Poor innovation
7. The inability to have the development value streams operate at a faster pace than the quarterly business pace
8. Even small projects take a long time (requires smaller teams and a shorter than the 3 month PI cadence)
9. Misalignment of shared services and ops that slows down delivery of value
10. Products/projects may be funded but funding for required operations don’t necessarily happen (CapEx and OpEx funding not in synch)

The concept the minimum business increment (MBI) is quite useful in alleviating this problem. MBIs are the heart of FLEX’s approach to portfolio and product management. FLEX (FLow for Enterprise Transformation) is the operating model that is core to the Disciplined Agile Value Stream Consultant Workshop.

SAFe uses solutions, epics and features for budgeting. For general guidelines solutions and epics are fine. We need to make a distinction between general budgets that can be used to balance funding of specific work. Budgeting for strategies, solutions, initiatives and even epics makes sense. It provides a high-level guidance for the organization. But allocating funds for these does not provide the focus required for specific functionality. When it comes time to allocate funds to build something, it is imperative that what is being funded be a complete value proposition.?This means that all components required for the functionality being proposed are to be funded together.

Consider that funding features and stories will not guarantee all aspects of the functionality will be created. Funding requires all of the functionality be included but not more than what is essential. Less would mean value is not consumable. Too much will slow down the delivery of value. Consider the concept of the MBI. It contains not just the functionality that is required but who is required to do it. ?Funding an MBI requires funding the functionality, means of delivery, means of support and means of marketing/sales. An MBI in this sense breaks down the silos of the organization by making all those required to build and support new functionality to be funded and work together.

Restating the above concisely - we must allocate funds for all that is necessary to create and deliver value. This allocation must be done for the actual amount to be delivered. We don't fully deliver solutions, initiatives or epics. The MBI is an artifact that provides us with a way to both sequence the work we are to do while tracking all that needs to be done. CapEx and OpEx are accounting functions. We need to focus on functionality and drive from that. After an MBI has been funded the appropriate CapEx and OpEx accounting can be done.

#SAFe #DAVSC

?