Agile: Bugs

Agile can make things work for your process, you can get a ton done, but one question everyone has is “What about bugs?” or “What about things that come up during the sprint?” Oh noes!! Agile can’t handle it.. Agile will fail us.. fear not..

  • If you can, wait till next sprint
    Of course, if you can wait, wait. Don’t interrupt the current sprint, don’t get in the way of your do’ers focus, wait on it, assess it, analyze it, verify it, validate it, make sure you understand it instead of jumping in quickly and screwing something else up. Most times unless it is a HUGE showstopper, you *can* wait.
  • If you must, handle it. Swap something out
    If you can’t wait, then you should swap something out. You can’t just keep adding things to the current sprint, you will overfill your capacity. You need to swap something out. If this is a critical bug, it must be more important than *something* on your current sprint (that you haven’t started yet). If you are near the end of the sprint, then wait till next sprint.
  • If not a bug, but a request – First Option
    if it isn’t a bug, but a high priority request, you know the ones, from the president or god or you know. Well, then the first thing you can do is go to that user and say “Hey, we can do this, but we are going to move something out of the sprint that you requested.” If they say “Hey, no way, I want it all done”, then you respond “That isn’t the way it works, you need to move something out to move something in, or you need to wait and see if we get ahead where we *might* be able to pull something in, is that acceptable?” and then you think to yourself “someday these users will learn to think farther out than 2 days in front of their face”
  • If not a bug, but a request – Second Option
    So if you get this “god” request that *must* be done, but the user doesn’t have any existing stories to pull out, well here is what you do. You need to find a comparable story from someone else to pull out, and then you have to get that person, and the requester together and ask “Hey person we already committed to, is it ok if this other guys request bumps you out of the queue/sprint?” and if the person is ok with it (they usually are) then you can swap, if not, well, tough luck to the late request, they need to wait. (You can see from this process you need to learn to say “No”.
  • Last Resort
    the last resort, and I hate this option, but it seems it usually is the one that gets done the most. You just do the request. You fit it in, you work late, you do something different or something else takes a hit. The person gets there request, but no one learns from the process, since they think they can still request anything at anytime and get something from you, instead of learning to plan out a bit.

I’m sure there are infinite permutations of things you can do and situations you need and will need to deal with. The above is just a broad look at some the more recurring situations.

What you can learn from Bugs or Requests that need to be done *now!* is this:

There is always a way to adjust and handle things. Nothing is written in concrete. “Responding to change over following a plan”

Advertisements

2 thoughts on “Agile: Bugs”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s