Scrum, in its more general definition, is a simple framework to help us address complex challenges. Product development is the subset of complex problem domains where Scrum took root first; by explicitly acknowledging software and new product development to be complex work, serving to deliver complex products in complex circumstances.
Scrum is increasingly being discovered as a simple framework to address complex problems and situations other than software and product development. More and different people, teams and organizations ask for guidance and support on their journey of Scrum, no matter the nature of their problem. Organizations discover that fighting complexity with complexity is not helping. Too much waste, organizational redundancy and fundamental impediments remain unaddressed by the overly complex approaches that organizations use. No sustainable agility is achieved. Organizations discover that they have been seeking for (or were pointed to) universal truths where there are none.
Complex work, of which software and product development are good examples, does not have the high degree of predictability to apply the old approaches that build on linearity, causality and predictive management.
One aspect of ‘complexity’ are the parameters, variables and events that influence an activity and its course. Think of your work, make a list. Consider how predictable the listed variables are, how much control you actually have over them and how sure you are that you listed all of them. However, it is not only the number of known parameters that is important, but also the available as well as the required knowledge over these parameters. What is the level of detail required to comprehend a variable as well as the future behavior of that variable? How long does it take to gather that information? How stable is that information, once collected? Even if a parameter is known, the level of detail may be too deep to be able to manage and control it. And then, of course, the behavior of the parameter is still not necessarily predictable. A known variable may still behave completely different compared to what was planned or expected to happen. And, do not forget that all variables, known and unknown, are related and impact each other, typically in non-linear ways.
‘Complexity’ is also dependent on the nature of the work itself. The combined steps, tasks and activities that make out complex work are not predictable with any degree of high precision. They have not been performed before, or not in the same way or context. They are not repeatable. New insights, techniques and approaches emerge, even while the work is already taking place. Also, the exact and detailed outcomes of complex work are hard to describe and predict before or even at the beginning of the actual work. Expectations change. Markets evolve. Competitors surprise you. And, complex work typically requires the cognitive and creative capabilities of people performing the work. The engagement and involvement of people is dependent on more circumstances than we comprehend, let alone can control.
Complex work is actually more unpredictable than it is predictable. Complex problems are dynamic, not static. The degree of dynamism of a problem or activity requires the right forms of process and stability to be in place in order to have some form of control. Stability in complex work performed in a complex world comes not from fixing requirements, outputs, timelines or plans. These are destined to be unstable and will change. Stability is not about certainty or predictability. Stability is about an environment and boundaries within which to explore and experiment, within which to continually diverge and converge towards incremental solutions answering your complex needs.
Too many organizations end up in total chaos when they experience how the old elements of stability no longer work, but fail to replace them with the minimal measures that would help them optimize their Scrum to better address their complexity:
Start with identifying your problem (product).
In a typical Scrum setting, the problem is developing complex solutions, often a product or a service.
Define and identify your product first. Then organize your Scrum, or re-imagine your Scrum, to optimally tackle your problem or serve your product.
I have observed too many many organizations form Scrum Teams within existing specialist silos and departments, doing little more than renaming existing titles and functions to Scrum terms, certainly not minding the scope of their Scrum, let alone capitalizing on synergies that exist across those individual Scrum Teams, like the fact that they actually all work on the same product. Disconnectedness is not resolved. The complex problem is not adequately tackled. Parts or components of product are being built, rather than integrated, cohesive product versions that provide end-to-end value.
Have dedicated teams working in dedicated team spaces.
Complex problem-solving requires focus, interaction, communication, collaboration, cross-fertilization and collective intelligence. It requires dedication.
Teams should not be all over the place in terms of getting dragged to external meetings regularly or having to work in multiple teams or on multiple projects. Your teams should be able to primarily dedicate their time maximally on the problem/product at hand, self-manage their work in Sprints and even figure out and establish their own team size and team composition. I have observed too many teams that were really jelling and achieving a highly collaborative state, until being pulled apart by people external to the team; resource managers, departments heads, project management offices. Each one of those teams ultimately plummeted, demotivated.
Teams definitely need a dedicated team space to get the most out of their collaboration, conversations and interactions. Open offices kill innovation and creativity, even more when combined with clean wall policies. People dare not speak up or need to move to separate meeting rooms to do so. Open offices are good for… office work, not for intense and collective problem-solving.
Benefit from the consistency that the Scrum events provide without industrializing your Scrum to death.
Scrum by default offers stability and consistency by suggesting to keep Sprint length stable over a substantial period. It allows people to, often unconsciously, grow an intuition of what is (not) possible, which is extremely helpful in forecasting Sprint and Product Backlog work. It offers minimal stability. It is why Sprints, as container events, have a fixed time-box. Sprints don’t end sooner or later than the set time-box, while the other events can end sooner. Sprint is a stable container event that provides overall rhythm and cadence to the opportunities for inspections and adaptations foreseen within a Sprint; Sprint Review, Daily Scrum, Sprint Review and Sprint Retrospective.
I am astonished however how organizations dictate a fixed Sprint length to all teams across the organization, regardless of their problem, technology, business domain, product. Organizations tend to industrialize their Scrum, rather than standardize on Scrum. Scrum can be introduced and adopted, allowing all within an organization to speak the same language, without eliminating the option of tuning your Scrum to a specific context.
Scrum only defines that Sprints should be no longer than 4 weeks. Within that range every complex product development endeavor can decide over its own right-size Sprint length. This right-size stability factor is not necessarily the same for all products. This brings us back to the necessity of identifying your product or service first, and then organizing your Scrum to optimally serve your product (including considering the Sprint cadence for all teams serving the product).
. . .
Originally published at http://guntherverheyen.com.