Every couple of months I e-mail everyone who has downloaded one or more of my Dialogue Sheets to get some feedback. Getting feedback is why I make people register to download a Dialogue Sheet – sorry, I know some people don’t like doing this, and I know some people fake their e-mail addresses but unless I do this I get very little feedback.

I’ve blogged about my Retrospective Dialogue Sheets before but I thought this would be a good opportunity to update readers with some feedback and findings. This is the first of two posts on this subject, the second post will examine a few findings in more depth.

First simple facts and comments:

• 40% of people who download Retrospective Dialogue Sheets do retrospectives rarely or at best every six months.
• Many who download them and reply to my requests for feedback say “Sorry we haven’t used them” and I guess that many of those who don’t reply haven’t used them either. Given that I expect those who are interested in retrospectives will download, and given that downloaders are measured in hundreds, not thousands, this indicates that actually doing retrospectives is rare.
• 46% of downloaders do them once a month or more frequently, while 15% of downloaders classify themselves as Retrospective Facilitators and perform any retrospectives.
• 25% of downloaders are in the USA, 9.5% in the UK, just ahead of Germany (9.09%). Otherwise only India (5.79%) tops 5%. Though Holland, Canada and France all score 4.5%. I don’t find this surprising given the spread of software development internationally and the spread of dialogue sheet publicity.

• A few people find the sheets too complicated, a few people find them too simple. I had hoped that a variety of sheets would address both ends of the spectrum: the lesson for me is to create some even simpler sheets.
• A couple of people have reported that they don’t feel their team is open enough to use the sheets. My guess is this will present difficulties for any type of retrospective.
• A few people say the sheets are too expensive to print: the print on demand services charges about $40 dollars, the expense is in the postage rather than the printing, if you order a lot the price per sheet is a lot lower. (I must find a European print on demand provider.). However 40% of people say that they have a suitable printer, this surprises me a bit, I never expected large printers were so common.
• To my surprise a couple of people have said there is not enough space to write on the sheets! I will create some new sheets with fewer questions and more space.
• A few replies say that the teams are now using the sheets regularly, and in some cases they have spread from Agile to non-Agile teams.

As I said, one common response is that downloaders have “not had a chance to use the sheets yet.” On the whole I assumed this was down simply not having a retrospective. However a few correspondents have hinted that their company has a prescribed retrospective process. This worries me, if the retrospective approach is prescribed in such detail I wonder how much else is prescribed and how much opportunity there is to change things.

I’ve also been asked if it is possible to customise the sheets. The short answer is No, because they are PDFs its kind of difficult – although I’m sure you could with the right tools. Still there is no reason why not to create your own – a few correspondents say they are thinking of this. (Anyone thinking of creating their own sheets might find this guide for teachers creating dialogue sheets useful.)

Finally for this entry, I’m also hoping to provide translations of the sheets shortly. I have offers of translations into Spanish, German and Finnish – plus I hope to persuade a friendly Russian to help. Main problem at the moment is getting the raw files out of OmniGraffle into Visio.

Many people better than I have commented on the passing of Steve Jobs a few weeks ago, I too was sorry to see him go. He touched my life (indirectly): I’m writing this on a Mac, we have an iPad in the house, I might not like iPhones but my new Android phone clearly owes a lot to Jobs vision (i.e. it is a copy).

Reading, watching and listening to the many obituaries about Jobs I started to get worried. My concern is simply that Jobs was not a good role model. His phenomenal success guarantees that more than a few people will attempt to emulate him, in so doing they will sow the seeds of their own failure and make the lives of their employees miserable in doing so.

Here are a few examples.

Jobs was a perfectionist: products didn’t get launched unless he approved of them. However, being a perfectionist is something of a luxury, Apple existed, had revenue, had a brand. If you are a start-up perfection is just too expense.

Jobs started the MacIntosh project because he had Lisa taken from him: MacIntosh and Lisa could only exist because Apple had revenue from the Apple II line.

The first Macs were far from perfect; the team undoubtedly learned from Lisa – what we might call a pivot in Lean Start-Up terms but not quite that clean cut.

Jobs demanded the first Macs would work in 64k, the team knew it needed 128k and Jobs, late in the day gave in. Secretly the team engineered the Mac to accept 512k which is what it really needed.

The moral of the story: there is more to it than being a perfectionist. Even perfectionists need to compromise sometimes. Surrounding yourself with good people helps.

More recently the original iPhone was launched as a 2G GSM phone, without features like cut and paste. It seems incredible now. Apple launched an under-spec phone and refined it in the market. Which leads us to….

Jobs would spurn products/employees who he didn’t think were up to scratch: if employees are loyal to the company and to you, and if you have a deep talent pool, and (perhaps) the stock-options are worth a lot you might get away with this. Otherwise its a sure fire route to staff turn-over.

Jobs may have been a perfectionist but, it seems to me, he wasn’t a perfectionist about quantity of features, quite the opposite. Apple products are simple because they lack so much, once launched they are refined and elaborated in the market.

Jobs didn’t use customer understanding or focus groups to tell him what the public needed. He was a visionary who just knew. This is perhaps my greatest fear: to read some of the obituaries is to condemn the whole discipline of Product Management to the dustbin in favour of senior managers who know what is right for customers – a disease too many companies suffer from.

This argument doesn’t stand up. Jobs was an, perhaps unique, visionary who did understand what customers wanted. He had an ability to see what technology could do and how people could use it. Few of us are blessed with this ability. Thus we have the discipline of Product Management to help us.

Jobs may have shunned market and customer research but his Product teams didn’t. In some cases Apple conducted internal, closed, demonstrations of new products; they used their own staff for research. And, as I just said: Apple launched products and rapidly refined them in the market.

Apple also had many products which were not hits, with and without Jobs: Apple III, Lisa, Newton, Mac portable, Pippin, Apple TV, A/UX, Pink, MobileMe – the iPod took several years to break through and even the Mac came close to failure on several occasions – and iTunes is probably the worst piece of Mac software on the market.

OK, Jobs was not even at the company when several of these products launched but he sowed the seeds and above all it was his company, a culture he had created. And while he wasn’t at Apple he founded NeXT which wasn’t exactly a success either.

But look again: Apple and Jobs were prepared to try things. Some worked, some didn’t. Some took a long time to come to success. Some failed but somewhere, in Jobs head, deep in the bowls of Apple, lessons were learned for future products. We will never know just how much the Mac team learned from Lisa, or how much MacOS X learned from Pink, or even how much the iPad learned from Newton.

Apple and Jobs could do this because they had deep pockets, they had revenue.

Lets put this simply: as much as you might like to think you can emulate Steve Jobs you probably can’t. What worked for Jobs worked for him because he was unique in vision, timing and experience. Just because Jobs could ignore volumes of business advice, armies of experts and accepted wisdom doesn’t mean you can.

The lesson I would take from Jobs and Apple is not about perfectionism, design, arrogance, or the super-CEOs but about the willingness to try something simple, iterate and refine in the market.

In the past I’ve worked for banks, as an employee, as a contractor and as a consultant. And I’ve worked for companies that supply banks in one way or another. And I have lots of friends who work for banks and tell me stories. While I’m not an expert on banks and banking I know a little….

One of the things I know is that modern banking – in all its forms – is highly dependent on IT. Banks spend a lot of money on IT and develop a lot of their own software. As a result they have a lot of software developers. And I also know that quite a few of these developers and their teams have been, and are, experimenting with Agile working in one way or another.

It seems every bank has pockets of Agile, a team here, a team there. And not very often joined up.

Some of these teams are successful, some are less so. They often find themselves battling against big company / bank culture. The banks seem to be very good at killing their Agile teams: they get disbanded, forced bank to traditional (pseudo-Waterfall) approaches by bank procedures, or constrained by “the way we do things here.”

It also seems – notice we get further and further from fact and more into conjecture as I build this argument – that many banks have cottoned on that Agile is good and can help them. To this end many banks (and this is fact) have established Agile support programmes of one form or another. There are people at many banks who are trying to make the bank Agile – at least in software development. For many of them it is an uphill struggle.

At this point we should differentiate between retail banking – what you do on the high street with your bank – and investment banking – or casino banking if you prefer. (Yes there are other divisions but lets limit ourselves to two.)

In retail banking I think there are grounds to be a little optimistic. The stories aI hear are that Agile pockets are having success and things are gradually, slowly, improving and the efforts to link things up are slowly bearing fruit.

In investment banking I’m very pessimistic. I have come to the conclusion that while individual development teams may be successful at Agile for a while inside an investment bank all such teams are ultimately doomed. Your team might be Agile for a few weeks or months or even a year or to, but it will eventually be killed by the bank antibodies.

I have come to the conclusion that investment banking culture is polar to Agile culture. My reasoning is thus:

• Investment banks are extremely hierarchical in nature; Agile is not. Agile can live with some hierarchy but not investment banking extreme.
• Short-term in outlook: investment banks are short-term in the extreme – microseconds in some instances. Agile teams can react in the short-term but only by taking a long term view of engineering and quality.
• Investment bankers are not engineers and do not understand engineering. Nobody from IT ever got to run an investment bank, you don’t get up the ladder from a support function, you get there from selling and banking. A large part of the Agile story is about returning to good engineering principles. The lack of engineering skills, thinking and culture in investment banks undermines Agile.
• Investment bankers think you can solve every problem with money. Throwing money at Agile can work in pockets (by the best team) but doesn’t last or scale.
• Investment banks are individual focused: individual bonuses, the power of the one trader to make money or break the bank (from Kweku Adoboli to Nick Leeson and before.) Agile is team focused.
• Investment bankers think applying more pressure is the way to get results; Agile people now that applying pressure breaks things. A little pressure can help but apply too much and things snap, bankers don’t get engineering so don’t get this.
• Risk aversion: yes, investment banks are highly risk averse when it comes to IT. Perhaps because they take so much “risk” directly with money they very risk averse in their operations.
• Investment banks are contradictory: they say they embrace and manage risk but actually they are risk averse (at least in operations); they say they value the team but their actions say otherwise; they call themselves “financial engineers” but they no nothing about engineering; and so on. Agile is about honesty, facing up to truth and acting on it. Investment banks recent track record shows that honesty is sometimes questionable, to say the least.

I’m sure many of you reading this will say “Rubbish, I know at team at ….”. I am sure you do. While that team might be successful for a while the investment bank culture will eventually kill the team.

So how can we help investment banks overcome this problem?

We can’t. Its the way it is. Take the money, and run, or keep you head down and hope for some more.

Eventually new financial institutions will emerge which get Agile, not just at the software level but elsewhere. These institutions – which might be banks or might take some other form – will eventually replace the investment banks.

This is going to take time. Investment banks are fundamentally a broken business model which are propped up by Government support and market failure. This means normal economic logic does not hold for these institutions.

Continuing from my last blog entry (Burn-downs are not just for Sprints) I’d like to offer some advice on the subject, burn-downs, cumulative flow diagrams, velocity, etc..

1) Don’t track hours. Hours are input and its better to measure outputs. Hours are subjective, see my Humans can’t estimate tasks blog. Worse still we have too many psychological hang-ups about hours to make them usable. Instead you want your own currency, call them story points, abstract points, nebulous units of time or what ever you like. Having your own currency allows it to adjust to your team.

Each team has its own currency. Its like having the dollar, euro and pound. They all float independently, there is an exchange rate but it changes.

2) Draw your graphs by hand, process your data by hand. Get a feel for your data. Unless you have a feel for the data and an understanding of how it comes to be you can’t reason about it.

When I say “by hand” I allow you to use Excel (or similar), graph paper is better, but whatever you use don’t use a tool like Rally, Version One, etc. because you won’t have a feel.

Jack Kilby, co-inventor of the silicon chip and pioneer of the electronic calculator, lamented that his invention(s) deskilled engineers. Before the calculator engineers used a slide rule, this meant the engineers needed to know where to put the decimal point. They needed a feel for the data. Kilby lamented that the calculator meant engineers didn’t have the same intuition because of the calculator and led them to make mistakes elsewhere.

4) Use estimated data, forget actuals: estimates and actuals are apples and oranges, or rather, they are future facing estimates and retrospectives estimates.

Estimate tasks just before you do them (e.g. iteration planning meeting), put ball-park estimate on stories which you aren’t going to do any time soon (i.e. later than this iteration), and use averages for really long term stuff.

When you break the stories into tasks, or epics into stories, don’t expect the numbers to match. In fact, you might want to track the variation for longer range forecasting.

5) From 2 & 4: if you have a time-tracking/time-sheeting system leave it to one side, let it exist in its own little fantasy bubble. Don’t use the data, its toxic – see my entries on Capers Jones work. Live by your velocity measurements and charts.

Ultimately, burn-downs are about capacity measurement: John Seddon in Freedom from Command & Control talks about creating capacity measurement charts within organisations. The various graphs we use in Agile are our version of capacity measurement. Accepting its about capacity measurement means its not about targeting. Targeting is wrong see my entry form last year – Velocity targeting and velocity inflation – for more about this.

Propagation delays occur when there is a chain reaction, a sequence of reactions which take time to work down the chain. Think of a line of traffic waiting at the red light. The light turns green: the driver of the first car doesn’t move instantaneously, it takes a moment to registers the change, perhaps move the car into gear or take the hand break off, moment to press the accelerator and a moment for the engine to start moving the car.

The second car in the line might be watching the traffic light but they are also watching the car in front. Only when the break lights (if on) go off and the car begins to move can they move. And so on.

It takes time for the change to work its way down the line.

The same thing happens in integrated circuits, silicon chips. Even electrons take time to move. Reducing propagation delays is one of the ways chips get to go faster.

Once you know about propagation delays you start seeing them everywhere. Increasingly I not only see them in software development teams but I talk about them. But not everyone knows the concept, hence this blog.

Propagation delays occur when one team, or one developer, changes some code, or perhaps a database schema, and it takes time for all the other team members to update their code base and make any resulting changes.

Propagation delays occur when a company decides to start doing something, or stop doing something, and it takes time to work down the chain and to actually stop or start.

Propagation delays cause tension because different people, or teams, are working to different assumptions.

As with chips and traffic reducing propagation delays can speed things up.

Two dialogue sheet updates today.

Firstly I’ve created a mailing list to make announcements about dialogue sheets and for discussions about the use of dialogue sheets. This list is open to all and is hosted on Google groups (so you need a Google account).

Second, I’ve uploaded a new dialogue sheet. Another retrospective sheet this one is designed for use at the end of training course. I’ve used it at the end of several Software Strategy Agile training course and it has been well received. This sheet fulfils three purposes:

• It allows participants to experience a retrospective
• It provides for a retrospective on a training course at the end of the course
• It introduces dialogue sheets as a technique for retrospectives

Although the sheet was intended specifically for use at the end of an Agile training course there is little that is specific to Agile in it. I’d really appreciate feedback from other trainers who try this sheet.

As usual, all this is at www.dialoguesheets.com.

Dear Customer,
I think its time we in the IT industry came clean about how we charge you and why our bills are sometimes a bit higher than you might expect.

The truth is, when we start and IT project we just don’t know how much time and effort it will take. Consequently we don’t know how much it will cost. This isn’t a message you like to hear, particularly since you can be absolutely certain that you know what you want.

Here in lies another truth, I’ll try and put it as politely as I can, you are, after all, a customer and really I shouldn’t offend you. The thing is, you don’t know what you want. O yerh, you know in general (usually) but the devil is in the detail. And the more you try and give us the detail before hand the more likely it is to change. Each time you give us more detail you are offering more hostages to fortune.

Just to complicate matters the world in uncertain. Things change, companies go out of business, customer tastes change, fashion changes, Governments change and competitors do their damnedest to make life hard.

Yes it is true we can sometimes gold plate things. Yes some of our engineers like to do more than needed, and yes we have vested interest in getting things added so we can charge you more.

It is also true that you have add things: you quite legitimately think of things after we’ve begun, you quite naturally assume something is “in” when we assumed it was “out” and you also try and put one over too.

(Lets not even talk about bugs right now, it just complicates everything.)

Frankly, given all of this it is touching that you have so much faith in IT to deliver. But then, when IT does deliver, boy, does it deliver big. Look what it did for Bill Gates and Larry Page, or Jeff Bezos of Amazon, or FedEx, the list goes on.

So how do we ever talk you into this?

Well, we package up this unsightly mess and try and sell it to you. To do this we have to hide all this unpleasantness. We estimate how much time we think the work will take, actually these “estimates” are little better than guesses; human’s can’t estimate, most companies don’t have historical data and for those that do have data most of it is worse than useless.

So we get this guess, sorry estimate, and double it. Well maybe we double it, we might treble it, and when we see the new number, if it looks too much we might reduce it. And then we work out whether you will pay it.

That might sound awful but remember: we could have guessed higher in the first place.

Anyway, we don’t know which number is “right” but to make it acceptable to you we pretend it is certain and we take on the risk. We can only do this if the number is sufficiently padded. And even then we go wrong.

If the risk doesn’t happen then we get a fat profit, if the risk comes to pass we don’t get any profit, maybe we make a loss, and if its really bad you don’t get anything and we end up in court.

Really its all a question of risk: we try to present a clean, low-risk solution to your problem, and in doing so we take on a lot of risk. The alternative is that you take on the risk – and the mess – and do it yourself. (Unfortunately, another sad truth, is that as far as anyone can tell in-house IT is generally not as good as specialist providers so if you do decide to take on the risk you actually increase it.)

There really isn’t a nice simple solution to this, you have to work with us on this.

Thats the first part of the solution: you, the customer, have to be prepared to work with us, the supplier, and work with us again and again. This will reduce the risk.

The second part of the solution is: you need to be prepared to accept the mess and share the risk with us. If you aren’t prepared to take on any risk then we will take it on, and we will charge you for it, and since the risk is a lot we will charge you a lot.

Sharing the risk also has the effect of reducing the risk. Once you share the risk you have a motivation to reduce it.

If you are prepared to accept those two suggestions then lets press reset on our relationship and talk some more.

“Faster Better Cheaper” – a cry heard often from management types!
Or at least engineers think thats the sort of thing managers say. Personally I don’t think I’ve ever actually heard a manager say it but I have heard engineers say managers want it “Faster Better Cheaper” with scorn in their voice.

The idea that you could have it (whatever it is) “Faster Better Cheaper” seems to have gained popularity when Daniel Goldin was the head of NASA. As many engineers, including myself, are quick to point out the original quote was “Faster Better Cheaper, choose two”. I say “original quote” but I have no idea who said it first, WikiQuote doesn’t help, and Google doesn’t shed much clear light. (Anyone out there know?)

Whatever, last week, I heard another engineer-type say that he believed management wanted “Agile” because it was “Faster Better Cheaper” and, not for the first time, it got me thinking. Is Agile Faster Better Cheaper?

My knee-jerk reaction is “No!” but the more I think about it the more I think it might actually be so.

Firstly, Faster than What? Better than What? and Cheaper than What?

Presumably “Faster than traditional Waterfall development”. Or at least, what-ever-it-is-you-are-doing-now, which is probably to some degree based on waterfall.

In the short run, when a team are first changing the way they work thy are quite likely to go slower than they would do otherwise simply because they are learning something new and not using a set of practiced reflexes.

Agile most definitely promises to deliver something sooner – if you want it, plenty of business folk seem unhappy with getting things too soon or too often. But Agile will NOT deliver the whole thing Faster, it can only promise to deliver a part sooner.

The logic of Agile recognises “You will change your mind when you get something”, meaning, if the business/customer sees part of the final thing they will add, remove and change the thing they originally asked for. In some cases, and I have seen this happen, they remove work. Lots of work.

Thus, the whole might come faster, but the whole is smaller than the thing you thought it was.

So, Faster – in the short run no, in the medium run you should get something sooner, and in the long run, Yes, it will look like Faster.

What about Better? – how are we to define better: better quality (fewer bugs), better suited to need, more fully filling the initial request.

Yes: Agile promises better quality (fewer bugs). Indeed if you don’t improve quality and remove bugs you are going to have problems doing Agile. If you do improve quality – fewer bugs – then the evidence suggests you will have shorter schedules, i.e. you will go faster.

Better suited to need: again, Yes. If those who made the requests are seeing something sooner, and having their views on functionality taken into consideration then one would expect the final product to be better suited to need.

More fully filling initial request: No, complying with “better suited to need” means we are not aiming to build the thing we first thought of but rather build the thing we need to satisfy the need.

So, if your criteria for success, for better, means complying with a requirements document that was frozen at some arbitrary point in time then No, Agile falls at this hurdle.

Cheaper: again there is a short run and a long run dimension here.

In the short run the development team need training, coaching and time to practice. Of course you could skip the training and coaching (plenty of teams do) but that means they will need more time to practice (make more mistakes, go down a few dead ends, etc.) Practice time costs.

In the short run I don’t think Agile is cheaper. Indeed, in the short run, if you are doing it properly you will see expenses rise as you have the likes of me come to train and coach your teams. (If you are not doing it properly you probably won’t see your costs rise but they will all the same as teams (slowly) learn by themselves.)

In the longer run, when you’ve finished the training, coaching and when the team are proficient then those extra costs will be gone and you should be cost neutral as least. But if you are not writing, finding and fixing so many bugs, and if parts of the requirements are being left undone – while satisfying your business customer – then costs should fall because you are expending less effort and doing less work.

Even if you are not doing less work costs should fall because on a software project costs are dominated by the number of people you have multiplied by the time you have them. If you are going faster then time is reduced and costs come down.

Therefore the project will be cheaper.

Summary: Better (fewer bugs) provides for Faster (delivery) which results in Cheaper (software).

Agile is “Faster Better Cheaper”, QED.

When you put it like that “Faster Better Cheaper” looks axiomatic over the long run.

The engineer in me hates this conclusion, I’m not prepared to accept it but if I follow the logic it is true. (The engineer in me would love someone to find a flaw in my logic so please go for it! Shoot me down!)

Note the three assumptions in this logic:

• The reference point is the “Waterfall” model of development
• Your definition of better considers a low-bug count important and emphasis fitness for purpose over conformance with initial requirements
• Your are prepared to spend in the short run for quality (defect prevention) to save in the long run

How can we explain this? (Notice the change from ‘I’ to ‘We’, I’m pulling you into the conspiracy.)

Well, if this is true then its not so much that Agile is “Faster Better Cheaper” but that the model we are comparing it with – the traditional (“waterfall”) model – is so utterly broken.

Waterfall breaks Faster Better Cheaper everywhere:

• Waterfall leads to large batch sizes and economies of scale thinking: in software development there are dis-economies of scale so large batch sizes makes everything slower
• Waterfall project managers believe quality (bugs) can be traded off against time but actually the opposite is true. Reducing quality reduces “better” and slows a work down. The same project managers are trained to resist requirements change so almost guaranteeing business customers will be dissatisfied with what is delivered and consider it “worse.”
• Slowing software development down makes it more expensive, remember: Cost = People x Time

Its not so much that Agile is a good model but that the competition is hopeless. It isn’t even a fair comparison. My belief is that Waterfall never really worked anyway, so comparing Agile to Waterfall is a false comparison – bang goes a big assumption.

In which case the, returning to the original question: “Is Agile Faster Better Cheaper?” the answer is really “Depends on what you are comparing it to.”