Had enough of arguing about agile? Concerned that software development has been side-tracked by religious war? Keen to inject an element of pragmatism, not to mention fact-based-ness into the debates? Perhaps what you need is a New Deal at http://www.the-new-deal.org
Improving the accuracy of software project estimates: multiply everything by 3
I found when I'd worked in software for a couple of years that everything I delivered took me about three times longer than I expected.
Eventually I realised that my 'gut feel' for estimating a coding task was 'about how long will it take me to code this if I make no errors & get it right first go'. Which is a good starting point for an estimate, so long as you then go on to add testing, debugging, changing or misunderstanding requirements and time to release.
If you have stable requirements and a pushbutton deployment toolchain, then 3 x gut feel is may be about right. That covers clarification of requirements, testing, subsequent clarification of misunderstanding, and deploy.
If you haven't got those things, x5 or higher is usually closer.
I notice that others have found something similar. I'm please to find that multiplying by 3 puts me about 4.7% ahead of the curve - http://alistair.cockburn.us/The+magic+of+pi+for+project+managers.
Project Success vs Project Value
Somehow earlier this year I subscribed to the chaos report email. Given the significant criticism of chaos report's measure of success - on time, on spec, on budget - I was amused by this week's email which poses the question whether their success criteria are relevant. What the Standish group does have that most of us don't, is access to a large number of (unpublished and hence unverifiable) examples.
From the email: "Which is more important project success or project value? It turns out the project success and project value is orthogonal or at right angles to each other. The harder you strive for perfect success the lower your project value. The harder you strive for greater values the lower the success rate.
We know this because we have coded each of the 50,000 projects within the CHAOS Database a success rate and value rate. Each rate has a score from 0 to 100. By grouping the projects by organization we can come up with a ranking by success and value. We then can compare the rankings. One of the items we discuss is another question Is the traditional triple Constraints (cost, time, and quality) measurement still appropriate?"
I'm surprised by the assertion that success and value are orthogonal. I'd have thought that there was at least some connection between time/cost/functionality and perceived value; if the value of your project is not in the spec, surely you wrote the wrong spec?
Just Enough Design Upfront? How to draw the line between enough and too much
Earlier this year the term Hayim Makabee proposed the term 'Adaptable Design Up Front' as a way of pointing the way forwards between the Scylla of BDUF and the Charybdis of degenerating into a Ball of Mud.
Others have used the term 'Just Enough Design Up Front.' But what counts as just enough?
That's the wrong question. Because 'just enough' is an insight that misdirects you. Design is not a scalar quantity like length. There is no amount of up-front design that is the right amount. The question is, what are the useful bits of design to do up front?
And this is what 'Adaptable Design Up Front' addresses. What you must do up-front is support the change and development to come — usually growth or change in functionality — whilst nailing down the things that ought to be fixed: the invariants which give stability so that developers don't have to re-learn the system from scratch each day they come into work.
So the basic idea is this: you want just the up-front design that helps you to draw lines between things that will change frequently and things that remain stable over time.
So how to do it?
For the 3 minute kick-start, Hayim has an excellent set of slides to get you going. His 'architecture vs interior design' analogy and the idea of applying the open/closed principle at the architecture level hit that 'brilliantly simple' spot that make it all seem obvious in hindsight.
ADUF - Adaptable Design Up Front –Hayim Makabee
For more detail on designing for what changes vs. what stays stable, I seriously recommend Jim Coplien & Gertrud Bjørnvig's under-rated book Lean Architecture: for Agile Software Development which contains decades of hard thought and wisdom. They know the pitfalls on the way first-hand and they can help you navigate them. More important, they show how to prioritise the human factors in your technical architecture. Which, as every architect knows, is what really matters.