drwill's bailiwick

General insights and product information by David R. Williamson, Senior Development Manager

Trying Scrum

Over the last several months, our team has decided to try all this “agile” stuff we keep hearing about.  In large part, our new manager is responsible for putting us on this course but many of us were curious with what it would offer and fed up with some of the problems we’d been perpetually dealing with.

My biggest pet peeve was the huge bug backlog we’d always acquire.  I always dreaded getting to code complete and then spending months just bug fixing.  The developers hated it as much as they loved spending all their time coding before code complete.  Overall I think devs were less happy with the pendulum swing facet of their work.  I thought they’d be much happier if they had balance in their life where it was always  a mix of bug fixing and feature work.  Plus, they wouldn’t have the feeling of dread associated with a massive bug backlog.

Going forward our goal was to keep bug counts to a minimum.

For QA, the feeling was almost opposite of dev.  While the feature work was interesting, they had a nagging feeling about the Pri2 and up bugs not being addressed.  They felt guilty and depressed that we might ship with those bugs.  “Why can’t we just fix them now?”  After code complete, they were finally content to start addressing the bug backlog.  Of course since the end of the release is imminent there’s always bugs that won’t get fixed due to what seemed to be some arbitrary date.  “Why can’t we just be quality driven for releases?”  In the end, QA was almost always discontent with the release.  It takes an SP1 to relieve the shame.  And why do dev and QA have to be at odds?  Don’t we both want the same thing ultimately?

Going forward our goal was to keep dev and QA in sync, working towards the same prize, and both driven for the same outcome.

We’ve been doing this for six sprints now and I’ve learned a lot about agile (small A as my manager reminds me since we’re following the spirit of Agile but not adopting every nuance of the methodology).  We’ve made tweaks each sprint, some minor, some major, to make it work for us.  Mostly, the engineers have embraced it but change isn’t always easy and it hasn’t been unusual to encounter resistance at the start.