Press "Enter" to skip to content

Now that we’ve talked about the various visual management boards we’re using to handle releasing, I wish we’d focus about our daily stand-up meetings. Indeed this meeting also played a major role on our path to continuous delivery!

From 1 release per quarter to 2+ releases per week

How we used visual management and gamification for our releasing process

Boosting the release pace

Obviously with even more visual management!

We have formalized how our daily stand-up are unfolding in what we call a daily stand-up routine. Because there are so much things you can play with about the daily stand-up! I got this idea, along with a lot of other ideas, from Jimmy Janlén and his wonderful book about visual management, 96 Visualization Examples.

Lecture : “96 Visualization Examples” par Jimmy Janlén

Un petit livret plein de fantastiques conseils sur le management visuel d’une équipe Scrum ou Kanban !

Here is an example of the typical daily stand-up routine of our teams:

Typical Daily Stand-up Routine in our teams

Two things are of special interest:

  • How people get turn to speak
  • Agreeing on a daily goal for the team

How people get turn to speak

We are not following the classic daily stand-up sequence of events, with everybody taking turns to speak and to answer to the famous three questions.

Instead of focusing on the people attending the daily stand-up, we rather focus on the board and on the post-its.

Instead of having people taking turns, the post-its are taking the turns. We walk through the team’s board.

Focus on priority

During the daily stand-up meeting, we walk through the team’s board by following the priorities given to the various post-its

The golden rule is to walk through the board by following the priorities:

  • From top to bottom: given that the lower on the board, the lower the priority of the User Story
  • From right to left: it’s always better to finish on-going technical tasks than to begin working on new technical tasks

What’s really interesting is that we are putting the releases on the team’s board. Moreover, we are putting the releases on top of the board, before the US of the sprint:

The releases planned for the sprint are added on smaller, top-most rows of the board and before the User Stories: pushing to prod is more important than writing new code.

Then, by following the board’s priorities, we discuss releases before we discuss the User Stories of the sprint.

Let me tell it one more time:

Getting some code out there in production is more important than writing new code. Until it is available in production, it doesn’t have any value.

Update the other boards about the releases

When discussing of the releases planned for the sprint, the team also updates the other boards about these releases:

  • We update the status of the release on the push to prod process board, by moving the release token. It is the perfect moment for the team to check what’s left to do and how things are going. And to not miss anything important!
  • When applicable, we also update the release planning board. When a release date changes, then the whole planning must be revised, and the other releases tentative dates must be updated. The new tentative dates must also be updated on the sprint boards of affected teams.
Push to prod process and release planning boards. The team updates those when discussing the releases on the team’s sprint board.

And only then, comes the User Stories

The team discusses of the User Stories of the sprint only when all the on-going releases have been taken care of.

But as always, by following the order of the priorities!

Benefits of this daily stand-up format

We can list the following benefits of walking through the board instead of having people take turn:

  • Nobody can ignore the board. The team has no way around taking ownership of the board, understanding how it works, making it better, living with it.
  • Something that Scrum teams typically encounter problems with, is to stick with the priorities on the board: do not start a low-priority US until the higher-priority US are done. To walk through the board by focusing on the priorities is a superb way to help the team succeed. If anyone is working on a lower-priority US, nobody will be able to ignore it and everyone will have the reflex to challenge it.
  • The sprint vision is strengthened; we are all here together to reach this common goal, which can be seen on this board.
  • If the Product Owner attends the stand-up, then he’ll walk out of the meeting with a very clear vision of what’s going on. Because the focus will be on the product backlog that he knows and understand, rather than on a story told in no particular order. The stand-up meeting tells the story of the sprint backlog rather than the story of the team members.
  • Nothing gets forgotten: we are literally walking through the board from top to bottom. If things are missing, there will be no argument on the fact that it mist be added to the board to share it with everybody in full transparency. The rules of the game are made clear and are enforced by themselves.

Shortcomings of this daily stand-up format

By following this format, you’re at risk of having strong personalities to take over the stand-up meeting, thus leaving no room to the other team members who then could feel wronged.

So it is very important to pay attention to the interactions between team members. Some way to circumvent the issue might be to name a daily stand-up meeting animator, and to make sure that a different team member takes up the animator responsibility at each daily stand-up meeting.

In my experience, we never had to use this kind of trick. The speaking time might not be fairly shared between all team members, but no-one has ever felt wronged or set aside.

The team’s daily goal

Once the board has been fully walked through, the team has to decide of today’s top priority and to make sure that everybody knows what he has to do.

This is another thing we took from 96 Visualization Examples: defining a daily goal, that is a goal for the day, a goal that can be achieved before the next daily stand-up meeting. This goal is chosen by the development team.

This daily goal is an extremely powerful way to keep the team focused and productive. Focus is still my favorite core value of Scrum.

This practice is especially important when using Scrum, because the team has a constant need to re-focus in order to deliver what truly matters, and to deliver only one thing at a time.

And when it’s all about pushing to prod a feature or a bugfix, it is precisely this daily goal which helps to keep focused on the true priorities. Which means doing everything possible to get the code into production even when that means doing a lot of boring and hellish work.

Sometimes in order to release something up until the last mile, the team must forget that there are other things out there to work on. That’s exactly the purpose of the daily goal. Focus.

Here are some examples of typical daily goal related to releases:

Thursday: finish non-regression of release

Friday: release ready for Monday

Monday: release!

Sample daily and sprint goals. Having these about releasing is a common view for us.

Bonus: story-tell the sprint in Sprint Review meeting

What happened during the sprint? Walking through the daily goals gives a nice, quick, complete view of the sprint.

Daily goals also provide a nice side-effect: you can read them once the sprint is finished, giving a nice and quick sum-up of the sprint. Story-telling the sprint that way is very powerful and efficient, because all the ups and downs of the team are in some way in these daily goals.

I have already talked about this in a previous article about how we do our Sprint Reviews.

Did you like this article?

Follow me to be notified of the other articles!

And don’t forget to click on the heart 💗 to support me, and to share the article: these like are what makes me putting my heart and soul into writing.

Thank you! 😄

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *