Standup - What have you done for the team lately

The Standup, like all Scrum ceremonies, is about focus. It is so very easy to make this conversation into something other than it should be. In a well oiled Scrum team, the team will standup when it is time for Standup without any prompting from the Scrum Master. In these cases the whole teams understands that this conversation is needed for the team to continually be delivering the features of highest value. 

As you are probably aware there are 3 questions that all team members answer during the daily standup

1.       What did you do yesterday? (meaning since the last standup)

2.       What are you planning to do today (between now and tomorrow’s standup)

3.       Is there anything in your way (are there any impediments)

At times it is advisable to add in a 4th piece of information and that is if there is something mentally in your way outside of the team such as a sick child at home. This alerts the team to the fact that you may have a bit of a split focus. It also lets the team know up front that you have an urgent issue outside of the team that at some point during the day may need immediate attention. For example, I have let team members know when I have been in this situation, so that when I answered the phone in the middle of a conversation, wish I usually wont do, they understood that I was not trying to be rude. It also helped, because when I walked out of the team from for a couple of minutes and forgot my phone, team members came looking for me with the phone when it rang.

There are a few points that I think are worth keeping in mind as we have Standup

A.  When you tell the team what you did yesterday, the team wants to know what tasks on the scrum board you completed. What you did yesterday shouldn’t be a laundry list of activities, the team needs to know what tasks were completed that moves the story currently in progress closer to Done.

B.  What you are planning to do today is also a task, or list of tasks, on the scrum board. It may be a task that you are going to move into “In Progress” or one that you have moved into that state since yesterday’s standup. If there are multiple small tasks, what you are planning to do today can be a list of tasks.

C.  Since tasks should be no more than one days worth of work, preferably a half day or less, an impediment is anything that causes someone to say they are working on the same task at two consecutive standups. More succinctly, an impediment is anything that prevents a team member from moving at their optimal velocity. An impediment may not be a full stop, it may just be something that is slowing you down.

D.  Anything not related to the 3 questions should be “parked” until right after the standup, then involve the relevant people in that conversation. Those "parked" conversations may not involve the whole team, so don't force them to be part of them. Also "parking" those conversations helps keep Standup focused on what it needs to be focused on.

E.  Lastly, stand up during Standup, it will move the discussion along and keep it short and sweet as it is supposed to be.

I hope that will help you focus your Standups.

Stay Agile.

Comments

Post a Comment

Popular posts from this blog

The Five Dysfunctions and Tuckman's Stages

No, this is not a post about a new band, it is about understand Scrum team growth . In my  previous post I discussed The Five Dysfunctions of a Team by Patrick Lencioni and how the dysfunctions in that book apply not only to management teams as described in the book but to Scrum teams as well. In 1965 Bruce Tuckman proposed his model of team development. While you may not be familiar with Tuckman’s name, you have probably heard of the stages of his model, forming, storming, norming and performing. Forming - The team is coming together for the first time. Team members behave independently, they are on their best behavior and very focused on themselves. To move out of this stage, team members must be willing to risk the possibility of conflict Storming - The team members are learning each others strengths and weaknesses and learning to trust each other. Some of the teams disagreements are passionate, but also can tend to lean toward personal attacks as opposed to healthy confl
Read more

How many dysfunctions does your Scrum team exhibit?

Image
If you say your team does not exhibit any dysfunctions I have to ask you to revisit your thoughts again as that is so very highly unlikely. Most if not all teams exhibit some dysfunction some of the time, if not all of the time.  Merriam Webster defines dysfunction as  impaired or abnormal functioning or abnormal or unhealthy interpersonal behavior or interaction within a group I think both of those definitions work well with regards to a Scrum team. In Patrick Lencioni's book The Five Dysfunctions of a Team he tells a tale about the five dysfunctions that a team typically struggles with followed by a discussion of how to address them. As a scrum master it is well worth the time to read it. As far as I know the author was focusing on management teams when he wrote it, but without very much tweaking, all the same dysfunctions and corrective actions apply to a Scrum team as well.  The five dysfunctions are laid out in a pyramid. The reason for the pyramid is that
Read more

Feedback - Skills Relevant in the Torah and Today

There is a story in the Old Testament known as the Waters of Strife . It occurs when the Jews were wandering in the desert. They complain to Moses that there was no water and that they were going to die. Moses prays to G-d, the response is to talk to a rock and tell it to give water. Instead of talking to the rock, Moses hits the rock and water comes out. Aaron was punished after this incident. Reading the text in the original Hebrew, Aaron wasn't given any instructions other than to accompany Moses, which he did. What did Aaron do wrong? Why was he punished? At this point if you are still with me, you are probably wondering what this has to do with agility or Scrum. It was Rabbi Yehuda Meyers that gave me the answer to both of those questions, both what Aaron did wrong and what does this have to do with Scrum. Aaron's mistake was a simple and a common one, unfortunately one made on many Scrum teams.  First, a bit of background is needed. This event occurs right after Mo
Read more