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.
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.
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.
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.
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
||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.|
|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 (…)|
|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.|
||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 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 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 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.|
||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.|
||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.|
||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:
- 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