The customer-oriented enterprise: (1) Scrum in the land of Extremistan

Publish date:

Thoughts on empirical management, Business Agility and Enterprise Scrum (part 1/3)   The game of Scrum knows no more than 3 roles: Development Team, Product Owner and Scrum Master. These roles have proven to be sufficient for developing, maintaining and evolving great software products in the land of Extremistan°, the land in a constant state […]

Thoughts on empirical management, Business Agility and Enterprise Scrum (part 1/3)


The game of Scrum knows no more than 3 roles: Development Team, Product Owner and Scrum Master. These roles have proven to be sufficient for developing, maintaining and evolving great software products in the land of Extremistan°, the land in a constant state of statistical unpredictability. It’s where we live. The reason why Scrum is so great over there (here) is that Scrum not only embraces the unforeseen, but that the players of Scrum take full advantage of the unforeseeable, detect it early, exploit it and turn it into differentiating, competitive advantage.

The Scrum framework, as described in the Scrum Guide, uses empirical techniques and principles to solve complex problems in a complex environment. Increments°° of working product are frequently delivered upon time-boxed iterations ensuring that the Value of a total Product continuously increases and matches the current demands, not crystal ball predictions that were made once upon a time. Delivery of such working Increments is the core objective of a Scrum Team. Therefore Scrum needs not describe more than the 3 mentioned roles, as they are the only required to performantly realize that objective. Scrum does recognize direct stakeholders for a product outside of the 3 Scrum Team roles, but instructs no more than inviting them to review every working increment at the end of a Sprint (‘Sprint Review’ event) if their feedback and input are important to evolve and improve the product. These stakeholders, and by extension all other people in the organization, are expected to respect the rules of Scrum to let self-organization drive the emergence of innovative ideas and better products. This implies that the Scrum framework in itself has no explicit definitions for the broader organization.

But when rolling out Scrum, the broader organization will obviously be impacted. Issues will come up and need to be taken care of in order to have the full benefit of Scrum, to further facilitate the Scrum Teams. Organizational opportunities and improvement areas are discovered through the application of Scrum. There are 2 linked Scrum demands that will primarily drive this disclosure, when looking at actual situations:

  • Development Teams are expected to be (or evolve to) cross-functional (Feature) Teams. This means that the Development Teams need to have all skills and talents as active part of the Team that are required to turn selected requirements (from the Product Backlog) into working software, shippable increments;
  • Having a shippable increment by the end of every Sprint implies that no additional work needs to be organized in order to get the produced increment into production.

Impact on the broader organization lies also in the fact that the full benefit of Scrum lies well beyond just using Scrum to better organize development from a pure IT perspective. Limiting the use of Scrum to the mere development process is a sub-optimal implementation of Scrum. It may result in faster results and better software, but does not enable taking advantage of unforeseen or hidden business opportunities.  It misses exploiting the Power of the Possible Product, as pursued by an Agile product manager. A typical sign of this type of implementation is having a proxy Product Owner, i.e. a person representing business on the Scrum Team, not a business person… in person. Such implementation tends to lack the insights, connections and mandate that an Agile product manager has, and that are fundamental to the optimal operation of a Scrum Team.

It connects to the awareness that organizations should have; that Scrum should not be implemented just for the sake of it, but as a tool to be Agile from an organizational, enterprise perspective. Feel the power of Scrum and the force of its empirical adaptiveness by not implementing Scrum as just a new development approach, but as a framework of rules, roles and events that enable organizations to capitalize on the unforeseeable, to achieve Business Agility. The least such a full implementation of Scrum will do from that perspective, is enable fast adaptation to follow the market and the competition (again).

But a vast majority of organizations currently act as if they still reside in the land of Mediocristan, where a characteristic is that success has a direct relationship to hours or effort spent on non-scalable, repetitive work. Scrum has what it takes to beam up the inhabitants of Mediocristan to Extremistan so they become at least ‘a’ player over there (here). In Extremistan success depends on the ‘production’ of ideas and the elaboration of the unpredicted singularity. Ignition to the potential power of adapting so fast that leading the game comes within reach to outnumber the rest of the population, being a (the?) giant.


° Extremistan: I am currently reading “The Black Swan” by Nassim Taleb. Reading through the first chapters I couldn’t help noticing that much of the described global circumstances are applicable to our world of software, technology and IT. And these circumstances are exactly the reasons why we promote non-predictive process control mechanisms via Scrum. It seems though that Taleb describes empiricism as the passive collection of data to ‘know’. In Scrum we emphasize the need to use those data actively to move quickly, learn, improve and adapt upon short cycles to quickly detect and respond to the unforeseen. I can’t exclude misunderstanding it as as I haven’t read it completely. I just couldn’t resist using the similarities as I detect them at this point in time.

°° Increments: Thinking about the real land of Extremistan makes me wonder whether we should not even be more stringent when applying Scrum. While we currently say an increment is not expected to be fully functional (‘useful’), but must be fully operational (‘useable’), it seems we might need to consider making every increment also fully functional as we are moving further and further into Extremistan.

Related Posts


Agile and architecture – lessons from the trenches

Ben Kooistra
Date icon April 28, 2020

Scaling agile teams is a necessity to stay agile and keeping up business value. The agile...


Architecting the ecosystem: Five challenges for 2020 and beyond

Date icon April 8, 2020

Being agile, both in business and technology, is rapidly becoming the standard.


Capgemini’s Technovision 2020

Gunnar Menzel
Date icon March 13, 2020

This is what I show people when they ask about the future of tech