Some teams of knowledge workers (En.wikipedia.org, 2019) work primarily on complex problems. Scrum operates in the complex problem domain, so it can be a natural choice.
Picture this context
Single team Scrum is in use by many teams of different initiatives
Having genuinely tried, some teams are unable to use Scrum, as they cannot deliver potentially releasable value in 30 days or less. Even 90 days might be a struggle.
OK, one might say “can” and “cannot” are just opinions/attitudes.
In a scaling context, some patterns can deal with the kind of Scrum that does not yet deliver value per team from a Scrum Sprint.
The teams in this context are operating deeply in the complex space with more unknown than known.
Maybe in some cases, the team members’ belief systems are closer to Kanban.
And, maybe the teams have non-software knowledge work
Professional Scrum with Kanban still requires Scrum as rule 0. This guide is based on the Kanban Guide for Scrum Team by Daniel Vacanti and Scrum.org. The Professional Scrum with Kanban class is stewarded by Steve Porter, Daniel Vacanti and Yuval Yeret. PSK does allow for Kanban upstream and “dare we say it”, downstream. Yet, this Kanban for Complexity™ Guide for Teams and Servants has many differences to the Kanban Guide for Scrum Teams, and it shares an approach for dealing with complexity using Kanban.
This guide describes a variant of Kanban training, call it a new method if you wish. Let’s call it Kanplexity™ for short. In the spirit of empiricism, this guide will evolve. The intent in this guide is to attain satisfactory handling of complexity, eventually “nailing it” through empiricism. We’re quite possibly not there yet.
The flow-based perspective of Kanban for Complexity™ can enhance and complement what you do now, and help move towards a new Direction of Travel. Teams can apply Kanban for Complexity™ if they’re willing to pay the price, that is, using complexity sense-making, embracing uncertainty, optimizing work in progress, using explicit policies, and avoiding local optimization.
Professional knowledge workers (En.wikipedia.org, 2019) potentially of many sorts, e.g., marketing, HR, finance, legal, software, hardware, telecoms, energy, supply chain, manufacturing, automotive, innovation, etc., can benefit from the application of Kanban for Complexity™ together with what they do now. But context is key. Kanplexity™ might not be useful for very unstable Teams or Teams that have team members with a strong disincentive to collaborate.
Kanban for Complexity™ is itself on an empirical Direction of Travel, and it is designed to support the Cynefin™ Sense Making Framework’s complicated (domain of experts) & complex (domain of emergence) domains, regardless of the type of knowledge work, regardless of whether (customer and/or knowledge) value can be delivered in 4 weeks or less. Kanban for Complexity™ has Rhythmic Cycles. The words “iteration” are “sprint” are overloaded for Kanban. In any case, the essence of Kanplexity™ is small self-managing cross-discipline cross-functional Teams learning from stakeholders in fast feedback loops governed in rhythm cycles. Kanplexity™ has two roles, Team(s) and Servant(s). Kanplexity™ has a Direction of Travel and a Workflow. It has five events, the Rhythmic Cycle, (optional) Rhythmic Replenishment, Daily Kanban, Rhythmic Impact Review, and Rhythmic Retrospective. It supports discovery & delivery, and it attempts to avoid the Innovator’s Dilemma (En.wikipedia.org, 2019) through disruptive innovation, as well as sustaining innovation. For over two teams, to help avoid typical failure-modes, this guide recommends some tried & tested strategies (appendix).
See the Kanban for Complexity (Kanplexity) Guide for Teams and Servants here.
John Coleman has been knocking around with agility since 2004, starting with a mission critical piece of work back then against advice and taking on ever more scary work since then :). A speaker, consultant, coach and trainer on all sorts of agility.