Conventional versus Agile Approaches
4. MW: Your slide #6 (see Figure 2) is a good illustration of the impossibility of both "Conventional" and "Agile" approaches.
Figure 2: Difference of Approach
If, under Conventional", time and/or cost are allegedly fixed (as they often are), then the only "relief" is to cut back on "Features" - or leave something unfinished (as they also often are!)
PMcB: I love that - the impossibility of both approaches! Of course, we are discussing academic approaches, not real life stuff. These values are as much aspirational as anything else. We should strive for them, but they probably cannot be achieved perfectly.
5. MW: However, under "Agile" the illustration is telling me that: "Just tell me how much money and/or time I've got and we'll deliver what we can. Depending on the competence of the team, that may be more or less. The redeeming feature of Agile is, of course, that it only applies to software development and similar type projects, and stresses the need for "iterative" development. It's a bit like building a cathedral in the old days - one arch at a time. If it stands up, we'll build another one, and so on until the money or time runs out. But, given the presence of technological perfectionists, how will the Sponsor know if they are getting good value for money?
PMcB: Value for money is one of the primary values of Agile. By delivering the REALLY IMPORTANT functionality first, fast and "good enough", the organization gets its real needs met. The rest of the effort is to add features, functions etc. that add value, and only those that add value. The leadership team is mandated with making sure there is value for money. Don't trust that team? Don't start the project.
|
Roles and Responsibilities
