Creating the Agile Workplace

March 31, 2009 by devinhedge

I recently rolled off a project where I used the Scrum version of agile development methodologies for a government client. The irony was that the program office hated it, the security auditors hated it, and the government client loved it. Why? We got stuff done. The underlying principles for getting mission capabilities implemented rapidly were:

• We (the client and the team) are naive if we think we know what we really want
• We are naive if we think we will get it right the first time
• The needs of the government will always be evolving as policy changes occur, legislative mandates are created, and/or we learn how to do stuff (e.g. business process optimization, system re-factorization, organizational restructuring, etc.) better.
• We will use light-weight governance for requirements management
• All system requirements must be mapped to business requirements or they are thrown-out
• All business requirements must be mapped to a specific capability or it is thrown-out
• All capabilities are mapped must be mapped to the higher-organization's Vision, a policy change, a legislative mandates, or a target of opportunity for doing stuff better
• We will bake in security from the beginning
• We will build-it using automated testing
• We will bake in quality from the beginning

Instead of taking months/years to deploy system changes, we were able to vett changes in two-week increments and deliver testable capabilities every two-weeks. Once the system met the "good enough" test from the clients, it was released into the organization. Coming back to the present, HBR is running an article that highlights where Japan's Shinsei Bank is using IT as a lauchpad for growth instead of IT being a constraint on business optimzation efforts.

"Instead of building systems that are legacy from the day they are turned on, managers can and should develop systems that can be improved—rapidly and continuously—well after they’ve gone live."

There is no doubt that the system we build for the government met this criteria. From the article,

"The approach’s premises are that it is difficult and costly to map out all requirements before a project starts because people often cannot specify everything they’ll need beforehand. Also, unanticipated needs almost always arise once a system is in operation. And persuading people to use and 'own' the system after it is up and running is much easier said than done."

Exactly!

So when you pull out that PMI PMBOK and it talks about locking down scope, don't ignore two things: 1) Change is a constant, and 2) in the Monitoring and Controlling process group, don't forget about the Integrated Change Control processes. You have to bake in Integrated Change Control up front. You have to get everyone to agree that the only constant is Change (and your weekly burn rate).

I'll talk about best practices around cost management in another article when I get around to it.

Permalink