Work Agile!

I’m going to continue the previous discussion about why people who claim to hate Agile actually hate poorly run versions of Agile. In this post I want to discuss some of the techniques I’ve seen applied incorrectly and ways to make them better.  Keep in mind that in Agile, the idea of Best Practices can be dangerous.  What I’m talking about here is more the bad habits and pitfalls that can happen with Agile.

Daily Stand-ups
Communication is key!  Don’t ignore the value of daily Stand-ups but also be aware of the dangers of a poorly run Stand-up.  The number one complaint I hear about Agile is the boring, useless, and long Daily Stand-up meetings.  When I was at Microsoft this was actually my first exposure to Agile and I saw immediately how the technique was being used incorrectly.

Our Lead, who had no training or experience with Agile, didn’t understand the differences between a regular status meeting and a Daily Stand-up.  She would have each person give a detailed description of each feature, bug, and interaction they had had in the previous day along with all their work, including estimates, for the upcoming day.  She would also often interrupt and get into a discussions with each person on almost every item. It got to the point where people would bring in notepads filled with work details that they would then use to capture the new assignments she would give out.  With a team of only 5 people, she somehow managed to stretch the Daily Stand-up into 30-45 minutes a day of excruciating boredom.

As a Scrum Master, I see limiting the length of the meeting as an absolutely key component; 10 minutes is ideal, 15 minutes is pushing it.  In the training I do with a new team I always tell participants that if a Daily Stand-up goes over the agreed to length, they can walk out.  I have several goals with this statement.  First, to provide a little levity, but also to let them know that they as the team have power in this meeting.  By getting up and walking out the team is letting the Scrum Master know, in a not so subtle way, that they are not doing their job to protect the team’s time.  Of course I also recommend that the team first bring up the issue in a Retrospective meeting or talk to the Scrum Master directly.  But if the situation doesn’t improve then, as the ultimate owners of the process, the team needs to make it clear that change is needed.

In a Daily Stand-up, my team members never go beyond stating their general work items with no more detail than how they appear in the Sprint Backlog.  If they’ve been working on bugs, the status is “I’ve been fixing bugs.”  Only if they are having difficulty with a bug should they bring up a specific bug number and any discussions about how to fix it should be held after the Stand-up is over.  I personally hate the “Chicken and Pig” story and allow others to speak too, but they are not allow to derail the meeting anymore than any other team member.

Planning Meetings
There are many Agile books out there that advocate half day or all day Planning Meetings with the entire team.  In general I think this is a bad idea and is another one of those things I constantly hear complaints about.  Too many managers have gotten used to constantly being in meetings that drag on all day.  They begin to think that a half-day or all day meeting is no big deal.  The fact of the matter is it is a big deal to engineers and should be to the Scrum Master.  These meetings can be incredibly tedious and boring.  Yes, each engineer on a project should have visibility into what every other member of the team is doing, but no, it is not going to fascinate them and hold their attention for an entire day.  It’s far more likely that they will pay little to no attention at all.

One technique I use is Pre-Planning sessions.  If there is any way to divide up the overall team into smaller teams (these should typically be by feature/component, not function), I will meet with these teams separately.  Usually I’ll hold the Pre-Planning meetings on the Thursday before the end of a Sprint.  We’ll sit down with the Product Owner and go over the User Stories that relate to just these team members (which should have already been sent to the team by the Product Owner).  We’ll then identify the owners for the work and put the work items along with their just created estimates into the Sprint Backlog.  These meetings are typically time boxed at 1 hour, more if the team is new to Agile.

Using this technique I am able to keep Monday’s Planning meeting to under 2 hours.  We still look at everyone’s work items, make sure team members are balanced, and that the group as a whole agrees to the goals and demos for the upcoming Sprint, but we no longer have to walk through all the details and discussions with the entire team falling asleep.

Stay tuned for Pt. 3 where I will discuss a couple more of the Agile pitfalls.