Marek Blotny's Blog

I see daily stand-up meetings (“daily scrums”) as a one of the most beneficial practices in SCRUM’s repertory. Theory says that during the daily scrum each team member should answer three well-known questions:

• What did you do yesterday?
• What will you do today?
• Are there any impediments in your way?

Daily scrum is a great example of small things which make great difference. Three simple answers from each team member ensure that entire team is on the same page. It’s clear who is working on what, what will be achieved by the end of day, what problems we have etc.

What I find strange is that theory doesn’t leave much room for any discussion during the daily scrums. Discussions should take place during the follow-up meetings, immediately after the daily scrum. In general I agree with this rule. Bigger issues which don’t require entire team can be talked through later.

But I think it’s much more beneficial for a team if all members are allowed to jump in anytime during the daily scrum to add anything they find helpful. I have seen many scenarios where such impulsive hints work very well. Although scrummaster has a tough task with keeping the discussion under control. On the other hand the worst thing which can happen is when team members are in ‘on hold’ state until it’s their time to speak. That kills spontaneous knowledge sharing and potentially turns daily scrum into a progress report with limited profit for a team.

It’s vital however to keep the meeting under 15 minutes and stay high level. There is not enough time for the team to go into each and every detail. That should happen during the follow-up meetings. Scrummaster responsibility is to ensure that discussions are on reasonable level.

So if you ask me if enforcing so rigid structure of daily scrum make sense. I will answer … definitely not! On one hand you have effective and useful daily scrums which encourage teamwork and on the other quite rigid structure and doing everything by the book. I’m far from saying that traditional approach doesn’t work, but it can be improved, so for me it’s a simple choice.

What’s your view on this? Do you think it makes more sense to follow traditional rigid structure of daily scrums?

I have been watching Cory Foy’s presentation yesterday. The presentation was about ‘Growing and Fostering Software Craftsmanship‘ but for me the most striking part was when Cory was talking about knowledge sharing and about Bus Number. Bus Number Wikipedia defines in a following way:

Bus Number is the number of developers on a project who could be removed before understanding of a particular part, or all of the codebase would suffer severely. The term refers to the fact that if these developers were unable to work on, or consult for, a project it would be difficult (or impossible) for new developers to pick up where they left off. In other words, if the developers were hit by the proverbial bus, the project would be in jeopardy.

So it’s pretty much clear that we want Bus Number to be as high as possible. We don’t want to see our projects to be so vulnerable. With low Bus Factor one unexpected event can lead to serious problems.

And here comes the most interesting part, Cory claims that in most organisations this factor equals exactly one! Think about it for a second … it means that entire project is in trouble with one person taking a new job, having a health problems or being hit by a bus. How bad is that?

Another point made by Cory – most organisations are not promoting knowledge sharing. Rewards and fame go to the people who know how to rescue projects, who are able to deal with complex projects, difficult clients. Knowledge sharing is not that high on the list, as a side-effect people don’t pay much attention to it.

I think usually people will agree that knowledge sharing is an important thing, but in the same time people tend to focus more on urgent things rather than important. As a consequence typical ways to share knowledge like code reviews, pair programming don’t happen very often.

What is the Bus Number in your organisation? How do you ensure knowledge sharing? Who should be the most interested in increasing Bus Number within a team? (PM? Tech Lead? or maybe someone else?)