Cet article est également disponible en français
Why do we encourage problems to be discussed once an iteration?
Imagine you could transmit your experience to all your teammates. Your failures, your success, your discovery; in an instant and you could have a constructive discussion in the process. Wouldn’t it be amazing? Let’s discover the D-Rex, then.
Definition
Why “D-Rex”? In French, we use the term “Retour d’Experience” (Experience Feedback) to name the event to share one’s knowledge, and it’s usually shorten to “Rex”.
A Daily-Rex is a feedback event, no longer than 10 minutes to be done “as soon as necessary and everyone is available, but no later than the end of the current day”.
The D-Rex, an event that fits in Scrum
In Scrum, the sprint is a learning time-box for the team, to experiment and improve itself, as much as product.
Uh … more events, more meetings! No, it’s basic communication.
Because we work on complex problems in a complex world, the team learn continuously and get to be confronted to new problems more complex than anticipated.
In front of such problem, the developer will search, study and ‒usually‒ find solutions (if needed, he or she will be helped by other team members). The developer wins some experience on two levels:
- The experience of the problem
- The experience of the solution
As a Scrum Master, you should be aware to this experience gain and the team should be take some time after the problem has been solved for the D-Rex: “as soon as necessary and everyone is available, but no later than the end of the current day”.
It is important to run the D-Rex as soon as possible to limit the contagion effect and to benefit that the even is fresh in the developer’s mind.
At worst, the D-Rex will start 10 minutes before the end of the day and will look like this (it can be important, as in other events, to display how the event will occur):
- The one who initiate the D-Rex starts by describing the problem he or she met and its impact on the product or process before it has been fixed.
- He or she describe quickly the leads he followed without success to arrive at the solution.
- An important step then is to describe known consequences of the fix and its impact on the product and the work of other team members or other teams.
- Attendees can ask questions then and challenge the solution. We prefer to schedule a dedicated point to argue and dig into other solutions later.
- If you estimate backlog items (like with story points per example) it’s a good moment now to review the estimation to reflect this discovery within team’s velocity
10 minutes is not long enough
The 10 minutes time-box of the D-Rex is necessary to make it happen within the day with limited impact on team members’ agendas/
If the discovery asks for more explanations or introspections, we like to keep the short-time of 10 minutes within the day, and to propose to go deeper on the subject at another time .
Who should attend?
The person who initiate the D-Rex, of course, and at least the development team.
The Product Owner must be involved if the discovery on other sprint backlog’s items or on product backlog’s items.
Other teams (or their representatives) can be invited if the problem or the solution have an impact of their part.
Why can’t we use Scrum events?
Let’s have a look:
The retrospective, which is a dedicated event to inspect the team, is a very good time to share one’s experience on problem solving, but it should not be the only one!
Often, teams wait for the end of the sprint to speak about problems. It can have a limited impact if you do one week sprint, but it can be disastrous for longer sprints.
Daily Scrum is not the time to explain problems, but to show them, in particular if they can impact others or the sprint goal, but it is not the time to go deeper during the Daily Scrum.
D-Rex does not replace the daily scrum but come is addition when necessary.
What about you?
What do you think of this event? Did you already use something like that to address sharing knowledge quickly and soon?