Agility

Every new system we build is by definition new, therefore not clearly defined, therefore subject to change.

During many years trying to develop massive princely systems, I always believed there was a more agile way.

From the agile manifesto, my personal top five:
1. Released development is the measure of progress.
2. Welcome changing requirements - even late in development.
3. The best architectures, requirements, and designs emerge from self-organizing teams.
4. Promote sustainable development - should be able to maintain a constant pace indefinitely.
5. Simplicity - minimizing the amount of work done.

And to prove this is the right approach - wherever a group is relatively free from red tape, as in some business units who happen to be independent of formal IT, this is how we develop.

Campaign Project and Stock Management

To maintain effective marketing, or to run effective projects, both require constant cycles of prediction and measurement.

For example, first you measure the current one, use that to plan and predict the next one. Measure that one. And so on.

Having been through plenty of campaigns and plenty of projects, I know there are some things that I can predict well. Perhaps an odd predilection for stats helps. Of course we all get some estimates wrong, but the more we do the better we estimate. And I've done loads.

But there are some things that I cannot predict. I cannot predict share prices without insider knowledge. So I agree with what Stephen Dubner wrote on Freakonomics a while back:

Here are a couple of stock-market headlines I’d love to read one day:
“Stocks Surge, Reasons Unknown; May Be Nothing More Than the Random Fluctuation of a Complex System”
or:
“Stocks Dive: Three First-Movers Sold Hard and Then Everyone Else Inexplicably Followed”

Of course, in the second case, if the first-movers sold hard, if you believe that others will also sell hard, then you should sensibly follow.

So my own investment strategy, still holding all my boom-bought shares as they go bust one by one, now it looks very foolish indeed.

Meeting Project Deadlines

Following a comment on my note yesterday.

There are no panaceas, only checks and balances and choices, while we hope that management has enough experience and insight to choose appropriately. By the way, insight and lateral thinking to me are just the identification of hidden variables, but that's another subject.

Anyway, no miracles, but these are five genuine ways to achieve deadlines, all that I have actually experienced.

1. Have everyone work ridiculous hours. Not just long hours, stupid hours. Say 8 a.m. to 10 p.m. actually in the office every day. Including weekends. And not just at launch time, but for month after month after month. But it was Wall Street.

2. Rent more equipment. At the same office as above, the client had a splendid approach to hardware issues. PC not working or running too slowly? Phone IT support pointing out that you are losing thousands of dollars in productivity and potential lost trades … and within an hour you could get a completely brand new one set up and running at your desk.

3. Recruit more short term staff. In the early 1990's I worked on a big government project, and the deadline was completely immovable because of legislative commitments. But because the wider economy was struggling, no shortage of skilled resource elsewhere, so a constantly growing team.

4. Shiftwork. At a utility company, where it was hard to persuade people and unions to work extended hours, and there was not enough flexibility to hire more PCs and desks. So we had one set of developers working 6 a.m. to 3 p.m. and another working from 2 p.m. to 10 p.m. Deliberately an hour of overlap for "handover" but that hour was chaos, remember not enough PCs and desks.

5. Compromise quality. I deliberately wrote that to sound harsh, but it is inevitable. Where you cannot grow the team or squeeze more out of the team or extend the deadline or change the specified deliverable, then "something" can usually be delivered on time, but that something will not match all of the prior expectations. Tough.

Estimating Project Delivery Time

I have spent a lot of my working life doing IT Project Estimation and IT Project Proposals, it is not the most interesting subject in the world, but it is important, and I touched upon it in an earlier post.

I could throw in a few key words used to manage the estimation, words like originality, uncertainty, statistics, experience, reductionism, but it would need thick volumes to explain them properly. What is interesting is why people keep getting their estimates wrong.

It is obvious that people tend to over-estimate their own abilities. That is such basic human nature and so well-documented that we may as well just call it fact.

But many people, even educated ones, seem to have trouble with simple extrapolation, even for things as commonplace as car journeys. The British Psychology Society just published a simple study that asked:

for both pairs, just make an intuitive judgement about which jump in speed will make the largest difference to your time of arrival (i.e. save the most time):

a)Travelling at 50km/h instead of 40km/h.
b)Travelling at 130km/h instead of 80km/h.

a)Travelling at 50km/h instead of 30km/h.
b)Travelling at 130km/h instead of 60km/h.

If you're like most of the participants in Svenson's study, you will have assumed that option (b) in both pairs is the most time saving.

That guess is simply wrong. In each case, option (a) saves more time. However far the journey.