Inside of the whirlwind (The third Scrum Wave)

Scrum is a simple framework that supports people in making the most of complex challenges. Organizations are re-discovering the sophisticated simplicity of Scrum. The third Scrum Wave is rising. Will you sink? Swim? Or will you surf? Shape the wave, shape the future?

TALC – the Technology Adoption Lifecycle

The Technology Adoption Lifecycle (TALC) describes the adoption stages of technology products or services, disruptions and discontinuities in hi-tech innovation. The TALC was created by Geoffrey Moore as an expanded version of the adoption cycle of more traditional products and product lines. Every stage has typical adopter types.

Moore added a “Chasm” period after the phase of Early Market. It is a period of stagnation, a period where adoption stalls. Some unknown time passes by before the next phase of adoption is entered, the Bowling Alley. The Chasm is unpredictable in length, but also in outcome. Some products never get out of this stand-still and simply disappear.

AALC – the Agile Adoption Lifecycle

The term ‘Agile’ became part of the software development lingo in 2001 with the publication of the Agile Manifesto. Before that time, it was just a plain English word that -in short- is synonymous to ‘adaptive’. In a way, it still is.

New technological products that follow the Technology Adoption Lifecycle could be developed applying Agile techniques and principles. Agile in itself however is also a new, and clearly disruptive, game on the technology market and is therefore subject to the Technology Adoption Lifecycle as well.

2001 marks the start of the Early Market phase. At this stage Agile was mainly recognized and promoted for its potential value by early adopters; pioneers, visionaries, enthusiasts, innovators. Early adopters included individuals, teams and organizations.

During the preceding ‘avant la lettre’ phase several approaches and techniques that later became ‘Agile’ were being explored by various ‘creators’. Important milestones are 1995 and 1996, the genesis of Scrum and eXtreme Programming. They were 2 well-defined new approaches to software development in which many of the core ideas of what became ‘Agile’ can already be discerned.

A much broader audience discovered Agile as from 2005-2006. For many organizations the traditional way of working, the industrial paradigm, had been stretched far beyond its limits. There was nothing to stretch anymore. It created mental openness for a very different paradigm. Early Pragmatists discovered the advantages of the new paradigm, of ‘Agile’, and believed its problem-solving capabilities to exceed those of the existing ways. They were looking for solutions that might work. They had no need for widely documented evidence, but settled for the growing amount of anecdotal evidence. Agile crossed the chasm.

Although the TALC typically describes the succession of the Bowling Alley and Tornado adoption phases, the post-Chasm years of Agile primarily showed many back-and-forth movements. There was a lot of pull-back from the traditional, industrial paradigm. Still, a viable market formed.

It is probably too soon to distinguish the Bowling Alley from the Tornado yet. I mainly observe a strong whirlwind that Agile goes through.

Inside of the whirlwind – The 3 Scrum Waves

Regardless the inability to distinguish the transition from Bowling Alley into Tornado at the current point in history already, Scrum has been the dominant definition of Agile post-Chasm. Scrum is the gorilla that emerged.

Inside of the whirlwind, three waves of Scrum have manifested.

The first wave of Scrum, rising with Agile crossing the chasm in 2005-2006, was a reconnaissance wave for many. Organizations faced obvious problems in the IT and software delivery domain that could no longer be patched through the industrial ways. Scrum was adopted as the new IT development process.

The second wave of Scrum built on the first wave when in 2010-2011 large organizations -often in the aftermath of the financial crisis- discovered they were at the end of the old ways of working too. In the slipstream of this ‘success’, sub-groups and derivative movements took off, new movements and methods were invented, introduced, launched, and often disbanded again. Divergence and scale were the ruling themes, on top of the common use of Scrum’s terminology and the shared desire to deliver working software in Sprints.

The third Scrum Wave (2016-2017) is fuelled by the desire, the drive for rhythm, focus and simplicity. Too much organizational waste, neglect of people and embedded complexity remain, fundamental impediments unresolved by the (often complex) solutions of the second wave. Organizations renew their acquaintance with Scrum. They appreciate that it is a well-defined and clearly stated framework that creates room for diversity, in it that Scrum can wrap a variety of strategies and techniques to be employed.

Convergence appears on the horizon, where the rage of scattering, where the whirlwind might start calming down. Agile professionals worldwide sow seeds, and fertilize the grounds for many organizations to start bearing fruits, to start enacting Scrum. Join the bigger movement.

 

Closed-loop feedback control with Scrum

Scrum is a simple framework to manage complex challenges. Software delivery is a complex challenge. Software delivery encompasses a multitude of complex activities to create and evolve complex products in complex circumstances. Scrum embraces and emphasizes the complexity of software delivery by implementing the only process type that fits its complexity, empirical process control.

Complexity

There are many variables that have an impact on delivering software; requirements, skills, experience, people, teams, technology, integrations, market conditions, company strategies, budgets, regulations and dependencies, to name just a few. Not all known variables are controlled by the people doing the work, although they have to incorporate the impact on the work. For some known variables too much detail is needed to fully comprehend them. Even if a variable is known, its behavior -now or in the future- may be unknown, or different from what is anticipated.

Products are created by people with cognitive capacities. People are not robots, or replaceable pieces of machinery. The outcomes are hard to describe in an exact and detailed way; before, at the beginning or even as the work advances. Every product created is unique and what is appreciated can only be established when released. The activities to be undertaken aren’t predictable with any degree of high precision. They have not been performed before, in the same way, under the same conditions, several times. The environment evolves constantly. And, most annoying, not all variables are known. There is a high degree of unpredictability.

The degree of dynamism of a challenge requires the right process to be in place in order to have control:

Open-loop systems

An open-loop system is designed for execution of a series of preempted steps to result in a defined outcome in a single run. Such a system assumes a near-perfect predictability of the variables that influence the process as well as of the process activities themselves.

For larger problems, typically a chain of open-loop subsystems is created. The output of a subsystem is the input to the next subsystem. Although theoretically risks should be confined to the smaller subsystems, in practice the whole system’s vulnerability increases exponentially. In situations of turbulence and change, deviations and variances accumulate across the various subsystems, e.g. in timing and quality. It is not uncommon for the accumulated problems to surface only at the end of the final subsystem.

Predictive plans and hand-overs of work between separate functional groups are implementations of open-loop thinking. Predictive plans can only include known variables, their known details and their anticipated behavior, creating the illusion that no unknowns exist. Open-loop thinking invites lengthy upfront consideration of all elements of the plan, and ultimately attempt to foresee the unforeseeable.

An open-loop system is -by design- unable to cope with the amount of disruptions and unknowns typical for complex challenges like software delivery.

Closed-loop systems

Closed-loop systems implement frequent opportunities for inspection so adaptations can be implemented. The actual outcome of the system is compared in a timely fashion against a desired outcome. Desires may change. Variances or undesired results are eliminated or corrected in the next or in future runs. Not all variables and parameters need to be known precisely and in detail, as the process is self-correcting. The system requires and creates transparency. Reality is inspected, and exposed, so that appropriate adaptations are undertaken. The people performing the inspections have clear and agreed standards in place to inspect-and-adapt against. Inspection for reporting and status purposes is pointless. Inspection without adaptation is pointless.

Closed-loop feedback control with Scrum

Scrum embraces and stresses the complexity of software delivery by implementing empirical process control. Scrum replaces the open loops of traditional, phase-gate, staged or similar processes with closed-loop feedback. Scrum defines regular opportunities to inspect and adapt. Scrum enables players to halt the traditional rat race. The players are enabled to stop, reflect, learn from inspections, gather feedback over the output and change course, re-organize, update priorities, improve, adapt. Scrum brings reality back in the game. Scrum brings transparency. That is pleasant when all is progressing well. That is crucial when all is not progressing as hoped for. It allows re-positioning and correction.

In Scrum all work is organised in Sprints. Sprints are time-boxed to assure timely inspection and adaptation. A Sprint forms an ‘inspect and adapt’ cycle of a few weeks at most that wraps the 24-hours ‘inspect and adapt’ cycle of the Daily Scrum:

  • At the Daily Scrum the people doing the work inspect their progress, and identify their most important work to do next within the container of the Sprint. They use the Sprint Backlog, the Sprint Goal and a progress visualization to self-organize within the Sprint. The daily cadence assures they never get out of sync for more than 24 hours.
  • A Sprint is a cycle that starts with identifying and interiorizing the most important ideas instantiated on Product Backlog. Sprints end with an inspection of the product Increment that was actually released or could be released, as well as how it was built, the process, the interactions, the technology at play. As with all inspections, they are forward-looking. They serve the purpose of adapting.

All events of Scrum set a frequency for the inspection and adaptation process, where the artifacts contain the information to be inspected and adapted. Scrum describes the accountabilities needed to perform the inspections and adaptations.

Organizing work in Sprints allows people to take a breath, to break with the traditional rat races, and work at a sustainable pace. Explicit reflection moments are introduced that are crucial for humans to thrive in cognitive, creative work of high complexity, like software delivery is. Within a Sprint, additional feedback loops are created, e.g. through agreed work and development standards.

Note: above text is adapted from my book “Scrum – A Pocket Guide (A smart travel companion)”. If you have more time to spend, consider reading it.

Re-vers-ify (re-imagine your Scrum to re-vers-ify your organization)

Agility is why organizations adopt Scrum.

Organizations suffer as they fail to act with agility through product releases, on the market, for users and consumers, facing competitors. Scrum is mandated and it is overlooked that the agility demonstrated outwardly also depends on the setup of internal structures.

Organisational rigidity is the result when people are separated in functional silos, when collaboration is instructed through hand-overs and governance, when go-see management is not practiced, when the daily work has no room for discontinuous innovation. Basically, such rigidity is the anti-thesis of Agile and impedes outward agility.

Scrum is a simple framework for complex product delivery. Scrum thrives on the self-organizing capabilities of collaboractive people creating finished versions of product in short cycles, called Sprints. Scrum is in itself agnostic of internal structures, positions, titles, hierarchies. Scrum has no mandatory rules for organisational constructs. Scrum is simple, not easy. The simple rules and roles of Scrum are most often twisted and broken to fit an existing organization. Yet, it is nearly impossible to benefit really from adopting Scrum without updating the internal operating systems.

The sensible and courageous way forward is to re-vers-ify, to re-imagine your Scrum to re-emerge your organization. It is a path, not the destination. The destination, an updated organization, is unknown, remains to be discovered.

  • Use Product Backlog as the single plan for one (1) meaningful initiative (project/product/service). Slice the initiative if it is too big.
  • Reset the accountabilities for the selected initiative to Product Owner, Scrum Master and Development Team(s).
  • Facilitate the eco-system with tools, infrastructure and a (Scrum) team zone in order for them to create sashimi releases. A controlled and automated deployment pipeline is certainly a much needed step forward.
  • Repeat, grow, learn, expand.

“Re-vers-ify” is a narrative to help people re-invent their organizations; an invitation for people to re-imagine their Scrum to re-vers-ify their organization. Over the course of 2017 I have introduced re-vers-ify in several ways. I have now highlighted the essence in a short movie. It takes only slightly over 3 minutes of your time. Enjoy!

If you have more time to spend, consider reading my book “Scrum – A Pocket Guide (A smart travel companion)“. It ends with following belief:

Product Backlog and the tea leaves effect (a message to Product Owners)

Product Backlog is a strategic instrument of high value; for stakeholders, product management, the organization, the Development Team(s), and the Product Owner. When employed well, Product Backlog reflects the vision, ambitions, roadmap, needs and wants for a product or a service, all in one place. Imagine how your competitors would love to have access to it!

Product Backlog has the potential, as a single artefact, to replace a multitude of other predictive plans and traditional documents. In Scrum, Product Backlog is all the plan you need. For Product Backlog to enhance simplicity and transparency, Product Owners maintain Product Backlog continuously. The Product Owner, actually owning the product, orders and manages it to reflect the actual needs, wants and ambitions.

Product Owners likely apply multiple hands-on strategies to keep Product Backlog tidy and accurate. It helps for many Product Owners to realize how the tea leaves on a Product Backlog impact transparency.

Having explained Product Backlog and the Tea Leaves Effect in the past, I have now summarized it in a short movie. It takes less than 2 minutes of your time. Enjoy!

Scrum. Period.

I observe a revived interest in Scrum. I observe how people, teams and organizations re-discover Scrum. Scrum has the simplicity they grasp for. They see the value Scrum brings. Simple and valuable, not easy. In a forward-looking observation I described it as the third Scrum wave that is rising.

Scrum is simple indeed, yet has so many aspects to be discovered by so many organizations. Scrum serves a journey of product discovery. Adopting Scrum is a journey of discovery in itself.

Scrum is a simple, yet sufficient framework for complex product delivery, for managing complex challenges. There is a high cohesion in the minimalist set of rules and advised activities of Scrum. There is no such thing as individual Scrum practices. Scrum lays down essential boundaries within which people self-organize, within which people devise a way of working tuned to their own context. Scrum can wrap many practices. When applied well, the integral result is still… Scrum.

The themes of the recent past of Scrum were ‘scale’ (volume) and ‘divergence’ (different names and movements). Distractions. People, teams and organizations realize that it did not result in the agility they need in their complex context. I observe a revived interest in the cohesion of Scrum, the framework as a whole. People, teams and organizations learn that over-focusing on isolated elements of Scrum has not helped them tackle their complex challenges and humanize their workplace.

While rediscovering Scrum, as a whole, people, teams and organizations discover that Scrum still leaves plenty of room for their context-specific needs. Scrum is designed to holistically support people, teams and organizations to create, maintain and sustain complex products. Scrum does not replace people’s intelligence and creativity, rather provides a frame for people to operate within and create valuable results. Scrum is intentionally low prescriptive. Scrum offers a limited set of mandatory prescriptions, which in turn allow many variations to apply the rules.

Scrum most often does not fit the existing, rigid structures of many organizations, the hidden impediment to achieve true agility. Stick with Scrum. Consider the core framework to be immutable. Period. Start small. Through practice all people involved will ingrain new behavior, enact the Scrum Values and grow a new working culture, a more humanized workplace.

Twisting Scrum, hacking into the basics of the framework breaks its cohesion, covering up dysfunctions rather than revealing them, probably disregarding the principles and foundations upon which Scrum is founded, rather than promoting great behavior. Such versions and implementations are possible. Isolated use of Scrum’s terminology or individual elements is possible. They might look like fun. They might work. They lack cohesion. They are not Scrum.

The 3rd Scrum wave is rising. Will you sink? Will you swim? Be a laggard of the second wave? Or will you surf?

On a personal note I want to add that I am delighted to see a shift from ‘Agile Coach’ to… Scrum Master. A good sign. A sign also that the need is real to have someone working with the teams and with the organization in fostering a healthy environment, an environment where innovation and creativity can emerge, where people can demonstrate traditionally unsafe behavior.

Product Owner, actually owns the product

The description of a Product Owner’s work reads as no existing job summary. “Product Owner” is not just a new name for the old roles and titles originating in the industrial beliefs that dominated businesses and society far too long.

Our dependence on software and technology keeps accelerating. We live and work not only in a globalized but also in a digitized age where technology, knowledge and the availability of information prevail more than ever, through a variety of technology products more than ever. Product Owner is a new, modern role, that fits that new world.

Product Owner, within an organization, actually owns the product, is a product-CEO. Product Owner is the many-faceted servant-leader in an eco-system revolving around the product, an eco-system that stretches beyond the borders of the organisation that creates the product. Product Owner is a strategic role, that is still ignored too much.

Scrum, a simple framework for complex product delivery

Much has been said, is being said, and will be said about Scrum, the most adopted Agile process.

Scrum, in the end, is a simple framework for complex product delivery. Scrum has a limited set of mandatory rules and roles. They all serve to create an environment within which people inspect their work regularly, so they can adapt. Scrum is an open framework in the sense that people can employ a variety of specific practices. When these practices are employed well, the integral result is still… Scrum.

Despite/due to its popularity and simplicity, much misunderstandings exist. I highlighted the essence of the Scrum framework in a short movie. It takes less than 3 minutes of your time. Enjoy!

If you have more time to spend, consider reading my book “Scrum – A Pocket Guide (A smart travel companion)“.