An Issue Arises That Spans Multiple Teams or Products
Products often share components. When an issue arises pertaining to the component, many other subsystems or products might be affected, affecting many teams across different parts of the organization.
Agility does not result from one’s process. A process handles what to do that you have planned for; agility is about response to what has not been planned for. To be agile, one must react immediately, and intelligently, without process.
The ability to react quickly to unplanned situations is crucial today. There have always been unplanned situations, but what has changed is (1) their frequency, and (2) the interdependence of today’s products and supply chains. Today there are a lot more dependencies, and so it is rare that a needed changes has only a local impact. Today it is commonplace that changes to a component or a product affects many products, possibly across product lines, and possibly affecting multiple customer segments.
That means that agility is essential today. But if your process only accommodates scheduled planning sessions, then you cannot be agile: it is not possible.
Consider this example: Teams are working, and an unexpected issue arises…and the issue cuts across several teams, and even across two product lines. How do we resolve the issue?
If the initiative is using the SAFe methodology then this is what would likely happen:
When the issue arises, the person who notices it will tell their release train engineer.
The issue gets dealt with in the next PI.
Time elapsed: up to 10 weeks.
Here is what should happen instead:
An individual notices the issue.
They reach out to those who are effected. They also notify their team lead, because the team lead might be aware of who else needs to be included in the discussion.
The individual or team lead arranges for them all to discuss the issue.
The individual or leader drives the issue to resolution.
Time elapsed: hours or days.
Agility does not result from process: agility results from what occurs outside of process.
The key points of this are:
In the truly agile approach, the issue was resolved outside of process.
Agility resulted from the behavior of individuals—not from process.
Agility does not result from process: agility results from what occurs outside of process.
This is not to say that process is not needed: it is. But process will not yield agility: there is no such thing as an “Agile process”, despite the claims of Agile framework vendors. People need to define their own processes, and continuously refine those over time. Frameworks are a good source of ideas for one’s process, but copying a framework’s process will not bring agility: most likely it will reduce agility and mire your teams in excessive complexity.