This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.
1. Classic Scrum starts w/ 4 values, about a dozen prescribed roles & practices. The premise is that using these will enable performing in an Agile manner. But the why of these practices (other than the generic “be Agile”) is not presented. The laws of knowledge work are not stated. These are laws include overworking people causes delays; delays cause rework, low-quality &waste; quick feedback & managing queues is essential. Scrum ignores that there are no universal practices. The culture of the organization & how to transition to Scrum other than just jumping to it are also ignored
2. Disciplined Agile Scrum. This starts with seeing what the organization is trying to accomplish & what challenges they are having in doing so. It presents a small, but sufficient amount of theory for people to understand what would work in their situation. Guided by a DA ScrumMaster, the team decides on a starting point that is fit for them. This adds some work to the DA ScrumMaster but makes life easier for the team. The likelihood of success is greater. Furthermore, this understanding enhances the ability of the to work well with other teams & any external constraints
As the primary creator of the Disciplined Agile Value Stream Consultant workshop I facilitate the Community of Practice of the graduates of the workshop where we provide deeper training and pragmatic advice. One thing I do is ask how I can help them in their work. I have been told that one of the biggest impediments they face is Agile coaches saying the line in the title in response to suggestions for creating a more fit for purse approach than Scrum. There are several unexplored assumptions in that statement:
1-starting with Scrum will lead to improvement. Maybe it won’t. There are no universal practices. It’s possible starting with Scrum won’t work well because it may not be fit for the team's needs & using it will create frustration, causing it to be abandoned later
2-that if you start w/Scrum you’ll learn how to improve later. But Scrum doesn’t provide any insights on how to do this. And, since Scrum is based on empiricism, you may not have the theory required to do so
3-Scrum teaches the principles of Agile. It doesn’t. It teaches a variety of Agile values &practices. It may be you'll discover these principles using Scrum, but it's more effective when they are included in your approach
Systems thinking is a conceptual framework which takes the view that understanding how systems work requires an holistic view &a realization that systems exist within other systems. None of these systems (or system of systems) are well-defined by the components themselves but rather are driven by the relationships of the components
A systems thinking view has usually been missing in most parts of Agile, particularly those based on frameworks that have prescribed practices. Culture and attitudes of the people adopting the framework are part of the system. No framework exists on its own and therefore its practices may not be fit for purpose. Practitioners and consultants can improve their frameworks by adopting some central thoughts of systems thinking
Changing one part of the system affects other parts of the system, often with unpredictable behavior.
Systems manifest patterns of behavior, the understanding of which can help improve them
Systems interact with the systems they are part of
an holistic view must be taken when looking where to start
Wherever started, the goal should be to affect the larger system. This requires attending to how those in the starting point are affected by and affect other parts of the organization
In ’09, after Kanban had its coming out party at the Miami Lean-Kanban Conf, Ken Schwaber blasted the “explicit workflow” concept of Kanban on the misguided thinking that people would follow this explicit workflow
Explicit means “stated clearly and in detail, leaving no room for confusion or doubt"
Implicit means “implied though not plainly expressed”
There should be no inference that explicit means hard to change or something to follow. It just means that we’ve stated what we think the best way of working is. It's changed with just another explicit statement
Part of an explicit workflow can also have an out like – “except when” or “let someone know when you don't do it, if there's a better way"
The agreements they represent are a reflection of what the team believes is the best way of working, not something to be followed
The idea that explicit means hard to change or to be followed is one of the great misunderstandings of Lean/KB still in the Scrum community. A common understanding of how people are working improves collaboration and discovering better ways of working. W/o explicit workflow it gets hard to make improvements since no one is sure what is being done.