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,

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.

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.

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 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

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)

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.

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.

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.

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)

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.

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.

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

To summarise Scrum X

I’ve learned long time 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

Originally published at https://myao.blog on December 12, 2018.