I would like to share some thoughts and reflections on the experience I got when teams (especially new ones) “perform” the Daily Scrum. But before we do that let’s take a look at the Scrum Guide what it says about this ceremony:
- It’s time-boxed to 15 minutes
- It’s an event done by all members of the development team
- In this the team will synchronize the activities and create a plan how to move on till the next Daily Scrum
- It takes place every day at the same place at the same time
- During the Daily Scrum each member of the development team has to answer the following questions
- What have I done since the last Daily Scrum?
- What will I do till the next Daily Scrum?
- Did I observe any impediments since the last Daily Scrum?
There are some more details in the Scrum Guide about the Daily Scrum but for now it’s ok. I will come to it later.
Performing the Daily Scrum
When teams are “performing” their Daily Scrum I often see that the development team members are reporting to the Scrum Master or the Product Owner (or some high level managers or what ever). That’s not the intention of the Daily Scrum. It’s a special meeting from the development team for the development team. It’s public and everybody is allowed to attend but only committed people (in this case the development team and the Scrum Master) are allowed to talk. But it’s not a report meeting where each development team member justify what he or she has done. And it’s not a spoken word performance only. It’s also about interaction.
Confucius and the stages of learning
For me the first important point is the visual interaction. As a Scrum Master you should take care that the “performer” is looking at everyone else (and changes the person he or she is looking at from time to time). This creates a closer relationship between each other and makes them feeling as part of a team. If you are only reporting to a single guy it doesn’t create such relationship. The other important thing is when the development team is performing a spoken word performance only. Here is what Confucius said about knowledge and learning:
“I hear and I forget. I see and I remember. I do and I understand.”
So if the team is only talking and talking it’s the first stage of Confucius’ stages of knowledge and learning which is about hearing and forgetting so the most things will be handled with less attention. But how to avoid that – and this is pretty easy. In all cases I’ve seen the Daily Scrum takes place in front of the Scrum Board. So each performer should interact with it moving the tasks from one column to another or pointing at a task which will be continued after the Daily Scrum, adding new stuff or removing something. In this case people will look at the performer, following his movements and listen to him. In front of brain science it’s way more better for the observer because they have to link what they see and what they hear. And the visual element makes it easier to follow especially when many tasks are moving. So interaction is leading to Confucius’ second stage of knowledge and learning. Here’s a short summary:
- Each development team member should look at each other during their speaking time
- Each development team member should interact with the Scrum Board and the team while talking
- Moving is also a good energizer π and good to attract attention
If an interaction with the Scrum Board is impossible it’s a good sign that’s something’s not on the board π
I hope that helps.
How could you use a daily scrum time-boxed to 15 minutes and at the same time use the logo “I use Pomodoro”?
A pomodoro is atomic, and it lasts 25 minutes
π
π It’s all about a high focused time-box. And you can use the pomodoro technique to manage your time and doing the Scrum Ceremonies – why not π
@Nusco,
Interesting observation about the feet. Is there any guide about this (feet movement vs. what the person really thinks)?
If you can stand the overly all-american, “let me tell you about my life” tone, this book contains more than a few hints like that one:
http://books.google.com/books/about/What_Every_Body_Is_Saying.html?id=W5opGQAACAAJ
It’s not a scientific masterpiece by any means, and the good informartion in it is pretty diluted… But I still found it a fun read.
Thanks for the post BjΓΆrn. I agree that it is important to run the stand-up around the board in order keep interaction high and the Confucius statement is a good way of helping us understand why.
One other tip that I`ve used to help keep stand-ups running smoothly is to rotate the coordinator every day. Each person gets a chance to remind others to keep the stand-up focused, minimize discussions, start on time, etc. This has helped our stand-ups stay effective over the longer term and is another way of applying “I do and I understand”.
Hi Steve,
I think rotating the “coordinator”-role (I would call the role facilitator) is a good way the spread the knowledge why and how we’re doing this. Thanks for sharing π
I think this has some interesting points, but what I think the scrummers forget is that
1) Many of the topics brought up at such meetings are extremely banal and do not affect most of the team members
2) Thus, it is quite pointless, for people doing the javascript, to be looking at or talking to people doing the backend database about issues they are working on related to this or that browser compatabilility.
They also probably have little or no need to interact with the database people directly;
If they are communicating with the people they need to communicate with is the important question not whether they are able to get the whole team to focus on their particular issues which in fact don’t need the whole teams energy.
Nothing burns people out more than listening to people drone on about things that have nothing to do with their work effort.
Jordan
Hey Jordan,
I get the point but I have some additions to that:
1. You have a strict time box of 15 minutes for the “development team”. So there not much room for excessive descriptions. So as a Scrum Master you should highlight that a focus on the three questions is essential. If you observe that an answer is drifting away interrupt the performer in a gentle way and ask if he could continue it right after the Daily Scrum so it’s up to each team member to stay. At least necessary members should stay π
2. It’s absolutely valuable that every team member hears what other members are doing. Talking about cross-functionality is also about having more generalists than specialists in this team (i.e. having JavaScript Developers only doing JS and database people only doing database stuff). In many cases you start with a team of specialists. But they should be eager to know more about the things other members are doing. But this “eagerness” is difficult to “create”. My point of view is that as team we are working on reaching a goal for the whole team. And not on individual goals. So if you see that somebody’s task is taking more time than expected there might be a problem – and where you can help. And it’s very frustrating being on your own facing a problem which is hard to solve and having “colleagues” right behind your back trampling with their feets to make you hurry up – that’s not working. Only the goal is counting and if something is completed to 80% (because only the damned database guy didn’t make it) it’s not finished so it doesn’t count. If you have an environment like this you are working more in a group of people but not in a team. The whole team should be interested in reaching the goal and it should do everything what is necessary to achieve it.
If I am working with a team of specialists I try to engage pairing (not only focused on programming, but I use it as an example). Working in pairs has some very valuable benefits:
– the programmer can reflect what he is going to do because he will explain it to his peer
– the peer is learning something about a possible new context and also about the way the programmer things and how the programmer is going to solve problems and where the related code is
– the programmer and the peer should switch their roles (for more simple cases in the beginning). So the “new” programmer will internalize and learn the things the “old” programmer has done
– this is a risk minimizing activity. If a specialist is sick, gone, dead or whatever it has a huge negative impact on the team. If you’re doing pairing you minimize this impact. You have someone (at least one team member) in place who is able to jump in and to work on the “specialists” item. Not as effective maybe but he or she know where to go and what to do. At least he or she has an idea how to move on.
But working in pairs takes time – but it’s worth to be invested.
Using a daily time-box of 15 minutes to synchronize and to plan how to move on till the next day is very valuable for the whole team because we’re talking about goal for the team. And when ever somebody needs to talk to somebody else because of issues or what ever – do it. Don’t wait till the next daily. And if something is coming up in the Daily Scrum which not of interest for the whole team try to move it right after the Daily Scrum.
Does it fit?
1) That’s my point; the 3 questions don’t matter to most of the team, so why force everyone to listen to them? They could be talking about js, etc, the dbs could be talking about db etc… 7 ppl * 15 mins * 5 days/week is a lot of wasted time when really the various subgroups should just meet directly
2) The cross functional aspect you describe is not realistic; database ppl will not be doing high quality js and vice versa… read my blog for more details, espcially where I discuss the Nanoka paper.
3) No, still doesn’t fit… But I didn’t expect it would; I’ve spent a lot of time debunking Scrum so I doubt I’ll have a change of heart in the near term future
Jordan
Hi Jordan,
I would like to come back to your points:
1) I wouldn’t be so sticky on the 15 min. If a team is done earlier – fine. My experience is that everyone I am working with find that the Daily Scrum is very valuable – even the not committed ppl. Your experience seems to be different and that’s absolutely ok. And if you say that the Daily Scrum is not valuable for you and your team – keep it lean: eleminate everything what’s not adding value…but don’t do it without trying it. But I guess you give it a try as well π
2) Thanks for the link to your blog post. And I don’t mention a cross-functional team where everybody is a high-flyer for everything. I haven’t seen something like this. What I see in many cases is that teams begin to spread special knowledge to minimize risks and to have a better understanding about what’s going on.. And sometimes team members get very sticky on the new knowledge so they want to master it as well.
I really like the ongoing discussion π
Thx a lot.
Nice and simple explanation. I have though a small disagreement regarding who has to speak during this meeting. Testers are nowadays permanent members of an agile team and work in parallel with development. I believe that they should also speak to inform the team about the process of their testing tasks.
Regards
HI Papapetrou,
I see the point about testers etc. I use the terminology from the Scrum Guide where the name “development team” is similar misinterpreted as the “Scrum Master” is. The so called “development team” is a cross-functional team including all competences needed to deliver a potential shippable product increment at the end of each sprint. This means that the members of the “development team” are not only software developers. In most cases I’ve seen “development teams” include testers, UI(X) – experts etc. as well.
And the speaking time(-box) is about focus. So it’s valid that it belongs to the committed people (incl. the testers if they are part of the “development team”). And if some attendees have something valuable to add it’s no problem to do it right after the Daily Scrum. If someone is needed during the Daily Scrum the team can decide to give him some time to speak or not. But if they do they should take care about the timebox. Does it makes sense?
Well said, and I like the analogy to performing and getting your audience engaged.
Very good advice. The Daily Scrum (sorry, it’s still the Stand-up Meeting to me) is the first litmus test to tell if a team is truly self-organizing, or just “going through the motions” of Agile. For me as a coach, the stand-ups have been the place where I found my biggest satisfactions (“You should have seen them this morning at the stand-up… Suddenly they were a real team!”) or the most depressing early morning wake-up calls (“Man, this team is just reporting to the Scrum Master. There is absolutely zero collaboration”).
One more trick of the trade: as you attend a stand-up, don’t waste your time listening to everything they say… Instead, look at their feet. It’s amazing how much feet position gives away about their attitude and feelings.
Hey Nusco,
I really like your hint about the feet position. I’ll share my next observations π
Thanks a lot!