Why do we plan at all?
Just because Scrum or SAFe says so?
Of course, Planning must have a purpose, right?
Isn’t it enough to simply set an order of what needs to be implemented?
If it were a single Scrum team in the middle of nowhere, without any dependencies to other teams, there could be the following reasons for planning:
- If several developers work on a product in parallel, they would undoubtedly come to blows without any coordination about who does what. So coordination makes sense, if not necessary. It is not uncommon for several developers to work on one and the same customer requirement.
- Stakeholders are curious. They want to know what they can expect in the near future.
When a really big product or solution is to be developed and multiple teams are working on it as part of an Agile Release Train (SAFe), it is inevitable that one team will only be able to continue working if it receives input from another team. We’re talking about so-called dependencies here, and it’s probably clear to everyone that without a little planning, it’s no longer possible. Also see: SAFe: Inner und Outer Dependencies.
And of course, also in the larger SAFe framework, stakeholders want to know when they can expect their requirements to be implemented. Here, the larger framework / period of an entire Program Increment (PI) is planned. Usually a period of 8 – 12 weeks.
Note: Anyone who has ever done stakeholder management (correctly) knows how difficult it can be, because stakeholders are often not an easy people. It is necessary to be able to provide them with information, and halfway binding commitments are often a means of keeping important stakeholders in line. You need them, the stakeholders. Without stakeholders no project / no Agile release train.
All legitimate reasons for planning, right?
The Commitment
In pure Scrum, planning is done from Sprint to Sprint. Each Sprint starts with a Sprint Planning. In SAFe, planning is done in larger cycles. All development sprints of a program increase (PI) are planned within the framework of a PI planning. The plan, or the plans in the context of SAFe, represent the commitment to the product owner, product manager and the stakeholders.
What is a Commitment
A commitment in the sense of Scrum or SAFe is not a promise that you have signed in blood or that you lose your soul to the devil if you don’t keep. No, you don’t have to go to confession if it didn’t work out.
But a commitment in the sense of Scrum should represent the unconditional will to deliver what one has planned to implement in the context of Scrum or PI planning. The plan is the commitment to the product owner and the stakeholders.
What is the right mindset?
The Manifest für agile Softwareentwicklung states that the highest priority should be to satisfy customers through early and continuous delivery of valuable software. All stakeholders who are entitled to make requests are customers of the Scrum team, respectively of the Scrum teams of an Agile release train. Satisfying all customers, with their many requirements, is a challenge that the teams should face with drive and vigor.
Reliability …
… is a characteristic that customers / stakeholders expect from Scrum teams.
If requirements (objectives and user stories) are scheduled for implementation in the sprints of a program increment (PI), customers expect the delivery of high-quality increments that largely correspond to the original plan at the end of the program increment at the latest. If a few nice-to-have functionalities are missing, this is usually not a big deal. However, the MVP of what was promised according to Planning (= Commitment) should be delivered; and in good quality.
The right mindset of developers should therefore include trying to satisfy the customers/stakeholders to the best of one’s knowledge and belief. Knowing the expectations of the stakeholders, the right mindset can be summarized in one sentence.
In order to satisfy our stakeholders, we want to implement as many of their requirements as quickly as possible in good quality.
This does not mean that we should constantly work overtime to satisfy the excessive needs of our stakeholders, but it also does not mean that we should dawdle. Sprints should be planned in such a way that they represent a feasible challenge.
See also the German Blog: Nur ein wenig Mehrwert reicht nicht
Recommendation: Sprints should be planned with 80% Prio 1 requirements (= MVP-relevant) and 20% Prio 2 requirements (= not MVP-relevant). If everything MVP-relevant can be delivered in good quality at the end of a sprint / PI, the stakeholders should be satisfied.
Conclusion
The right mindset is crucial for the quality of a team. Unfortunately, the awareness for it is often missing.
If you need support in implementing the right mindset,
