Author: Dot Tudor and George A. Walter
Date: 2006-07-10

Case Study: Agile Approach in a Traditional Organization

Step 1: OCLC Meets DSDM

OCLC became ISO 9000 and TickIT certified in 1998 and has a long history of repeatable software development processes derived through a strong quality Assurance Organization. The "traditional" or waterfall approach to software development was well entrenched, and supported, by a system of policies, procedures, and templates: the overall approach was generally standardized across all project teams working in the Dublin, Ohio Company. After going through the process of documenting our Software Development procedures (over-documenting them as it turned out), solving the document control issues, and keeping all the records necessary to retain our ISO certification, we did not want to implement a method that would conflict with the changes we had made in our culture. During my research into Rapid Application Development (RAD) methods (we did not use the term Agile at the time), I came across a publication entitled "The Dynamic Systems Development Method and TickIT". This publication provided a guide to reconciling the requirements of ISO 9000 with the procedures used for DSDM - but what on earth was DSDM?

Step 2: Does it really work that way?

I established that DSDM (Dynamic Systems Development Method) was an incremental development approach, promising on-time delivery, short increments and it seemed to be strong on user satisfaction. "That's for us!" I thought. I set off on the trail of this DSDM approach. I identified some training, but it all seemed to be in England. Further research persuaded me that this approach really could help us, and it that it would be worth the trip to a 3-day course in Cheshire, UK for Accredited DSDM training with a local company, TCC.

After all, I could combine it with a spot of golf, and visit my ancestral home in Scotland after the class.

Driving from Manchester Airport, down roads barely wide enough for one car, let alone for two to pass, I arrived at the hotel where the course was running, a typical "olde worlde" English building (Figure 1).

The course began. Dot Tudor was the tutor. In addition to her considerable project experience with DSDM, she clearly had a passion for the DSDM approach. "With DSDM, we WILL deliver on time - every time! We WILL stay within budget! We WILL give you what the business needs!" I must have said something like "Would you care to come over to Ohio and prove it?" And so the road to DSDM began for OCLC.

I'm an avid believer in the iterative approach, and in delivering on-time by prioritizing which features you deliver in relation to business need. Requirements will always change: new ones will emerge; and while we are building our software the world will just "move on" so that what we first envisioned will be just plain wrong! Why not involve the users throughout the development of their products. If we were making a suit of clothes for a customer and delivering it 6 months later, we wouldn't expect our first measurement to still be perfect 6 months later (especially if the project spanned the festive season) so we would have regular "fitting" sessions. DSDM does the same - involving the right users and testing throughout the life-cycle. Yes, I am passionate about this. I've spent too many years using a structured, waterfall approach and trying to specify and estimate every requirement up front - some things are just not possible or sensible, however we try to deceive ourselves.

With DSDM, requirements can be agreed at a high level and prioritized in relation to their business importance. DSDM uses the acronym MoSCoW to focus the prioritization of requirements: M(ust have) for those requirements which it would be impossible to manage without; S(hould have) for requirements which, although important, we could work around in some way and manage without for at least a while; C(ould have) for requirements which would add business benefit but are not essential; and W(ont have) for requirements which have been discussed, but it has been agreed to drop for the current deliverable (increment) in order to focus on the more important ones. DSDM also relies on the use of a timeboxed schedule - planning work into specific periods of time (usually between 2 and 6 weeks) in which they either will happen or be dropped. Any timebox must have an element of Must, Should and Could, to give flexibility to drop something non-essential if time is running out.