Getting Things Done




The strategies for getting things done vary. (Continued)

Multi-Release Burnup




Sad Statements

I hope this will be done by then.

These are sad and scary words to me.  When I hear them in the context of a software development project, I associate them with a project unlikely to meet expectations.  Further, it’s likely that there is no good indicator of what can be delivered when.  With no hard evidence to tell them what’s possible, and to judge the effects of changes they try, people fall back on a strategy of hope. They no longer feel in control of the situation.

We’ve done our part.

This signals the underlying hopelessness. When you can’t make things come out the way you want, when you can’t even predict how they will come out, one natural response is to give up. Often the cultural expectations don’t allow saying “this project is in trouble.” The person who does so is the person who will attract all the scrutiny. Without the clear data to back up the perception of trouble, why stick your neck out? Others should be noticing the same thing; let them call attention to it. And when things don’t work out as “hoped,” if weve “done our part,” then someone else will get the blame.

You can’t solve a problem that no one wants to see. Instead, we’ve found an acceptable way to fail.

5 Minutes to Process Improvement Success



A Virtue of Imprecise Measurements


My advice is to

  • measure your progress
  • watch the trends
  • project the trends tentatively into the future




It’s something to think about.


3 Legs to Running an Agile Transition


Projecting into the Future

In my recent posting on estimation precision, I briefly mentioned how you can estimate when certain features will be done, or estimate what features will be done by a given date, using a burn-up chart.  Some people don’t find this an obvious and easy thing to do.  Let me explain in more detail.

I’ll start with the assumption that you have a list of features you want to add to an application.  Some of the things you want to add may not be properly called features–they might be bug fixes, for example.  And the application might be brand-new, with zero functionality so far.  That’s OK, we can handle cases like that.  Let’s walk through how I do this… (Continued)

Tracking your investments

The world is slowly recovering from a major financial meltdown.  People blame the collapse on a number of different things: a bubble of inflated housing prices, relaxed requirements for qualifying for a mortgage, predatory lending practices, greed on the part of mortgage companies and investment banks….  There are certainly many places to point fingers.  Each of these places, however, was doing what seemed logical when looking at a small piece of the puzzle.

As is often the case, we must back up and take a larger systemic view to see further.  Once upon a time, people borrowed money to buy a house, paid it back over time, and ultimately the bank was able to lend that money to someone else.  With the creation of the FNMA (Fannie Mae) in 1938, the income streams of those mortgages being repaid were converted to bonds, so that they could be sold to other investors and the banks to re-lend their money more frequently.  This allowed many more people to afford houses.  In the 1970s, private banks got into the business of creating their own bonds based on debt repayment streams.

Nothing ever stands still, of course.  People continued to look for new wrinkles on these themes to allow them to expand the business, or to increase the profit on the business they had.  Some of these investment vehicles got very complicated, intended only for professional bankers who could understand and evaluate them where the mass public could not.  Or, so went the pitch at the time. (Continued)

DIY Project/Process Evaluation Kit




And here it is: (Continued)

Agility and Predictability

I was reading the latest post on Johanna Rothman’s Managing Product Development blog.  In it she says,

Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction that’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by–the first possible, optimistic date.

I like that characterization of the predicted date.  Another characterization, usually true of serial lifeycles, is that the predicted delivery date is the first day of schedule slip.  I’ve seen many serial projects get almost to that date before they first admit that they’re in trouble. (Continued)