Posts Tagged: project management


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?


18
Oct 10

Focusing on Value

Esther Derby recommends you focus on value, not on costs:

“A small engineering firm axed the company lunch room and eliminated over $200,000 per year in costs. That gave an immediate boost to the bottom line. [... however,] A more insidious side-effect was invisible (at least on the balance sheet) for several months.”

Read her full post to see what havoc this cost saving effort did to the company.


16
Sep 10

Do something right?

When you want something done right -the saying goes- do it yourself.

But how would the corollary go? If you want someone else to do it right, do you: a) exhaustively document how to do it -or- b) have an open, honest, and regular conversation with them?

My next question: if your practices do not line up with your answer, why not?


12
Sep 10

What is fixed? Quality or Time?

Ken Schwaber was contemplating team dynamics: they were taking on too much work in hopes of meeting a time frame. The deadline (time) was fixed and the features (scope) were fixed, and the outcome was that regression testing, performance testing and unit tests, were skipped (quality).

Of course, everyone says quality is the #1 priority, but given the triad of time, scope, and quality – how do people act?

My experience is that a deadline is set first (time is priority #1), then what can be done in that time is ascertained (scope is priority #2), and then the unit test, regression tests, etc slide (quality is priority #3) to ensure the time & scope are met.

I don’t think this is malicious — it is just that when you’re focused on the short term, a missed deadline is much more visible than a missed quality goal. Technical deficit issues with quality can hide for months or even years without ever being caught – so naturally they get a low priority.

My advice: If you want to think in the long term, set the quality standard first and set the deadline second. Missed scope can be addressed in the next iteration, but missed quality may never get fixed till your whole system crashes.


8
Sep 10

On Documentation

George Dinwiddie:

“Why is documentation so important to us? It’s because we’re used to using documents to carry our thoughts and ideas to other people, other places, other times. Documents are good at the “other places, other times” part. Documents can be good at transporting ideas to “other people,” but it’s really hard work.”

When you are on a team that is co-located, it’s a lot easier to have a simple face-to-face conversation. Time spent creating a document and time spend understanding a document are all to waste if it ultimately falls back on a conversation to clarify the original intent.

My suggestion: start with the conversation. Then, evaluate what is lost in translation. I’m guessing you will find that the conversation is far more accurate in transporting ideas than a document — and it takes a fraction of the time to complete.