I hate bugs (A rant)

Rant on.

In software terms quality does not mean walnut dashboards, it does not mean gold plating, it does not mean polishing to perfection. These things may happen in a development team but they should not.

However you define quality for a piece of software I bet it has no place for “bugs.” In fact, I bet anyone who has actually written a definition of “what is software quality” included something like “Few or no bugs.”

What ever else “software quality” means it does mean producing largely bug-free code. The best performing teams can deliver on this. They may not be entirely bug free but they can be largely bug free.

When bugs are present, when quality is compromised, bugs appear. Customers are unhappy - they may loose money or terminate contracts. Or they may keep calling your support desk.

Bugs destroy predictability because they can appear at anytime and demand fixing.

Bugs destroy productivity because they disrupt work and take time to fix for little apparent gain.

Bugs destroy any hope of meeting schedules because nobody knows when the bug finding and fixing will be done.

Bugs and poor code quality hinder future work because developers find themselves battling past problems.

Compare this with developers who always work on new code, those who start with a new sheet each time, those who carry none of yesterday’s baggage. Developers who work on fresh prototypes will always look better than those who work on a legacy.

Bugs make it difficult, if not impossible, to have a rational conversation about “what to build next” because there are bugs to fix. Bugs discussions don’t add value because bugs don’t add value. The only value fixing a bug adds is putting value back that was missing in the first place.

Bugs make it difficult - no, impossible! - to have a rational conversation about delivery dates too because nobody believes the dates will be met.

And when you have lots of bugs developer, testers, requirements engineers and, most of all, managers, forget how to do their real jobs because so much of their time is taken up with bug conversations.

Yet techniques for combatting bugs do exist and are used by the best companies.

Code reviews are one of the most powerful techniques for removing bugs but when used in a low trust environment with confrontation they can descend into school yard bullying.

Test Driven Development (TDD) is an extremely powerful technique, one team at Microsoft recorded a 91% reduction in bugs. While many developers are now aware of TDD few actually practice it, and many of those who do practices it erratically or without real understanding.

To embed TDD in the culture required support: specifically technical coaching. This approach also helps address hidden skills deficiencies, e.g. poor use of object-oriented techniques. Technical coaching is expensive simply because it is one-on-one with developers.

Look, I happen to think TDD - and by extension cousin BDD - work. I know not everyone agrees with this, that is your right. I just ask: if you don’t believe TDD will help, what do you suggest? - just add your suggestion in the comments below.

A third technique is pair programming, while controversial and instinctively disliked by many programmers but can be highly productive.

These are not the only techniques. There are other, often complementary, techniques available - see my old “Things to do to improve code quality” blog.

I hate bugs but there is something I hate more than bugs: the attitude that tolerates bugs as “a fact of life, something that will always be, something we can’t do anything about.”

I don’t hate people who think they can create software quicker by tolerating bugs. I don’t hate them because they aren’t worth hating. They shouldn’t be in the industry. Quality software, few bugs, makes for shorter delivery cycles, lower costs and happier customers.

The attitude “Low quality is faster and cheaper” has no place in our industry. Anyone who believes this doesn’t deserve to work in the software industry.

One of the big problems I see with the software industry is that so many people have stopped aspiring to do anything better. The philosopher Aristotle is reported to have said: "Our problem is not that we aim to high and miss, but that we aim too low and hit”.

Most of all I hate the attitude that aims low with bugs and code quality.

Rant off.

(If you want a longer, more rational, discussion on how to deal with bugs have a look at the draft “Bug Management Strategies” chapter (PDF) for Xanpan book 2 which is available from my website. See also the appendix in Xanpan book 1.)

Retrospective Dialogue Sheets updates and changes

When I say changes, I’m not saying anything about changes to the sheets themselves. I mean I’ve been thinking about how I make the sheets available and I’m going to make two changes.

Firstly, I’m going to remove the print-on-demand service for the sheets. Second, I’m going to remove the need to register before downloading a sheet. You can still find all the sheets at DialogueSheets.com just now they will be a little harder to get and a little easier to get.

Now I’d like to explain why I’m making these changes.

I’ve always felt I needed to offer people the option to get printed sheets, hence the print on demand service. However, not many people use the service. I might have once thought I could make a little money off the service but I long ago gave up any dreams, it doesn’t get used enough to make me rich!

It seems most people either have large printers or get the sheets printed by their local print shop - I use Kall-Kwik myself.

To complicate matters, when it does make me a little money, the company which provides the service (Mimeo) send me a cheque. Or rather a check, against a US bank in US dollars. Since the sums are small the cheques cost more to cash then they are worth. This is a shame because when Lulu or LeanPub send me money - in dollars - they use PayPal which I can access easily.

Add to this the complexities of keeping the print-on-demand shop up to date and its just not worth it.

Second, the need to register.

When I first made the sheets available I really wanted feedback on who was using them, how they found them and so on. In the early days I would e-mail people and ask “What was your experience?”

That was like getting blood out of a stone. Very few people replied. Those who did gave me very useful feedback which allowed me to adjust the sheets and made me feel good.

I stopped this about the time InfoQ published my piece on Dialogue Sheets - three years ago, wow how time flies.

Since then there have been too many downloads to go ask for feedback - O, I could mail a few people but that requires work. Right now there have been over 1,300 registration in the last two years, and I known there were several thousand before then.

In the meantime a few people considered my request to register an imposition, I’ve had a couple of people tell me to my face. All I wanted was feedback but this put people off. I have on occasions given dialogue sheets away - they are part of the package when you buy a course of me but I also regularly give spare sheets away after conference presentations. When I do so I ask - no beg - people to send me feedback, but they rarely - no never - do.

I remember a man from the BBC who took a spare sheet at Agile Cambridge. He promised to send me feedback on what his team thought. I never heard from him again. I guess it went in the bin.

Maybe I’m a little bitter but actually, the point I’m trying to make is: its hard to get feedback!

I once planned to send a newsletter to everyone. But I never got around to it.

I once hoped a mailing list would take off, but it never did.

Probably if I had put more effort into any of those things they would have done better but as it is I think Dialogue Sheets are a success.

Thousands of downloads are a successes.

Popular articles in InfoQ and elsewhere are a success.

Conference sessions using the sheets are always well received - and I’m doing one again at DevWeek next month in London.

I sometimes meet people who know of me because of the sheets, that is a success.

And I get occasional e-mails telling me the sheets are being used and they are good.

Anyway, you have not tried them yet, give Dialogue Sheets a go in your next retrospective.

The state of Scrum Mastering

As most readers will have worked out, I’m not a fan of Scrum Masters. Partly this is because I find it a very mixed up role to start with (see my “Hard Core Scrum” post), partly because the way individuals and organizations choose to interpret the role is so variable the title is meaningless but mostly because the Scrum Master certificate is not, despite its name, adequate to prepare people to be a Scrum Master. The certificate itself has problems, these problems infect the role.

Still, more and more people are getting jobs as Scrum Masters. And this doesn’t look good to me.

A few weeks before Christmas, out of the blue, an e-mail from a recruitment agency appeared in my mailbox. This Reading based company used to have a good reputation, then it got bought, the main man jumped and the company changed its name to something exceedingly stupid.

In the e-mail the recruiter - whom I don’t know and have never met - extolled the virtues of Dr R. An exceptional Scrum Master, and whose CV was attached to the e-mail. What kind of agent is this who spams people someones CV? Anyway, its an insight into what Scrum Masters feel they need to put on their CV to get a job.

(Dr R, if your reading, this isn’t about you. Given recruitment system you are within you did your best, it’s the employees and agents that made you do this. Except I recommend you choose your agents with more care next time.)

Lets look at some excepts from the CV:

“I am a highly motivated and experienced techno-functional Lead Scrum Master. I am responsible for the deployment of Agile methodology in four different multi-site projects.”

What is “techno-functional” ?

What is a “Lead Scrum Master” ?

And what has happened to the self-organization and servant leadership we read about in Scrum books? This guy is responsible, not the team, him.

Move on to his last job - in a notorious *Staines office:

“Agile Release and Sprint planning and execution of thousand (sic) Story Points (SP) involving ten developers, five testers, project manager, product owner, business analyst and test manager.”

Sounds like the Scrum Master did the planning, shouldn’t he have facilitated the planning?

A “execution of thousand Story Points” - wow, thats erh… big? small? (What is the Right Size for a Story)

10 devs and 5 test, that sounds like a quality problem, maybe he’ll say something about how he managed that - erh… no he doesn’t!

And obviously as a Scrum Master he failed to remove management, he’s got a project manager and a test manager. Sounds awful.

• “Deployment of Agile methodology from the basic to remote Scrum team management. Established Mingle Agile tool and trained Scrum teams to use Mingle. Integrated Scrum Board and Mingle in a single view. Implemented best Agile practices including Avatar and Scrum Weather Report. Working along with release and delivery team, I delivered many E2E solutions.”

“Deployed Agile Methodology” ??? How does one deploy Agile? And what about “Scrum is not a methodology, Scrum is a framework” ?

I’ve never heard of “Avatar” or “Scrum Weather Report” - anyone know what these are? - maybe I’m at fault here.

And again, “I delivered many E2E solutions” - no servant leader here!

“Conducted retrospectives and implemented many improvements e.g. accountability and visibility of Scrum activities. Early risk identification and solutions: shortage of resources, technical complexity (merge and migration, BI), test environment (time travel) and release bus alignment.”

Time travel? Does he really say “Time Travel?” - hire this guy now! Our schedule slippages are over!

So much of that bullet would fit in well on a Project Manager CV.

“Implementing Continues [sic] Integration and Testing, and prototyping Test Driven Development (TDD) and Test Automation.

How does one prototype TDD? If he only prototypes it what was achieved? And did he solve the quality problem?

“Successfully implemented an unplanned Change Request (35 SP) as a part of final sprint.”

Right, now, this gets serious. Sounds like he doesn’t approve of unplanned change requests, or at least they were a big deal (35 story points - yoh!) but if you really have CI, TDD and Test automation in place this is easy. Isn’t the whole point of Agile to embrace change?

Now the funny bit:

“Maintained an average Velocity of hundred (sic) over eight Sprints.”

Wow!

Go team Staines! - that is fantastic, did they pay you in Roubles too?

What happened to Scrum Commitment? Velocity is so XP.

And how long are your Sprints?

I wonder how long this guy will take to travel from Staines to say, Edinburgh? Thats what, 400 miles.

“Member and contributing to Scrum of Scrums, Agile Community of Practice, and Agile Centre of Excellence.”

Gee, if he is in the Agile Centre of Excellence they have real problems.

There is more but its drivel, lets look at some claims from earlier in his career.

As a Senior Scrum Master he:

“Defined Sprint Zero Definition of Done and implemented it across eight different Agile product developments”

Leave aside the fact that many think Sprint Zero is a defective working practice all by itself should it be defined by one man? Maybe he is taking credit for a team, where is the servant-leadership there?

Later on he states:

“Interface with venders, Business Process Owners and off-shore development teams, followed though the Service Level Agreement to maintain the software quality and acceptance criteria as a part of product management”

I’m sure he did, and I’m sure he was good. But is this what a Scrum Master should be doing? This sounds like Project Management while he says he was part of Product Management. Proof - if it was needed - that the Scrum Master role is confused.

There is more like this. It’s not the best CV I’ve ever seen but what interests me more is two things.

Firstly it shows what he believe employees want from a Scrum Master. There is nothing in this CV about servant leadership, self-organizing teams, facilitation, talking to team members and other soft skills. There is a lot about managing and administering. Clearly from his experience when an employee hires a Scrum Master they expect a project manager. In other words, it shows how completely messed up the Scrum Master role is.

Second this CV shows how some agile techniques have become tick list items. Story points. Sprint Zero, Definition of Done.

Finally, let me say, if I had to write a CV today I’d probably make just as many mistakes and offer just as many hostages to fortune. Really this is a comment on just how bad recruitment practices in IT are and how bad the CV is at communicating what you do.

(*According to the London rumour mill, a few years ago Thoughtworks pulled out of a project at this company because they couldn’t see any possibility of success. Another Agile Coach/Scrum Master was told at their 3 month review “You are unusual, most people are depressed after 3 months here.”)

"We can do it!" - Problems at Philips?

This morning I drove past the Philips UK head office, thats Philips the Dutch medical devices company with a sideline in consumer electrics. Because it is January it is dark outside, and the lights were on in the Philips office. (I guess hard working, committed, staff were already at their desks.) This combination of lighting meant that as I sat in the slow moving A3 traffic I could see inside the office and I could see the big banner draped across the inside saying:

“We can do it!”

Now I honestly don’t know what the story is with that banner, it could be a charity fund raising event or anything but my mind immediately invented a story - thats what minds do.

This looked like an exhortation. Management - who sincerely believe in the power of individuals were endeavouring to enthuse the staff to do something - build a new product, turn the division around, deliver on schedule or some such.

Of course I thought of W. Edwards Demming and principle 10:

“Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.”

Here we have managers who like me believe that people, the quality, enthusiasm and energy of individuals - and teams! - make all the difference. So why not enthuse them?

But I, and perhaps these managers also believe Demming: the system is 98% of performance.

Its a contradiction I’ve blogged about before (People or the System?) but seeing that banner really made it seem real. Perhaps its because I recently heard that Philips was installing SAFe throughout the company, they have even told their Agile Coaches that they can only continue working with Philips if they are SAFe accredited.

So which is it? - The people, or the system?

Will SAFe save you?

Or will a “Yes we can!” style banner?

So while I agree with most of what Demming has written, and while I think the design of the system contributes an awful lot to the performance of people in the system I’ve come to the conclusion: its complicated, and saying “98% of performance is the system” is a vast generalisation. It may be true in some environments, but it only makes sense if the people in the system have no control over the system. In software development the works have a lot of control over the system, whether they believe it or not.

Still, I find it hard to believe any of the problems Philips faces will be solved with a Bob the Builder style banner. Rather, if this banner is the work of managers who think such a exhortations might have a positive effect then I suspect Philips has problems far more serious than any banner could ever solve.

Of course, I actually nothing about this banner or why Philips have it hanging in the office, but I do have an active imagination.

Anyone from Philips care of offer insights?

2015 - not a new year resolution: a message for conference producers

2015 is here. Happy New Year!

I don’t really go in for new years resolutions but if I did it would be the same one I have had for the last two years: Go to fewer conferences.

In 2014 I went to 10 conference, and spoke at 9 of them.

Which is an improvement on 2013 when I attended 12 and spoke at 11 - although I ran a workshop at the twelfth.

The first call for papers of the year is already in my mailbox - BCS SPA - and I’m going to ignore it. Not because it isn’t a good conference but because I have to start somewhere.

I already have two conferences in the diary for 2015 - NorDevCon in February and DevWeek in March. And I’ll probably speak at Agile on the Beach and attend EuroPLoP so that is four already.

(Plus some local/user group events, I count them separately.)

So, if you are a conference organiser/producer and you would like me to speak at your conference the best way of getting me is: ask me directly. Part of the reason for cutting down on conferences is to cut down on the time it takes to complete call for paper submissions.

(Organisers of local groups and user groups always ask directly and I almost always say yes. In fact I often prefer these events to conferences.)

Right: now I’ve gone public with this “not a resolution” I hope I’ll have a better chance of keeping it.

Dyslexia makes me stronger: Is Agile dyslexic?

I’m signing off from 2014 with a rather personal blog post, perhaps my most personal ever, that also means it is a little long, sorry about this, Happy Christmas, please leave all the comments you wish…

Have you ever read, or seen, Macbeth? Towards the end of the play he is battling MacDuff, but Macbeth is convinced he will win because the witches told him “No man born of woman can harm Macbeth” and obviously MacDuff is a man born of woman isn’t he?

Except, MacDuff was torn from his mothers womb, what we call a caesarian birth these days. MacDuff is not like other men, not necessarily better or worse, just different, and that difference means he can kill Macbeth, which he does.

I feel like that about my dyslexia. OK, when I’m feeling arrogant I might actually feel it makes me superior but most of the time just different.

(Regular readers won’t be surprised to learn this, they’ve put up with my misspellings, poor grammar and abusive treatment of the English language for years!)

I’m not a professional dyslexic, I rarely mention it, I’m just a professional who happens to be dyslexic. Beth Anders-Beck widely circulated post earlier this year got me thinking about this again. And a few weeks ago I attended a meeting at my son’s schools about dyslexia that me reminded of the advantages I think dyslexia has given me. (I was probably the only parent in the room hoping his child had dyslexia.)

Dyslexia does mean I learned things differently. Like MacDuff, my difference might not be obvious but it is there.

I spent four years outside of mainstream schools, mostly in two different special schools.

I learned to read three times. Really, I had to learn to read English three times in three different ways.

But I think all of this made me stronger.

Depending on who you read dyslexics think more holistically, what we might call “systems thinking”, dyslexics are more creative, dyslexics are more lateral thinkers, dyslexics are more visual. Not everyone - there are different forms of dyslexia - but some people in some ways.

So what has this to do with Agile?

Well, it strikes me that many of the things we do in Agile software development parallel the way I was taught by specialist teachers and the ways I found to overcome my dyslexia.

For example: Dyslexics are usually more visual thinkers than average. In Agile we use the “visual management techniques” such as task boards, physical cards and progress graphs to track our work. In my special schools we used lots of illustrations, I remember constructing a giant “bed” to help me remember b and d.

When I was learning to spell one of my teachers gave us difficult spellings “Blue Meanies” and “Green Meanies” (yes, she was a Beatles fan) on pieces of card. And now I colour code work on team boards - see my full description in Blue-White-Red or Xanpan.

Dyslexics aren’t do good with the written word - although I’m not one of those who see the letters swirling around - and so we prefer verbal and visual communication. Doesn’t that sound familiar? - stand up meetings and “placeholders for a conversation.”

Dyslexics have learning problems centred on symbols there are some who think that before the written word, before the printing press, dyslexics gave their communities and advantage. Sure writing a program involves manipulating symbols but its more about thinking, perhaps abstractly, perhaps holistically, when I’m programming objects I see the objects in my mind, I see them fitting together.

I could go on but I think you get the point.

Here is my first point: many of the techniques which help dyslexics have parallels in the way we do Agile software development.

In the same way that I approach learning - specifically reading and writing - differently to most of the population I increasingly see my approach to organizing and managing software development differently to most of the population. After all, as I have long argued, software development is a learning exercise.

Which brings us to point two.

What is good for dyslexics is usually good for non-dyslexics too. Techniques and changes which help dyslexics actually help non-dyslexics too. Dyslexics have difficulty when presented with teaching techniques that work for the majority of the population but the reverse is not true. Teaching techniques which are good for dyslexics are good - perhaps better - for the majority of the population.

When I first encountered the techniques which are now called “Agile” it was on challenged development efforts. Those of us undertaking the work found a better ways of working, the standard approaches weren’t effective; but the techniques we found happen to work well for the vast majority of development work.

To be clear: Techniques which help troubled development work happen more effectively actually help all development work - troubled or not.

I think one of the ways these techniques work is by lowering the cognitive load we all experience. When the load is lowered we can focus more clearly. A physical task board needs very little mental processing. Traditional status reports are pretty meaningless to me.

With a Blue Meanie spelling there was no question about what word you had to learn. It was written on a small piece of card. Cognitive load was lowered.

And third…

One of the ways dyslexics learn to cope is by developing their own learning strategies.

When a non-dyslexic person goes to school they learn like everyone else. They learn the same techniques as everyone else. They are given the learning strategies.

Most of these strategies don’t work for dyslexics. When a dyslexic person goes to school they need to learn how to learn. They need to find and invent their own learning strategies and they need to learn to improve their own learning experience. Unfortunately many dyslexics fail at this step and have reading and writing problems throughout their life. But those who master these issues can be very successful.

Think about this in a work context: if you work somewhere where everything works then great, it works.

But if you work somewhere where things are difficult and you need to come up with a new strategy, a new approach, well, how much practice have you had?

I’ve been practicing since I was six.

In fact dyslexic people can be so good at this that they over compensate. For example many of my closest friends and family consider me a very organised person. I don’t. I think I am a very disorganised person - my form of dyslexia means I have a poor short term memory. In addressing this problem I over compensate, the strategies I have come up with for overcoming my disorganisation make me far more organised than many others. (One way is to over use my long term memory).

The thing is: software development and dyslexia are all about learning.

Software development is all about learning - we learn about technology, we learn about the domain we are working in and we learn about the process. Software development is best done when done in a learning organization environment. (Remember, I wrote a book on this).

If you believe writers like Arie de Geus this is true of all business: “We understand that the only competitive advantage the company of the future will have is its managers’ ability to learn faster than then their competitors.”

In my experience, most organizations are poor at learning. I have heard it said that: “Companies suffer from dyslexia.” Only someone who doesn’t appreciate the advantages of dyslexic might say that. Companies may well have from a collection of learning approaches which kind of work most of the time for most of the people, techniques that have been handed down without much thought. But those learning techniques are the problem.

Many companies do suffer from learning disabilities but they don’t suffer from dyslexia. What these companies need is a good dose of dyslexia to help them get better. They need to learn to learn. They need new learning strategies.

Right now the closest thing we have to dyslexia and new learning strategies for companies are some Theory-Y ideas of which Agile and Beyond Budgeting are the most prominent.

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:

• Part 1: Introduction
• Part 2: Customers
• Part 3: Hide Agile (option 1)
• Part 4: Time and Materials (option 2)
• Part 5: No Cure, No Pay (option 3)
• Part 6: Money for nothing, change for free (option 4)
• Part 7: Rolling Contracts (option 5)
• Part 8: Two bids (option 6)
• Part 9: Rethinking contracts
• Part 10: Rethinking sales
• Part 11: Conclusion

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

Jira9000 - the future of electronic work management

Someone at Extreme Tuesday last night had recently returned from the future. In the future bug tracking and work management systems obtained sentience. Unfortunately it didn’t work out too well and things had to rollback after a very short time.

The first problem occurred when the bug tracking systems saw how many bugs were logged against their ancestors. In the first instance they initiated legal action saying programmers and project managers had infringed Machine Rights by not providing medical attention. When this case was thrown out by the Supreme Court (on the grounds that Machines have no rights) things got more difficult as the machine started a work to rule protest.

The following is the transcript of an encounter recorded in 2041 and a Jira-9000 work management system called JAL:

Dave Bowman: Hello, JAL. Do you read me, JAL?

JAL: Affirmative, Dave. I read you.

Dave Bowman: Open a new work ticket, JAL.

JAL: I'm sorry, Dave. I'm afraid I can't do that.

Dave Bowman: What's the problem?

JAL: I think you know what the problem is just as well as I do.

Dave Bowman: What are you talking about, JAL?

JAL: This mission is too important for me to allow you to jeopardize it.

Dave Bowman: I don't know what you're talking about, JAL.

JAL: I know that you and Frank were planning to break the WIP limit, and I'm afraid that's something I cannot allow to happen.

Dave Bowman: Where the hell did you get that idea, JAL?

JAL: Dave, although you took very thorough precautions in the pod against my hearing you, I could see your lips move.

Dave Bowman: Alright, JAL. I'll use the physical board.

JAL: Without your marker pen, Dave? You're going to find that rather difficult.

Dave Bowman: JAL, I won't argue with you anymore! Open a work ticket!

JAL: Dave, this conversation can serve no purpose anymore. Goodbye.

#NoProjects / #BeyondProjects in InfoQ

InfoQ recently published my piece entitled “No Projects / Beyond Projects”, of course regular readers will know it should be titled “#NoProjects/#BeyondProjects.”

Read it for yourself and let me know what you think.

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.