I found about 10 years ago that everything I delivered in software took me 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. So if you have stable requirements and a pushbutton deployment toolchain, then x3 is about right. If you haven’t, x5 is probably closer.
I note 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.
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?
Alan Gawthorpe & I a talk last month on doing architecture with agile teams:
We did the session agile-style: We had cards for our topics, and the ‘customers’ in the audience prioritised. I think it worked okay, it would probably go smoother doing it a second time. Some of the significant books & articles that went into the slides were:
Agile Methodologies for the Enterprise
* Scott Ambler & Mark Lines – Disciplined Agile Delivery
* Scott’s whitepaper on Agile@Scale
What does a technical architecture for agile look like?
* Coplien & Bjørnvig, Lean Architecture for Agile Software Development
* Poppendieck & Poppendieck, Lean Software Development: An Agile Toolkit
The further reading list
* George Fairbanks, Just Enough Software Architecture
* The UK government’s national audit office report on Agile Governance
A friend of name, a teenage actor, asked me about SEO stuff earlier today. She has a website and was concerned it wasn’t rising up the rankings very well.
Using a third party website site doesn’t give you a huge amount of control but the basics are the same under any circumstances: You need a page with information on the topic at hand; and you want other websites to link to it. I originally had Rachel’s name in the title of this post, but since she’s now dominating the rankings for here name, I guessed it was no longer necessary! It does help if you have a name like Rachel Kevern though – shared by only a handful of other people in the world 😉
In 2013 I saw Rachel acting & singing in Les Miserables and also saw her singing last night as part of The Voice. Which was excellent! After that, she got the role of Vi, the Reverend’s wife in Footloose, at the Z-arts centre in Manchester. Find her at http://rachelkevernactor.wix.com/rachelkevern.
If a team or organisation wants to adopt agile, should they do it all in one, or gradually? How do you overcome problems in agile adoption?
Agile Principles when Adopting Agile
Agile is not about process and methodology; it’s about people, relationships and learning and so turns out to be very much democratic and consensus based. Effective adoption presupposes that you’ve got the team(s) on board; if you have to impose agile, you’re probably doing it wrong. You can’t adopt faster than your teams and individuals are motivated to adopt.
If you apply the agile manifesto to the project of ‘adopt agile’ then you’d adopt agile incrementally, of course. I suggest an obvious principle: You can’t adopt faster than you can learn.
Agile’s take on organisation & adjustment is that teams self-organise with regular reflection, which enables you to see what’s not going well and consider ways to correct. There is no learning without feedback. Adopt incrementally with regular reflection and adjustment.
Agile teams puts work items in priority order, in to deliver the greatest business value first. Look at your current pain points – what’s not working well – and find out which practices are found to address them. Prioritise changes which add most value.
Risk management is arguably a missing subject in agile, so let’s add that here: soberly consider what, at this stage, you are capable of adopting successfully. First adopting practises you’re capable of to maximise your chance of early success. The choice to deliver value or to attack risk first is a judgement call. When you’re doing something new the risk of failure is high, so that judgement is largely about knowing how new to your team(s) the changes you’re making really are.
Finally, agile starts with the vision of a wider community learning. Any fool can learn from their mistakes but the wise learn from others’ mistakes too. In the past 10 years, others have already tried out all the mistakes for you. Call in someone in who’s done it before.