The “ScrumAnd” Stance (requires thought and discipline)

Try organizing a party in a “Yes, but…” atmosphere. The result is probably a zillion obstacles identified, but no party.
Try moving through a door with your eyes stubbornly fixated on the door frame. People seemingly can become deeply obsessed with frames-as-obstacles.

Try benefiting from Scrum in a “Yes, but…” environment, where the primary response is to raise concerns and hindrances, where the conversation is all about obstacles, and that what cannot be done.

“Yes, but” comes in many guises.

“Yes, but” is a tempting stance, offering the illusion of safety. Shifting to “Yes, and” requires thought and discipline. It requires thought and discipline to consciously look for possibilities and opportunities first, no matter how small. This does not preclude awareness of problems and obstacles, but the focal point shifts radically. Check if the door is actually open. Look at the doorway. Trust the door frame for holding the wall from collapsing if you pass the door. If the door is closed, the frame is probably not where the solution is. 

Imagine adopting Scrum from a “Yes, and” stance.

Over the past decade Scrum did more than just gain a critical mass to build on. Since Scrum’s inception in 1995 and the definition of ‘Agile’ as a set of values and principles in 2001, Scrum gradually became the most preferred way for people, teams and organizations worldwide to become more Agile. Agile crossed the chasm (2005-2006) and by now the 3rd Scrum Wave has risen.

Zeitgeist. Inclusive language and an inclusive stance are more helpful today. “ScrumAnd” is today’s way forward to help people increase the benefits realized through their manifestation of Scrum. 

“ScrumAnd” starts with Scrum. Scrum is a simple, yet cohesive framework. In a nutshell:

A Scrum Master fosters an environment where:

1. A Product Owner assures there is a Product Backlog, an ordered list of work deemed necessary to optimize the value a product delivers.
2. In consultation with the Product Owner, Developers pull the work from Product Backlog deemed feasible to get done in a time-boxed Sprint against an overarching Sprint Goal.
3. On a daily basis the Developers synchronize their progress and upcoming work toward delivering a releasable version of product, available no later than by the end the Sprint.
4. All players involved figure out what to work on next and how to best organize as from the next Sprint.
5. Repeat.

Although crucial to optimize the benefits realized, observation shows how difficult it is to keep Scrum cohesive. There are no practices that can be left out or cut out without harmfully breaking the cohesion (covering up dysfunctions or other ways of undermining important benefits). There is no such thing as individual Scrum practices.

Observation shows how difficult it is to keep Scrum lightweight and nimble. There is no need to aggravate Scrum. The “And” in “ScrumAnd” is not the next excuse to stack practices, rules or roles on top of Scrum. Instead, Scrum can wrap many practices, as tactics to apply the overarching rules, principles and values. Such are inclusive practices. Inclusive practices are needed and even make out a specific manifestation of Scrum. When inclusive practices are applied well, cohesion is preserved in the resultant system that is still recognizably… Scrum. “ScrumAnd” is more about the overarching rules, principles and values of Scrum, than it is about inclusive practices.

“ScrumAnd” starts, and ends, with Scrum. Many roles and domains exist that may not be covered by Scrum, for which Scrum has no rules, events and artefacts in place. Practices in such domains can help an organization get more out of Scrum. They are complementary practices. Complementary practices don’t change your manifestation of Scrum. The “And” in “ScrumAnd” is not about complementary practices.

“ScrumAnd” supports thinking about how to get more out of Scrum, how to be more effective in employing Scrum, and gain agility.

The syntax of “ScrumAnd” -if any- might look like:

Illustrations of “ScrumAnd”:

• “YES, we have a Product Owner,
  AND a dedicated, full-time Product Owner, acting from a business perspective, with a mandate, and clear decision authority increases our agility in terms of customer proximity."
• “YES, we have a Product Backlog,
  AND going from using it merely as an inventory of exhaustive specifications to experiencing it as a collaborative instrument that helps us focus on what is really important and valuable increases our agility in terms of our ability to deal with unpredictability."
• “YES, we have a definition of Done,
  AND expanding it beyond producing only coded, tested or even integrated work to creating releasable and valuable Increments increases our agility in terms of our ability to deliver actual value (and close the feedback loop with the customer base)."

 

The illustrations of “ScrumAnd” are just that, illustrations, representations of what might work, like some earlier illustrations. There are no universal definitions, labels or boundaries, not within an individual “ScrumAnd”, nor across several of them.

Download the "ScrumAnd" poster. 

And then complexity comes into play.

“ScrumAnd” illustrations can be created for all elements of the Scrum framework. The implied “ScrumAnd” stance shifts the mind to the exploration of options and possibilities, patterns of improvements, away from the frame (Scrum) or obstacles only.

And then complexity comes into play. There is a “ScrumAnd” in understanding and employing “ScrumAnd”. “ScrumAnd” is not for judging or assessing, it is more than a simplistic model of linear progression, more than phases, maturity or other levels. Inspection without adaptation is pointless anyhow, to start with. Despite the possible creation of individual “ScrumAnd” representations, the topics they target are necessarily connected, matched, intertwined. They reinforce or diminish each other without clear cause-effect relationships.

Complexity kicks in even more. One “ScrumAnd” may not result in improved agility through Scrum. Improvement requires concurrency and comes in Increments too. Reversely, increased agility through Scrum cannot be attributed to one “ScrumAnd” alone. “ScrumAnd” abides by the sfumato principle, the reality that reality has layers and shades of gradual progression, shadows rather than cold delineations, monochromatic color areas and binary separations.