Creating opportunities to deliver value (as an Independent Scrum Caretaker)

I have wandered the fascinating realms of IT, technology and software development since graduating in 1992, except for the years of running a bookstore (1996-1999). I discovered an Agile way of working through eXtreme Programming and Scrum in 2003. It became my purpose, my belief and my core; spreading the Agile paradigm to help people create better products and humanize their workplace.

After a career as a consultant (2001-2013) and spending 3 years working exclusively at Scrum.org as partner to Ken Schwaber, in 2016 I decided to further my path as an independent Scrum Caretaker; a connector, writer, speaker, humanizer.

I’ve come to accept the difficulty of grasping what this holds. I understand the difficulty when people offer me positions and assignments, assuming I am desperate (for money, status, work). Regardless, through my self-chosen ‘title’ I consider the areas through which to deliver value to the world, to help that world become a better place to live and to work in.

  • Classes“: Facilitating people’s knowledge and insights in Scrum through Professional Scrum Master and Professional Scrum Product Owner classes, and custom workshops.
  • Events“: Attending and speaking at events.
  • Writing“: Creating papers, a new book and blog notes (reproduced at some other channels).
  • Consulting“: Working with teams and organizations, upon the non-negotiable requirements that it must be personal, about Scrum and serious.

Every activity involves plenty of hours of devising the right words and even many more hours of silent reflection, travelling mental cobblestone labyrinths. I don’t look for money for every single activity in every single service area. Context prevails.

From my standard offer of services:

Through my work I have come to appreciate the uniqueness of every person, team, department and organisation. It has inspired me to move away from fixed approaches. (…) I don’t require specific task descriptions. I require no title. I don’t post my assignments or expose the name of your organisation, unless you explicitly allow or ask me to do so.

Through the initiative of the Scrum Caretakers meetups, I see my experience confirmed that it is not easy being a Scrum Caretaker. It takes quite some intrinsic motivation, belief and dedication (a purpose) to give up (paid) time for mere collaboration on open-ended topics that rarely serve a commercial purpose. It did get me in touch with a lot of non-usuals suspects, outside of the threaded paths of ‘Agile’. The sheer beauty of that experience makes up for a lot of the sacrifices.

I am gratified for the opportunities I stumbled into through my years at work. It served me well in becoming what I didn’t know I wanted (or was able) to be. Most dots only got connected in retrospect, still making it seem as if there was a plan. There wasn’t. In general I had no clue. I still haven’t. But becoming an independent Scrum Caretaker did help me shift towards creating opportunities to deliver value, and help more people deliver value. Reciprocity.

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.

Scrum and universal truths

An update to the Scrum Guide will be released on 7 November 2017. In a webinar the principal co-creators of Scrum, Jeff Sutherland and Ken Schwaber, will introduce the changes relative to the previous update. The previous update was released on 6 July 2016 and encompassed the addition of the Scrum Values.

Although language and words matter, I imagine the difficulty of the rewording involved in updating the Scrum Guide. The Scrum Guide holds the single definition of Scrum for countless practitioners across the world, all employing Scrum in unique environments and varying situations. I imagine the discipline of updating the Scrum Guide knowing that many people will not read it. Most of all, I imagine the difficulty of updating the Scrum Guide knowing that many will micro-dissect the texts to identify the tiniest of changes. Many over-think individual words upon the (false!) assumption of traps, tricks and hidden messages. Many still look for methodological exactness and universal precision.

Regardless, the fact that Scrum has a clear and documented definition is priceless. The Scrum Guide provides clarity and purpose, albeit not the perfect precision that many seem to look for.

Scrum is a tool. Useless unless employed. The Scrum Guide intentionally has no universally applicable, detailed instructions or tactics that in the end only work in specific circumstances. The Scrum Guide describes how the tool works, the rules and roles that apply, the behaviors that make the tool work; not the tactics to apply the rules. Scrum, by design, offers room and breathing space, inviting people to conceive an approach specific to their context upon the empirical foundation of Scrum. Scrum is a framework, not a traditional IT methodology. The Scrum Guide describes the framework, the minimal boundaries within which people deal with complex challenges and create complex solutions in complex circumstances.

All exact decisions within those boundaries depend on people, tools, technology, business domain, organizational environment, market situation, and many other aspects.
What is the availability of people? Their skills, experience? How well do teams gel? Do they work remotely, or co-located? How long have they been working together? How much multi-tasking does a team or team members have to do? How well are teams facilitated by the environment? What technology is being used? Which version? What dependencies are at play? What development practices does a team have in place? What tools and infrastructure are at the teams’ disposal? How long are the Sprints? How is the connection with product management? What is the competition doing?

The Scrum Guide does not have the false pretence of offering universal truths, universal answers that apply in every single situation. Scrum essentially invites people to regularly match the actual state of their work against reality, in order to re-align and adapt to new circumstances and incorporate new insights. Scrum is a simple framework for complex product delivery.

The Scrum Guide offers the simplicity needed, without being simplistic about the unique challenges that teams face. I notice how many people struggle with this deliberate imprecision when they try to improve their understanding of Scrum. They look for detailed instructions. They ask universal questions and demand exact and precise answers.
How long should Sprint Planning be? And the other events? How much time does the Product Owner role take? Is the Scrum Master role a full-time job? Should a team be available full-time? How must we organize when the team is distributed? How much time of a Sprint should a team spend on testing? How many business analysts are needed in the team? How should we calculate utilization? How can we measure productivity? Should the Product Owner and the Scrum Master understand the technology? What if… ?

No document, no matter its size, can provide exact answers to these questions for all Scrum practitioners around the globe. It requires courageous professionals (Scrum Masters, trainers, and otherwise) to build on the language and words provided by the Scrum Guide and explain intent and purpose. It requires skilled professionals to help teams, organizations, and students grow an understanding of how Scrum supports them in empirically dealing with the diverse, complex challenges they face in their real-life complexity. Such professionals understand that what works today might not work tomorrow. Exact instructions lead people astray, undermine their ability to think autonomously in terms of Scrum.

My personal stance, as a trainer, a friend, a trusted advisor, a whatever in Scrum, is to facilitate people in understanding the purpose of the rules and the roles of Scrum. I consider it the only viable way for people to devise their own solutions employing Scrum. No external instance, expert or otherwise, can or should do that for them. It may be tempting. It is certainly highly convenient. It might make a person appear knowledgeable. But it promises certainty where there isn’t. That is unprofessional. It ignores context and complexity. It ignores people’s intelligence and creativity.

I am extremely wary of being seen as an ‘expert’ providing universal solutions. Consider me an eternal novice instead.

Every case of Scrum is unique. There is no copy-paste. There are no universal truths in the complex novelty space. The definition of Scrum requires no methodological precision. There is no future in ignoring complexity.

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!

Blog Statistics (country views)

On Valentine’s Day of 2008 I started my blog “Ullizee.wordpress.com” with a first blog post. The URL still exists but is now redirected to “guntherverheyen.com”.

Since that day I have created 457 posts. The past years I blogged primarily about Scrum, and rather occasionally still about my love for books, music and my family.

I am mostly amazed by the global reach of my musings. The statistics show that my blog was visited by people from 182 countries. The top 10 countries (5,5%) account for 75% of all traffic.

Another 20% of all traffic is by visitors from an additional 30 countries (16,5%). So, 95% of all traffic on my site is generated by visitors from 40 countries, i.e. 22% of all countries. That leaves 142 countries, 78% of all countries, accounting for the remaining 5% of traffic.

Hereby a huge thanks and a big hug to my international readers, followers, likers, sharers. You mean the world to me.

Love
Gunther.