Paul Boos

For all, I am working with an Agile coach I met through this past year’s Agile Coach Camp to create a repository/search mechanism for Agile Adoption Experiences, Stories, Or Parables (Agile AESOP for short). I think one of the issues he and I both agree with standard case studies is trying to understand the context and can that context apply to yours. Agile AESOP will try and help guide you to finding things in similar context to yours and how well it worked. We want to know about Agile Adoption failures as well as successes. So I may want to come looking around to you folks when we get things up and running…

Here are two very quick results for the cases I had…

USDA Scrum usage:

By obtaining high customer involvement and regularly having good functional slices implemented so we could demo the product, we were able to deliver one application early at a savings of $69K; that may not sound like a lot until I mention it was only a $170K development project in the first place. For another application project (several hundred $K), we delivered on time and within budget by constantly working the scope and cutting out unneeded features (basically lowering the priority and placing them into the backlog) with the customer. Using velocity we could project that we had to constantly work the scope to ensure we would make it (it had a fixed immobile deadline). This was a web-based GIS application.

Here at OPP, everyone was always blaming the maintenance developers for being slow in getting bugs resolved or new features added. By using Kanban, we could see that our biggest constraints were the approval of the SCRs for work (though we never said “no”) and acceptance testing by users at the end. We also could see that users were not working with us to get the developers the answers they needed on requirements or clarifications. This highlighting alone made the use of Kanban worthwhile as it focused us on addressing the real reasons things weren’t being delivered in a timely manner and not passing things into a black box of blame.

I’ll close though, Agile is not a silver bullet; what it does do is highlight the problems/impediments quicker so you can get to resolving them. In the traditional phase-gate approach known as Waterfall, you often don’t discover the issues until the end. The traditional approach gives you the illusion of control over things you don’t have control over; the Agile approach gives you regular feedback so you can sense and respond.

PS – why wasn’t this discussion placed in the Agile Development group? Was it because you wanted non-software development examples?