I’m at the opening keynote of the
Conference in Salt Lake City. Timothy Lister (co-author of
with Bears) is talking about software development and risk. The heading of
this post is the view he often has of the software development
lifecycle (he’s an arbitrator for software development disputes).
Lister doesn’t think much of CMM.
He shows a slide from the Software
Engineering Institute (the creators of CMM) with the simple heading
“No” over it. The problem he sees is the idea that, as you get more
mature, you gradually eliminate risk. You never eliminate
risk. Instead, as you get more mature, you take on more ambitious
projects, maintaining a steady, acceptable level of risk.
“A risk is any variable
on your project that, within its normal distribution of possible values,
could prove detrimental or even fatal to your project.” Lister has
never met an “unlucky” project. Every failure had people recognizing
that there were possible events that could doom the project, but they
didn’t plan for those events to happen.
Risk management and agile processes. Incrementalism is a great risk
management strategy. Risks are discovered, and addressed, early on.
And “on time, in budget, in scope” is not the
definition of success. The software still has to be enticing to
the market and get adopted. Software successes may well not be
on time, nor in budget, nor in scope. Software may be used for
decades; no one will remember the early problems, they will look
at how good it ended up being.
“We are not recording secretaries.” We talk about customer driven
development, but that’s really just giving up on doing our jobs,
and dumping it on the customer. The term “gathering requirements”
is terrible. You can’t “gather” them, except for real simple ones;
you have to “invent” requirements based on an understanding of
what the customer does and needs. For example, Google’s
“I’m Feeling Lucky” button is a user requirement that Google
clearly invented. It didn’t come from the customer.
Agility through your Peopleware goggles… “Nothing beats face-to-face.”
Conference calls (even video conferences) aren’t team meetings, they’re
multiple teams negotiating. Nothing will ever beat shoulder to
shoulder contact. Nothing beats working on only one project.
Nothing beats working hard, and then going home.
What’s at the intersection of Agility, Risk Management, and
Peopleware? An attempt to increase the chance of success. But
“the Dead Fish of Failure” sits on the table of far too many
projects from day one. And nobody wants to talk about it.
These projects are created to fail. Everybody smells the dead fish
right away, but everybody hunkers down even though they know they
will fail. They’re avoiding the individual blame, rather than seeking
success for the project. The project participants are not
The Joy of Success. It lets you: try hard; learn; experiment; have
pride. You’re willing to try, because you know you can succeed.
Lister doesn’t know how to fix this problem. We need a chance to
succeed, not a guarantee (“guarantees are for children”). Who
stands up and talks about the dead fish, and lets it be cleared out
so the project has a chance of success?