Posts Tagged: agile

Main — Comments Off
17
Nov 10

Avoid the Big Bang

Johanna on Incremental Progress Not Big Bang:

“The problem is that the more big-bang you are, the less likely you will get everything you want. That’s because there’s a ton of work in progress, and that it’s hard to be omniscient about how your architecture will work in practice.”

I think this point gets over-looked far to much. The more stuff you keep up in the air (in progress), the less certain completion will be what you were expecting. Make your iterations shorter and you’ll get to guide your project more to your liking.

Main — Comments Off
30
Oct 10

Deliver Product, not Process

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.”

Main — Comments Off
26
Oct 10

Estimation anti-patterns

Liz Keogh writes about Estimation anti-patterns. My favorite one:

Presenter: How tall am I?
Crowd:5′8″! 5′9″! 2 metres!
Presenter: Go on, you can manage more than that. How tall am I?
Crowd: 6′2″?
Presenter: Come on! You can do better than that! HOW TALL AM I?
Crowd: (Giggles nervously.)
Presenter: Just because a project manager tells you you can do more, it doesn’t make it true.

If you’ve ever felt burned by an estimate, you’ll enjoy the levity.

Main — 1 Comment
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?

Main — 1 Comment
16
Oct 10

Things take the time they take

In an interview with Jerry Weinberg:

“Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.”

I absolutely agree! When you push for a project to complete faster, something has to give. And more often than not, it is the quality that suffers because that’s the easiest cutback to hide in the short term.

Jerry is an author of more than 40 books, including “The Psychology of Computer Programming” and “Introduction to General Systems Thinking” and was the Manager of Operating Systems Development in the Project Mercury (1959–1963), which aimed to put a human in orbit around the Earth. (Thank you Wikipedia!)

← Older Entries