A project is launched and quickly we arrive in the phase still today commonly called “Sprint 0”. What to do during this period? Here is the question I asked myself recently when starting a client project and to which I discovered a way to answer it. Back to basics, what is Sprint 0 for? It allows you to prepare everything necessary to start producing a potentially deliverable product increment (in the Scrum sense). I will share with you here my progress in this Sprint 0 through the various workshops that we will have decided to carry out. Let's start with the first!
Bringing a Sprint to life through the workshop format
This is the challenge I set myself.
Now where to start? The question I asked myself was:
What lessons would I like to share with the team?
1. Planning and Prioritization
Planning
The planning of the workshop was co-constructed with the team of coaches that I accompany.
We then agreed on the following program:
- What is the project environment? Who are the different actors, interlocutors? (20 mins)
The project environment corresponds to all the people who will be directly or indirectly linked to the project. It is important for the entire project team not only to be aware of these interfaces but above all to know the interlocutors with whom it will be required to interact. Moreover, by putting names on the roles, it gives a more human dimension to the project context: let's not forget that behind a role, a department hides a person with his constraints, his objectives and his own way of functioning.
Expected result: a project constellation map visually representing the interactions between the Scrum team and the outside.
- What are the expectations of the various parties? (Team / Coach) (25 mins)
This part is in my opinion essential to the good start of a coaching collaboration. Indeed, we sometimes forget that in a collaboration of this type, expectations / demands are two-way. In addition, to be able to best meet everyone's needs, it seemed healthy to be transparent from the start.
Expected result: a coaching contract with a symbolic signature of the different parties.
- What is the relevant project information to share? (15 mins)
Through this question, we not only wanted to be introduced to the subject covered by the project, but also to discover the underlying objectives and issues. Indeed, this would allow us, coaches, to be able to direct our support more adequately, and the whole team to be aware of this information.
Expected result: Sharing of objectives and challenges on Post-it.
- How do you organize the coaching? (15 mins)
How will we concretely organize the coaching? This is what we wanted to share with the Scrum team. Apart from the budget aspect which had been defined upstream - nevertheless important to share - this allowed us to share the content of the various workshops that could take place as well as to allow the team to project itself in a more concrete way. in the accompaniment.
Expected result: Sharing of topics related to support on Post-it.
- What metrics will we use? (15 mins)
The elements of measurement allow us to follow the evolution, the progress of the team according to the criteria studied. They are necessary in order to be able to establish a baseline, and for the team to have elements of comparison for self-assessment. Indeed, these measurement elements should not be a monitoring tool but rather a tool allowing the team to improve continuously.
Expected result: First results of team indicators.
- Are there elements requiring clarification following the training? (20 mins)
Following the training and after a few nights of sleep, certain topics may have emerged. Depending on the need, we may take a moment to answer any questions.
Prioritization
I then reminded that we only had 2 hours of workshop, which required knowing what to cut back on in the event that we were unable to deal with everything. Indeed, if we add the estimated timing, we are at 1h50 out of 2h which corresponds to a filling of 92 %. I felt that could be a good source of learning too! 😉
By refocusing on the objective of this first workshop (think Sprint objective! ;-)) – define the bases of the coaching relationship – we have agreed to make the last 2 subjects optional for the following reasons:
- What metrics will we use?
Even if it can be interesting to quantitatively define measurement elements, it did not seem essential to define them from this first workshop. We could very well do it just before starting the Sprint or during a workshop centered on the teams to allow them to have a starting point to refer to to measure their progress.
- Are there elements requiring clarification following the training?
For my part, as I said above, the training is not enough and the support on the ground is necessary for the assimilation and learning of the team. Moreover, we could debate for hours on the theoretical virtues of such and such a practice but without confronting them with the reality on the ground, our exchanges risked lacking values compared to other subjects.
2. Visual Management
As agilists, we often have that reputation of interior decorators with Post-its. It was then important for me to show the interest of physical visual management (even minimalist) and its impact on team dynamics. Indeed, not only does it allow the team to know at any time where the project is - we sometimes speak of collective consciousness – but it also helps the team to collaborate better.
Task board and work item
Thus, I thought of making a simple generic task board – To do, In Progress, Done – on which we would indicate the progress of our various workshops as we go along.
I was saying that we would move our workshops forward as we went, so it was important to do it right.
To make things clearly visible, we opted for a format of one A4 sheet per workshop, on which we indicated the following information:
- Title of the workshop
- Estimated time
- Expected result
We can thus easily make the correlation with:
- Title of work item / story
- Estimated effort
- Acceptance criterion
Progress Tracking
To go to the end of the experience, I thought it would be interesting to follow the progress of the workshop as it goes along. I then established a burndown chart of the workshop with the time on the abscissa and the time on the ordinate (considered as an estimated effort).
Intro to the workshop
After preparing the room with the initial backlog and the empty burndown chart, I present the workshop agenda to the participants.
I tell them that the animation will be mainly done by the other coaches present in the room, that I will intervene punctually if necessary but that my role today will be above all to update the elements around them that we will talk about. at the end.
Team Constellation
The construction of the constellation map seems quite intuitive. After constructing the central circle symbolizing the team, we invited them to add all the interfaces (department, trades, title, name of contact person) of which they were aware. This gives rise to interesting exchanges and even if for some it only gave very few new elements, it allowed everyone to have a clearer idea of the project environment.
Sharing expectations
We have decided to orient this part according to 3 themes:
- Everyone's expectations of the Agile transformation experience, what everyone wanted to achieve.
- The expectations of the team with regard to coaching and coaches.
- Coaches' expectations of the team.
Agile Transformation Expectations
In this first part, the project leader spoke, having already thought about the question with a few people. We then observe that most Post-its indicate expectations related to project performance: more efficiency, better team management, better execution control, better task monitoring…
One of the coaches then asked the following question:
Could this experience also bring something to you personally?
I found this question relevant because agility is not just about improving performance but also allows everyone to develop in an environment conducive to personal – and therefore professional – fulfillment. Post-it notes then appeared stating: better atmosphere, less stress, more transparency…
The expectations of the team / coaching
Once again, the project leader took control of the subject.
We then discover Post-its indicating: validates backlog entries, optimizes visual management, helps with external relations, advises, guides, etc.
They were then asked the following question:
How will you know that the coaching was successful?
One of the first responses was:
If the project is a success!
It was then that a discussion started on the posture of coach/consultant to put things flat. Indeed, we explained that we do not necessarily have the technical knowledge to validate the content of their backlog or their technical solutions, on the contrary, the team is much more specialized than us on this subject. Our goal as a coach is to help the team improve continuously by providing a safe environment conducive to learning. To do this, we will sometimes change hats (coach, consultant, trainer) to best help them achieve their objective, but we will not achieve it for them – which was well understood by the whole team.
I then asked the same question in another form:
Following this discussion, how will you be able to know that the coaching has been useful to you?
To which the team replied:
When the team has become more autonomous.
This exchange is important to have at the very beginning of the project so that we do not have to come back to it later, causing loss of time and above all loss of value. The nuance is essential in my opinion because the coach has an obligation of means and not of results.
After having discussed the expectations of the team, the coaches made a commitment to it in this sense by the terms: availability and resources.
I wanted to make sure at this time that the 2 terms used were meaningful enough for the team. Indeed, I reminded the team that like all “Agile documentation,” these terms should be self-explanatory enough to allow them to remember the discussion that ensued.
The expectations of the coaches / the team
On the side of the coaching team, we also took a moment to think about the question. I suggested that they formulate their expectations in the form of values described by behaviors. Indeed, it allows people to see more concretely what the value represents for coaches and allows coaches to explain the reason for this request.
These are the ones that have been defined:
- Transparency
- Behaviour: Saying things when things are going badly, and even when they are going well.
- Reason: This allows coaches to support the team in a more relevant way, with the right thing, at the right time.
- Opening
- Behaviors: Willing to try new things, ready to break.
- Reason: This allows coaches to help the team learn, experiment, and find the strategy that works best for them.
- Patience
- Behaviour: Give time to time, do not act too quickly and risk hurting yourself.
- Reason: Transformation takes time and results will not be immediate.
Note: We could have asked the team to do the same in terms of format and restrict them to 3-5 values to get them used to prioritizing and making choices.
The symbolic signature
To close this part, I invited all the members of the team as well as the coaches to come and symbolically sign this coaching contract that we had made together.
Interesting case : despite the symbolic side (which may seem a bit cliché), some people took this signature very seriously and initially refused to sign. Indeed, they did not want to sign something of which they did not know the implications, which seemed completely normal to me. I then recalled that the commitment requested was simply based on behavior which, at first glance, would not put anyone in danger – this made it possible to obtain a signature even if without much conviction. This type of situation is interesting because it makes it possible to identify the people who may need more support at the start of the project, to reassure them and help them make sense of the process.
Project Information
In this part, the project leader shared the objectives and challenges associated with the project allowing everyone (team and coaches) to have a collective awareness of the challenge ahead.
Organization Coaching
First, we shared with the project team the information concerning the planned budgeting of coaching support, attendance time, frequency, etc.
Then, we discussed the topics we wanted to cover during Sprint 0 before we could really launch the first development sprints.
This allowed everyone to have an idea of the extent of the preparation work to be done before starting (patience plays its role here despite the still tight schedules).
Debriefing
The end of the Organization Coaching part arrived around 1h45 on 2 hours of workshop planned. I then proposed to the coaches to stop here content level and to debrief quietly. Indeed, this was the time to share the notions related to the format of the workshop.
The task board
Small focus on the workshop task board. We successfully completed 4 items, verified by their expected outcome which I displayed in the room as proof each time.
I then explain that this type of result is common in overfilled sprints – I remind you that we have a filling rate of 92 % – and that in general it is recommended to fill the sprint between 60 and 80 % of its maximum capacity so as to be able to manage the unforeseen events occurring during the sprint. In our case, we accomplished about 63 TP3T of sprint content, which would fit well within that range taking into account the disruptions that occurred during the workshop. I describe them below by going to the Burndown chart.
Progress monitoring
Throughout the workshop, I updated the workshop progress burndown as I went.
I then asked the participants what they could tell about the progress of the workshop by looking at this graph: the result was clear and telling, the workshop drifted little by little because of disturbances. These last that I noted in references just below to remind them: an unplanned round table, an unplanned return to the basics of Scrum, movements of people who generated loss of time, unrelated debates about the workshop...
With this burndown, we can even see the actual duration of each part of the workshop, those that took longer than expected, for what reasons... I specify then that it is a way of sharing the progress of a sprint / of an external project without having to disturb the team in its work. In addition, it also allows for a longer term forecast: I then draw the dashed red line showing when we would hope to finish if our speed had remained constant at the end.
Thus, through small one-off updates, one can obtain a very precise vision of the status of the project.
Conclusion
The format was appreciated by the participants and made it possible to launch very interesting discussions around the implementation of Scrum. Posting all the results on the walls helped to keep in mind what we had done during the workshop – it also helped to get the information across to latecomers more quickly.
I don't think I would do it every time because it requires a lot of preparation, however for a first workshop it is worth it especially to do a reminder after a training.
The next workshop will focus on team alignment which I will describe in a future article! 😉
