The Retrospective is a critical part of succeeding with software projects. I have seen many teams ignore this and as a result be less effective than they could have been. Other teams that do retrospectives just use it as an opportunity to say what went well, what didn’t go so well and what could be done better next time without actually doing anything to improve their process.
In the LeSS framework, you will undertake two retrospectives. The first will be at the team level where individual teams inspect and adapt their ways of working and processes, and the second will be at the product level where all teams (or suitable representatives from all teams) gather to inspect and adapt the whole system.
“What’s the system? Everyone and everything from concept to cash, and all its dynamics in time and space. People, organizational design, physical and technical environments, and more are part of the system—and all related and interacting.”
Larman C., Vodde B., (2016:320)
LeSS is very keen to stress that the overall retrospective is not meant to be simply an amalgamation of outputs from the team-level retrospectives. It is rather a reflective look at the how the whole system works. To do that, you must employ system thinking.
Participants in the overall retrospective will discuss the system and its dynamics as a whole and use system modelling to describe those conversations in a model of the system on a board.
To begin with the as-is system should be modelled so that there is discovery of how it is perceived and actualised throughout the whole product team. Changes that are suggested can then be added to the model to tease out a to-be model of the system.
This will require the overall retrospective participants to actively engage in searching themsleves and how they work as well as all external factors that impact on their work in order to properly diagram what the current and desired state of the system in which they work looks like.
This is a fruitful activity but its real benefit comes in the next step of the retrospective: experimentation.
True to Scrum, LeSS provides that reflecting upon and modelling the current and desired states of the system, although beneficial, is not an end in itself. Improvement experiments must be taken from this modelling exercise and implemented in the following sprints to truly realise the full benefit. All the diagramming and modelling is of little use if it does not translate into behaviour and system change. So participants must take forward improvements into real life sprints and do so with an attitude of experimentation. This really gets to the heart of working with an empirical process and its commitment to transparency, inspection and adaptation.
References
Larman, Craig, and Bas Vodde. 2016. Large-Scale Scrum: More with LeSS. Boston, MA: Addison-Wesley Educational.