Allan’s new Law of Social Networks

“The more social networks one joins the less one interacts with any one social network”

Just saying.

Please don’t create another social network. If you need a social network please piggy back on an existing one: Facebook, LinkedIn, Instagram, Pinterest, ….

If you think you need a social network – perhaps to challenge one of the existing ones? – remember Google Plus.

And make sure you know why you will succeed where Google failed.

Almost certainly you have less resources than Google.
Almost certainly you have a smaller existing user base then Google.
Almost certainly Google will see you as a competitor (as will Facebook, and LinkedIn/Microsoft, Instagram…)

So unless you are in fact the Google evil-empire don’t even think about it. And if you are Google remember you already failed, twice – remember Orkut?

Only a company as rich as Google can maintain the pretence that Google Plus was not an abject failure.

Blogger, Blog move & Comments


“And now, the end is near
And so I face the final curtain
My friend, I’ll say it clear
I’ll state my case, of which I’m certain”
My Way, Paul Anka/Frank Sinantra
(public domain picture from WikiCommons)

Don’t panic!

I’m not going away, this blog is not finishing.

But it is changing. And with the change there will be some loss.

Blog entry 1 appeared in April 2005, and after 12 years on Blogger this blog is moving and that move has a downside.

I’ve always been happy on Blogger but in the last few years I’ve been operating three website: the blog on Blogger, – a static site written in RapidWeaver and my commercial site, Software Strategy (

This means my efforts have been split between three sites, and Google has seen me as three sites. Given that my web presence is part of marketing my training and consultancy that might not have been the smartest move.

So last month I decided to merge the three sites and adopt a new corporate identity. Most of the move has been done, Software Strategy is now doing to, the blog is mostly moved – thanks to the great work of the folks at CMS2CMS, highly recommended – and here in lies the problem….

CMS2CMS have done a great job of moving the blog posts, images and comments. But they can’t move all the comments. That is because around October 2014 I switch the comments from Blogger to Google+. The comments on Blogger, before October 2014, can, and have, been moved across, but the comments on Google+ can’t – so all comments left since October 2014 are lost. I regret the decisions to switch to Google+ comments massively.

So many of the comments over the few years (I’m not sure exactly how many!) are about to be lost when the Blogger blog is set to redirect to

In order that the comments are not lost entirely here are some of my “greatest hits” as PDF files with comments and the view count according to Blogger:

I could go on, I’m sorry I can’t save more comments, it is sad looking now at all the comments, far more than I thought there were. I’m also amazon by how the blog has grown, from early posts with, maybe, a hundred views to a regular audience of thousands and sometimes tens of thousands.

And I completely blame Google and G+ for this, on Blogger Google are quite supportive of blog exports but there is nothing equivalent on Google+.

O, the third site,, this is mostly an archive of my writing down the years and it too will disappear inside in the very near future – most of the content is already moved.

Exciting: Something different for those Leading & Managing Agile

“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias … sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Frederick P. Brooks, The Mythical Man Month – Anniversary Edition (1995a, p.276)

This is one of my favourite quotes about software development.

Those of you who followed my management mini-series last year might remember some of my conclusions, specifically:

  • Management is still needed in most software teams
  • Even if you don’t have dedicated managers there is still management work to do; and without dedicated management that management work gets spread around so in a self-organizing team more people need to do management work

I can’t remember if I said it in that series or in another post: the quality of management in software development is often poor.

So now I’m going to do something about it.

Part of the problem is that very very few software engineers ever take time to learn about management. Sure they learn about Java, BDD, AWS, CSS etc. etc. but most people learn “managing” by watching the people who had the job before them. Unfortunately that tends to propagate poor management.

Why don’t people take the time to learn management skills the way they do technical skills?

A few days in the classroom learning about Java is great, why not spend a little time learning about management?

Now most readers probably know that I provide training, usually agile training to teams, but I have long felt that simply offering a two day training course for current and future managers wouldn’t be enough. I’ve long dreamt of offering a course that ran over a series of weeks, that allowed people to mix classroom learning and discussion of topics with hands on practice and, perhaps more importantly, reflection and group discussion.

Now I’m partnering up with Learning Connexions to offer just this course – I’m more excited about this than anything I have been in a while!

It’s going to run this autumn, September to December, half a day every two weeks.

In each session I’ll present some material but more importantly we’ll have discussions between people doing work. We’ll try and apply the material to real work. I expect group discussions will go beyond the stated subjects and allow everyone – me included! – to learn from one another.

Not only is this a new course it is a new way of approaching learning in work. Since it is new the course we are going to keep the price down. We’re running it on Friday afternoons so hopefully it won’t interfere with the usual work week too much.

Here are the hypothesis I’m testing:

  • Software development can be improved if software management can be improved: current software managers, aspiring software managers and software engineers will all do a better job if they take time to pro-actively learn about key issues in the software industry.
  • People will learn more and deeper if it is organised as a little and often.
  • Encouraging self reflection and group discussion about topics and real life problems will enhance learning.

The hypothesis you would be testing by coming along are:

  • I will learn more by discussing key topics with a cross section of my peers
  • An investment of six-half says and a little less than £1000 will pay back in increased effectiveness, productivity, organization, focus….

More information on the workshops on the training pages. (Yes, this is the new website.)

I hope, I very much hope we can make this work…. – please get over to Learning Connexions and book Leading & Managing Agile today. Even if you cannot attend I’d love to know your thoughts on this, please give me feedback – comment here or mail me direct,

And apologies, I’m going to be talking more about this in the next few weeks as I put material together and get more and more excited!

A new blog home

After over 10 years blogging on Blogger I’m moving.

Actually, for the last 10 years I’ve been running three websites. The blog, and my company, commercial, site, This kind of made sense once upon a time but it has increasingly meant that all three sites were a little neglected.

My plan is to merge all three sites into this one eventually. Hopefully that will also benefit my Google rankings but, it also means I need to keep all those inbound links!

This is going to be a gradual process…

Technical Liabilities and not Technical Debt

My last – frustrated – post finished with this line:


“banks are collecting technical debt the way they used to collect sub-prime”


I’ve always disliked the tech debt metaphor, in part because the way it is generally used is different to Ward Cunningham original defined technical debt and in part because those using it often have a simplistic understanding of debt – for example, credit card debt (which is generally to be avoided) is different from mortgage debt (which many of readers are only too glad to take on.)


A couple of years ago Chris Matts and Steve Freeman suggested a better analogy: an unhedged call option. While technically correct this metaphor required one to understand financial markets and options, most people outside the financial arena (and a good few inside it!) aren’t familiar with such concepts and so the idea floundered because the metaphor was more difficult to understand than the thing it was describing.


Still, Chris and Steve instincts were right, especially in financial arena’s the tech debt metaphor may be doing more harm than good. For a banker collecting debt is good… let me explain.


For you and me, as individuals, a debt is something I have to repay, it is a call on my future cashflow. For individuals – and many non-financial companies – a debt is a liability. As such we would rather not have it.


But for a bank a debt is an asset.


The bank holds the debt, when I take out a loan I promise to pay a bank sums of money in the future. Therefore my liability is their asset. It is two sides of the same coin.


Conversely, for a banker liabilities are things they own other people, e.g. my savings. When I place £1000 in my savings account it is an asset for me but a liability to the bank because the bank need to pay me £1000 at some date in the future. (Importantly, I decide that date and am unlikely to forwarn them.)


Bankers want more debt because debt is an asset. Debt is good.


So every time as software engineer says to a banker: “Doing it this way will create more technical debt” the banker hears “Doing it this way created more assets.”


One of the problems that occurred in the 2000’s was that banks found a new way to take on even more debt. The debt was packaged in technical ways “collateralized debt obligation” and “tranches” and such which allowed the banks to assume more debt. Things went well for a while and bankers believed they had found new way to make money. The problem was these debt packages were hideously complicated, so complicated in fact that many of those trading in these instruments didn’t understand them.


Nor did the banks own risk officers.


Nor did the regulators.


Does this sound familiar? Isn’t this technical debt?


What happened next made things worse: new instruments were divised by some of the people who didn’t understand how the original instruments were structured. In Fools Gold Gillian Tett tells of how the original JP Morgan team who devised these debt products warned as other banks introduced products which they could see didn’t make sense.


Doesn’t that sound familiar?


Doesn’t that sound like the Chief Engineer telling the Captain “She cannae take it, Captain” and the Captain doing it all the same? (Did Star Trek condition those in command to ignore the advice of their engineers?)


Banks aren’t unique here but their business model makes the problems more acute. Even outside of banking the technical debt metaphor has encouraged “debt thinking”, i.e. the idea that one can borrow from the future to get something delivered sooner and pay back later. This might be viable if we treated such debt as a mortgage which allows an asset to be purchased now in return for a long term payments plan.


However when programmers use technical debt to borrow from the future it is more like a payday loan which very quickly balloons and demands increasing amounts of our capacity (cashflow) to service the loan.


Banks are an extreme example of debt funded businesses. Most companies balance the amount of debt they take, if they need more money they may borrow it or they may ask shareholders. In general reasonable to see companies as getting half the money they need from shareholders and half from borrowing.


But banks don’t.


Banks may get less than 10% of their funds from shareholders, they rest they borrow. Anat Admati and Martin Hellwig in Bankers new Clothes explain this in detail but basically a non-financial company couldn’t do this because there is a high risk the company would go bust. But a bank can do it because in the event of failure they believe (and RBS proved) that the government will save the bank.


In other words: banks pile on debt because there is someone else who will save them if something goes wrong. (Economists call this “moral hazard.”)


It is a common business practice to borrow (increase debt) to improve returns so bankers aren’t alone in seeing financial debt as good but they are extreme.


So the question is: Do bankers believe they can take on technical debt because someone else will save them?


I can’t answer that question but clearly engineers view debt differently to bankers. Its more complex than a simple failure to understand.


Bank IT runs on a project model: as I say in #NoProjects this model encourages cutting quality because of goal displacement and the erroneous idea that it will be “done.” Even if bank managers don’t believe it will ever be “done” they can see their involvement ending, perhaps they are contractors, or perhaps they will move onto another “project.”


There are plenty of companies out there, be they outsourcers or tool vendors, who are only too happy to say their service or tool will solve the problem:


“Tech debt too high? No problem for Far Eastern Outsourcer No.1, we can fix it!”


“Do you suffer with long testing cycles? Then get Cyber Tester 3.0, it will find your bugs and shrink the cycle quicker than you can say contingent convertible bond


As Willy Sutton is might have said: “I sell IT to banks because thats where the money is.”


So is there a way out of this?


Well, there is one more complication that might actually offer a way out.


Another dimension to banking is time: the loans that banks make (their assets) extend over the long term (25 years for a mortgage) and the bank have little power to force repayment. They are said to be illiquid – it is difficult to cancel an existing loan so you can’t turn a loan you have extended into hard cash very easily.


But, the deposits banks accept (their liabilities) are very liquid. I can get my money out of a cash machine at any time and leave the bank with less money – ever wondered why banks pay higher interest rates on fixed savings?


Some say it is this problem that banks exist to solve: turning short term liquid deposits into long term illiquid loans; matching assets and liabilities on different time scales. (Mervyn King has as interesting discussion about this in The End of Alchemy.)


When we build a software system we are building an asset.


The system itself – retail banking systems, trading platforms, risk management systems – are long term investments and become major assets. Some last decades but they are illiquid, changing systems is hard. RBS has recently aborted a demerger because of the difficult of building a new retail system (FT: RBS chief warns it may fail to sell Williams & Glyn this year).


Conversely, defects in these systems (bugs) and poor architecture (what is often called technical debt) are liabilities. More importantly, like banks financial liabilities, these can strike at any time. I can visit the cash machine today and an unknown bug can crash the system today. Similarly, a poorly designed sub-system – say there is a singleton in the system – might not crash a system but can slow down operations, enhancements and so on.


Sure these problems might not appear today, but they might, likewise I might not visit an ATM and withdraw cash today, but I might.


Therefore, let me suggest that we drop the language or Technical Debt. (Or perhaps let Technical Debt return back to Ward’s original meaning.)


Lets instead talk about Technical Liabilities:


Technical liabilities, in software, are sections of code, even entire systems, which because of their (poor) design are difficult to change, significantly hinder enhancement and are fertile ground for defeats. Such code often lacks unit tests and coherent design.


Such liabilities are highly liquid and problems may transpire at any time – impeding performance of the system itself or enhancements by programmers.


In building an asset some liabilities will be incurred. But,

  • a) it is possible to minimise these liabilities while building and
  • b) these liabilities can be reduced with investment.


Reducing the liabilities will make the asset more valuable itself and enhance the asset’s ability to change in future.


Replacing the words “technical debt” with “technical liabilities” is a small change to our language, one we can all understand easily, removes a poorly understood metaphor that is open to misinterpretation.

Managing requires skills and intuition

If you’ve been reading my series of blogs on management it should be clear by now that I think some element of management is essential in software development. You might also have picked up that management, in various forms, is bigger than is commonly realised.


I also believe that good management can make a big difference to software development teams, I agree with Fred Brooks when he wrote:


“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias … sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Brooks, Mythical Man Month, 1995.


Tools, technologies and processes change all the time in software development but some things last. Mythical Man Month is one such, a book originally published in 1975 about work that mainly happened in the 1960s remains, perhaps because management of software development is important.


So why is it manager-less teams do so well? Let me suggest that the value that can be destroyed by bad management is far greater than the value that can be added by good management. I would venture that sometimes no manager is better than a bad management; self-organization doesn’t so much do away with management as do away with managers.


I would also venture that the quality of management in software engineering, indeed IT in general, is pretty poor. This is especially true in the corporate IT world. The standard in software producing firms (ISVs, SIs, etc.) is generally better.


Thus is seems sensible to ask: what makes a good manager? or perhaps, what makes an individual good at managing?


Well, two things.


First, management is a skill set in its own right. Managing requires skills in the same way writing Java, Testing software or Analysing requirements does. Simply appointing someone as a manager does not automatically endowed them with the necessary skills. These skills include communication, analysis, empathy, decision making and others. It helps too to have at good understanding of the business you are working in.


And as I said in my first blog in this series, it takes an engineer to manage engineering. Someone who is an engineer, understands engineering sensibilities, the thought process of engineering and engineers and knows the issues raised in software engineering will make a much better software manager than someone who does not.


Let me quote Fred Brooks again:


“In many ways, managing a large computer programming project is like managing any other large undertaking – in more ways than most programmers believe. But in many other ways it is different – in more ways than most professional managers expect.” Brooks, Mythical Man Month, 1975.


As an industry we fail to recognise that managing is itself a skill-set, and while software managers may learn more from non-software manager there it more to it than “general” management.


But managing software engineering, indeed any form of management, requires something more than skills…


Managing requires Intuition.


That might come as a surprise to some of you but it follows directly from something I blogged about a few weeks back: Management operates in the messy, fuzzy, ambiguous “real world”. Intuition allows one to work in such an environment.


Intuition also allows for rapid decision making; an engineer, especially one schooled in agile and lean startup may often prefer to set up an experiment and test options but such an approach inevitably slows things down. Sure there is a place for hypothesising and testing but sometimes speed is more important. Plus, it is not practical to set up experiments for all the the hundreds of decisions a manager must make during a day. Sometimes having a decision is more important than having the right decision.


Intuition is more difficult to teach, it needs to be built largely from ones own experiences. Some intuition comes from having done the work which is itself being managed. Intuition is also built from past management experiences. And intuition can be enhanced in various way: self-reflection and writing to name two.


This is not to say all management is about intuition, some benefits from analysis – and that requires the skills. There is a mixture here. Let me again quote from Professor Henry Mintzberg:


“Management certainly applies science: managers have to use all the knowledge they can get. But effective managing is more dependent on art and is especially rooted in craft. Art produces ‘insights’ and ‘vision’ based on intuition … and craft is about learning from experience – working things out as the manager goes along.

Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to manage; it depends on the situation.” Mintzberg, Simply Managing


That is how I see management: art, craft, science, intuition, and context dependent.


Isn’t that a lot like engineering?


Lets try that quote again with a little change:


“Programming certainly applies science: programmers have to use all the knowledge they can get. But effective programming is more dependent on art and is especially rooted in craft. Art produces ‘insights’ and ‘vision’ based on intuition … and craft is about learning from experience – working things out as the programmer goes along.

Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to program; it depends on the situation.”


Do you see? – Programming has more in common with management than is commonly recognised.

Thoughts on 6-Sigma and Agile

Question that comes up from time to time:

“Does anyone have Agile project which is Six Sigma? How these two things Six Sigma and Agile complement each other on software product development project? “

My answer:

In theory Agile and 6-Sigma should fit, they both have their roots in the quality movement.

A cursory glance at the 6-Sigma toolset reveals similarities to the Lean toolkit – continuous improvement, root course analysis, statistical methods, so at first it looks good but…

While there are a few stories of Agile and 6-Sigma working successfully together my own experience, and the majority of the stories I hear are that they are contrary.

Let me briefly share my experience….

I did some work with a financial services company which was a big believer in 6-Sigma. Any change had to be set up as a 6-Sigma change, with a business objective, current status measurement, target, approach, etc. Its difficult to argue with such a rational position but it was hard to pull all these bits together.

The change then needed to be signed off by more senior managers as a 6-Sigma effort. And it was hard to get the necessary managers in the same room at the same time. Which meant efforts didn’t get signed off.

And with all this effort you needed to put a lot of effort into any change which meant even thinking about change was expensive.

The net effect was to freeze the status quo. Six-Sigma had the effect of preventing change not supporting it.

On a day to day level the attention paid to variance was highly detrimental. Teams adopted behaviours designed to minimize variance (e.g. differences between estimated effort and actual effort) which both made measurements unreliable and made people wary of any change, experimentation or risk. (They had bonuses related to variance reduction.)

It seems there are some big difference between 6-Sigma and Agile, if not in intent then in implementation:

  • 6-Sigma is very top down, Agile is traditionally bottom up (although this is changing)
  • 6-Sigma is process and plan driven, 6-Sigma demands evidence; Agile is more “experiment and see what happens”, in other words Agile is happier with failed experiments
  • 6-Sigma demands study from its devotees (all those belts!) while Agile benefits from study it is a free-for-all when it comes to what to do (this may well be a disadvantage)
  • 6-Sigma anoints experts (black belts) while Agile is much more egalitarian (or at least should be)

So while Agile and 6-Sigma may have somethings in common they are culturally incompatible.

And as for the newer mutant form of 6-Sigma known as “Lean 6-Sigma”, well let me quote something I heard Dave Snowden say at a conference a couple of years back:

“Lean 6-Sigma is about removing all the waste that 6-Sigma introduces.”

Agile Contracts – a video mini-series

Over the years I’ve build up a bit of knowledge about commercial contracts in an Agile environment. This is not something I really noticed until a few months ago when Laurence Bascle asked me to talk to the Agile4Agencies meetup group on just this subject.

Laurence’s interest came from a piece I published in InfoQ a few years back – Agile Contract Options – but more recently I published “Dear Customer, the truth about IT projects” in the Agile Journal (which later became Agile Connection). Dear Customer has become something of an ever-green, I use it as a prologue in Xanpan and it regularly gets rediscovered and Tweeted about.

So I sat down and compiled all my thinking into a presentation which I have now delivered twice and is available online. (Funnily enough, Ewan Milne did a similar presentation to Agile on the Beach 2013 also based on my original article!).

Now as some readers will be aware, this year I have been experimenting with video recordings as alternatives to the written word. I’m still learning here but after chatting with director Brian Barnes (OK, the only director I know, but a) it sounds good to say that and b) he has a new independent film out soon which need plug, trailer on that link) I though I’d try my hand at video again.

I’ve broken the Agile Contracts presentation into 11 short recordings and published them on YouTube. Each recording is between two and three minutes long:

I’d love to have feedback and comments, just e-mail me as usual. Really my question is: should I try this format again?

Estimating business value: adding Value poker and Dragons Den to the Agile toolkit


A common piece of advice heard in Agile circles is:

“Prioritise by value. Do the highest value first.”

Sound advice, easy to say but perhaps harder to do.

And if you know me – or just read this blog regularly – you may have heard me say something like: “Estimate the benefit/value expected, measure what is actually delivered and feed this back to your decision making process: calibrate you benefit estimates, do more work where benefit is missing or change direction when it is not possible.”

I’m sure I could find more examples but I’m sure you know what I’m talking about: understand the benefit/value you expect to get – and possibly check it afterwards.

Easy really.

But there is a problem: How do you know what benefit/value is expected?

A good product manager or business analyst might be able to come up with some numbers. Good, but if you dig deep enough you’ll find assumptions or models in these figures which could be questionable. The better your analyst the deeper you will need to dig before any assumptions come to light.

As for teams who don’t have a product manager or business analyst, well, they aren’t even going to get that far before they find questionable assumptions.

Very often the expected benefit/value is a matter of conjecture and opinion.

So let me make a suggestion: Value poker.

This is a technique I’ve been using for a while and always teach it in my Agile for BAs courses. Whenever I mention it people get interested. To make it work I adapt a game-show format, specifically: Dragons Den, Sharks’ Tank if you are in the US.

Here is how you play…

Two teams.

One drawn from the people who are planning to build a product. This could be the entire development team, it could be just the product manager or business analyst with the product sponsor/champion. This team play the Entrepreneurs.

If need be this could be just one person (a product owner/business analysts/product manager) but it helps if there are two of them and if there is a whole team then bring them along too.

The second team is the Dragons/Sharks/Investors Team.

This team is probably a bigger. In a training session I usually use two teams from an earlier exercise where they have created user stories but in real life it is business managers from elsewhere in the business, perhaps product managers, analysts, sponsors and champions of other products. It could even be a high level committee – CEO, CFO, CTO, Sales, etc.

The Entrepreneurs come armed with a set of story cards – these could be in user story format, use case format or some other format, they could be epics or smaller. Whatever, the team need to believe each of these has business value.

Preferably I’d rather these cards did NOT have any effort estimates on them at this stage.
Then we set up a Dragons Den setting.
Next I ask the Entrepreneurs to pitch their product – the whole thing – to the Dragons. Usually one of the team who is a bit more entrepreneurial steps up. When the pitch is finished the dragons get to ask questions.

And we have a discussion back and forth.

Then, as moderator, I ask the Entrepreneurs for the lowest value item them have in their deck.
I take it from them and I invent a currency. This is usually named after the town I’m in, so I’ve invented Newcastle Shillings, Houston Dollars, Bath Spa Pounds or some such. Its imaginary, lets pretend I’m using London Dollars, L$.

I read out the card the Entrepreneurs gave me and make sure everyone understands what it is. If necessary the Dragons can ask some questions.

Then I write on the card L$10,000 – ten thousand London Dollars. I tell everyone about the imaginary currency and about London Dollars.

I then place the card in full view – on a magnetic whiteboard or blu-tacked to the wall, or somewhere.

I hand out the planning poker cards to the Dragons only and tell them the cards are now denominated in thousands of London Dollars. So a 1 card is worth L$1,000 and a 8 card is worth L$8,000, a 21 card is worth L$21,000 and so on.

And I ask the Entrepreneurs for the next card.

I take it, I read it out. I ask the Entrepreneurs if they want to add anything to what is written.

Then we take questions from the Dragons, and the discussion rolls.

After a while – sometimes a few minutes, sometimes a lot longer – I move to the vote, planning poker style.

I read the card out again and ask choose a card that indicates how many London Dollars this story is worth – relative to the L$10,000 card we already have.

I count down, 3, 2, 1 – show me!

And the Dragons hold up the cards. I average the answer and write the number on the story card. So, if I have a vote of 11, 21, 65 and 40 the value would be: 137/4 = L$34,000.

I usually don’t bother doing any discussion or re-voting, I just average – and I don’t care if the average is a number not on any planning poker card.

And we repeat – as a value estimate is assigned to one card we move to the next. Not every story needs to be estimated, the Entrepreneurs may decide to skip some once they see the results of previous rounds.

Entrepreneurs may write some new ones as conversations with Dragons reveals new ideas or prompts a rethink. Indeed one of the reasons I like to have more than one entrepreneur in the game is so that one can write new cards while the other is pitching and talking to the Dragons.

As each card is estimated it goes on the board with the others relative to the value assigned so everyone can see how the stories stack up.

People can really get into their role play, you can see some entrepreneurs really fighting for their product as the Dragons poke holes in the idea.

Sometimes – perhaps even most time – the conversations that occur as the game plays out are the most interesting bit. New features and functionality are brought to light. Sometimes the value the entrepreneurs see is not what the dragons see. Sometimes critical pieces of requirement or specification are discovered.

During the summer I played this game with a class in Louisiana, the entrepreneurs had created a set of stories around a food-truck locator app. Some of the stories related to the food-truck owner and some to a Hungry Jo. The entrepreneurs saw the value being on the food-truck owner side, so they emphasized this in their pitch and kept offering up stories abut the owner.

The dragons kept low-balling these stories, the entrepreneurs got frustrated and argued more, how the dragons didn’t realise what they saw.

At my promoting the entrepreneurs offered up a story about the Hungry Jo. To their surprise the dragons went high. This was the story the dragons saw value in.

Now you could say that it would be better to test the market – research or lean start-up – and I wouldn’t disagree but even if you do that it can be hard to put value behind stories. Plus, faced with 20 stories which one should you research or try first?

This approach applies wisdom of crowds. It gives you a starting point.

And as I just said, its just possible that the real value of the technique is not in the value it assigns to the cards – although that is useful – but in the conversation you have in the process.

Sure you end up with a fantasy valuation but you do have an idea of relative values, you do let stakeholders have their say, and you have some initial priorities. Much better than Must, Should, Could, etc. Potentially even better than 1, 2, 3, …

Maybe, just maybe, one day you might be able to see the value one story actually delivered – a jump in eyeballs, sales, donations or something. And with that you might be able to calculate what L$1 is worth.

Two final points before I end.

I try to keep effort estimates out of this. It is my (unproven) belief that if the dragons know the effort estimate on a card this will anchor their value estimate. I want value estimates to be made without reference to cost.

Second, a twist on this would be to revisit the story cards with a cost of delay dimension. So: value estimate the cards on the basis of “If you had this next month” then revisit then say “Now lets assume the cards aren’t ready for three months” and revote.

I haven’t had a chance to do that yet but I think it would be interesting.

Finally: if you get a chance to try this technique – or if you have done something similar already – please share, I’d love to heard what other people think of the technique and how it plays out elsewhere.