My Agile Team: More Code, More Problems
Originally published on AgileSoftwareDevelopment.com
Welcome to the newest installment of My Agile Team, my team’s ongoing series of misadventures in trying to get better at Agile development. This time around, we’re still playing Whack-A-Mole on the list of bugs we’ve encountered since Go Live. We stomp one out, another pops up.
What I’m going to discuss this time is our approach to trying to fix these critical bugs while maintaining at least a semblance of our Agile nature. It’s hard to do a planning meeting and decide on what to work on when you’ve got new things popping up and old things dragging on. Read on for more on how we’re planning in the midst of firefighting production bugs.
Bugs incoming!
We did a lot of user testing. I mean a lot. The app is a billing system for an insurance company and 4-6 members of the billing team worked overtime for months to go over the system with as fine of a toothed comb as they could muster. And still, when we went live we started having problems we’ve never seen before. Billing in insurance is complicated and it’s not until you have to live with the decisions you made in development interacting with real people and real situations that you start seeing some stuff, there’s just no way around it.
Planning with fire
The question is, how do we plan for this? We’re trying to keep on the Scrum path and plan but as I mentioned last time, our “Top Priority” / Critical list is now 10 items. As soon as we get rid of one of them, another pops up and since it has to do with people’s money our Product Owner labels them critical. What we’ve been doing is using the critical list as our Product Backlog. We’re still not in the habit of estimating the size of the items the way we’d like to, but with most of these things we don’t know what they are until we get into them anyway. So we basically take the list of critical bugs and split them up based on who originally worked in that area and how much bandwidth people have. Giving people items in the area they worked on is really just to help speed up the process since hopefully the person with the knowledge already in their head will get a faster jump on things. Since these are by definition weird bugs though (if they weren’t weird we’d have seen them before) sometimes prior knowledge doesn’t help.
The Red Queen’s Race
The problem of course comes in between planning meetings when new critical things come up. Since to our Product Owner everything that’s critical needs to be fixed now, there’s not much we can do to re-prioritize. Some things are obvious but most stuff just goes on the list to fix as fast as we can. This is what I mean by Whack-A-Mole, we knock them down but there’s always new ones in their place.
The Finish Line?
At this point we’re just hoping the point where we stop finding new critical things comes soon. Our manager took our extremely rough time estimates and told the company that meant we would be done with everything in 2 months so we’re all shooting for that goal. Any comments from me about this will have to come over beer. :)
Agile Much?
At this point I realize that this series hasn’t exactly been All Agile, All The Time as much as I wish it were. I’m doing my best to keep our team and these articles informative and focused on Agile but it’s been difficult. I’m trying to make sure reading about our progress (or lack thereof) isn’t as hard as actually living it but I also think it’s valuable to see somebody else’s story, even when it’s a lot of running in place. I really, really hope that we make progress in the coming weeks and I have better things to write about next time. Thank you for reading and if you’ve kept up with this series, thank you even more.
If you have questions for me or suggestions for something you’d like to see me write about our team, I’d love to hear it in the comments below. Thanks again.
You should follow me on Twitter here!
|
|
