10' reading time
<version originale en français ici>
TL; DR
Sometimes, some actions seem good in the short term, but in reality mask serious dysfunctions. Working overtime in stressful situations is not a viable long-term remedy and should not be seen as a professional solution, but as a warning signal to be heard courageously.
CONTEXT
It's Thursday night, the night before the end of the Sprint.
It is planned by the Product Owner that the increment that will be inspected tomorrow will be released at the end of the Sprint Review. The last release was done several Sprints earlier.
The Scrum Master says, "The team stays until 9:00 p.m. the day before production, they are very committed and professional!"
Are you certain? Is this behavior really aligned with the sustainable pace advocated by the Agile Manifesto and Scrum's values?
SYMPTOMS
On Thursday morning, the expected release is very uncertain, especially since a lot of work is still in progress.
However, no alerts or corrective actions were raised within the development team or with the Product Owner during the Sprint.
All this work represents a significant risk to the achievement of the Sprint Goal and the success of the Sprint.
In addition, the release procedures are complex and require the intervention of other operational teams that have the skills, tools or authorizations required to perform the installations on the production servers.
Finally, the company has high expectations for this new release. The last one took place several Sprints ago, and the team is feeling strong pressure related to the importance of this new release.
The risk and stakes are felt by all to be so high that failure is no longer an acceptable option for the organization.
The stress level is very high, the development team already knows that a hell of a day is coming.
The team is walking a tightrope, it no longer works with confidence, the work rhythm is unsustainable, it is physically and mentally exhausted, the risk of mistakes increases, motivation drops.
CAUSES
A great strength of Scrum is that it is a great risk management tool.
In a complex environment, an empirical approach such as Scrum is a perfectly appropriate tool: the amount of uncertainty is so great that we are more likely to succeed by probe, analysis and respond than by making and following a rigid plan. To achieve this, we need the 3 pillars of empiricism : Transparency, Inspection and Adaptation.
But empiricism works only if it works in a context where adaptation is possible, i.e. it is possible that the results may not be as expected and that decisions are taken to implement relevant adaptations.
Simply put: you have the right to make mistakes, because the risk of probable error is acceptable.
Unfortunately, Scrum is often implemented in organizations that have not fully integrated what the basic concepts of empiricism and complexity mean.
Scrum is implemented without a change in mindset or a change in behaviour:
one works "as usual", one tries at best to stick to the original delivery plan (meeting the original deadlines and scope), but using new jargon.
As a result, the Product Owner continues to schedule large, infrequent releases, which affects transparency and restricts inspection opportunities. The acceptable risk horizon for operating on an empirical basis is then largely exceeded. Risks are no longer "managed", one hopes, crosses one's fingers, burns candles and does everything possible to ensure that the plan is followed as planned.
Work is pushed to the team without the organization respecting the team's capacity and responsibility, or without the team having the courage to refuse to be pushed more work than it should be.
It is also common for members of the development team to work on too many Product Backlog items in parallel. The team is not focused on achieving the Sprint Goal, but on occupying "resources".
As a result, the implementation of the Product Backlog items starts early in the Sprint, but they are declared "finished" very late, and the integration of all the work is painfully completed by Thursday evening 9:00 p.m.!
The team is unable to reduce the risks because of this lack of focus to regularly and frequently finish the Product Backlog items, one by one, as the Sprint progresses. Possible causes include insufficient collaboration between team members.
This inadequacy may be accentuated by a lack of versatility (I" shaped profiles more than "T" shaped profiles because each has his or her own area of expertise and cannot or will not contribute to another area); a lack of skills or tools to achieve a Definition of Done allowing a simple production rollout; dependencies with other teams that prevent our team from being autonomous enough to implement and release increments alone and quickly.
All of this leaves risks hanging over the team's head like a sword of Damocles until the very end of the Sprint.
POSSIBLE REMEDIES
Gunther Verheyen helps us understand what commitment means in the context of Scrum :
"Commitment is about dedication and applies to the actions and the intensity of the effort. It is not about the final result, as this in itself is often uncertain and unpredictable for complex challenges in complex circumstances."
A Scrum team that claims to be both professional and committed must therefore limit the accumulation of risk by making the effort to focus and collaborate on doing the work differently.
The team must use empiricism to work within a tolerable risk perimeter, which means that on a daily basis, especially through Daily Scrum, the development team must inspect the work remaining to be done to achieve the Sprint Goal and act as soon as it considers, in a professional manner, that risks are increasing rather than decreasing.
For example, if the team realizes that the implementation of a Product Backlog item is more difficult than expected, the Sprint Backlog is impacted. This may lead the development team to now consider that the implementation of another Product Backlog item is highly compromised, unless quality is sacrificed, which is not an acceptable option for a professional Scrum team.
The Scrum team will then be able to act with openness, courage and professionalism and decide to adapt the Sprint Backlog while preserving the Sprint Goal.
This adaptation can be done by deciding to review the breakdown of the Product Backlog items by isolating the features that ensure the achievement of the Sprint Goal and by leaving aside for later Sprints less important features.
But the adaptation can also be done by organizing the work of the development team differently, by setting up pair-programming, mob programming, training or mentoring to facilitate the versatility, autonomy and focus of the team.
Thus, risk management is a daily concern and is no longer a subject that the Scrum team painfully remembers only the day before the end of the Sprint.
For its part, the Product Owner should seek to limit the size of deliveries as much as possible, ideally as soon as an increment is ready, several times per Sprint.
Of course, the Scrum Master is here to make all these problems transparent so that the team can implement the relevant adaptations.
CONCLUSION
A professional use of Scrum should result in the respect and implementation of all the values and principles of agility.
In particular, products with high added value must be delivered quickly and regularly, without ever decreasing quality goals, while respecting a work pace that is sustainable for everyone.
It is up to each individual to act as a responsible professional and to have the courage to transform their way of working in order to obtain all the benefits of Agility.
This can invite us to challenge our mental models if we want to obtain sustainable changes.
And you, what will you have the courage to do differently now?