In this interview, Andy Berner of QSM talks about his upcoming presentation, the importance of keeping a well-groomed backlog, the pitfalls of the impossible zone, and why it's vital that you and your team keep your tools serving you and not the other way around.
Cameron Philipp-Edmonds: All right, today we have Andy Berner of QSM and he's going to be talking to us today about his session titled Grooming the Backlog: Plan the Work, Work the Plan. To start things off, thank you for joining us and can you tell us about yourself and your role at the company.
Andy Berner: Sure. Thanks Cameron. I've been with QSM a little over two years after many years with IBM Rational and several other companies before that. I guess I've been in this industry more years than maybe I care to admit. QSM is a company that provides consulting and tools for software estimation and project control. I'm on the development team for those tools, but I'm also focused on making sure that our tools keep up with new methodologies such as agile. QSM has been in business over thirty years and we've seen probably every methodology that exists. We try to make sure that our tools stay adaptable and up-to-date so that they can be used with modern methods.
We try to make sure that customers can tailor our tools to fit their agile environments. I'm also involved with integrations between our tools and other tools throughout the software life cycle.
Cameron: What led you to the idea of your session?
Andy: We've done a lot of research at QSM. We've been doing more and more research on the factors that make agile projects successful. One key factor that we found is making sure that there's enough time and efforts spent on getting the requirements right. Agile coaches recognize and even emphasize the importance of grooming the backlog but we've seen that there is less information available on what that work actually entails and how you plan and make sure that you have the resources that you need to do it.
We thought it would be valuable at the conference to say more than "you ought to just do it" and really help folks anticipate the resources and the effort that they'll need to put in. And be able to set the expectations on what's going to be needed to keep that backlog groomed.
Cameron: Your session covers the best practices and how to really just be super successful at grooming the backlog. Really, why is it important to groom the backlog?
Andy: It's incredibly important. Agile coders can really only stay as productive as the requirements that they're given. They have to have well-thought-out requirements at the start of each iteration. Vague requirements and requirements churn are just as much of a hindrance in agile projects as they are in any other kind of software development. It's especially difficult in agile because we get going right away. You always need a steady flow of groomed requirements. We don't have the luxury that you might have in some other methods of a big upfront requirement phase to get everything straightened out in advance, which of course causes inevitable delay in the development.
At least you have a chance to get some of that churn removed before the developers even see it. In agile, you have to keep at it iteration by iteration. If you don't keep the backlog groomed, the developers can't do their jobs.
Cameron: Now, you believe that after your session attendees will be able to take back to their team new ways to plan for a well-groomed backlog. As cited in your presentation summary, a well-groomed backlog is something you feel everyone's project and team deserves. Is it cruel and unusual punishment in this day and age to force a team to succumb to backlog chaos?
Andy: Absolutely, it is. Not getting requirements right has been the cause of chaos in software development for forever and that's still true with agile techniques. We talk in agile about embracing change but that's different from requirements churn where you're constantly changing what's demanded because you haven’t thought it out well in the first place. That churn is a productivity killer. Unlike the change that we know how to manage in agile, you don't want to keep changing because you haven't figured out what you're trying to do.
So, you can't just say it's up to the product owner to get it right. Bob Galen in some recent conferences has talked about it "taking a village" and discipline to keep the backlog groomed. Requirements have to meet the definition of ready, ready to be turned into working code and it's not fair to hold a team of great developers hostage to an undisciplined backlog.
Cameron: OK. So, it definitely is cruel and unusual punishment?
Andy: Yes, it is.