Any change requires that a problem has been identified. In agile software development we are dealing with complex adaptive systems:
Any part of the system creates value through interaction. Thus, the problem’s underlying cause necessarily already spread in different forms to all parts of our system.
The traditional practice of “root cause analysis” tries to deal with problems following a reverse-deterministic approach. Therefor it can deal with events which follow strict causalities. Applied to system thinking it implies that we can cut of a malfunctioning part, fix it and hereby fix the problem. (See related The limitations of root cause analysis) Well … we can’t:
As unfixed parts of the complex adaptive system are aligned with the overall dysfunctional behavior the fixed part now creates a tension. This is as true on the multi-team level (See related experience report), as it is for individuals, artifacts, events, etc.
This tension may now override an existing modus operandi, or it may be overwritten again / rendered useless. (See related Management 3.0 concept: basin of attraction [wiki]). The logical options are:
1) introduce change in as many parts of the system, that it’ll collectively be viable (e.g. sustainable change which is able to create positive feedback loops, thus, self-sufficiency) or
2) introduce change in all parts of the system, a.k.a. start everywhere at once.
Starting everywhere at once would mean that we pick as many parts of the system, as to which we can get access, and understand how the problem’s systemic effects reflect themselves in each of them. Let’s take this picture to get some examples:
See explanation of that drawing over here: An Agile software production cycle.
Note that it doesn’t matter whether the parts are practices, artifacts, events or technical systems. This is the case since we are doing a qualitative analysis, which is descriptive.
Now, let’s assume the Review constantly fails to be a success:
No insights are gained, participants feel left out, there is frustration over the results. Very likely the system of people involved will get a very sub-optimal understanding of how its latest release changed the Business Landscape.
thus, conversations on different requirement areas will suffer a lack of common understanding. Whether the latest release gained the benefits we hoped for will be harder to grasp. Consequently it will be harder to shape out User Stories / Tasks to refill the Product Backlog.
With the User Stories / Tasks in the product backlog being more ambiguous, and the developers not getting a common ground with all involved colleagues during the last Review, the iterative refinement on the User Stories / Tasks is very likely to be too superficial, e.g. too big slicing, too little implicit understanding for the developers, wrong/missing details.
Now, the Definition of Done is the next victim: Without the developers being able to clearly work down the User Stories / Tasks in a Sprint (in other words: not in flow), it will be even more harder to maintain the regulations of agreed upon coding practices, as scope creep and spillover to the next Sprint are very likely to be happening.
As a result the practice of Incremental Design will not bear success, as it is demands very high quality standards, and the combined application Plan/Design/Build/Verification in a very limited time frame.
Since the team at this stage is not able to deliver close to satisfiable DevOps are not a focus. That can have negative implications such as:
Expansion on the CI/CD practices will stand still, technical dept will rise, the infrastructure (if existing and fully functional) will not be used for its laid out purpose and corrode (as bugs/malfunctions not a priority).
So how to start everywhere at once? Understand and adress all issues together with the Actors & Owners of the complex adaptive system.
thanks to Joshua for phrasing the question what do you mean by ‘start everywhere at once’? on twitter