My Preferred Agile, Scrum, and XP Resources

If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

My Preferred Resources

All are in order of my personal preference in each category.


Scrum

  1. The Scrum Guide (Must read for all)
  2. Deemer, et al. “The Scrum Primer”
  3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
  4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
  5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
  6. Kniberg’s _Scrum and XP From the Trenches_ (Note that there is a free PDF download of this book if you register with InfoQ – something I recommend anyway)
  7. Derby/Larsen’s _Agile Retrospectives_

XP (Extreme Programming)

  1. Jeffries’ “What is Extreme Programming?”
  2. Jeffries’ _Extreme Programming Installed_
  3. Koskela’s _Test Driven…_
  4. Martin’s _Clean Code_
  5. Feathers’ _Working Effectively With Legacy Code_
  6. “The Rules of Extreme Programming”
  7. Wiki entry on XP Practices

Agile/XP Testing

  1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
  2. Cripin’s “Using the Agile Testing Quadrants”
  3. Crispin/Gregory’s _Agile Testing_
  4. Crispin/House’s _Testing Extreme Programming_
  5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
  6. Osherove’s _The Art of Unit Testing_

User Stories (which originated in XP)

  1. My “User Story Basics” article and all of the links at the bottom of that article
  2. Cohn’s _User Stories Applied_
  3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
  4. Lawrence’s “Patterns for Splitting User Stories”

Special Agile Topics (if applicable)

  1. Deemer’s “The Distributed Scrum Primer” (If some of all your team is remotely distributed)
  2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
  3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)

A Great Link for Patterns on How to Hold a Great Agile Standup Meeting

I never cease to be amazed by the great work that Martin Fowler has on his web site.  (In all fairness, though, this post seems to be mostly from Jason Yip).

Anyway, GREAT LINK!

“It’s Not Just Standing Up: Patterns for Daily Standup Meetings”

http://martinfowler.com/articles/itsNotJustStandingUp.html

Also, while you’re here, you might want to take a look at one of my older blog posts:

“Bad Smells of the Daily Scrum”

https://scrumcrazy.wordpress.com/2010/09/18/bad-smells-of-the-daily-scrum/

As usual, all feedback welcome.

P.S.  Have you noticed that I’ve been posting a lot more lately?  One reason is that I’ve had more time lately to write, and another reason is that I figured out that WordPress now has a feature that allows me to schedule when the posts are to be delivered, so I can just queue them up! Sweet!

.

One Way to Handle Bugs and Production Support in Scrum

This article has been updated and republished here.

Sprint In Progress Tip – Resolve Obstacles and Update Task Completion Immediately! (Don’t wait until the Daily Scrum)

Intro

I have long recommended that Scrum teams have a team working agreement that their Scrum board (aka Sprint Backlog) be updated immediately, but at least once daily about 30 minutes before the Daily Scrum.

Someone once questioned me on this advice as follows:


If the team updates task and story state immediately upon a state change or does such updates at least 30 minutes before the daily meeting:

  • What is the purpose of the daily meeting?
  • What does the team talk about in the meeting?
  • In other words, doesn’t that make the daily meeting redundant and, therefore, waste?

My Answer

One should not assume that everything that needs communicating is communicated via the task stickies(or whatever task token your team uses). Therefore, while the tasks are spoken about at the Daily Scrum, they need not be moved in the daily standup, and their effect on the burndown has already been recorded and plotted.

Usually, they will say something akin to:
“Yesterday I finished (pointing) tasks A & B, and began working on task C this morning. I should be able to finish task C this morning, but then I have to partake in some interviews for a new team member, so I’ll need a new task later this afternoon. I’ll look at the board then to determine which task.”

“Yesterday I finished task F. I ran into an obstacle X working on that one [but rather than wait until today to report it in the daily Scrum…], so I hit up Bob and he said to talk to Lucy over in Finance, and they were able to get me past that obstacle. So, if you have obstacle X, talk to Bob or Lucy and they can get that fixed for ya, or come see me and I can help. I also started on task F at the end of the day yesterday, and I should have that finished after lunch. I’m thinking for my next task that I’ll look into Story 7 and pick up one of those tasks. I wasn’t here when Story 7 was last groomed, so a potential obstacle I might have is understanding some of the requirements. Who’s a good person to talk to?” (If the answer to this question is super short, then it’s handled immediately, if it becomes a deeper discussion, this issue gets resolved after the daily Scrum as an impediment/obstacle.)

“Hi team. I was out yesterday so I didn’t do anything, and I noticed by looking at our [accurate]burndown that we’re way behind schedule for this sprint, so I think we need to have a quick impediment meeting after the Daily Scrum and figure out what needs to drop or happen so that I can know what’s best for me to work on.”

Another example:
Let’s say your Daily Scrum is at 10am. Let’s say there are 3 tasks, task A, B, and C, that are dependent on each other. (I coach my teams to remove these dependencies and make tasks as independent as possible, but that’s not always possible or easily done). If Fred finishes task A at 11am today and then goes to lunch, why doesn’t he go ahead and move it? That way Jennifer could pick up task B, and get that done. Why should Fred wait until 10am tomorrow in the Daily Scrum to move his task, when someone could have begun work on it yesterday at 11am?

My advice

  • Move tasks and stories as soon as they change status, like immediately.
  • Have someone update the burndown shortly before the Daily Scrum, so that Scope(too much, too little) and critical pathing problems are apparent and can be identified as impediments in the Daily Scrum (to be resolved outside of the Daily Scrum)
  • Team members, attempt to resolve an obstacle on your own first.
  • If you can’t resolve it in what seems like a reasonable amount of time, talk to someone who you think can. If you’re not sure who to talk to, ask someone or ping the ScrumMaster. Do not wait until the Daily Scrum to do this.
  • Try to foresee and identify obstacles before they become obstacles. Give the team a head’s up if you see a likely obstacle coming. (Critical path issues are often easily foreseen)

Best Practice: Look to the Scrum Guide *First*

Short Story:

When teams struggle with Scrum, it is my strong opinion that they should look *first* to the Scrum Guide for guidance.
(Or *look back* to the Scrum Guide, if they are an experienced team)

Long story:

A more complete way of saying this is:
When teams struggle(whether they be beginner or experienced), it is my strong opinion that they should look *first* to the Scrum Guide, and secondarily to other resources (books, articles, online, other professionals) for help. In fact, read and learn as much as you can from the Scrum Guide and the secondary resources. So long as those other resources don’t contradict the Scrum Guide, then it’s probably ok to try what they suggest. If those other resources do contradict the Scrum Guide, then think long and hard before deviating.

I have observed the following Anti-Patterns with respect to Scrum implementation.

Faux Scrum: Disinformed or Misinformed
1. Someone advocates a practice that is not consistent with the Scrum Guide.
2. The team struggles with that “something, ” often times because the “something” is not really Scrum at all, but some practice that someone inaccurately said was Scrum.
3. Rinse and Repeat until either:
a) “Scrum” is a dirty word in your organization, or b) your organization settles for mediocrity, or c) you decide to move on to some other process, or d) until someone figures out what you are doing is way out of line with the Scrum Guide vision, and tries to help you get back to basics.

Faux Scrum: Give up quickly and Deviate from the Scrum Guide
1. A team struggles mildly with implementing some practice described in the Scrum Guide.
2. Rather than retrospect and improve their implementation of the practice as the Scrum Guide would suggest, they choose a different practice that deviates from the Scrum Guide, usually with negative consequences that that team may or may not have the ability to immediately see.
3. See step 3 above.

Faux Scrum: Pretend you’re doing Scrum
1. Pretend to be doing Scrum, but instead use a bunch of your existing practices instead of what the Scrum Guide suggests. “Hey look, Mom! We’re Agile!”
2. Rename a lot of your old practices, artifacts, and roles with Scrum terms. Proceed as usual with the status quo and tell everyone in your company how Agile or how Scrummy you are.
3. See step 3 above.
(Ken Schwaber calls this the “Methodology Facade Pattern”)

Faux Scrum: Selective Scrum
1. Like you did successfully with WaterRUP processes, selectively pick a small number of Scrum practices and implement those only.
2. Enjoy the new practices, but be sure you stop progressing towards the Scrum Guide vision either because you get too complacent or too busy.
3. see step 3 above

The Power of Positive Thinking
I know what you’re thinking. Man, this guy is negative! If you spoke to people in my personal or work life, I think they would tell you that I’m generally a very positive person. I’m even hilarious at times, but that’s hard to convey in prose about intellectual topics. I think, though, that they would also tell you I’m a very detailed person, and that I’m honest and direct about serious subjects.

So, rather than call everyone “Chickens” and “Scrumbuts” and “Faux Scrumites”, what I do instead is I advocate a positive strategy.
That positive strategy is : When deciding how to proceed with Scrum, look to the Scrum Guide *first*.

If you look at my blog and web site, I generally give positive advice, but I also don’t shy away from Worst Practices, Anti-Patterns, Bad Smells, and Traps. Any good tester tests happy, sad, and bad paths, usually with particular attention to the sad and bad paths. I do the same. I also make sure that I propose solutions to all of these Worst Practices, Anti-Patterns, Bad Smells, and Traps. I do want to help, but sometimes people are not Scrum knowledgeable enough to recognize the bad practices.

Sometimes, to convince people to get back to basics, I have to point out where they’ve deviated from the Scrum Guide. This usually involves quoting the Scrum Guide. Yet other times, to further convince people to get back to basics, I have to express some of the possible advantages and disadvantages of their current strategy. That’s part of being a Scrum Coach and change agent, and comes with a certain amount of resistance. I’m ok with that. The reason I’m ok with that resistance is that I do it because I passionately and honestly believe it’s the right thing to do.

Bad Smells of the Sprint Backlog

Feel free to add your own bad smells in the comments below.  This article is my own opinion, and is based on my knowledge and Scrum Coaching experiences.

Does your Scrum Team seem to lose focus in the current sprint? Do stories stay stalled  for several days?  Does your team have trouble finishing the amount of work it committed to?  Does your team want to get more productive and increase their velocity?  Does your Scrum board confuse you?

Some of these situations are indicators that your team is not maximing it’s productivity in the sprint.  Removing some of the bad smells from your Sprint Backlog(some teams just refer to their Sprint Backlog as “The Scrum Board” or “The Board”) can help with many of these issues.

I define a “bad smell” as any symptom in a process that possibly indicates a deeper problem.  It doesn’t always mean the bad smell is indicative of a true problem, but most times it is.  Everyone on the Scrum Team is responsible for results, so any team member can point out these bad smells.  However, the one person ultimately responsible for optimizing the use of the Scrum framework is the ScrumMaster.  If your ScrumMaster is not identifying these bad smells to the team (and following up to make sure the team resolves them of course), then your ScrumMaster is not doing a terribly good job in the ScrumMaster role.

Bad Smell:  Sprint Burndown is not used to analyze the Sprint Backlog

Not using and updating a sprint burndown chart is breaking one of the fundamental rules of Scrum.  Sometimes teams are able to judge progress by gut feel or by just looking at the board, but this is very rare.  A team can learn very interesting things by viewing their burndown(chiefly, are we on track to get to ‘DONE’ on everything this sprint?).  If you’re not using it, start!

Bad Smell:  Sprint Burndown is not kept up to date

This is almost as bad as not using a Sprint Burndown at all.  The Scrum Guide is very specific on this topic, the burndown must be updated daily.  If you’re not updating it daily, then your team is not optimizing their work, or said conversely, your team is operating at a sub-optimal level.  Assign someone (maybe the role rotates) to update it every day, preferrably before your team’s Daily Scrum.

Bad Smell: Tasks change status in Daily Scrum

If developers move their tasks to “Done” during the daily Scrum, then obviously the burndown chart is now out of date.  If many developers do this, then the problem is multiplied.  It’s ok to point to tasks and stories on the board, but try to get your team to make a habit to either a) ALWAYS update tasks as SOON as they are complete, or at least b) ALWAYS update tasks 30 minutes prior to the Daily Scrum (That way the burndown is updated with fresh data just in time for the Daily Scrum).

Bad Smell: Everyone on the team doesn’t have at least one task “In Progress”

There are several causes for this smell, so identify it as an obstacle and bring it up to the team to resolve.

Potential Cause: Tasks are not reflective of the work that’s actually being done.

Potential Solution: Re-write the tasks so that they more accurately reflect what is actually being done.

Potential Cause: Roles on the team are siloed.  (“I’m a tester, and early in the sprint, nothing is ready to test yet?”)

Potential Solution: Cross train team members.  In theory, every team member should be able to pick up and do ANY task on the board.  Some might take longer than others to finish it, but that’s ok.  If your team is not cross functional, then there is no excuse for anyone to be sitting on the sidelines.  Have that idle person ‘pair’ with someone else so they become more cross functional.  Other things testers can do while being so called ‘idle’:  Prepare test cases and test data for stories in progress, help the PO write acceptance tests for stories coming in the next sprint, automating tests that previously had been done manually, researching new test tools, or refactoring tests.   No matter what they choose to do, there ought to be  a task on the board that describes what they are doing.

Bad Smell: Tasks not estimated

The Scrum Guide is very clear here.  Tasks should be designed to be completed in a day or less.  Further, they should be estimated in some consistent unit so that the Sprint Burndown can accurately track progress.  Most teams use hours, and many teams assume a 5 or 6 hour work day, leaving the other 2 hours for other corporate responsibilities, bathroom breaks, etc.  This means no task should be longer than 6 hours.

Bad Smell: Tasks not recorded, especially defects/bugs found in the current sprint

If a bug is found and fixed all in the same day, then by all means, don’t record a task for it, just do it!  Otherwise, the bug should be confirmed by a developer, and that developer should put one or more tasks on the board that represent the amount of time to code the fix and test the fix.  All too often teams either track these bugs elsewhere or don’t track them at all, and this means the current sprint backlog is not being represented well.  If a bug will be resolved in a future sprint(should be VERY rare), then the bug needs to be added to the product backlog.

Bad Smell: Tasks stay “In Progress” for more than two days.

If your tasks are designed to be one day or less, than no task should stay “In Progress” for more than two days, unless that task is blocked.  If anyone on the team notices this happening, they should ask, “What is blocking this task?”

Bad Smell: Tasks that are estimated and/or designed to span longer than one day

As is discussed above, tasks should not be designed to last longer than one day of effort.  If a task will take longer than that, the team should break it up into sub-tasks.  If the tasks are designed to be longer than a day, there will be much more slippage, and your burndown will not reflect actual progress.

Bad Smell: Not properly accounting for meetings when creating the Sprint Backlog

Go ahead and make tasks for all of your meetings that you think will happen in a sprint, even the Scrum ceremonies like the Planning Meeting, Retro, Backlog grooming, etc.  Also task any design or other scheduled meetings the team might have in order to work on a story.  Tasking your Daily Scrum is probably going too far.  Record the amount of time that the team estimates for the meeting, multiplied by the number of team members attending.  Your goal is to accurately account for about 5-6 hours of effort per day for each developer.  Once your team accomplishes this, they can then begin to inspect and adapt their estimates moving forward.  If a whole bunch of time is unaccounted for on the sprint backlog, then it becomes very hard to inspect and adapt your task estimating.

Bad Smell: Product Backlog item shows no task movement for several days

This is the “forgotten story.”  This is a story that shows no progress for several days.  In rare cases, it may just mean that no one has had a chance to work on that story.  If the story has been started, but has shown no progress for several days, a team member should speak up and say “What’s blocking this story from getting to Done?”

Bad Smell: Ideal line is not used on the Sprint Burndown.

Using an “Ideal line” is not a required part of Scrum, as specified by the Scrum Guide.  However, I still consider it a bad smell to not be using one.  The ideal line should be the sum of capacities (5-6 hrs/day X number of developers X number of days in a sprint) for the entire team for the sprint.  If you must, you can adjust capacities of those who are matrixed in, but you should also know that the more matrixed in resources you have, the less productive your Scrum team will be.  So, the ideal line is drawn between the total capacity hours for the team for the sprint, beginning on Day One of the sprint, down to zero hours on the last day of the sprint.  This line will often tell us if we’re ahead of or behind schedule.  I use a rule of thumb that, for any team who has executed 3-4 sprints already, we automatically don’t care about the ideal vs. actual comparison unless they are more than 15-20% different.  Anything inside that band (below or above) is not in and of itself indicative of a problem.  If it is outside of that band, it’s an impediment that should be removed.

Bad Smell: Ideal line in Sprint Burndown is not used correctly to indicate team capacity.

I’ve seen teams start their ideal line on Day One of the sprint as the total number of hours remaining for all tasks in this sprint.  That is NOT an ideal line, because it does not reflect team capacity.  See Mike Cohn’s book (referenced below) for tips on how to draw a proper ideal line in your Sprint Burndown.

Bad Smell: Tasks way too detailed

Remember that tasks need not be terribly detailed.  They should be described in 2-4 words, and should generally be more generic than specific.  For instance, instead of “Add fields to jsp in PaymantPage.jsp”, something like “JSP changes” or “UI changes” is fine.  One benefit of keeping things a little more generic is you can use the same task description on different stories.  “UI changes” could end up being a task on most of your stories, and that’s ok.  Another benefit of keeping tasks more generic vs. narrow is that narrow tasks increase the chances of  work being missed in a story.  What if, in addition to adding those fields, you also needed to add validation for those fields in the UI?  As long as the team understands what the task entails, that’s what matters more than the text used to describe the task, so fewer words generally work better.

Bad Smell: A team member having more than 2-3 tasks “In Progress”

Cohn’s book has a good section on why working on more than 2 tasks generally degrades productivity.  Having 2-3 tasks in progress also prevents the burndown chart from properly measuring progress, much the same way that having tasks longer than about one day skews the burndown chart.  Many teams make a rule that a single developer cannot have more than 2 tasks in progress.  Another strategy is that, by definition, 3 or more tasks in progress by a single developer is an impediment that must be discussed after the daily standup so that the root cause is known and well understood.  Yet another strategy is to put one of the tasks back in the “TO DO” bucket, so long as it’s not a task on the critical path for the sprint.

Potential Cause:  Tasks poorly defined. Tasks are intertwined such that you can’t do one without the other without the other.  Combine tasks or redefine them so they can be done sequentially.

Potential Cause:  One or more of the tasks is currently blocked.  As long the impediments are well known, then this cause means the bad smell is not necessarily bad.  However, make sure the impediments are being discussed and removed!

Bad Smell: Not knowing who a task is assigned to.

It happens a lot.  People move the tasks but don’t indicate who is working on them.  Much of Scrum development is a team effort, and when a team member has to go around to each member and say “I need to discuss Task X, are you working on it?”, that creates waste and inefficiency.  Worse, someone starts the task and then forgets about it, but that would eventually  show up as one of the bad smells relating to a task staying “In Progress” for too long.

Bad Smell: Sprint Backlog not highly visible.

Highly visible does not mean an 8.5 X 11 sheet of paper or a web site.  Highly visible means something at least about 24″ X 24″, posted near the location of the Daily Scrum.  Hand draw it if you have to — most experts prefer that method anyway.  Don’t let the cool drawing features of Excel or some other Agile reporting tool seduce you.  It’s not worth your time unless it can be printed BIG!

Bad Smell: Double entry of Sprint Backlog into a tool.

If your team finds itself entering all of your Sprint Backlog tasks into a tool AND recording and tracking them on a board somewhere, you might want to stop and consider whether this is valuable or not.  For remote teams, it is sometimes valuable, but for most teams, chances are it is waste.  Tracking at the Story or Product Backlog level in a tool is often valuable, but tracking such minute tasks in both places (tool and board) is often wasted time and effort.

Bad Smell: Team working way out of line with priority.

This one is rare.  Once a team begins a sprint, technically there is no order to the stories.  It’s up to the team to optimize on which stories to work on.   However, when one of the high priority or critical path stories gets totally ignored for the first few days of the sprint, discuss it as a potential impediment.   Also in the beginning of a sprint, beware if folks immediately jump to the lowest priority stories.

Bad Smell:  Too many team members on a single story. (Overswarming)

I often hear new Scrum teams thinking they can all swarm on a single story.  Swarming is an advanced technique, and to do well, requires certain conditions to be true (highly cross functional team, non trivial story size, highly collocated team members, etc).  Don’t be smelly by just assuming your team can swarm on every story all of the time.  First, work diligently on setting the right conditions for swarming.  Then, try it it sparingly at first, starting with at least 2 team members per story, then working your way up to more team members.  Eventually you’ll bump into the “too many chefs in the kitchen” problem, but your team will learn the right balance over time and begin to do “smart swarming.”  Some people associate Swarming with attacking the highest priority stories first — I cover that concept under the bad smell titled “Team working way out of line with priority.”  See Mike Cohn’s blog entry for more info on Overswarming: http://blog.mountaingoatsoftware.com/should-a-team-swarm-on-to-one-backlog-item-at-a-time

Bad Smell: Team members dispersed across too many stories at one time. (Dispersing)

Dispersing is the opposite of Overswarming.  Team members march off into their silos and each work on a different story, never teaming up to get a story done.  This is a throwback to the old Command and Control days of software development, which means the strategy comes with much of the baggage of that kind of approach (bottlenecking, code dictatorship(“my code”), blamestorming, tribal knowledge, etc).  See the “Overswarming” bad smell for tips on how to grow your team into a place where they can do “smart swarming.”

Bad Smell: Story stays 90% done for several days.

The story that never closes.  It happens a lot with new teams.  Someone on the team needs to take to pick up the “closure football” and run that baby across the goal line.  The ScrumMaster(or any team member, of course) can help here by identifying the impediment and then asking someone if they will take the lead in getting closure.

If you need to combat some of these bad smells,  check out the relevant Sprint Planning chapters in Mike Cohn’s book, Agile Estimating and Planning .

May the Sprint be with you. 🙂

© 2010 Charles Bradley.  All Rights Reserved.

About the author:Mr Bradley is an experienced Scrum Coach, Certified ScrumMaster, and Certified Professional ScrumMaster I.  In addition to his Scrum credentials, Mr. Bradley is also a highly capable, full lifecycle experienced, software development team lead that prefers XP for good engineering practices.   He is Sun Certified in Java, and has  13 years of experience in J2EE application development across all tiers.  More recently he has also picked up some good C# experience as well.  In his spare time, he enjoys driving his wife crazy by talking about Scrum, especially when he refers to his “honey do” list as his “personal backlog” and asks his wife to prioritize her requests.  He lives in Denver, Colorado, and he is easily found on LinkedIn.

Bad Smells of the Daily Scrum

Are your Daily Scrums not satisfying you?  Does something just feel wrong?  Maybe your Daily Scrum has a bad smell.  I define a “bad smell” as any symptom in a process that possibly indicates a deeper problem.  It doesn’t always mean the bad smell is indicative of a true problem, but most times it is.

Bad Smell:  Discussions or Trying to Resolve Obstacles in the Daily Scrum
Identifying obstacles in the Daily Scrum is ok, trying to resolve them is generally not.  A better way to handle obstacle resolution is to have informal follow-on conversations with those that have an interest in resolving the obstacle.  Some teams simply keep a list of identified obstacles.  Then when the Daily Scrum is officially over, they immediately go into a recurring “obstacle resolution” meeting.  In the obstacle resolution meeting, members are free to sit down, find a conference room, or just stay standing by their Scrum board.  Hopefully someone on your team is good at managing these obstacle meetings (often the ScrumMaster).  Some ScrumMasters will prioritize the obstacles discussions by those that require the most people in attendance, and then work their way down the list until there is really no need for a large group to assemble.  It is important, though, the obstacles get resolved.

Bad Smell:  Obstacles Identified in Daily Scrum but rarely solved in any reasonable time frame
It’s important that someone makes sure obstacles are removed.  If no one else on the The Team takes the lead in this, then the responsibility falls upon the ScrumMaster as “obstacle remover in chief.”  I coach teams and ScrumMasters to encourage individual Team members to take the lead in resolving their own obstacles, as they’re often the most likely decision makers anyways.

Bad Smell:  Always Postponing Obstacle Identification until Daily Scrum
New Scrum teams often decide that if they find an obstacle at 2pm, they’ll wait until the Daily Scrum (and possible follow on obstacle meeting) to identify and attempt resolution.  This is extremely inefficient.  The better practice is for that team member to round up the right people on their team and try to resolve the obstacle immediately.  You’ll notice this bad smell when your list of obstacles in the Daily Scrum starts to be large.

Bad Smell:  Team updates tasks on Scrum board during Daily Scrum
This one is really stinky.  Updating tasks during the Daily Scrum is a bad practice because a) chances are you did not just finish that task, so the board has been out of date for hours, and b) your task update will not be reflected in the Sprint Burndown.  Just think, if everyone did this, your Sprint Burndown would always be 2-12 hours behind, and be inaccurate by a large margin.  The Sprint Burndown is meant to be current at least once a day, and the Daily Scrum is the perfect time to optimize and refocus based on what the burndown is telling you.  Many teams make a policy that the burndown is updated by a certain time, usually 15 minutes to an hour or so before the Daily Scrum, so someone has the time to update the Burndown and the team will be looking at near real time data in the Daily Scrum.

Bad Smell:  Burndown not highly visible at Daily Scrum
This one is also stinky.  How do you know if the team is probably ahead or probably behind?  Sometimes the board will indicate this, but sometimes it won’t.  Make it visible, and hopefully you’re not thinking an 8.5 X 11 sheet of paper is “highly visible”.  That’s better than no burndown at all, but a 2ft by 2ft or larger display is what I consider highly visible.  Other burndown tips:  Keep it simple, do it with marker and paper or on a whiteboard, experiment with multiple types of burndowns, plot it manually, and don’t feel like you have to have a discussion about the burndown every day.  If your actual burndown is within your ideal number(assuming you burn down hours) by 10-15%, then there is no reason to make a big deal about it.

Bad Smell:  The PO never attends the Daily Scrum
Ok, so the Scrum Guide doesn’t say the PO has to attend the Daily Scrum.  That’s true, but I consider it a bad smell when the PO never comes to it.  They should at least try to attend 2-3 times a week.  The best PO’s come every day they are possibly available, and they usually also report status in the “Yesterday, Today, Obstacles” format as well.

Bad Smell:  Team Member X seems to go on forever during the Daily Scrum
It happens, some people are longwinded, mostly a carryover from old school daily staff meetings.  Some teams decide to add the word “done” to their format, so it becomes “What I got done yesterday, What I will get done today, and What obstacles are in the way of me getting to done.”  The point of the three questions is to give a summary, not every last detail.  Some teams set a maximum time limit for each person, so that could work too.  One suggestion I give to new teams is to have the ScrumMaster hold up a yellow card (or sticky) when someone seems to be getting too detailed or breaking some other rule of the Daily Scrum.  One of the reasons this might be occurring is because the Team has broken so many other rules of the Daily Scrum (having discussions, resolving obstacles) that this person feels it’s just fine and peachy to be longwinded since everyone else is.

Bad Smell:  No one prevents the meeting from getting off focus or being too long
This is probably the stinkiest of them all.  Short and sweet, that should be the goal.  The ultimate responsibility for this falls on the ScrumMaster’s shoulders, but like everything else, The Team itself is also responsible for optimizing their Daily Scrum, so any team member can act to make sure the meeting stays on focus, not just the ScrumMaster.

May the Sprint be with you. 🙂

© 2010 Charles Bradley.  All Rights Reserved.

About the author:Mr Bradley is an experienced Scrum Coach, Certified ScrumMaster, and Certified Professional ScrumMaster I.  In addition to his Scrum credentials, Mr. Bradley is also a highly capable, full lifecycle experienced, software development team lead that prefers XP for good engineering practices.   He is Sun Certified in Java, and has  13 years of experience in J2EE application development across all tiers.  More recently he has also picked up some good C# experience as well.  In his spare time, he enjoys driving his wife crazy by talking about Scrum, especially when he refers to his “honey do” list as his “personal backlog” and asks his wife to prioritize her requests.  He lives in Denver, Colorado, and he is easily found on LinkedIn.

%d bloggers like this: