Manifesting Business Agility

SAFe often achieves unjamming dev orgs that hadn't been able to work together. However, true organizational agility requires the creation of a network of semi-autonomous teams working together to deliver value to customers. After organizing people into ARTs that have the abilities to build products it is important to be able to decompose these ARTs into smaller teams, each aligned to a particular product. SAFe, unfortunately, provides little guidance in how to do this, often resulting in a stagnated SAFe adoption. 

FLEX's playbook for SAFe is designed to accomplish the decomposition of ARTs to align to business stakeholders, shorten the horizon for planning and allow agile budgeting,all the while simplifying SAFe. This playbook has 4 phases:

1. Improve in place. Use 2 new concepts &a few plays to improve SAFe’s core practices.
2. Restructure teams & shorten their planning cycles. Use Lean thinking to decompose ARTs into dedicated product teams
3. Align teams to business stakeholders. Achieve the desired network of semi-autonomous teams aligned with business stakeholders. Move to agile budgeting as possible.
4. Guided continuous improvement. Continue tuning your methods, trains and workflows by attending to flow.

I'm working on a 2-day subset of the DA Value Stream Consultant workshop called Disciplined Agile for SAFe. Here's a list of main changes & additions:

• The goal is not coordination of teams but decoupling of teams
• Focus on creating a network of semi-autonomous, cross-functional team or groups of teams (dedicated product team - DPT)
• Use flow/kanban to manage work between teams
• Use dedicated product teams instead of ARTs
• View SAFe from a value stream (Lean's definition) perspective
• How to improve value streams
• Use MBIs and MVPs (Ries’ meaning) as MVPs can't be done in a 3 month cycle
• Use FLEX's simpler budgeting, portfolio & product management method aligned around products (true project to product shift)
• Middle-up-down management
• calculate cost of delay on MBIs, not epics or features
• take a systems-thinking perspective
• one size does not fit all - look where to start
• attend to culture
• Use Big Room Planning to identify dependencies and to guide DPT creation - BRP deals with symptoms not root cause so don’t have it be your central method of planning
• Agreements to make across the organization
• Why you must start your improvements with test-first methods
• Use Goldratt's inherent simplicity to deal with complexity

The two biggest factors in getting to semi-autonomous, cross-functional teams are the current degree of existing cross-functionality and the level of dependency across the teams. This solution is when the organization has mostly cross-functional teams and has small to medium size projects.

In this case, the first thing to do is to identify the dependencies between the existing teams. These can then be used to temporarily reassign some folks (mostly from component and shared services teams) to the teams in order to lower handoffs and workflow delays. MBIs need to be sequenced to provide guidance when have conflicts. This approach starts with one planning event but then continues without them.

Steps 1+2: Have a big room planning event (usually 2, 4hr sessions):
a. Ensure everyone knows of the MBI concept
b. Agree to map dependencies and get commitments as to the dates they will be fulfilled
c. Support teams (e.g., component teams, shared services) consider lending people to teams they support to make them more cross-functional

Follow on.: Use a flow model after the event to track dependencies. Use Kanban to track work of teams supporting other teams

I like intention revealing names, that is, phrases or names of things that describe what they are referring to. There are currently two phrases for WIP. The more popular one is “work in progress” whereas the more accurate is “work in process.” This difference is not academic as the usage of 'progress' can lead to bad practices.

Progress means “forward or onward movement toward a destination.” But WIP refers to work that has started but hasn’t been completed. Work may be blocked,  that is, not progressing at all. Work in progress (in English) does not include blocked work. But it is WIP. This has led many teams new to kanban to not include items that are blocked (not progressing) towards their WIP limits. This is not effective.

“In process” means “of, relating to, or being goods in manufacture as distinguished from raw materials or from finished products.” English tells us that something blocked is not in progress but is in process.

It’s worth having our words mean what is inferred by their common definitions.

It is interesting to note that Scrumban (the first book on Kanban) used process, as does Don Reinertsen’s work.

Imagine if MLK had said “I have a plan.” Think of the emotion that would stir. Or not. Consider this from the Brightline Initiative’s People Centered Transformation – “Organizations cannot change unless their people change, and most transformation efforts fail because organizations over-emphasize the tangible side of change and under-emphasize the emotional one.”

There are several challenges in giving solutions to people. First, they may be the solutions to the wrong problem. Solutions are like answers to questions. Pre-defined solutions are to pre-defined questions. They may not be the right questions you need asked.

Even if correct, people may not have an emotional attachment to them - they may even resist them. People need to be given something they can emotionally attach to – a vision. Something they can identify with and work towards.

DA’s principles of to be pragmatic based on context drives DA’s choose your way of working. DA provides both questions and answers (in the form of solutions). These are based on the experience we have with thousands of clients. DA helps those people doing the work to ask better questions and choose from a toolkit of solutions.