Update: Picked up on a thread on TheServerSide, so there may be some more discussion over there.
In my experience (and more so that of my more experienced colleagues) there are five variables over which you can exert control to decide when – and with what functionality – you can deliver your software.
In simple terms, if you deliver less functionality, it will take you less time. The problem is that often the decision as to what not to deliver happens during the development process itself. This means that prioritisation of functionality from the outset is important. if half way through you need to cut scope, but the only stuff you have left is the stuff your users simply must have, and you spent the last three months delivering things they’d only like to have, your options are limited. Priorities can change, but core functionality tends not too – concentrate on delivering that and you’ll make it easier for yourself in the long run.
Typically the thing over which technical people have the least control (anecdotally it seems as though the go-live date for software is defined more by sales and marketing than by need), but you can decide to deliver later to get what you want.
Adding more people to a project can make it faster – to a point. However in software adding people very rarely tends to result in a linear increase in productivity. Hiring the right people can be more efficient, but is far from easy.
Some organisations take the ‘lots of dumb people being told what to do by one or two smart people’ route, others the ‘a few smart people all knowing what to do’. I’m sure most of us (myself included) believe we hope for the later. I’ve certainly seen examples in the consultancy world where an organisation with a lower charge rate but lots of people ends up costing much more deliver than a small number of people with higher charge rates.
Reworking one’s process in order to be more efficient is an obvious thing to do, but hard to achieve. Depending on the flexibility of your organisation changing your process might not be easy, even if you know what it is to change. Changes mid-project – for example in order to deliver faster – tend to be limited, small changes. Retrospecitves can be a good tool for identifying what the team thinks is required, but don’t discount seeking outside help – someone from another team might have a different take on things.
A far more common type of process change occurs when people make what is often claimed to be short-term sacrifices in terms of software quality to deliver on time. Changes could involve writing less developer tests, spending less time performing manual tests, stop pairing, or spend less time ensuring consistent technical vision. When these changes really are short-term, and time is set aside afterwards to repair the damage done, this may be a viable technique. However those organisations which tend to drop quality in order to deliver faster tend to use this technique more than any other, and frequently never spend time playing catch up – leading to a team spending most of their time running from one disaster to another.
Risk Management is something I’m personally becoming aware of. Making sure you have situations in which potential risks can be raised is important (a daily stand-up might be one). Periodically risks should be assessed, in terms of how likely they are to occur, and also in terms of how much damage they can create.
Some risks can be mitigated, some eliminated entirely, and others cannot be addressed by you. In any case once prioritised in terms of likelihood and potential damage, they can be mitigated or communicated to your business sponsor accordingly.