Scrum Fundamental: Communication, Delegation

I’ve been blogging lately on common issues in teams practicing Scrum or otherwise trying to be agile, and not having complete success. Yesterday's post covered a hodgepodge of items very loosely related to measuring progress. Last week's post covered user stories. Today I thought I’d talk about communication and delegation.

Communication

The purpose of the daily stand-up/scrum is communication. This is very important. The idea is to keep the meeting short (so make everyone stand) and have everyone share just the info that most everyone else needs to know. This can often be done in five or ten minutes.

Some teams cover what they did yesterday, what they plan to do today and roadblocks. It’s useful to mention some significant change that they are about to commit to source control.

Teams that are co-located and that pair-program with collective code ownership and limited Work In Process don’t typically need to discuss those topics because everyone already knows what everyone else is working on. Those teams just talk about less about what they are doing and more about their impediments – things that are slowing them down.

Decide what is most important for your situation. Whatever your standard topic is, don’t go into much detail or resolve anything during the meeting. Those that need to follow-up or work together or have a deeper discussion get together afterwards.

Whatever your standard topic is, vary it. Don’t get stuck in a rut. If you usually go in order by person, once in a while go in order by story. Throw in a different question to answer, perhaps related to something you are trying to improve upon identified in a retrospective.

The standup is a start, but don’t stop there. Stop using email. Get out of your seat and speak to someone face to face. And working with the whole team in an open space is a really really really good idea.

Delegation

Let go of assigning tasks to people. Let the team manage task assignment themselves. People will choose the correct tasks most of the time. When they don’t, let that be a learning experience.

Let the team estimate the stories.

Let the team come up with the tasks.

Make time for yourself. Take time to think about and to improve the system. By ‘system’ I’m referring to the process and the organization, not the software you are developing.

Next

Next up should be a post on planning.

What is on your short list of common problems related to some fundamental aspect of Scrum?