Jeff Patton has a good reminder:
“The design process that supports delivering a great design document is not the same process that supports delivering a great product.”
Posts Tagged: enterprise software
30
Oct 10
Deliver Product, not Process
28
Oct 10
Communication as a Deliverable
One more post from Liz:
“If the BA above was a piece of software, her users would be filing bug reports, working around her, and using her competitors instead.”
In Who are your Users? she contemplates the general state of command and control, and how the system is not really set up to offer feedback on various forms of communication (like design documents or requirements documents), and as such it is hard for them to get better.
24
Oct 10
The only constant is change
Liz Keogh in Change, and keep changing:
“There is no end-state with Agile or Lean. You’ll be improving, and continue to improve, trying new things out and discarding the ones which don’t work.”
This is what appeals to me about agile. It isn’t a destination, it is a mindset of improving continuously. I look at corporate waterfall processes, and the thing that hurts the process far more than anything else is that it is considered to be a complete and well-rounded, immutable process.
The problem is that it doesn’t work well in every situation. Facts confront the reality (yet another project delivered late and over budget!), but process isn’t blamed … the people are. “You were not following the process as closely as you should.” is the common explanation you hear. “We need better documentation!” is another. But these strike me as a rather inhumane approach. Do you really want to blame your own people (of whom you would like to remain productive, and have been added to the staff at considerable cost) when the evidence suggests that it is the process that is broken?
22
Sep 09
Documentation
Jim Highsmith wrote: “Documentation is often the solution to a communications problem that can’t be corrected with documentation.”
I found this to be a good reminder. I mean, the point of documentation is a simple one isn’t it? To convey ideas and intent clearly and without ambiguity. We write it down because we can’t remember long enough or clearly enough, or we don’t trust the people we are working with enough. (“I asked for X” “I thought you asked for Y” “well, let’s go look at the document!”)
If we worked in smaller iterations (with people we trust), our need for documentation would decrease exponentially. With contract thinking (ie, everything must be written down and signed) increases project cost by 30-50%. That’s a lot of waste for a problem that is pretty easy to solve.
I suppose there is a secondary purpose to documentation that focuses on tracking the history of an item. But let’s be honest – how many times do you go back and look at project documentation after it has been released into production? In my experience, the more detailed the document, the faster it becomes irrelevant and unhelpful.
15
Jun 09
Ignore Sunk Costs
Seth writes:
“When making a choice between two options, only consider what’s going to happen in the future, not which investments you’ve made in the past. The past investments are over, lost, gone forever. They are irrelevant to the future.”
I agree. Too many bad things happen when people insist on preserving the past only because they paid a lot for it. It might be painful, but sometimes you have to true up and say: That might have been a good decision when it was first made, but it is not a good decision today. Be honest with yourself, and embrace the change.
monthly email
RSS 2.0