How do bugs fit into Scrum

Zero bugs; it's the nirvana we all strive for as software professionals, it's also unfortunately a myth. The only way to write code without bugs is to not write code. All software has bugs, it's simply of matter of how hard you look to find them. You'd like to think that the top companies somehow have come up with a way to create bug free software. After working at two of the biggest, Intel and Microsoft I can tell you they haven't figured out how to ship bug free code either.

Scrum isn't a magic process that doesn't have to deal with finding and fixing bugs. Like waterfall it focuses on the delivery of the product and with the product comes bugs. If you're using scrum how do you account for fixing the bugs that exist in your legacy product or dealing with the new ones you're creating as you write code this sprint.

Most of us should be familiar with bug triage and assigning severity and priority to bugs. All well and good but that doesn't get the bugs fixed and regression tested. I recommend an approach to assist with first managing the current load of existing bugs and to deal with any new bugs found.

1. If you aren't holding a weekly bug triage do this now. I've been on teams that didn't emphasize triage of bugs. It came back to bite them. As a scrum master on these teams my job is to facilitate and schedule these weekly triage meetings which is the first thing I did when encountering this issue. Second, make sure that you show up prepared with a query that can identify open high priority bugs, bugs awaiting triage bugs fixed but not verified, and all bugs that fail regression. This should give a quick look at the overall health of your product wrt bugs.
2. Now that you've got a regularly occurring bug triage meeting let's account for the time it takes to fix legacy bugs. On my past teams we've taken on the highest priority bugs during the sprint planning meeting by having a story for fixing the 'X' highest priority bugs. Note: this is an estimate, you will not be able to fix all of the bugs in the bug database. This bug "bucket" allows the team to carve out enough time for the highest priority bugs while still leaving time for the team to focus on features.
3. Developers are writing code during the current sprint, bugs are being created too. Your development team shouldn't be using the entire sprint to develop code, there has to be time to do testing and find/fix bug loop. If the team doesn't leave time to do this you will either ship low quality code and/or push technical debt into a future sprint. Which isn't good because the Product Owner is expecting the team to be ready to start the next set of features in the next sprint, not fix the left over issues from the last sprint.

Your mileage may vary but I've been relatively successful in keeping technical debt low, shipping high quality features, and meeting the needs of my team and customers using this technique.

Making the leap from Project Manager to Scrum Master

So you've gotten your certification from PMI as a certified Project Management Professional (PMP) but the world starts to change around you. Something new is on the horizon called agile software development and it's moving fast. Everywhere around you people are talking about it, it routinely shows up in job descriptions, and you feel woefully unprepared. First, don't panic. Today agile SDLC is gaining mind share among software professionals but in practice you still find waterfall SDLC deeply rooted. Even organizations that say they are doing agile are trying XP, Lean, or Scrum on a trial basis and often with a heavy overtone of waterfall processes.

Whew, you've still got time to prepare. So you ask yourself, how do I prepare myself for Agile SDLC. Fortunately there are courses you can take, books and blogs to read to get you better acquainted with this process. I recommend you start by reading blogs and books, it's by far the cheapest way to get an introduction. Attending a local meeting of an agile SIG can also introduce you to the terminology and ideas. I attend a local group that meets monthly to discuss a variety of agile topics. Everyone is welcome and there are no dumb questions.

One thing you need to be prepared for are some of the bigger differences between Waterfall and Agile. In Waterfall you don't do anything until all of the preparation is complete (MRD, PRD, Functional Specs, Technical Specs, Design Documents, Test Plans, Release Plans, and finally a schedule); in Agile (Scrum in this example) you follow the agile manifesto principles which value conversation over documentation and working software over a well written plan. I've heard agile documentation referred to as "Just in time documentation", meaning you don't write it unless it's absolutely needed. On my teams we often do this on a wiki to keep the information easy to access and easy to update by anyone on the team.

I've just scratched the surface on some of the differences between Project Manager and Scrum Master. More later.

Scrum with an absent Product Owner

What is scrum? Scrum is a set of principles/activities that allows a group to coordinate actions and deliverables so that something useful is delivered (has business value) when finished. It's also an agile process for delivering software.

Scrum to many is just a word that can conjure images either of complete anarchy or nirvana depending on your understanding of it. Scrum is successful when all involved coordinate based on roles on the team. You have your pigs and chickens as roles; you have your team member, scrum master and product owner roles as well. As team member on the team my role is to produce output that in it's entirety has business value. As a scrum master my role is to ensure the team meets daily, identify and remove impediments, and act as the liaison to the Product Owner. As the Product Owner I'm the one ultimately responsible for delivering business value to my stakeholders.

What happens to the team if the product owner role isn't filled or even worse has someone who only takes that responsibility semi seriously? For many teams they will overcome and in the short term be successful. Unfortunately in the long term they fail; mainly because they are focused on the sprint or next couple of sprints. There is no overall strategy or vision. A product owner who rarely shows up at daily standups or decides that attending the end of sprint review is optional for them is doing a dis-service to the team and ultimately to the company.

If you find yourself with an absent product owner I recommend taking action by talking to the product owner and letting them know the value that they add by being an active member of the team.