AO Projects with Scrum X

Speaking about projects in an agile context is always funny. In January, I had a conversation with my friends Mike and Michael in Vienna, and when addressed the point of project management, they began getting very emotional. In their positions as agile trainers, there is no project management in Agile. My perspective was precisely on the opposite.

I love these guys, and we often have such bold conversations. On the other hand, they are very experienced agile coaches and trainers, and I asked myself what the message they share with their customers is? Is this message not over confusing?

As a coach, I have been analyzing the words, the gestures and the emotions to understand the underlying problems. I discover that project management wasn’t the issue; it was the role of the project manager. The Agile way of solving problems is that role is speed over the project team and not a single person.

At project management creation, the role of the project manager was supposed to be considered as an entrepreneur. An entrepreneur leading a project end-to-end, with a single team, until the budget is consumed, or time is over, or when the scope has been reached. And, that’s ok.

Since the last decade, the project manager position has become “structured” in the way that the role is to ensure compliance regarding expectations and contracts. When teaching a project management class, I asked the students why they want to be a project manager. They all answered that this is the entry door to management or other leading roles in the structure. The answer was never to deliver value for both customers or enterprise.

In other countries like France as an example, project management is a task for an engineer. It means you are en engineer and besides you are managing a project. It is a bit different in the Anglo-Saxon culture where project management is a specific job.

Project Management is the entry to shift from “structure” to “awaken”. You have to understand that clearly:

• A project is created to solve a problem
• A project has a sponsor, a client and a team
• A project has at least a budget even if the scope might evolve
• A project has a dead-end
• A project is small. When it becomes more significant, it is called a program.
• Demand is not a project even if you are using the project budget

In AO, project management is helping to limit the work-in-progress by helping to triage the activities like:

• What is the purpose of the project?
• Who is the customer or the benchmark for that project?
• What are the expected outcomes of that project?
• Who is sponsoring us from the side of the management?
• What is the budget for the project?

Maybe these questions sound evident for most of you. But, reality shows us that most of the project does not have a business case and not even an intention.

In my job as an agile coach, I wanted to know how people are working and how are their projects look alike. Projects are “fruits” for the organization, right.

Some project activities are time confusing like Project Scope. In digital transformation, people replaced the scope by customer journey. Putting the customer right in is smart. But you should pursue that intention and not handing over to a third party or your IT department in Bangalore to ensure that the developers know what needs to be done. Here you had a vocabulary shift only: the six months scope development shifted to six months of customer journey design. That’s a bit wrong.

From an agile systems dynamics perspective, scope or customer journey was a project on its own. Once ready for development, the one who completed the project thought that everything was “obvious” and the developers only have to proceed in a tight timeframe. In reality, there was no real alignment. The relationship was “complicated”, and the developers lost a lot of time in “chaos”. The responsibility moved from the one to the others. Because the developers were mostly offshore “cheap” “resources” it took a couple of months before the first alerts of weakness bubbled up.

Managing projects in AO

Before having a project, we have to have an idea about what problem we try to solve and for whom?

The idea usually comes from management, an existing customer, sales, or team members. Let’s use an example to avoid being too dogmatic.

Esther is a Product Owner working on a digital project. She always works with Peter and the same team of five developers. One day, Esther got a call from Francis, the business expert, he wants to discuss a new project with her.

A meeting is scheduled, and Peter exposes what the project opportunity is. After the presentation, Ether asked Peter some simple questions:

• Why is this project important?
• Who is the customer?
• Is there any timeframe in his mind?
• What is the budget?

These questions weren’t easy to answer, and Peter discovered that the customer wasn’t clearly defined. It was for the invoicing department.

Esther asked if Peter can arrange a meeting with the Invoicing Department. The first meeting was scheduled for the next Thursday with Jen, the head of the department.

While meeting with Jen, Esther explained Peter´s idea of a project, and she asked her if the idea might be helpful for the department. In a second time, she also asked how the department is proceeding with invoicing. Jen called Arthur, the process expert, to join the meeting.

Arthur explained how the invoicing process is performed and gave some pain points in the current process.

Esther asked Jen, who is handling the invoices. There is the Invoicing department with four accountants: Jan, Mike, Urban, Stephanie and Doris.

After the conversation, the idea sounds to be interesting for the department. The ideation workshop with the department and the project team is scheduled for the next week.

During the project quick-of meeting, the agenda was to define together (the whole project system) what the vision might be. The project system is composed of:

• The project team (aka scrum team)
• Product Owner: Esther
• Scrum Master: Peter
• The developers: Meriem, Amit, Rachel, Elie and Jan
• The sponsor: Jen
• The customer: Arthur
• The users: Jan, Mike, Urban, Stephanie and Doris
• The floater: Francis

During the meeting, Esther explained what the idea is. Arthur improved the concept by formulating what he is expecting. From that point, Esther asks each “user” to express how they might use the solution, what other problems could be solved. This user requirement form is called a user story.

These stories are sorted together in a bigger story with chapters called themes. The collection of themes and the stories are composing the customer journey.

Once the workshop is over, the project team is gathering together to discuss their current understanding. Rachel explained that during her conversation with Stephanie and Doris, she understood that other topics sound more vital for them and same for Amit and Jan. At the end of the debriefing, the team discovered that the main idea has four different options to address the problem. One option is what Arthur wants, and three others were coming while listening to the users and another option emerging from Meriem who has been inspired by the audience.

Peter plans feedback with all the stakeholder in a week to discuss on some prototypes. During the first week, the project team is working on different options to show and tell at the meeting.

At the review meeting, both customer and users were surprised by the ideas and had a lot of new stuff to add because they had plenty of time to think about the project. The discussion was very constructive, and all decided to concentrate the effort on three of the options until the next meeting.

One week later, those three options are illustrating both features and working process. Again the discussion was very passionated with all the attendees. In the end, one option only has been selected, and the development team was ready to start the development phase. The initial customer journey or roadmap has been reviewed together (project system) with the ideal cadence of one theme per month. And so on until budget is consumed, or full-scope achieved or time done.

What’s the difference between traditional project management?

The early phase of scope management, customer journey or blueprint has been reduced to its minimal set up: the team meets the customer, and the product owner tries to translate customer´s idea into a vision. The development team is already involved since the beginning to understand the matter and the purpose of the project. There is no handover to another group.

The model below was called Agile Digital Enterprise Model. That model was used to start large Digital Programs. In such programs, you can have up to two hundred people involved, and the cadence and the development process remains the same. It uses a mix of Service Design, Lean StartUp and Rapid Prototyping approach.

This pattern is used in small projects like in the example before. The reason for this design is to consider a project like a short time investment and not a long run.

In the digital world, such an approach is considered a swarm. Swarm is very hype nowadays and refers to parallel running initiatives. But in Agile, we avoid multitasking, so Swarms are like “spikes” in software development, a short time-bounded initiative to understand a problem to find a fix.

According to the AO approach, projects have to be sense-making and customer-oriented. In the framework, all projects will become swarms by default. This approach will help to identify how much swarms teams can deliver in a quarter in a portfolio perspective. That topic will be addressed later in that book.

Scrum X, a light improvement of scrum for complexity work

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 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 correctly. It avoids overloading it with unnecessary functions: 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” relationship between team members (Scrum Team).

Summarising basic Complex Adaptive System theory with Cynefin,

The Cynefin framework (D.Snowden) 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?

The approach is using the dynamic of flocking behaviour.

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 more significant 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 only 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 (quarterly 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 decide 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 exciting opportunities.

At this time, the team focuses on the selection. And dive more in-depth on each option according to its level of feasibility.

Decide

The results of the last iteration lead to a 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 often happens that a story stays forever like recurring activities. It has to be actively 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 three elements to ensure a win-win outcome.

Visualise progress

In the figure above, I use “burndown charts” to visualise the progress of the activity. The three 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 while using “Proto Kanban” ( the purest form of Kanban) as an excuse. Unfortunately, the real working model is “Taylor factory model”. Assuming that the activities are “simple”, but unfortunately a more in-depth organisational analysis will highlight that in 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 the rhythm they expect is.

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

To summarise Scrum X

Scrum X main principle

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

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

Originally published at https://myao.blog on October 21, 2019.