Zen and the Art of Software Quality - Jim Highsmith
When I arrived, Jim was talking about why we should not use the Standish Group Measures to evaluate software development success. The main reason he points is that the outcomes measured are outdated. They focus on projects that are on plan, on schedule and on features.
Meaning that a project that is delayed of a year but has a satisfied customer is a failed project.
A project that achieves an unexpected goal is a failure.
A project that delivers less feature in less time and stops is a failure.
Those are wrong concepts. Canceling a project soon enough is NOT a failure. It is a great success from an agile perspective. It means the client didn't waste his money for several months (or years) until he discovered he couldn't afford (or do) what he wanted to.
One of Jim's sentence that I liked is:
"Target high and miss
might be better than
target low and hit!"
What good is it to estimate every story as an epic story and manage to do it in 6 iterations while you could break the story in smaller ones and deliver 80% of the value in 1 iteration?
His suggestion from this scenario is that we shouldn't think about the old Cost-Scope-Schedule triangle as our variables in software development. That waterfall iron triangle should be replaced by an Agile Iron Triangle constituted of Value-Quality-Constraint where Constraint would be Cost-Scope-Schedule.
His idea is that those are constraints to software development. Variables related that fit in a greater picture. Our questioning should now be something like "how much value can we deliver given a certain level of quality and our constraints".
Jim explained then that there are "two kinds of Quality". An iextrinsic quality that is related to the quality imbued from value a given software has for a customer and an intrinsic quality. The intrinsic quality is closer to what we consider quality nowadays. It is the way the software is done. It is its bugless property, its simplicity, etc.
Separating those qualities help us understand something we already know. It is useless to produce the perfect software that solves nobody's problem.
Jim then defends what I understand as "fail fast". He argued that there is some point where cost outcomes value and that, at this point, the software development should be stopped. If we can pinpoint this moment, it is the best way to be have a good performance. If a feature is not worth being paid for, it should not be implemented. If no feature is worth being paid for then the development should stop. And it is NO failure if that happens in the middle of the original schedule. Quite the opposite!
Jim finished his talk mentioning the Parking Lot Diagram I reproduced below. The diagram very well known in FDD communities focuses on feature releasables. Meaning that, in opposition to the Gantt shart that focuses on tasks, the Parking Lot shows the features that can be released.
That was it. I've uploaded Jim's hand outs for more details.What I learned:
Revisiting some ideas that were pretty obvious can help refocus on what really matters. It is good to listen to the same ideas without having a brand (XP, Scrum, FDD, etc.).
Please leave your comments and ideas regarding this talk.
Next post will be about Alistair Cockburn's keynote.
Posts
No comments:
Post a Comment