A typical show will feature a couple who have recently purchased a promising but run-down house which they plan to rebuild, refurbish and sell on at a healthy markup. They stand against a backdrop of peeling plaster and outline their vision for the property, while Ms Beeny listens politely. When they’re finished she will ask them about their proposed budget and timescale, both of which are invariably wildly optimistic.

What’s interesting is what Ms Beeny then does not do. She doesn’t simply note down the couple’s ideas, do some drawings, go off and talk to some tradesmen and then come back with a quote, asking the couple what they wish to reconsider.

Instead she probes the couple’s real motivators – do they want to rent out the property or sell it? Might they live in it themselves? What logic lies behind their original plan? She then uses her experience as a developer to suggest better solutions which maximise the potential of the property – enlarging boxrooms to create bedrooms, controlling expenditure on bathrooms and kitchens, choosing decor tailored towards the target market for that type of dwelling.

If you’re involved in the world of software product development then you may have already spotted the parallels here. As a profession we are regularly faced with clients or colleagues whose vision matches neither their available resources nor their true business needs. We are not helping them if we simply accept their ‘requirements’, passively note them down and then pass them on for estimation, before coming back to talk about ‘descoping’. Instead we should try to understand their fundamental problems and use our knowledge and experience to help them find more affordable and appropriate solutions.

Of course the most entertaining aspect of the show is that the property owners often ignore Ms Beeny’s sage advice, falling in love with Italian marble floors, plate glass walls, cast iron baths and other dazzling architectural innovations not necessarily compatible with turning around a terraced property in Rotherham within two months before unloading it onto a cash-conscious young family. During the long property boom of the noughties the rising market had a frustrating habit of rescuing the budding real estate tycoons, but latterly the financial consequences of building the wrong thing have become more perilous. In other types of development they almost invariably are.

Boxer was the admiration of everybody. He had been a hard worker even in Jones’s time, but now he seemed more like three horses than one; there were days when the entire work of the farm seemed to rest on his mighty shoulders. From morning to night he was pushing and pulling, always at the spot where the work was hardest. He had made an arrangement with one of the cockerels to call him in the mornings half an hour earlier than anyone else, and would put in some volunteer labour at whatever seemed to be most needed, before the regular day’s work began. His answer to every problem, every setback, was “I will work harder!”–which he had adopted as his personal motto.

Sadly Boxer is not a young horse, and as the dream turns sour he works himself to the point of collapse, at which point the pigs who run the farm under the Stalinesque figure of Napoleon have him unceremoniously shipped off to the knackers’ yard.

I’m always reminded of Boxer when I see a team who appear to be trapped in a cycle of project failure and whose suggestions for improvement are to keep doing the same things, but try harder at them. The project didn’t go according to plan? Next time we’ll have an even more detailed plan. The requirements kept changing? Next time we’ll spend longer writing requirements before we start. Estimates weren’t accurate? Then we should put more effort into estimation. And so on.

Now I’m not knocking hard work or a willingness to improve, but I don’t recall ever seeing a project fail through lack of effort. If things keep going awry then it suggests there is something fundamentally wrong in the approach being taken. Perhaps in the context of the organisation requirements flux is inevitable, and a switch to a faster release cycle developing just a handful of requirements at once would help. If lack of accuracy in upfront planning and estimation is a problem then it would be better to understand and accept the limitations of such exercises, and think about ways to work around them. If code quality is persistently poor then perhaps there is an underlying architectural issue which no amount of testing will resolve. If you’re in a hole, stop digging.

Remember Boxer’s gluey fate. If it’s broke then fix it. Don’t just ‘work harder’.

Unfortunately my experience is that these metrics often fail to achieve what they intend. People spend a lot of time creating spreadsheets which draw impressive charts, but whenever these are presented at a planning meeting they are met with a sea of glazed-over eyes. The numbers don’t tell anybody anything.

I’ve often wondered why this is. I find that I can subjectively judge progress on a project quite accurately, so why is it so difficult to quantify objectively? Indeed I once got badly tripped up in a job interview over this very question.

Going back to first principles, we should perhaps define ‘progress on a project’. From my perspective it’s a question of how much you have done versus how much you still have to do to fulfil the vision, and how that looks in terms of the available time and effort. In a traditional waterfall project the target is quite clear, to deliver a fixed set of requirements by a certain date. Unfortunately you never know what you’ve actually achieved, nothing is built, tested and integrated, all you often have are a load of obscure tasks to which inane ‘percentage complete’ guesses are attached. In an agile project the situation is reversed – you know exactly what you have achieved, you have working and tested software in the bank. What you don’t understand so clearly is what you still have to do, as by definition the scope of the project is flexible.

In theory the agile answer to this conundrum is release planning – you estimate items on the backlog to arrive at an achievable target list of features to deliver in a given number of iterations, and thus obtain the information to create the classic burn-down chart. The problem is that given the level of story information available at this stage effort estimation is very difficult, so it is hard to arrive at a reasonable starting ‘height’ for the burn-down.

However when I’m asked to judge progress subjectively I can do it because, as the person in charge of the backlog, I know in my own mind what we still have to do, what the priorities are and what feature trade-offs I will be prepared to make to hit the target date. Now clearly, many heads are better than one and it would be preferred if the whole team had this appreciation. Which suggests to me that the aim of release planning should not be to generate metric targets, but to enable everybody to understand what lies ahead and what the finished product needs to look like. It seems like a good illustration of process not being a substitute for understanding.

For almost 50 of the 75 years from the War of the Austrian Succession in 1740 to the downfall of Napoleon in 1815 Britain was at war with France, wrestling for commercial and imperial supremacy and battling the threat of invasion. As an island nation with only a tiny army success and security rested heavily on the performance of the navy, and the navy responded magnificently. A gallery of iconic admirals produced a string of towering victories, culminating in the crushing triumph at Trafalgar in 1805 architected by the greatest of them all, Admiral Lord Nelson.

How did they do it? First of all practice made perfect. Being in action for so long kept them sharp, and no British seaman in this period could avoid collecting a string of hard-won battle scars.

Then it was about people. By the standards of the time (and certainly compared to the army) the Navy was a ruthless meritocracy. Traditionally younger siblings or the sons of distressed gentlefolk, naval officers joined the service as young boys and had to earn promotion up the ladder. To receive a command they usually had to be good, and if they weren’t good they might well end up dead. The ordinary crewmen are often portrayed as press-ganged victims cowering under the lash, but in fact they were usually highly experienced seamen, treated well compared to those of other nations, and keenly motivated by the lure of prize money from captured enemy ships.

High competence led to success after success, and a culture emerged of confidence, aggression and elan. Napoleon ordered his admirals around as though sailing fleets were armies on land. Nelson knew the limits of control; before each of his great battles he made sure sure his captains knew his overall strategy and then let them get on with their jobs. “No captain can do very wrong who places his ship alongside that of an enemy” he told them, a reflection of his belief that in a straight fight any given British ship would always defeat any given French ship.

The results speak for themselves. Tellingly the only significant reverses suffered in this period were against the Americans in war of 1812, operating as they did according to similar lights. But in the long years of peace that followed Waterloo the edge was inevitably lost. Queen Victoria’s navy became synonymous with stiff-necked formality, leading ultimately to a famous peacetime disaster and even, in the opinion of some historians, some less than Nelsonic performances during WW1.

Okay, so what does this have to do with the modern world of software product development? For me the lessons of Nelson’s navy have universal application:

• Men make ships. Recruit and retain the best people you possibly can.
• Maintain morale. Demand the highest standards, and reward people for achieving them.
• Keep busy. Without the need to be regularly delivering end product, atrophy sets in.
• Manage appropriately. Set your team on the right course, then trust their professionalism.

“Never mind manoeuvres”, was one piece of advice Nelson gave to his subordinates, ”always go at ‘em”. A dictum that would not look at all out of place in the Agile manifesto.

Now, ‘user buys a book’ is a huge epic of a story. On any bookstore site you’ve got the page which displays information about the book, you’ve got several screens of complex shopping cart functionality, you’ve got email receipts, hooks into the backoffice, etc. Starting at the beginning, your first story might be ‘Show book information’. Suppose your UI prototype is this screenshot from Amazon:

There’s an awful lot going on just on that page. What’s the most basic information you could include in ‘Show Book Information’? How about the title, author, and perhaps the front cover image? That will do for our first story. I would actually photoshop my screenshot and stick it to the front of the story card:

While my acceptance criteria would look like this:

There’s a number of things to note here. I started the acceptance script with ‘go directly to the url..’. That’s because at this early stage of the project I’m presuming there’s no way to search or browse to that page. I didn’t include price in this basic initial set of information. You might think that’s fairly fundamental, but my guess would be that the price is stored in a more complex piece of the backend that we aren’t talking to yet. I have included the cover image, assuming that is straightforward. These are all things I would know by talking to my developers. Adding the price would likely be my next story:

One temptation to avoid is putting dead links and buttons to things you haven’t developed yet. It would be no work to add the button which says ‘add to shopping basket’ at this stage – but it wouldn’t go anywhere. Doing this violates the principle of always having shippable software. Suppose we decide we have enough to beta the site as a kind of catalogue, without purchasing facilities – in that case we don’t want buttons to non-existent ecommerce sequences to appear. That may seem pretty obvious – but it’s quite easy to imagine buttons like ‘Tell A Friend’ or ‘Add to Wish List’ appearing on a live release before anyone remembers those features didn’t make the cut. I’d add the button when I do the story ‘Add book to Shopping Cart’:

I think a lot of people might say here that I’m going too far, and these stories are too small. For a lot of situations they might be, I used to produce stories this size when working with teams whose iterations were only 1 week long. But I think the basic principle is sound. You can almost always break things down – If there’s a tangible result and you can establish good acceptance criteria then it can be a story.

In the situations where I have worked there’s far, far too much going on there for one story, but in any event I wouldn’t write the acceptance criteria that way. My version would look much more like a UAT script:

That’s a much more detailed description of what the story should do. It’s more effort to write, but for me when I’m writing the story is when I want to put the effort in, and when I have all the information in my head. Come the end of the iteration, I have a pile of stories waiting to be signed off and I don’t want to spending time figuring out how to test ‘verify cancellation’ or whatever.

This type of ‘do this – see that’ script reminds me of the long-running British TV show Catchphrase, and host Roy Walker’s constant exhortation to ‘say what you see’.