Empirical vs. Defined or Prescriptive Process
In his book Agile and Iterative Development-A Manager's Guide, Craig Larman compares defined processes, which are suitable for predictable manufacturing domains, with empirical processes, which are used for high-change and unstable domains. When I read this it immediately made sense based on my earliest experiences with software project management.
My first experience was development of a Visual Basic client application to monitor and report on translation projects. I had two developers and I was the subject matter expert as well as the project manager. I followed an agile method without even knowing what it was. I wrote the user stories, built simple screen mockups, and prioritized features for rapid delivery and testing.
My next experience involved a much larger project, a web application for facilities management, and a large team from a contracted development service provider. We used the contractor's project methodology, which was a very formal, document-intensive process. At the end of the analysis phase (after 6 months) we had multiple 2-inch thick binders full of requirements documents and diagrams. These requirements then fed into a development phase (another 6 months). At the end of development, all evidence indicated we were going to get little of what we had hoped to get at a higher cost than budgeted and a much lower quality level (in terms of usability and performance) than would be acceptable to our users.
This is an over-simplification, but after the second experience, around 2001, I began reading about agile methodologies and recognized their value. By the time I got hold of Larman's book in 2004, I inherently understood the points he made about the nature of software development and the fact than an empirical process made much more sense in that domain than a prescriptive process.
My first experience was development of a Visual Basic client application to monitor and report on translation projects. I had two developers and I was the subject matter expert as well as the project manager. I followed an agile method without even knowing what it was. I wrote the user stories, built simple screen mockups, and prioritized features for rapid delivery and testing.
My next experience involved a much larger project, a web application for facilities management, and a large team from a contracted development service provider. We used the contractor's project methodology, which was a very formal, document-intensive process. At the end of the analysis phase (after 6 months) we had multiple 2-inch thick binders full of requirements documents and diagrams. These requirements then fed into a development phase (another 6 months). At the end of development, all evidence indicated we were going to get little of what we had hoped to get at a higher cost than budgeted and a much lower quality level (in terms of usability and performance) than would be acceptable to our users.
This is an over-simplification, but after the second experience, around 2001, I began reading about agile methodologies and recognized their value. By the time I got hold of Larman's book in 2004, I inherently understood the points he made about the nature of software development and the fact than an empirical process made much more sense in that domain than a prescriptive process.
Comments