Avoiding "The Iron Triangle"

#apereo13

Transcript

1. Avoiding “The Iron Triangle” John A. Lewis Chief Software Architect Unicon, Inc. 29 July 2010 © Copyright Unicon, Inc., 2010. Some rights reserved. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/us/
2. 2 The Iron Triangle
3. 3 Iron Triangle Constraints • Interrelated constraints of Scope, Schedule, and Resources. • Change in one of these constraints has a necessary effect on one or both of the others. • If out of balance then one or more of them must change/break. • Or the resulting quality is destroyed by artificially meeting the constraints by cutting corners.
4. 4 Crux Of The Problem • Real crux of the problem: It is easy, even unavoidable, for the constraints to be out of balance at the beginning of a project. • To make matters worse, they can get more out of balance as the project proceeds. • Many reasons for this problem that all stem for them fact that we have only limited ability to control, or even truly understand, all three constraints and the relationships between them.
5. 5 Constraint: Scope • False Premise: One can detail how complex software should work before it is built. • Conditions that control Scope tend to change: – Understanding of the domain evolves. – Business has new ideas on project. – Underlying needs/priorities shift. • Waterfall projects lock scope at the beginning and intentionally make it hard to change. • Successful projects must accept & embrace significant changes in scope as they proceed.
6. 6 Constraint: Schedule • Estimating software development is highly imprecise. • We never build the same thing twice! “Construction” analogies are false. • Still need to estimate, but use estimates properly. Useful for planning and baseline, but not as guarantee or promise. • Given that scope is likely to change, detailed estimates aren't valuable anyway.
7. 7 Constraint: Resources • Most predictable/controllable constraint. • Mostly people, some hardware/software. • Need motivated, qualified people with good chemistry. • Avoid “Mythical Man Month” thinking: – "Adding manpower to a late software project makes it later." – Larger teams have diminishing, even negative, returns. • Can use agile to parallelize work, but this still adds overhead and has costs
8. 8 The Elastic Triangle • Reality: Must allow at least one of the points of the triangle to vary, making it “elastic”. • Hard to accept, since it means uncertainty. • Which to vary? – Resources easiest to control, and changes have negative impact, so lock this in. – Allow either scope or schedule, or both, to vary as best suits the project. • Overall, flexibility and quickly adapting to change is the key to project success.
9. 9 Questions & Answers John A. Lewis Chief Software Architect Unicon, Inc. jlewis@unicon.net www.unicon.net