Scrum X, scrum from an agile organisational perspective

I’ve been a passionate Scrum practitioner since over a decade and I really value it.

Scrum is the most used agile framework and it is well documented in the Scrum Guide.

To avoid confusion with “Scrum”, “Scrum X” is an evolution of the framework to support agile behaviour in a complex adaptive system that supports any kind of activities from accounting to a whole organisation.

My thesis is that Scrum provides a minimal organisational set and roles to help your system to run properly by overloading it with unecessary roles: someone in charge with the “what to do”, the Product Owner, someone in charge of the change and the coordination, the Scrum Master, and the Development Team in charge to create and deliver the expected “value”.

That agile system is a complex adaptive one, that allows individuals to act and develop their full potential. In that order, Product Owner and Scrum Master are considered as a genuine team member without any authority or subordination relation ensuring “eye-level” relation between team members (Scrum Team).

Summarising basic Complex Adaptive System theory with Cynefin,

categorisation model

Traditional categorisation models are using a 2×2 matrix also known as a quadrant, But as explained in the figure, the provided information is not sufficient to analyse a situation.

Dave Snowden (Author of Cynefin) explains that for categorisation models framework precedes data and in sensemaking models, data precedes Framework. As explained in a previous post, an agile system is a sensemaking system.

From the 3 basic systems like Complex System, Ordered System and Chaotic System, the Cynefin framework separated Ordered Systems into Complicated and Obvious (simple) systems and added “Disorder” to highlight the particularity of Chaotic system.

the Cynefin framework

This framework changed my understanding of agile by naming it a system.

This model can highlight how your company works but also can help to initiate a new dynamic that I will explain now.

interaction of agents in the Cynefin model

The model explains that in an Obvious system (down right), the information is obvious so each agent in that system doesn´t need to understand to execute a demand. Ex. “Fire!, everyone out…” 

Chaos is different. Each agent in that system doesn’t interact with the other parts. Ex. Researchers, Experts who don´t share their discoveries or their knowledge.

Complex is interesting. The system is made so that each agent interact with each other in a team co-creative manner.

Complicated is an ordered system where each agent share its information and validates a position or an outcome.

What is Scrum X?

Scrum X is a learning process moving from “Obvious” to “Chaos” to “Complex” to “Complicated” to finally completing the loop at “Obvious” again before starting another loop (cycle, iteration, sprint).

Scrum X dynamics

Scrum X has a couple of alignment and separation events called ceremonies. Like in traditional Scrum, these are similar and small changes are added to allow a better interaction:

  • Daily scrum: like in Scrum + 30 min if the team is bigger than 7, all stakeholders are invited, is lead by the development team, the focus is given to daily planning
  • Sprint Planning: similar to genuine Scrum
  • Sprint Review: like in Scrum + Demo of work completed + Collective User Acceptance Testing + Status of working condition (level of distraction, velocity, capacity, impediments)
  • Retrospective: like in Scrum + enforced focus on self-organisation and adaption of the working environment.

Scrum Roles are tightly enhanced: 

  • One Product Owner per team. The PO is fully empowered to work directly with the customer and the users. He doesn´t decompose requirements coming from another team. He doesn´t proceed to the technical decomposition of activities and he doesn´t assign work to developers.
  • One Scrum Master per team. The Scrum Master protects and feeds the Scrum Team and act as team coach and facilitator. He is responsible for the change and the evolution of the organisation (team and its interactions in crowd or structure.)
  • Developers are team members and are auto-committing to the common goal.
  • Floaters are non-fulltime team member helping and supporting the team in specific activities if necessary or simply someone who doesn´t want to work in a team or in the agile way.

Basic principles

principle 1

Setting the stage means to define the boundaries of the safe-to-fail container:

  • the company or the organisation
  • the crowd (entity or value creation unit)
  • the team
  • the sprint/iteration/feedback loop
  • the roadmap (quaterly based common goal)
everything is not an option

The team is working on a couple of ideas during a sprint. The outcome of it is a couple of options giving the possibility to take a decision on what worth to reach the expected goal.

Everything cannot be an option, in that order, decision-makers have to accept to left the less interesting options.

At this time, the team focuses on the selection and dive deeper on each option according their level of feasibility. 

decide

The results of the last iteration lead to the single valid option or minimal valuable solution (MVS).

I decomposed the principle 2 and 3 in separate sprints for clarity. With my teams, usually both steps are performed during a single sprint.

never ending stories

It happens often that a story stays forever like recurring activities as for example. This has to be strongly avoided. Always try to close a topic before starting a new one.

human interactions

As explained before, it´s all about human relations in a social network called system

  • interaction in a “complex” manner
  • safe-to-fail container fitted to enforce interactions
  • people in the container can pull information but the container doesn´t allow distractions from “pushed” information; container is protected the time of the iteration (sprint or roadmap)
balance is key

Agile work expects the engagement of all parts in the activity ex. the customer, the team and the management by example. Each of these parts has a specific agenda that need to be understood and agreed. But the purpose of agile activities is to deal with the balance of each 3 parts to ensure a win-win outcome.

visualise progress

In the figure above, I use “burndown charts” to visualise the progress of the activity. The 3 pictures show reals cases from my teams. 

Burndown charts are interesting because they enforce the conversation when your progress is deviating from the expected goal (orange line). When a deviation occurs, all stakeholders can decide what to do.

Burnups are more for research and development teams. The team has the time and the freedom to create the solution until the customer says it´s enough.

Unfortunately, a lot of agile teams in “structure phase” are just adding daily more activities so that they never make their accomplishment visible. Here the hidden purpose is to keep people busy without taking the customer into account.

Support teams are sometimes working like that whilst using “Proto Kanban” (the simplest form of Kanban) as an excuse. In fact, unfortunately, the real working model is “Taylor factory model” making the assumption that the activities are “simple” but unfortunately a deeper organisational analysis will highlight that in the reality this is a “chaotic” working model with low impact and low engagement.

set the pace

 Timeboxes are more than only containers, these are also the pace, the beat of your team.

In the figure, you can see a rule that I use when asking the team and the stakeholders what is the rhythm they expect.

In another post, I will explain the principle of the crowds. Crowds are larger organisations containing a collection of teams sharing the same large goal- At SAP, Corporate Finance was one crowd containing teams and other crowds like R2R, Core Finance, Controlling, etc… Crowds are using exactly the same logic but with a longer pace, usually 3 months. 3 Months is large enough to have sharp goals and avoid ever changing strategies that confuse the team. Over 3 months, the risk of changing requirements is too huge to federate all the talents.

Scrum vs Scrum X


Scrum Guide Scrum X
Purpose Scrum is a framework for developing, delivering, and sustaining complex products.  Scrum X is a minimal framework to organize people in Complex Systems.
Definition of Scrum
No changes
Uses of Scrum (…) Research and identify viable markets, technologies, and product capabilities; Develop products and enhancements; Release products and enhancements, as frequently as many times per day; Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and, Sustain and renew products. (…) (…) can be used in any kind of work as minimal organizational model (…)
Scrum Theory
No changes
Transparency Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen. Transparency allows the agents in the complex system to identify emerging patterns and take the right decisions based on those findings. The organizational scaffolding can be understood as standard ensuring an effective alignment with those outsides of that system. There are no observers in Scrum X. Observers might influence the behaviour in a complex system misleading the expected truth of transparency.
Inspection & Adaptation
Inspection, Negotiation, Adaptation.
Scrum Values commitment, courage, focus, openness and respect commitment, accountability, openness and respect
The Product Owner The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. The Product Owner is the Scrum Team member in charge to maximise the impact of the value created by the development team to meet customers expectations. It is not the voice-of-the-customer or a relay from a tier in the structure, and it is the translator of the customer´s vision. There is no Proxy Product Owner in Scrum X, and it is always a single person working for an only team. There is no Product Owner for multiple teams or Feature teams.
The Development Team
The development team is “stable”. It means that “all the work” is shared across all team members. A team member is fully dedicated to its team. Accountability is divided across the team and not on individuals.
Development Team Size
If the team size is more significant than nine, the scrum team has been split into a second-team with another Scrum Master and another Product Owner. Bigger doesn’t mean better.
The Scrum Master
The Scrum Master is one who masters scrum. It ensures that the agile dynamics work in the system called “team”. It is not an authority, not an assistant, no the voice of the management. It is the voice of the system called the Scrum Team. The ScrumMaster is not serving the Product Owner, the Development Team or the Organization. It is part of it and ensures that the relations between all stakeholders are running at its best.
Scrum Events
Are under Scrum Masters responsibility. It is in charge of the beat of the Scrum team. Scrum events are the celebrations that bind the people in that system called team. Besides the inspect-and-adapt, these events are defining the boundaries of the team’s swarm and are great opportunities for alignment.
The Sprint
The ScrumMaster as “process owner” is the only person able to stop or cancel a sprint. Even if the expected business value isn’t reached, there is almost a lot to learn about teams or project behaviour. The development team doesn’t need to wait until the end of the sprint to deliver done items.
Sprint Planning
Sprint planning is the alignment of the team with stakeholders requirements and vision. Planning means that each team member has to express its interpretation of those expectations. The planning part is a collaborative design of the best know plan to reach the customer´s vision. The plan doesn’t need to be precise, and it has to allow the emergence of best solutions. Values like business value or story points are just helpful to analyse the complexity of work and the expectations. Planning is a negotiation between what to do and how to do. The best plan is balanced in a win-win manner and fosters conversation between the agents in a system.
Sprint Goal
Sprint Goal has been unique and evident for all the stakeholders. Multiple goals don’t support the complex dynamic and pull the system in a chaotic state.
Daily Scrum
It is the daily alignment of the system (the scrum team). There is no restriction on who is attending. The “daily” is the ceremony where emerging changes are coming up from the team. Emphasises is given to the conversation into the system. The genuine three questions are guidance but not necessary. Done items and impediments are collected. Re-planning of the blockers are reviewed for problem-solving.
Sprint Review
The sprint review is an acceptance testing event where users and customers are testing completed work and leave feedback to the team. It is not a show and tell session, and not a status report to the Product Owner.
Sprint Retrospective
Continuous improvement of team works is vital. It is also the momentum where the team is reconfiguring its organizational model.
Scrum Artifacts Product Backlog It is now Team Backlog. Most of the scrum teams are not able to respect the single product approach. Team Backlog is more respectful with teams reality. The Product Backlog is only functional. There is no Technical Product Backlog, even if your product is technical. It contains all the necessary elements to support the customer´s journey.

To summarise Scrum X

Scrum X main principle

 I’ve learned longtime ago from Christoph Mathis that an “agile bag” is composed by:

  • delivering at least once a month (delivering enforces the conversation)
  • asking the team (most of the time, the answer is already available in the team)
  • treating people like adults (eye level relationship remove the fear and enforces trust)
  • and inspection and adaptation (every meeting is an opportunity for feedback and improvement

Posted in: tools

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.