Here’s the test question: You run a company that creates software in high level languages. You have a collection of developers who want to work for you. How do you sort the ones who are most suitable from the ones who are least suitable?

The answer is to query each one in turn using questions that most closely match the actual work they’ll be doing.

If you need them to design domain models then give them a toy domain and ask them to model it. If they need to work particularly closely with other developers then get them coding next to one of your current team. And if, for some perverse reason, company policy bans the use of software libraries and they have to implement every basic software function from scratch every time, then it’s a good idea to ask them to write a sorting algorithm.

But if that last situation is not true of your company, then the correct answer to “Show me how to sort an array x of integers” is “x.sort()”. Or some variant according to your local tongue.

If you get that question wrong, then unfortunately you fail, and miss out on some really excellent hires.

One major problem with targets comes about when they are different from the core thing the company is doing. For example, the number of features delivered by a software team may be a rough guide to their productivity, but is the team’s productivity really helping the customers get their widgets? As soon as you target the team members on this figure they will aim towards it to the exclusion of the end goal. You also end up creating or reinforcing a silo — suddenly the team is no longer interested in helping customers get widgets, it’s a team whose purpose is productivity, divorced from anything else.

A key phrase to watch out for is “is a proxy for”. For example, in a call centre: “Call duration is a proxy for resolved problems”. As soon as people are motivated towards a proxy the real target is forgotten.

At Øredev 2010 John Seddon gave an example of a service team whose managers thought they were meeting 100% of their targets, closing all their cases in 25 days or less. But the real work was not about closing cases; it was about resolving their customers’ problems. When they looked at the real activity that went on, they found that a single customer’s problem might be broken into four or more cases precisely because the staff were motivated by a 25 day case-closure time. From the customers’ point of view their problems were really taking 50 or 100 or 150 days to resolve. False targets obscured the reality and let an failing system remain in place. John says (at the 33:34 point):

If you hold people to account with arbitrary measures they learn to do anything to meet the arbitrary measures, and that is not the same as serving the customer.

There are other problems with performance targets, but that’s enough to be going on with.

When implementing a change of working a while back in my development team my boss of the time said, “Well, okay, but I want you to show me that your changes are making a difference”. What’s the metric for better software? I knew all about the dangers of measuring things like lines of code — that wouldn’t do anyone any good.

So I opted for something low-tech. I asked people. I asked team members and wider stakeholders once fortnight: “How are we doing?” I broke it down into ten questions, varying depending on the role of person and over time I could chart our progress. We went from around 30% satisfaction to 80% in four months and then plateaued. The plateau gnawed away at me, but by that time interest had moved on — the team was doing a great job and there were more pressing problems elsewhere.

I subsequently spoke to a programme manager who used a similar, but simpler, technique. He asked: “How would you score us out of five this month?” And then the follow-up question, if it wasn’t full marks… “What would we need to do to make it five?”

I much prefer this version, which is simpler, more direct, and there’s more clarity on what to do about the results. It reminds me of the guerilla approach to lean product development: putting a mock-up in front of someone in Starbucks and (eventually) asking “Would you buy this product? What would it take for you to buy it?”

I’ve used lots of other metrics for different things relating to performance, output and productivity: bugs resolved per week; lines of code per class, and so on. But I don’t think I’ve ever found any for this kind of thing which are so simple and connect the work and the output so effectively.

As part of a project some new requirements came in. I had been concerned that part of the system under development was a little complex, but not overly concerned, as it worked and had comprehensive automated tests.

But the new requirements changed that. They concerned a subsystem which took three inputs and processed them. The problem that the subsystem was trying to solve was roughly stated as follows:

We have an input stream which needs to be combined with two other input streams. But if some of the combining can’t take place because the input streams have gaps then we have to fill in the gaps from other sources. And then we can output the result.

If that seems a bit vague, it’s because it is: I hadn’t paid much attention to expressing the logic clearly.

The new requirement, meanwhile, was to add a fourth input. Since we were using a visual tool I can present the “as is” software design along with the “to be” that was the likely outcome of the requested changes:

The threatened “to be” state would have been excessively complex. Two things concerned me greatly. First was that I couldn’t keep all the “to be” logic in my head at one time, so didn’t have confidence that it was right. And second was that — as a guiding rule — software should be exactly as complex as the problem it attempts to address, and no more so… and that was not reflected here. My gut feeling was that the problem was simple, and adding one more input should have added linear complexity, but it felt like the complexity was growing exponentially. This was compounded by the fact that it was quite apparent there might soon be a fifth, sixth, or even seventh input.

The solution was to take a step back, express the logic of the problem clearly, and redesign the subsystem to reflect that. The problem, once clarified, became this:

We have a number of input streams which are merged. For each missing element of the merged stream we take action to fill it in. And then we output the result.

The refactored “as is” and the eventual “to be” logic became much simpler:

I hope you agree with me that the new flow is much clearer, and additional inputs add only linear complexity.

In terms of software development the sequence of steps was: (1) Make sure all the tests pass, (2) refactor the subsystem to reflect the new logic, (3) make sure all the tests still pass, (4) add the fourth input with appropriate tests.

For me this experience demonstrates a few things:

1. If software internals aren’t continually kept clean and of good quality then complexity increases excessively and progress slows accordingly. Or to put it another way, technical debt is very well named: the longer you neglect the debt the more interest you pay.
2. “Software should be exactly as complex as the problem it’s addressing” is a very good driver for reducing complexity.
3. Automated tests save the day again! The refactoring above would have been quite daunting and unreliable without them. But instead the worst thing about the operation was that it was a little time-consuming. It was not risky, it was not stressful, and it was not really that difficult.
4. Visual software development tools sure do expose messy software design for what it is.

I was thinking about this after reading Mark Foden’s excellent response to Sir Gus O’Donnell’s recent Telegraph article. If you’ve not read it, you should (Mark’s piece, but also the former Cabinet Secretary’s). The structure of Mark’s response is: (1) Sir Gus O’Donnell is another voice saying government needs to take more risks; (2) the truth is government needs to take fewer risks, which it can do through (3) trying things out in a small way and then learning and adapting, over and over again.

In fact this is a fascinating example of “what they say, and what we hear”. Here is a key part of Mark’s setup:

I infer a model of thinking that goes: The old ideas aren’t working any more… so we need to be innovative and adopt radical new ones… because the ideas are new we don’t know what will happen so this is risky… but we have no choice so that’s OK… if things go wrong we must be mature and learn from the failure rather than throw stones… next time we will know better.

When I looked for those words in the Telegraph article I couldn’t find them. And then I realised why: I was caught out by “I infer…”. Sir Gus didn’t say those words, but Mark heard them (or, more correctly, heard an echo of them).

Similarly there are many times when I’ve heard CEOs and others saying “we must take more risks”. And in retrospect, I think they didn’t actually say that — at least not in the way most of us understand it.

When we hear business leaders talking about taking more risks what they are actually saying is: we must move out of our comfort zone. More broadly they are saying: we have become stuck in our old ways, and become too comfortable, while the world around us has changed; the old certainties are no longer with us so we must work without the old systems that grew out of those old certainties.

And of course, working without old certainties feels like taking more risks. Indeed, less certainty is one key part of risk. (The other is undesirable consequences.)

If you gave pressured CEOs a hard choice between increased risks and a change in the way things get done, I think most of them would opt for the latter.

So many organisations are being disrupted — by digital startups, the internet generally, the economic downturn… The civil service is just one of these. Most leaders facing these problems do not want to increase the risk profile of their organisation. What they want is to sweep away their organisation’s old systems and embrace new ones. That might seem risky to some, but it doesn’t need to be.

To use an analogy: If you meet someone who will only ever cross roads at a pelican crossing then you might see them as someone who is stuck using old, time-consuming methods. They might see you a maverick risk-taker. But if you teach them the Green Cross Code they may learn that there are other ways of achieving their ends without taking undue risks.

Gus O’Donnell did indeed use the phrase “take more risks”, but he used it in the context of breaking away from cumbersome systems of red tape, and so I think he meant it more in the sense of moving out of a comfort zone. He also referenced one of the two keys to success that Mark mentioned: learning from experience. So I don’t think he and Mark are very far apart — if indeed they differ on anything much.

Similarly staff who hear their bosses say “take more risks” might want to reconsider what’s actually being said. Usually it will be: let’s do things differently.

Here goes…

Question 1: “Zeebox is now live” said PaidContent in October. “Appearing initially as a TV EPG, it shows users information, apps and further downloads about shows they are watching, creates live hyperlinks out of material discussed in shows and lets users both follow show-based social network chat and see what their friends are watching.”

Which former BBC iPlayer head is one of its two founders?

Answer: Anthony Rose

Question 2: From the New York Times:

So what took so long? Apple and [company] have been in talks for months trying to resolve issues that came up last year when the companies disagreed about [company]’s integration with Ping, Apple’s music-focused social network. Since then they have been caught in a stalemate over disagreements on coming projects.

But their iPad app finally launched in October. Which company is [company]?

Answer: Facebook

Question 3:

…And now suddenly we are living in that future. That future which only yesterday was the future now today is the present. [...] Where were you on Sept. 22, 2011, when the world changed? I, unfortunately, was holed up in my grubby little office in a small town in Massachusetts. Nevertheless, I will never forget this day. Never. Ever. How could I? This is the day when [feature] was introduced. [Feature]! It is, in a word, profound. Deeply, profoundly profound, in fact. “[Company] Just Schooled the Internet. Again” is how MG Siegler put it on TechCrunch. Which is a pretty amazing feat, coming as it does just a year and a half after “[Company] Just Seized Control of the Internet” as MG Siegler wrote in April 2010. It is pretty amazing, after all, to seize control of the Internet. That was bad-ass enough. But to then school the Internet that you’ve seized control of? Who but [Company] could do that? Good Lord I have to sit down and just think for a minute because my mind is reeling …

That was Real Dan Lyons implausibly over-excited about the announcements from which company’s annual conference?

Answer: Facebook, again, who announced Timelines and more at F8.

Question 4: What is the double- (or is it triple?) punning name of the tech startup recruitment fair that took place in May and October in East London?

Answer: Silicon Milkroundabout

Question 5: Here is a proposal from Mike Butcher:

You know what the problem with London is? It’s expensive. When you want to hire five rockstar coders (some prefer “gentleman coders” bizarrely. cc. Tariq Krim / Emi Gal) from Estonia or Budapest or wherever, you can do so – but they can’t even afford to move to London. So let’s requisition – nay, let’s storm “The Bastille” of those athlete villages after the games and claim a few blocks for the tech people. Can you imagine block upon block of innovative people housed so close together? That is your next Facebook or Google right there.

What is the UK government’s name for the East London development he’s talking about?

Answer: Tech City

Question 6: Here’s Mike Arrington, demonstrating his trademark compassion and empathy:

Suddenly everyone’s complaining about how unfair things are in Silicon Valley. How hard everyone has to work so darn hard, and how some people don’t get venture capital or a nice sale to Facebook or Google even though lots of other people are getting those things. [...] If you work at a startup and you think you’re working too hard and sacrificing too much, find a job somewhere else that will cater to your needs. [...] Work hard. Cry less. And realize you’re part of history.

…which was prompted by employee upset at which 4 1/2 year old, 1,600-person Silicon Valley startup?

Answer: Zynga, where “those who do not perform can perish”, according to the New York Times.

Question 7: Here is a story from Forbes:

In December 2009 Jobs beckoned Houston (pronounced like the New York City street, not the Texas city) and his partner, Arash Ferdowsi, for a meeting at his Cupertino office. “I mean, Steve friggin’ Jobs,” remembers Houston, now 28. “How do you even prepare for that?” When Houston whipped out his laptop for a demo, Jobs, in his signature jeans and black turtleneck, coolly waved him away: “I know what you do.”

What service do Houston and Ferdowsi run, which they refused to sell to Jobs, and to which Apple then responded by building its own competing service?

Answer: Dropbox, against which Apple compete with iCloud.

Question 8: Here’s the start of a story in Businessweek:

About five years ago, Apple design guru Jony Ive decided he wanted a new feature for the next MacBook: a small dot of green light above the screen, shining through the computer’s aluminum casing to indicate when its camera was on. The problem? It’s physically impossible to shine light through metal.

Fortunately the laws of physics are no barrier to Apple. What technology did Apple buy up in bulk to enable the green light to be seen?

Answer: Lasers. Hundreds of them, provided exclusively to Apple, and normally going for $250,000 each.

Question 9: “Apple does a great job. We need to improve our game and our products to take over the leadership position. Apple could go past [us] in 2012. We will try to become the champion in 2013. It will take time for the products that I have influence on to make it to the market.”

The new CEO of which company admits defeat, if only for the short term?

Answer: Meg Whitman, incoming CEO of HP.

Question 10: Oracle issues a scathing statement…

Either Mr. Lynch has a very poor memory or he’s lying.  ‘Some bank’ did not just happen to come to Oracle with [company] ‘on a list.’  The truth is that Mr. Lynch came to Oracle, along with his investment banker, Frank Quattrone, and met with Oracle’s head of M&A, Douglas Kehring and Oracle President Mark Hurd at 11 am on April 1, 2011.  After listening to Mr. Lynch’s PowerPoint slide sales pitch to sell [company] to Oracle, Mr. Kehring and Mr. Hurd told Mr. Lynch that with a current market value of $6 billion, [company] was already extremely over-priced.  The Lynch shopping visit to Oracle is easy to verify.  We still have his PowerPoint slides.

…hitting out at which British company?

Answer: Autonomy, which had just been bought by HP.

Question 11: Which company launched Qwikster… and then swiftly unlaunched it in the face of hostile customer reaction?

Answer: Netflix, which tried to disrupt itself. Cutting edge business theory confounded by old-fashioned reality.

Question 12: Computer Weekly reported:

The Department for Work and Pensions (DWP) has signed a seven-year contract with IBM worth £75m per year to provide systems, which will include the delivery of its flagship [redacted] programme.

What is the name of the programme?

Answer: Universal Credit, costing over £2bn, and one of the largest projects to use Agile techniques.

Did you have fun? Probably more than Leo Apotheker…

Normal service to this blog resumes soon.

So here is a quiz of the tech world in 2011. It’s entirely partial, with all the questions coming from links I’ve previously found interesting and posted to this blog.

Answers after the (festive) break.

Launches…

Question 1: “Zeebox is now live” said PaidContent in October. “Appearing initially as a TV EPG, it shows users information, apps and further downloads about shows they are watching, creates live hyperlinks out of material discussed in shows and lets users both follow show-based social network chat and see what their friends are watching.”

Which former BBC iPlayer head is one of its two founders?

Question 2: From the New York Times:

So what took so long? Apple and [company] have been in talks for months trying to resolve issues that came up last year when the companies disagreed about [company]’s integration with Ping, Apple’s music-focused social network. Since then they have been caught in a stalemate over disagreements on coming projects.

But their iPad app finally launched in October. Which company is [company]?

Question 3:

…And now suddenly we are living in that future. That future which only yesterday was the future now today is the present. [...] Where were you on Sept. 22, 2011, when the world changed? I, unfortunately, was holed up in my grubby little office in a small town in Massachusetts. Nevertheless, I will never forget this day. Never. Ever. How could I? This is the day when [feature] was introduced. [Feature]! It is, in a word, profound. Deeply, profoundly profound, in fact. “[Company] Just Schooled the Internet. Again” is how MG Siegler put it on TechCrunch. Which is a pretty amazing feat, coming as it does just a year and a half after “[Company] Just Seized Control of the Internet” as MG Siegler wrote in April 2010. It is pretty amazing, after all, to seize control of the Internet. That was bad-ass enough. But to then school the Internet that you’ve seized control of? Who but [Company] could do that? Good Lord I have to sit down and just think for a minute because my mind is reeling …

That was Real Dan Lyons implausibly over-excited about the announcements from which company’s annual conference?

Startups…

Question 4: What is the double- (or is it triple?) punning name of the tech startup recruitment fair that took place in May and October in East London?

Question 5: Here is a proposal from Mike Butcher:

You know what the problem with London is? It’s expensive. When you want to hire five rockstar coders (some prefer “gentleman coders” bizarrely. cc. Tariq Krim / Emi Gal) from Estonia or Budapest or wherever, you can do so – but they can’t even afford to move to London. So let’s requisition – nay, let’s storm “The Bastille” of those athlete villages after the games and claim a few blocks for the tech people. Can you imagine block upon block of innovative people housed so close together? That is your next Facebook or Google right there.

What is the UK government’s name for the East London development he’s talking about?

Question 6: Here’s Mike Arrington, demonstrating his trademark compassion and empathy:

Suddenly everyone’s complaining about how unfair things are in Silicon Valley. How hard everyone has to work so darn hard, and how some people don’t get venture capital or a nice sale to Facebook or Google even though lots of other people are getting those things. [...] If you work at a startup and you think you’re working too hard and sacrificing too much, find a job somewhere else that will cater to your needs. [...] Work hard. Cry less. And realize you’re part of history.

…which was prompted by employee upset at which 4 1/2 year old, 1,600-person Silicon Valley startup?

The obligatory Apple section…

Question 7: Here is a story from Forbes:

In December 2009 Jobs beckoned Houston (pronounced like the New York City street, not the Texas city) and his partner, Arash Ferdowsi, for a meeting at his Cupertino office. “I mean, Steve friggin’ Jobs,” remembers Houston, now 28. “How do you even prepare for that?” When Houston whipped out his laptop for a demo, Jobs, in his signature jeans and black turtleneck, coolly waved him away: “I know what you do.”

What service do Houston and Ferdowsi run, which they refused to sell to Jobs, and to which Apple then responded by building its own competing service?

Question 8: Here’s the start of a story in Businessweek:

About five years ago, Apple design guru Jony Ive decided he wanted a new feature for the next MacBook: a small dot of green light above the screen, shining through the computer’s aluminum casing to indicate when its camera was on. The problem? It’s physically impossible to shine light through metal.

Fortunately the laws of physics are no barrier to Apple. What technology did Apple buy up in bulk to enable the green light to be seen?

Question 9: “Apple does a great job. We need to improve our game and our products to take over the leadership position. Apple could go past [us] in 2012. We will try to become the champion in 2013. It will take time for the products that I have influence on to make it to the market.”

The new CEO of which company admits defeat, if only for the short term?

Business (actually, it’s “Miscelleneous” but that sounds like a cop-out)…

Question 10: Oracle issues a scathing statement…

Either Mr. Lynch has a very poor memory or he’s lying.  ‘Some bank’ did not just happen to come to Oracle with [company] ‘on a list.’  The truth is that Mr. Lynch came to Oracle, along with his investment banker, Frank Quattrone, and met with Oracle’s head of M&A, Douglas Kehring and Oracle President Mark Hurd at 11 am on April 1, 2011.  After listening to Mr. Lynch’s PowerPoint slide sales pitch to sell [company] to Oracle, Mr. Kehring and Mr. Hurd told Mr. Lynch that with a current market value of $6 billion, [company] was already extremely over-priced.  The Lynch shopping visit to Oracle is easy to verify.  We still have his PowerPoint slides.

…hitting out at which British company?

Question 11: Which company launched Qwikster… and then swiftly unlaunched it in the face of hostile customer reaction?

Question 12: Computer Weekly reported:

The Department for Work and Pensions (DWP) has signed a seven-year contract with IBM worth £75m per year to provide systems, which will include the delivery of its flagship [redacted] programme.

What is the name of the programme?

That’s it. Have fun.

Defect prevention is quality assurance in its true form. Testing to discover defects is too late — you really need to make sure there are no defects in the first place. Doing this is far less expensive than building in a defect and then doing the rework to take it out again.

Tom’s consistent experience is that projects run into problems because of ambiguity in earlier stages. For example, a system might be required to be scalable, but if the precise nature and extent of the scalability is not defined then the architects can easily spend an awful lot of time investigating solutions that address the wrong kind of scalability, or enable it to a degree which is not worthwhile to the business.

Even more significantly, if a project has many critical success factors which are not clearly distinguished in their relative value, then it’s far too easy for the development team to invest their time poorly.

So, ambiguity and a lack of clarity seem to be at heart of these problems. And since the earlier we pick up problems the better, we need to look out for that fuzziness at the very earliest stages… the business proposal, the requirements document, the design document, etc.

(For any Agilistas reading who shudder at the thought of a “requirements document” I would ask you let your imagination roam a little more freely. If your team is anything more than three or four people, and if your company is more than a dozen or so staff, then it’s very likely that someone is going to write down some kind of requirements to guard against people forgetting what’s been agreed from one day to the next. And those written-down-requirements are a “requirements document”, regardless of their precise physical form.)

Now I’m very used to having templates for proposal documents: standard headings, a standard cover sheet, and maybe even a standard font. But these are things designed to help the writer, and to make sure the information is complete. They are not designed to ensure the information is useful or clear to the decision-maker.

Thus the idea is to use rules for these documents. Here are some easy examples of rules…

• All statements in the document must be consistent
• Every statement must be unambiguous.
• All statements must be in their most elementary form.

I hope we can agree those look sensible, and they should be easy to stick to. But take a look at a business case from your company and go through it sentence by sentence. If the author isn’t consciously trying to adhere to the rules then it’s very easy to fall foul of them… sometimes several times per sentence.

Now here are some tougher ones:

• Evidence must be backed up by sources.
• All quality requirements must be quantified.

That last one is really tough. It means you can no longer just say “it must be much more user-friendly than the current system”. Instead you have to define unambiguously what user-friendly means (number of clicks to perform a given function? Number of people who abandon the process before the end?), you have to know what the current level is, and you have to know how much of an improvement you really want.

If that seems like a near-impossible demand, then take a look at Tom’s unambiguously-titled paper, “Quantifying management bullshit” [PDF]. Doug Hubbard’s “How to measure anything” is also entirely focused on this one issue, and is something I’ve written about before.

And here’s another rule to try out:

• Don’t put design ideas in the requirements document.

Tom’s example is that of passwords [PDF]: The business proposal (the business requirements) may ask for the system to be password-protected. But do they really want it password-protected… or do they want it to be secure? Because those are not necessarily the same thing, depending what “secure” really means. And the wrong design decision (i.e. implementing passwords) will lead to the wrong business outcome.

That last example also highlights another feature of document rules: different documents need different rules, depending on their purpose and audience. Clearly that “no design ideas” rule isn’t appropriate for a design document.

And finally… you’ve got the rules, you’ve received a business proposal… what next? Well, you review the business case against the rules, and if you find any violation of the rules then congratulations: you’ve found a defect. And finding defects at this early stage is going to save you a lot of time and money. Fix it now, and run it through the process again. When you’ve got an unambiguous business case you’re half way to a successful project.

Having often listened to John Seddon I’m wary of “lean”. He, too, learned from Ohno, and regards lean (which is the production approach extracted from Toyota) with disdain. His view is that lean is a version of Ohno’s approach which has been packaged by business school professors to sell to Western executives who want easy answers handed to them on a plate. Ohno’s real approach, he says, is to get people as close to the work as possible, and let them solve any problems that arise.

So while reading the summary of The Toyota Mindset I was curious as to what I would find, especially as it proclaims to hold “The Ten Commandments of Taiichi Ohno”. That sounds a bit packaged-for-resale to me. But in fact I was pleased to be wrong.

The “ten commandments” are much more ways of thinking, and ways of approaching business problems, than actual commandments. Two things really stand out from the stories of Ohno that Wakamatsu relates, via Abilla.

First, the number of times the phrase “the shop floor” appears. This is the reason lean might be considered packaged for resale: because Ohno’s real lessons are about getting onto the shop floor and seeing problems first hand, something that most executives in large companies would like to think they are beyond. Some examples from Abilla’s 10-part review:

• On standard work: “Standard work must be realistic and applicable on the shop floor”
• On how to know things: “Taiichi Ohno believed that one should base their judgments on his or her experience on the shop floor, not from a document alone.”
• On learning from the masters: “What you read from books is not usually useful when it comes to improving the shop floor. You will find much better ideas by just trying different methods on the shop floor.”
• On truth and understanding: “Stand and Observe the Shop Floor”
• On disclosing mistakes: “One day, Ohno stepped into the shop floor…”

Okay, that last one wasn’t such a big deal, but it’s notable that there aren’t any Taiichi Ohno stories that begin “One day, Ohno was sitting in his office…”

The second thing that stood out for me was how frustrating it must have been to work for Ohno. There are so many stories in which he asks an employee to do something, they do it, and he scolds them for doing exactly what he says (and in one case, for doing it immediately).

But the lesson here is that the staff should be thinking for themselves, solving problems for themselves, and always going beyond mere instructions.

Of course there is much more to the lean — sorry, the Ohno — way of thinking than these two observations. There is, for instance, the mindset of the continuously watching for waste and acting on it.

The stories related by Wakamatsu seem to be fascinating, and it’s yet another book to add to my growing reading list.

My criteria were: low tech (well, as low as a spreadsheet can be); must be able to track historical changes; must not rely on complicated spreadsheet formulas; must be very, very simple. Manual copying is allowed. Remember: this is for simple projects.

Oh, and of course it must product a burn-up chart which looks a bit like this:

That’s a pretty straightforward chart for a spreadsheet. So to generate that we want a simple grid that looks like this where the scope changes from time to time and total done slowly grows:

I’ll call that the “chart grid”. The “Day” column is a sanity check only.

But obviously it’s going to start off different. It will look a bit like this, with only the initial scope known, and no work done (yet):

But where does that “Estimated project size” of 20 come from? Well, we also need to show our (initial) scope, and the tasks that need to be done:

The 20 is the sum of all the tasks. I’ve not included an automatically calculated “Total” row, but you could. I pasted the sum (20) manually into the “Estimated project size” column for the present day and a few days into the future.

Then when the first task is done we record it, including the date done (for reference), how much was done, and the running total:

We also need to copy the total into the chart grid:

Again, the 5 is copied manually, as I decided that clever referencing formulas were just more trouble than they were worth.

As time goes on we complete more tasks:

…and we record these manually in the chart grid, too. We read the table above as “On 4 Nov the total done goes up to 7″ and “On 7 Nov the total done goes up to 8″. So the chart grid then looks like this:

At this point the burn-up chart looks like this:

But then, on 10 November, we discover the scope needs to change. It’s important to me that we retain the information of the scope as it has been so far, so we do a few things. First, we change the title of the scope grid to reflect when it was valid from. We rename it to “From Fri 21 Oct 2011 to Thu 10 Nov 2011″:

Second, we move it down a few rows in our spreadsheet (or maybe move it to another tab) to make room for the revised scope.

Third we create the revised scope. This involves copying the work already done, changing the other task lines as appropriate, and naming it to show the date from which it is valid:

Fourth and finally we also record the new scope total (24) and work done so far on the chart grid:

The burn-up chart now looks like this:

And so it goes. Shortly the scope changes again. Again we revise the title of our scope table, move it down out of the way, copy progress so far into a new scope table, and show the rest of the revised scope in this new table, adding progress as we go:

We also record the revised project size estimate (29) and we record progress in the chart grid:

And our burn-up chart looks like this:

If you want access to the formulas (there aren’t many) then this completed example spreadsheet is available as a public Google Doc.