Tag Archives: meetings

Pitfall of Scrum: Problem-Solving in the Daily Scrum

The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track. The Daily Scrum is timeboxed to a maximum of 15 minutes, but often should be even less. With a good physical task board, a Daily Scrum can often be done in less than a minute simply by each team member pointing at the pieces of work they are working on.

From the Scrum Guide:

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

In other words, don’t have those discussions during the Daily Scrum! The Daily Scrum is essential to creating transparency and implementing the Scrum value of Openness. The three questions of the Daily Scrum are effectively:

  1. What did I do since the last time we checked in as a team?
  2. What am I planning to do before the next check in time?
  3. What impediments, if any, are preventing us from getting our work done?

Each member of the team takes a turn and answers those three questions. This doesn’t have to be completely stilted, but it should be Focused (another value of Scrum) and efficient so that the need for other meetings is minimized. Accomplishing this takes some practice. The ScrumMaster helps the team to keep the timebox, but at first, a team might have challenges with this.

Struggling with the Daily Scrum

There are a some common reasons that a team might struggle with wanting to problem solve in the Daily Scrum:

  • One team member doesn’t know what to do next and it devolves into re-planning right there and then. A quick suggestion or two is probably fine, but it is a very steep slippery slope. A team can easily get into the habit of always doing this! The ScrumMaster needs to be vigilant about recommending that the discussion be taken up after the Daily Scrum is concluded in order to avoid this pitfall. This suggestion will be common when a team is first starting out.
  • One person mentions an impediment that someone else knows how to solve… and a third person has a different idea of solving it. In this situation it is much better for interested team members to just simply indicate “I have an idea for that,” and let the Daily Scrum continue. Then after the Daily Scrum those people have a quick discussion. This avoids wasting the time of everyone on the team with something that is only interesting to a few.
  • An individual doesn’t seem to have anything to report and other team members try to elicit more information. This should really be something that the ScrumMaster or the team’s coach should take up with the individual. It may be that there is an impediment that the person is uncomfortable sharing openly with the whole team. There is a subtle pitfall that may be revealed here: that the team does not have the safety to self-organize.
  • Disagreement about what to do next. This type of problem is the hardest to deal with because many people will feel that disagreements need to be resolved before any action can be taken. A good ScrumMaster will actually encourage competing ideas to be attempted. Learn by doing instead of by argument and analysis. This is the fundamental shift in culture that Scrum is attempting to put in place: an empirical approach to work rather than a defined approach.

Just beware: yet another pitfall (although not common) is to decide that the Daily Scrum shouldn’t be daily because it is taking so long. Unfortunately, making this change will often just make the meetings even longer until they devolve back into weekly status meetings reporting to the team lead!!! Remember that it’s not Scrum anymore if your team doesn’t meet together daily.

Ultimately, if a team is struggling with the Daily Scrum in any way, this is a valid topic for discussion in the Sprint Retrospective.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Meeting Check-Ins

Very nice article called Why I Always Start a Meeting with a Check-In.  From the article by Ted Lord, senior partner, The Giving Practice:

The greatest benefit of working in a group is our diversity of viewpoints and approaches; groups hobble themselves when they don’t continually give attention to creating a container of trust and shared identity that invites truth-telling, hard questions, and the outlier ideas that can lead to innovation

One antidote to over-designed collaboration is the check-in.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Comparison of the ScrumMaster, Product Owner, Project Manager and Team Lead Roles

Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum.  Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:

ScrumMaster Product Owner Project Manager Team Lead
NEVER NEVER Assign Tasks YES
NO PARTICIPATES Create Schedule NO
NO YES Manage Budget NO
Remove Obstacles PARTICIPATES YES YES
NO Define Business Requirements PARTICIPATES NO
NO YES (Deliveries) Define Milestones NO
Facilitate Meetings NO YES YES
YES (process and people) YES (business) Risk Management PARTICIPATES
Organizational Change Agent NO NO NO
NO Accountable for Business Results RARELY (just costs) NO

Of course, there are many other ways we could compare these four roles.  What would you like me to add to this list?  Add a comment with a question or a suggestion and I will update the table appropriately!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Timeboxing, Lateness and Character

I just finished reading a great rant about being on time by Greg Savage.  It got me thinking a bit.  I’ve been involved with Scrum and other Agile methods since the mid-90’s and in that time, my perspective on time has changed considerably.

saving time clock

I used to be the guy who was always late.  And it was a completely selfish behaviour.  Meetings, outings, even weddings.  I just couldn’t believe how “uptight” people were about time.  But gradually, over a period of about 5 years as I became more and more aware of the underlying philosophy of Agile, my perspective, and more importantly my behaviour, changed: I started being on time.  For everything.  Even if it meant doubling my travel time buffer.  Even if it meant sleeping 3 hours instead of 8 hours.  Even if it meant missing a meal or a drink or a personal to-do item.

Time is the only resource that, once spent, we can never get back.

Scrum and most other Agile methods respect this implicitly in their time-boxed iterations and meetings.  But people on Agile teams often need time to adapt and change their behaviour.  In many ways, timeliness (starting and finishing meetings on time) is a critical component of the Scrum value of Respect.

Timeliness is also related to our understanding of planning.  The Horizon of Predictability is short in most work environments.  Maybe a week or two.  If you dis-respect the tkmeboxes of the Agile process, you are jeopardizing your ability to effectively use the horizon of predictability.  Even the Daily Scrum, normally time boxed to 15 minutes each day, can through abuse of time, cause long-term ramifications in product development planning.

But really, I like Greg Savage’s point better than all the practical stuff: being late is rude.  Period.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Humor – A Typical Project Launch Meeting

One of the things that I love is how many great videos there are that show the ridiculousness of a lot of corporate behaviour.  This video is a hilarious (and painful) look at one aspect: the way we treat our experts.

Of course, I don’t mean to say that we should never be sceptical.  Rather, sometimes we just have acknowledge reality: there is no magic to make a red line with a green marker.  The role of the expert is to clarify reality to others through their knowledge and experience.

When I am doing CSM and CSPO training, I often am faced with people who want to know how to make high-performance teams with distributed team members.  They are often looking for some sort of magical solution.  This is an example of not being willing to face the reality that distance makes communication slower, less effective, and less likely to happen at all.

I’m sure all of you have interesting experiences of being the expert in something and your audience pushing you to find the magical solution… share your stories in the comments please!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I attend every Sprint Planning meeting in person

This rule of Scrum aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  In-person attendance of all Scrum Team members allows for the plan to unfold with minimal communication overhead and for the team to keep the meeting within the short time-box.  In-person attendance also allows the team to effectively collaborate in the work of creating the plan. The efficiency and effectiveness of the Product Owner’s presentation of the Product Backlog is optimized as well as the Development Team’s ability to collaboratively assess and select what it can and will accomplish in the Sprint. It also allows for everyone to be clear about the Sprint Goal and why the Development Team is building the increment. In-person attendance also allows the Development team to efficiently and effectively come to a decision as to how it will build the increment of functionality. In-person participation of all team members also increases the likelihood that the team will create the right design for the increment.  If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the planning becomes compromised. Compromised collaborative planning yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the planning will lack effectiveness. People are prone to estrangement from hazy goals reached through ineffective planning. In-person planning, therefore, is paramount to succeeding with Scrum.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: The Sprint Planning Meeting is Timeboxed to 2 Hours / Week of Sprint Length

Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants.  In Scrum, the length of the Sprint Planning Meeting is determined by the length of the Sprint.  For example, a one week long Sprint has a Sprint Planning Meeting that is timeboxed to two hours.  It is acceptable for the meeting to take less time, but not more.  A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours.  Keeping the Sprint Planning Meeting timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective planning in a very short period of time.  If the meeting is not timeboxed, then typically the team will keep planning until the plan is “done” which usually substantially eats into work time.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail