Agile

Why should I blog about airports? – this blog is about the business of software development. Well I could argue that its all business and within remit but I’m still its stretching it a little.

The reason to blog about terminal 5 (T5) is because past I have held it up as an outstanding example of lean practices in action.

• Compare and contrast: Terminal 5 and Wembley Stadium
• Terminal 5 is Lean

T5 is part of Heathrow airport, and Heathrow is owned an operated by BAA. In the past I’ve talked about T5 in isolation but, as all good system thinkers know, we have to look outside the immediate to understand the whole.

I think there are some interesting lessons to be learned from the recent mess at T5 and at Heathrow in general over the last few years. Some of these lessons might just help software developers.

Lets start with the re-occurring horrors that are Heathrow airport – well talk about the T5 opening mess another day. Take some examples:

• Disruption and Flight backlogs
• Reoccurring delays
• Baggage handling problems and cancellations
• Knock on problems elsewhere
• General unhappiness with the airport – I agree, I live close enough to it to make it pointless trying to use another and the experience is ghastly.

The paradox at Heathrow is that while T5 has been an exemplar case-study in Lean Thinking the rest of Heathrow shows many of the faults of traditional thinking non-lean thinking.

Travelling through Heathrow is an exercise in queuing: Lean Thinking tells us how to manage queues. Heathrow is an operating at the absolute limit of capacity, therefore it is highly efficient but prone to disruption. The slightest problem and everything is messed up.

While BAA managers have claimed that the opening of T5 would solve the problems they ignored changes on the existing terminals that would make real improvements for passengers. They have looked for a single big fixed (T5) over a myriad of smaller fixes.

For example:
• Why not strip out some shops and provide more seating? Why not strip out some shops and make popular ones bigger? OK I know why, because they make more money, we’ll come to that.
• Why not copy Liverpool airport and give people the option to pay for fast-track security? People who have a genuine choice will be more accepting.
• Why not give free water bottles for people who have their water taken off them at security?
• Why make it worse for passengers with petty, pointless rules? – the one that caught me last year was taking a cup of coffee (bought airside) with me to the departure gate. This is not allowed. Why not?

(By the way: has anyone noticed the one place at Heathrow where you can’t by a Grande Cappuccino? – The baggage hall, waiting for a case which may, or may not, appear is devoid of shops. Yet it’s the place where I’m usually most gasping for a drink, chocolate or newspaper to read while I wait.)

Part of the reason BAA has gone for the one big fix is because the myriad of small fixes requires staff co-operation, and it turns out Heathrow is a bastion of confrontational management, highly unionised workforce and prescribed working practises.

Customers have very little choice: BAA control the three biggest airports in the London area. Once you are at the airport BAA control everything you can do – doubly once you get through security.

So what are the lessons for software developers?
• Lean/Agile has its limited: No matter how lean T5 construction was the rest of the airport is a disaster. One group doing lean will not automatically infect everyone else.
• Pay attention to your customers: if you treat them badly they will start to find ways to buy competitor products, or simply stop buying (travelling). Vendor lock-in will eventually be broken.
• Queues work, they make you more efficient but they reduced your ability to react and change. Nobody likes queues, they make us all miserable. The fact that many software queues are hidden is no better.
• Management need to co-operate with those who do the work. They need to accept that a million small solutions can be as worthy as one big one.
• Short term gain (all those shop rents) detracts from long term improvement and customer experience. Sometimes the bottom line has to take second place.

Fundamentally the economics of Heathrow (and BAA and BA) are just wrong. I might go into that some other time, for the moment I’ll refer you to the Economist. Their analysis and solution is spot on. The objectives of BAA, shop holders, Government security, airlines and passengers are at odds. Nobody seems to benefit.

Perhaps the biggest problem is the business models of BAA and British Airways (which dominated Heathrow and is dominated by the airport) are utterly dependent on squeezing as many people through the airport as possible. This is not good for our national economy – let along London – but because BAA and BA carry so much political clout they are able to keep the Heathrow economic-fantasy protected. Making Heathrow responsive to real economics (as we did with coal mines, ship yards, steel factories and car companies) would actually solve the problems.

So the last lesson: It’s the Economics, stupid.

Software companies, unlike Heathrow, live in the real economic world. In the short run a company may be able to run a business model which harms its customers but customers have choice. So you’ve got to get the economic incentives aligned. If you are developing software make sure your economics benefit everyone: what is good your customer should be good for you.

Jobs and banks

There were a lot of bankers at the conference this year – or rather developers who work in banks. In truth this is always the case but this year I think there were more. It also gave the opportunity to find out what was happening in the financial job market.

Before Christmas I think many people were expecting a shake-out similar to that of 2001/2002 but it seems the effect of the crisis or credit crunch is very mixed. I observed a few weeks ago that one effect has been to push up rates and while some banks do seem to be shedding staff others are still hiring and demand is strong. I talked to someone from one (American) bank which had drastically cut back staff, while people at another (English) bank were still hiring lots, and another (Scottish) bank which recently bought another (Dutch) bank is having to hire lots of people to help integrate the systems of the two banks.

Lies, Damned Lies and Statistics

I’ve had a downer on metrics and statistics for a long time. But I’ve also been aware that getting the right data and measuring the right numbers is often the key to success. Tom Gilb is firmly in the numbers and metrics camp and argues a good case for measurement and targeting. I was lucky enough to spend lots of time listening to Tom and talking to him.

It seems that, as with so many other things in life, the key is doing it right. It is very easy to set the wrong targets, to measure the wrong thing and produce side-effects you don’t want. But when you look at the right numbers, measure the right thing, and set the right targets you can get great results.

But it isn’t easy, most people get it wrong.

Tom is a fascinating guy, if you ever get the chance to hear him speak do so. A lot of his ideas come directly from Deming – who he knew personally. I don’t think it is too much of an exaggeration to say Tom may be the Software World’s own Deming. If nothing else Tom interprets Deming’s message for software development.

Software development success

In an aside Tom also pointed out that the UK now has Royal Academy of Engineering and that they (not so) recently produced a report on software development. Its a shame that you can’t down load the report, I’d like to read it.

I notice the comment that “only around 16% of IT projects can be considered truly successful”. That 16% seems very close to the figures given in the MIT Sloan Review piece on the IT alignment trap last year. That report said 7% of companies had effective IT departments which delivered on business objectives and another 8% who were effective but were not aligned with the business.

Unfortunately that means 85% of us are working on failing projects. Depressing.

The 1968 wrong turn reconsidered

I’ve been heard to say that somewhere about 1968 the software industry took a wrong turn. We went down the route of engineering, planning and tools rather than people and learning. But the conference made me wonder, maybe it wasn’t such a wrong turn, maybe it was a diversion we needed to take so we could solve some problems. Now those problems are kind of solved we need to refocus on the people.

Maybe.

Product Managers

I have long claimed that UK business do not get Product Managers, this might now be changing. The term Product Manager was in wide use and more people seemed to have a Product Manager on their team.

Lets hope I’m right.

Still, there are too few Product Managers, too few of them are really good, their role is still misunderstood and there is not enough training for them.

Next years conference

I’m no longer on the committee for the conference but I still have conversations about it. It is already taking shape in peoples heads and promises to be an even better conference. For better or worse the conference is unlikely to get any bigger. If it were to get bigger it might loose some of its flavour.

I think the next 2-3 years will be an interesting time in the UK and European conference scene. The arrival of the profit making QCon is having an effect and I know there is some debate about the future, style, content and so on of other conferences. At a guess I think you might see one or two new conference appear and others (perhaps) disappear or change.

My book

It was good to see Changing Software Development selling, and fun to sign copies!

Latest figures say it is selling well, yippee!!!

This Blog

I met several readers of this blog at the conference. Seems they want shorter entries. I’ll try my best. But I’ve said this before and failed!

So I took the opportunity at SPA to ask Steve Freeman about it. Unlike me, Steve has spoken to David so here are some of the points I got:
• Kanban teams have given up on planning and estimating entirely. The activities took more time than they were worth. Prioritisation is – as far as possible – handed back to the business. The highest priority is simply done.
• Kanban teams have a number of ‘slots’ by which I think they mean ‘tasks they can be working on at one time’. The business decided what to put through these slots.
• Teams track how long it takes for a piece of work to move through the system. I guess they just note the start date and end date. They can then tell what their throughput is which replaces the need to estimate.
• Work is tracked by cards on a board. This visibility together with the flow measurement helps show where the bottlenecks are.
• The business may (i.e. not all teams do this) offer the business a ‘Silver Bullet’. The business can use this to cheat: to fast track a feature through the system, to do a feature without any of the usual pre-work, or such. However, the business is only allowed one Silver Bullet at a time.

It all sounds very interesting and I hope to hear more. And if anyone reading this knows any more – or thinks I’ve got something wrong – then please add your comment.

According to Steve, David is finding that his bottleneck is not development. The bottleneck is earlier, its with the business deciding what to do and what needs to doing. This is something I have observed myself. In fact I thought I had written a blog entry on this subject, perhaps with the title ‘The Bottleneck has moved’ but I can’t find it so probably I haven’t written it just thought about it.

Anyway, I’ll say it now: The Bottleneck has moved.

In my own experiences with my Blue-White-Red agile method, I found that while it took time for developers to do work this was simply leg-work. More developers more work. Quality improvements (unit testing, code reviews, etc) helped and these made the teams more productive. But when ever the developers needed to consult the business (i.e. product management) things slowed down. Or, developers took the wrong decision and re-work resulted.

And if we want to practice Lean development then we can’t waste time building the wrong thing. We need the business to support us.

Over the last 20-30 years developers have got a host of new toys to make them more productive: their own (fast) machines, more productive languages, nice IDEs like Eclipse, and so on. Surely some of this technology has boosted their performance. On the other hand, the pipe coming into development hasn’t go any bigger. If anything it has got smaller.

What strikes me about Kanban is that it requires more business buy in, more business acceptance of the method and requires the business to know more about its role and what it wants. This is good because it makes development more responsive to the business.

This is entirely what I would expect because, while Agile/Lean can improve development alone, it ultimately needs to exist in an Agile/Lean environment. If it does not there will be tension, eventually the organization will kill its Agile development or Agile development will infect the wider company. This might be what David is seeing (or creating!) with Kanban.

As I said at the start of the year I want to divert more of my writing into other projects. So this entry is here as a place holder and a preview of some stuff to expect. So please forgive me for breaking my one entry, one idea rule.

Those of you who know me off-blog will know I spent most of last year working with an Internet TV (IPTV) technology company. Some consultancy actually continued into the year, mainly with the CEO. Well now I’m please so say I’m going to get involved in IPTV again. I’m going to be doing some work with one of the major players to developer a completely new IPTV platform. Should be fun.

After XP Day last year I suggested that media companies are more open to Agile methods many other companies, specifically, banks. I am more and more convinced of this fact. Underpinning this is that fact that companies that use the traditional (broken) methods are still in business, these methods have brought them some success and fit with their business model – or their business model has been changed. Therefore these companies have little reason to go through a difficult change.

At ACCU London last month someone asked me: Why do banks have so many bad systems? It was that moment I realised: Because they can afford it. I hope to expand on this topic soon.

I’ve been busy with EuroPLoP 2008 and I’m at SPA 2008 next week, both look like being a good conferences. Then I’m at ACCU 2008 a couple of weeks later. Both of these will produce some reflections in this blog.

I’m going to be writing more about Project Management in the near future. Readers of this blog, and those who know me, will know I have been critical of them in the past. And I promise to carry on being so. But…

During the last two week I have taken Project Manager training, not just any training, PRINCE 2 certified training. Yes you read that right. Barring any surprised form the exam I took today I expect to be PRINCE 2 certified in the next few weeks.

So, why did I do it? Did I have a labotomy? Well it wasn’t an easy decision to spend nearly £1500 on the course but here’s why:
• I’ve criticised Project Managers in the past but this has been unfair, I haven’t really known what they should be doing, only what they do
• Increasingly I find that I’m asked to do Project Management roles, so the training should help there.
• More organizations look to PRINCE 2 to show you know about Project Management. To impress them you need to tick that box.
• I’d really like to understand how formal Project Management compares to Agile, and whether it is possible to bridge the divide.

I’ll write more about this soon but some immediate thoughts.

I had to do two courses for two exams, one last week and one this week. Consequently I’ve met over a dozen other people taking the same course and exams. Almost everyone of these people was an independent (contract) Project Manager in the IT sector. They were sending their own money to go on the course, and foregoing even more money by being there. Why?

Because increasingly PRINCE 2 is becoming a necessary qualification, if you don’t hold it your CV won’t get beyond the recruiter or HR department. PRINCE 2 fans are probably delighted to hear that. PRINCE 2 is wining! But actually I think its a very dangerous development.

This is because PRINCE 2 is massively risk averse. Of course PRINCE 2 practitioners would probably say “No its not, it just identifies and managers risk, you decide the risk level, isn’t that sensible?” but actually the very mechanism is risk averse.

Why is this dangerous? Because most companies – unlike the Government who developed PRINCE 2 – want to make a profit. Economists tell us “Profit is the return for Risk”. So, remove the risk and you remove the profit… more on this shortly.

Interestingly nobody on the course expected to actually use PRINCE 2. Even those sent by their companies (about 2) didn’t. So I don’t think PRINCE 2 is increasing in use, its just the qualification that is being asked for more and more.

Second insight. PRINCE 2 is not reflective, it considers the cost of projects, the cost of work but not the cost of itself. To run a full blown (or even half blown) PRINCE 2 is going to cost you a lot in administration and paperwork. That’s before you count the missed opportunities.

A few years ago I found myself introducing Agile at a company which hired a PRINCE 2 manager. We didn’t get on. We were both trying to do good for the company, and in many ways our prescriptions matched but … well I’ll explain where PRINCE 2 and Agile match soon, and I’ll explain why they are incompatible too.

Somehow I got cast as the zealot. Some people came to believe that I wanted Agile, Agile, Agile. He never got cast as a zealot, that only dawned on me this week. Actually advocating PRINCE 2 and its practices the way he did was every bit, more so, as zealous as I was. But…

PRINCE 2 is so respectable nobody will call you a zealot for advocating its use. Its like suggesting you play Bach or Mozart. How can anyone object? Its respectable. Agile on the other hand is punk, its putting a safety clip in your nose and taking risk. No wonder I was seen as the bad guy! Now, once my certification comes through….

Recently I’ve been consulting with a company which has a truely awful code base. The developers want to re-write it, naturally. Unfortunately the the code base isn’t the only problem, the company has other problems and matters aren’t helped by Kissinger-esque linkage with other issues. I’m not going to say anything else about them except to say Conway’s Law was clearer than ever.

And its not just software people who stuggle with the question: Is it better to re-wright, or not to re-write? This piece from last week’s FT shows English lawyers and tax authories have the re-write problem.

Bronek sent me a link to Portrait of a Noob by Steve Yegge – not a blogger I read but I’ve been sent several of his posts by people in the past so I know of him. In many ways I find this reminiscent of my own High Church C++ pieces from a few years back. Both pieces point out that quality code is subjective, what you think of as good code in one context is not the same as what you consider in another context. Steve is right to point out that your persepctive on code changes. In particular, as you get older and acquire more experience not only does you coding style change but the way you approach problems changes.

As someone pointed out on Thursday night, you also need to remember Fred Brook’s and the Second System Effect:

‘This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.’

I’ve long wanted to conduct a little experiment. Take a developer, take a system he developed in the first few years of his life. Wait long enough for him to forget the details, say 10 years. During that time let him learn, gather experience and continue developing systems. Now ask him to make changes to the system from his early years – with all the identify removed of course. My theory is, he will proclaim it unmaintainable and in need of a rewrite.

That is a little unfair actually because one of the things you learn as you get more experience – OK, get older, lets not beat around the bush – is that all systems are maintainable. The other thing you learn is that rewrites usually end in failure.

Our education system has it wrong. At school and college we learn to new write new code. But most developers spend most of their time maintaining old code. Our education trains us to believe a lie, that we write new systems. For the first few years of a graduate engineer’s career he is disappointed, he searches for ‘green field’ development and faced with an old system he throws his arms up – ‘Re-write! We must re-write!’

Not only are young developers sadly disappointed by the state of the world they are a risk. Sometimes people believe them and let the re-write the system. (Believe me, I was once that developer. I persuaded my employer to let me re-write a system. It was a mistake. )

Colleges need to recognise this and start setting assignments were people must maintain code written by others. Systems should be handed from one year to the next for changes.

As a developer gets more experience they learn how to work with existing systems, when to re-write parts and when to work around. The hallmark of an experienced developer is that they do not jump to say ‘Re-write!’ – they can at least present options.

In fact, the hallmark of the best developers is that do work with legacy systems. Anyone can write a new system, we get trained for it in college, its what the books describe, there are few limitations. You can create your own mess, and you usually know your way around your own mess.

But the best developers can work with someone else’s mess and still find gold.

• The Location Myth
• The Documentation Myth
• The Requirements Myth
• The Egoless Programming Myth
• The Design & Planning Myth
• The Plug Compatible Programmer Myth

I like this idea… maybe I can find some more, any suggestions?

• My brother lives in the UAE so we talk by phone. We would use Skype but the local telephone company blocks Skype and various other services.

• I have several kitchen containers from a New Zealand company. I bought them in the UK and would happily buy more but they are no longer stocked in any shop I know – and believe me I’ve tried. I could order them online from the US but the American shops won’t ship outside of the USA and Canada.

• When I’m searching the web, particularly if I’m looking to buy something, and I find the kind of site I’m looking for I want to know where are they based? London? Cardiff? Chicago? Mumbai? I have nothing against India companies, or American companies (provided they will ship abroad) but when I’m faced with a site I’ve never heard of I want some kind of reassurance. Their location is part of that. OK, there are fraudsters in London as there are in Chicago, I’m unlikely to chase them myself, and they could be lying about where they are, but it all adds to my understanding.

In short: the internet makes many things possible over long distanced but location still makes a difference.

The same is true in software development teams.

You can have people located in different offices, different parts of the world, and you can use telephones, wiki’s, Skype, video-conference kit, etc. etc. to work but it isn’t the same as having everyone in the same place.

When you locate people elsewhere you incur extra costs. Obviously the cost of telephone calls or bandwidth but these are a small part. As you use more technology (conference calls, video conferencing, shared whiteboards, etc. etc.) you incur more and more direct costs. Even wiki’s take time to installl, and time to use.

You also incur costs because conversation often need to be arranged. So I might IM someone and say ‘Can you talk?’ and 20 minutes later they get back and say ‘In 5’. The need synchronise before talking slows down the process and there is a cost of asking.

Then there is the cost of missed conversations. We make small talk, trivia, at the water cooler, or walking to lunch, or because someone is there and we want to moan. When someone is remote these conversations are lost. We incur cost because we don’t get the benefits of these costs.

Then there is the cost of setting up meetings to compensate. A few years ago Lise Hvatum and myself ran a focus group at EuroPLoP entitled ‘What do we think of Conways Law now’. One of the recommendation we came up with was: when you remove an informal communication channel you need to replace it with a formal one.

So when we have lots of remote workers you need more formal, arranged in advance, meetings. This ads to the costs again.

And when you do talk the level of information transfer is less. Even with video conferencing your primary communication mode is voice. Communication is centred on explicit words. Face to face much communication is implicit, its in the tone of the voice, the facial expressions, the body language and how other react. You loose all this when you are remote.

Lets face it, software developers don’t have a great reputation for communicating well anyway so why put obstacles in the way?

Every time we put an obstacle in the way we reduce information transfer. This goes for cubical walls and offices too, open plan offices are my preference. Every barrier, cubical partition, different floors, different buildings, different continents, reduces information flow. The bigger the barrier the bigger the loss.

And for a development team – focus on that word: team. Who ever heard of a football team which played on different pitches?

Team work is about just that, team work. You can’t do it when you are alone. Every barrier makes team work more difficult.

It is an illusion to think that you can develop software when your team is spread around a single building let alone the world.

This is especially true for people who are in leadership positions in an organization. You can’t have a CEO, a team leader or an architect who is removed from those he leads.

Sure there are exceptions. A few companies are completely distributed, Sleepycat software – before Oracle bought them – springs to mind, as do Open Source projects. On the whole these work because they are born on the internet.

The other reason remote working teams work is because they aren’t so much a team but a bunch of individuals, each working on their part of the system and seldom interacting with each other. I think of these as Swordfish teams – a bunch of developers flying in formation. As a result (Conway’s Law again) you are likely to end up with a very diverse system architecture.

Don’t get me wrong, I’m a big fan of working form home once in a while. The odd day spent working at home can be really productive – precisely because I have few conversations and can focus on one or two things. Working from home is great for reflecting and preparing oneself.

And it is acceptable for large teams to have the odd person working remotely. But the smaller the team is greater the need for them to be in one place.

Maybe once upon a time developers could work alone, remotely. They could put on headphones and switch off to the rest of the world. But today developing software is a team sport and needs to be played like one.

I say that as one who has never liked team sports such as football, rugby, cricket, etc. I’ve always preferred solo sports like skiing, running and swimming. I have to adopt and change too.

Yes, programming is really easy. You can buy ‘Programming for Dummies in …’ – well just about any language you want. People can, and do, create small world changing programs without ever really being taught how to program.

That’s why software development and new businesses go hand in hand. Its one of the reasons why so much innovation today appears as software.

But….

Software development is also one of the hardest things. In fact, developing good software is so complex it might be the most complex thing man has ever attempted.

Moon landing? – it used software, compared to the complexity of the systems in the international space station I’m sure Apollo looks simple.

Nuclear power? – compared to the maths used by the finance industry today it looks simple. And that is all in software.

The thing is, writing a small piece of software can be (but not always) very easy. Problems set in when you want to grow the software, want more people to use it, want to sell it, want to package it, want to re-use the code or ideas, take bugs out of the system, add features, make it run 24×7.

It is very very easy to write simple software and have it do something useful. It is an order of magnitude harder to get it to commercial quality and keep doing it. And, to make it harder, there is no single accepted method for doing this and getting it right every time.

It sometimes amazes me that we get any of this right. More amazing is that software which is fundamentally flawed works, or at least seems to work. Stuff which by any engineering criteria is broken is used by companies every day, they even base their business on it. (There is another blog entry in this.)

Developing good software, delivering on time, producing with sufficient quality, etc. etc. – all the things you expect from ‘professional systems’ is a matter of getting your Ducks in a Row. What I mean is…

Creating good software, meeting expectations, delivering on time and the rest is not just a matter of getting one thing right. It is a matter of getting many things “right” – or at least workable. You can get some of these wrong and still delivery something – maybe a little late, or lacking features but you will do something.

Each time you do something badly, each time one of your ducks is out of position, you won’t break the whole thing. This isn’t a chain, instead of breaking you will reduce your productivity, or move away from the target, or reduce quality. With each duck that moves out of position it gets worse but it still works, somehow.

Put it another way. If creating ‘the best software ever’ means scoring 100%. Each time you move a duck out of position you remove 10%. So:
• don’t co-locate your developers, loose 10%
• start work without talking about design, loose another 10%
• work to a fixed specification or work to no specification loose 10% as well.

Down to 70%.

• Fire developers half way through the project, loose 10% for lost productivity, loose 10% for moral.
• Projects looking late, add more developers, loose 10% for violating Brooks Law.

40% doesn’t look good does it?

But there aren’t many case where you need to score 100%. 90% will do, even 80%, 70% often, some customers will be happy with 40% – or less.

The people who get upset most by this?

Not customers, they get annoyed but quite often there is nothing they can do about it.

It is the developers themselves. They see each loss, they know where all those 10% are being lost. And these guys are problem solvers, they want to fix these problems.

Now go back to my falling off a log theory of business.

I said: you do something right. Not 100%, maybe you just need 10%. But that one thing is about doing something useful, something other people want. Its about benefit and effectiveness.

Viability of your software product/company =
benefit of your software
x
effectiveness of your organization

If your software doesn’t bring many benefits then you need an effective organization to stay in business. You have to be better than the rest.

If your software brings lots of benefits then it doesn’t matter how ineffective your organization – shoot the ducks! – you will stay in business.

If your software has few benefits and you can’t deliver, then Game Over.

Which leaves… lots of benefits and a highly effective organization. Then you have a world beater.

Unfortunately few companies fall into the last category which leave most people working in one of the first three.