John Hines' Software Process Blog

A blog on Agile software development and Scrum

  Home  |   Contact  |   Syndication    |   Login
  37 Posts | 6 Stories | 42 Comments | 0 Trackbacks

News

The information in this weblog is provided “AS IS” with no warranties, and confers no rights.

This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.

To err is human, to forgive is divine.

Tag Cloud


Archives

agile

Thursday, August 27, 2009 #

Agile development isn’t without its traps and pitfalls.  What’s surprised me is how Scrum’s most common problem areas are the same as those I’ve seen in other development lifecycles.  Here’s a list of three problems I've seen or heard arise in multiple sprints and my advice on resolving them.  It’s my hope that this post can benefit anyone who’s seeing these issues – but I’m happy to learn better ways to do it!

1. "People aren't marking their tasks complete as they finish them."

Start by being informed.  A good Scrum Master will review the tasks assigned to each story at the start of each day, before the daily stand-up meeting.  This will clearly show if any tasks aren’t being updated as well as helping you get a handle on your team.  This isn’t meant to be a deep dive – just pattern recognition.

The daily stand-up meeting is your best tool to fix delayed task updates.  After you review team status, mention: “I’ve noticed that there has been no progress on the XYZ story.”  Those working on the story should remind you that they just told you of the progress they’re making.  Smile and respond, “Please update the tasks on the story.”  Repeat this process at every daily scrum until the habit is established.  Eventually (and probably quite quickly) the team will recognize that you’re pushing process.

It’s possible that the tasks on the story are just too big and people are bogged down.   That’s a different problem. J

2. “People aren't attending the meetings.

This is the most common issue I see, and it’s far from being specific to Scrum.  Scrum has an erroneous reputation as having too many meetings.  At some companies it may also be acceptable to skip a meeting or two, but this really hampers Agile development.

Resolving attendance problems early is critical.  Meet privately with the person who's missing meetings and politely ask for a reason.  It could be that your daily stand-up meeting conflicts with that person’s schedule.  Or it could be that you were told this person was fully dedicated to the project when it’s really 50%.

The vast majority of what I’ve experienced has been people missing meetings without a compelling reason.  Worst is the engineer who happily decides to work independently, disappears for a few weeks, then reappears with work that was already done or has to be awkwardly merged with the whole.

This is where you need to be pragmatic.  If you’re losing a disruptive or unproductive person then feel glad and move on.  For potentially valuable resources, be direct; “I really need you to attend every meeting.  This project can’t be successful without your full involvement.”  The next step is to confirm that person’s expected time commitment from their manager.  The last step is to escalate the issue to their manager;; “I really need John to attend every meeting.  This project can’t be successful without his full involvement.”

If you are constantly fighting for people to show up or do work on your project, your peers are telling you something.  Your project may be conflicting with more important projects or it may be years ahead of its time.  A good Scrum Master doesn’t start a project without clear roles, clear commitment, and a clear definition of success.  Even if their boss tells them to.

3. “We’re all working hard, but we’re not making any progress.

There’s generally a simple remedy for this – make sure your tasks are small enough to track the work that’s being done.  In other words, you’re probably making progress, but the tasks assigned to your stories are too big to show it.  This does assume that the members of your Scrum team are working on what they’ve been assigned.

Signs that tasks are too generic are when team members report the same status at consecutive daily stand-up meetings.  Remember that a task should be about one day’s work – if a person has been working on the “Test new functionality” task for a week, it’s a sure sign that the task should be broken up.  I’ve also learned that the level of detail in breakup of stories into tasks can depend on the person working on those tasks.  In these cases it’s always best to include as much detail as makes sense.  If a senior person takes ownership of the tasks, checking off a rapid rate of progress makes them look good, and you still have the flexibility of assigning a less experienced person if you need to.

Lastly, there are instances when individuals just aren’t productive.  A good Scrum Master first learns why.  In my experience it’s been due to (in order of frequency):

·         Time conflicts with other projects.

·         Mistaken assumptions of how much time can be given to the project.

·         Lack of training.

·         Lack of motivation.

The best way to fully utilize Scrum is to make sure the first three are taken care of before the project starts.  The last issue should be escalated to be handled outside of the Scrum process.

Technorati tags: Scrum Scrum Process