Back in history, pre-Internet days, I was in charge of developing a new IT system to support Marketing. While this was a Marketing system, the sponsor, my boss, was in Finance. And to complicate things, Sales provided the funding! And they wanted us to be fast…in less than three months! That’s without having requirements, mind you. Obviously, time was of the essence and the traditional IT way of working, “back in 12 months with a solution”, would not work!
In true risk-taking fashion, and because of the more productive tools available, we picked client/server as the development and production environment instead of the mainframe. We could provide much more useful capabilities to our customers in, hopefully, a much faster way.
But how do we build something we don’t have requirements for in three months? While arguing with the boss that we needed more time was viable, that was also known as a CLM (Career Limiting Move). So I dove in, playing the role of data modeler. Oh, yes, we were not going to use the traditional waterfall methodology but would use Information Engineering (IE), a methodology developed by James Martin from IBM in the 1980s, to build it. If you are familiar with the Zachman architecture model, IE develops data models (data architecture) and process models (application architecture). Later on we found out that we needed business rules that IE did not include, so we captured our rules in what Zachman would consider a business architecture.
The data model allowed us to get a high-level picture of the data needed by the business, which then enabled us to determine what was the smallest delivery of value that we could give our customer. It took some negotiation with my boss, but we got the agreement.
With that initial priority, we refined the data and process models for the areas covered and turned them over to the developers, who promptly delivered a prototype and soon thereafter production code which we implemented. From start of project to first production: nine months. While the developers were working on the code, we refined the next set of priorities and models, ready to turn them over to development. Eventually, we reached a steady state that allowed us to develop three releases in parallel, delivering value on a monthly basis (each release took three months: one month in analysis/design, one month in code, one month in test/QA).
The benefits of this approach: we quickly and constantly delivered value to our customer; got feedback from them; allowed us to make the development manageable as analysis/design was done just before coding; and it allowed us to add or subtract from each release as necessary (minimal impact to our customers if we delayed something to the next release).
When we started, we didn’t know what we were doing and had to find our way as we went along. Now it is called Agile Project Management using Agile development methodologies. We knew we had found something powerful but had to wait until recently to see it in black and white.
While I’ve done other non-development activities since that client/server system, recently I’ve returned to the software development world and found out that waterfall is alive and doing well…and taking forever! Needless to say, I’ll be pushing for Agile in my current effort. Need to keep SOX compliance in mind, though…
So, how do you learn more about Agile? If you are in the software development world, a great source is the Agile Alliance at http://www.agilealliance.com. This site provides lots of good information on the methodologies. A good book is “Agile & Iterative Development: A Manager’s Guide” by Craig Larman. Craig provides an overview of the four most common Agile software development methodologies.
For all PMs, whether in the software world or not, a great reference is Jim Highsmith’s “Agile Project Management”. Jim is one of the founding members of the Agile Alliance but this book addresses Agile PM for all types of projects.
Based on my experience, Agile works. Has it worked for you?
PS Team culture and ability are critical. You need a team that is able to handle the uncertainty of not having all the requirements, all the design done before coding. Agile methodologies will help them handle this uncertainty as it provides them with a structure to understand what is going on.
