Agile is like sex

I’ll get back to software development economics, there are more posts in the works, but right now I need to say something….

I have blogged before on the subject of “What is Agile” – I’ve even expanded on that blog in an unfinished piece of writing called “What is Agile? Perspectives on Agile” – but sometimes I think its just sex….

(OK, this blog just got filtered out of lots of feeds and stopped by lots of firewalls but lets continue.)

In the software development world there are, broadly speaking, two groups of people: those who create the software (coders, testers, etc.) and those who manage the process (project managers, development managers, etc.). When discussing “Agile” I find that both sides think the problem is with the other.

To put it another way, if I’m talking to developers they think its managers who are the block to adopting more Agile techniques and improvement. But when I’m talking to managers they say its the developers who resist Agile and other improvements.

Which always reminds me of the old Philip Crosby quote:

“Quality has much in common with sex. Everyone is for it. (Under certain conditions, of course.) Everyone feels they understand it. (Even though they wouldn’t want to explain it.) Everyone thinks execution is only a matter of following natural inclinations. (After all, we do get along somehow.) And, of course, most people feel that all problems in these areas are caused by other people.” Philip Crosby

Lets bring it up to date and make it Agile specific, substitute the work ‘Agile’ for ‘Quality’:

“Agile has much in common with sex. Everyone is for it. (Under certain conditions, of course.) Everyone feels they understand it. (Even though they wouldn’t want to explain it.) Everyone thinks execution is only a matter of following natural inclinations. (After all, we do get along somehow.) And, of course, most people feel that all problems in these areas are caused by other people.” Allan Kelly after Philip Crosby

You see? It fits.

Agile isn’t someone else’s thing, it doesn’t belong to another person: Its yours. You are as likely to be the block as the person you think is the block.

Software supply & demand – this time its Agile

Carrying on from my previous posts applying the economists tools to thinking about software development (Supply & Demand in software development and Software supply over time). In this post I want to see what happens when we apply Agile…

We start with our supply and demand curves as before:


First we need to define Agile, not a trivial matter. Lets simplify this by saying “Agile practices”, specifically:

  • Short iterations and regular releases (or at least demos), e.g. every two weeks
  • Planning meetings, planning poker estimation (or similar, or #NoEstimates), velocity (or commitment if you prefer)
  • User Stories, Epics, task breakdown (if you do this sort of thing)
  • Stand-up meetings
  • Team retrospectives and team planning boards or electronic equivalent
  • Test driven development and continuous integration
  • Pair programming, code review and shared code-ownership
  • Acceptance Test Driven Development (ATDD), Behaviour Driven Development (BDD), Specification by Example (SbE), and other automated testing mechanisms

The first thing to note about all these techniques – and indeed the majority of what we tend to call “Agile” – is that these techniques work on the supply side. They operate on the supply curve, the net effect is to increase supply.

Possibly, if used in the right fashion, BDD and SbE might effect the supply side. But since most of the efforts to use BDD I encounter are little more than super-charged TDD we’ll leave it there for now – see Dan North’s blog for a better discussion BDD v. TDD.

Projects – specifically projects but other work initiatives too – are often still judged on the basis of: on schedule, on feature and on budget. Agile in this fashion is what I have called Iterative Agile, or at best Incremental. The team is still seeking to deliver a fixed quantity of software. Thus the demand curve is unchanged. (We will return to the demand curve in another post and discuss how Agile techniques might affect it.)

While Agile tools promise increased performance this is only in the long run. In the short run we can expect teams to slow down as they adopt these tools. We can also expect costs to go up as companies to spend money to buy in this expertise.

Maybe they hire the likes of myself to supply training and consulting in adoption (yes! I’m for hire, see my company website Software Strategy). Even if they don’t pay the likes of me costs will go up because engineers need to learn these skills. Companies rationale for hiring me is that I will help reduce the period of time for which they are slower and reduce the risk. The deal is: hire me and I will help you get to increased productivity faster (and with less risk).

Putting this in terms of curves:


A team starting on Ss can expect to move left (1) to Sasr (agile short run) before moving to the right (2) – Salr (agile long run) – reduced supply before greater supply. In the first instance the price per unit increases while the quantity delivered falls but after the second move the price per unit falls and the team produces more software.

Leave consultants like me to one side for a moment and simplify it. Imagine a team which “just does it”. Assume for a moment that the team members stay the same and the amount they are paid each week stays the same. When the team start doing something new they slow down, they produce less software each week so the average price of per unit increases. As they get better the same team better their original performance, earn the same money, produce more software and as a result the average price per unit falls.

Hopefully that all makes sense and isn’t controversial.

But I think something else happens. This is a hypothesis, at the moment I can’t measure it so please tell me – in the comments on this blog – whether you agree or think I’m wrong.

Staying with the supply curve, consider again the tools we were looking at:

  • Short iterations and regular releases make it cheaper to make small changes. Therefore the supply of the small quantities of can should take place at a lower cost. And since the delivery – or at least a demo – is earlier the whole “project” could be cancelled if things don’t work out. Thus the bottom of the curve moves left over time.
  • Automated testing (TDD, ATDD, etc.) reduce the quantity of faulty software produced and increase the amount of useful software increased at any point thereby raising all points on the curve. With less “technical debt” teams can deliver more functionality more cheaply.
  • The same techniques – TDD, ATDD, etc. – and shared code ownership also make it easier for new engineers to become productive because a) there are more code examples of how the system works and b) places a safety net under any work they do, allowing them to experiment and learn faster, and get their changes to production sooner.

The net consequence of these changes is to flatten the curve, not entirely but certainly reduce of an angle. In economics terms we increase the elasticity. Changes in price – adding or removing a developer – causes a bigger effect on the quantity supplied than before.


Supply moves from the initial Ss curve to the Savlr (Supply Agile Very Long Run). As the chosen name implies, this takes some time to occur.

Now there is a catch. Consider the total amount of software bought and the total price paid (price x quantity.) To do this look at the next two diagram.


The green area represents the total paid for the software. You can’t see it here but on my graphics tool I can see price is 10 high and quantity 7 wide, so 70 (whatever) units.


In this diagram, on the new supply curve, the blue area represents the total spend. Again you can’t see it but on OmniGraffle it is 5 high and slightly more than 9 wide, almost 45 units of total spend.

Now if you are producing software for your own company – either to resell (e.g. Microsoft) or to consume yourself (e.g. a bank) – this model is good news. You get more software for a lower overall spend.

But, if you are an outsourced provider of software selling custom software to a client this is bad news. You now deliver more software for less money, about 36% less in total. If profit is tied to revenue (time and materials) then this is bad.

No wonder outsourced providers can be reluctant to embrace Agile or to do it badly. If you are a consumer of outsourced software development services you might want to think about that.

Next time I want to turn my attention to the software demand curve.

(As a footnote, using the same analysis techniques it is possible to show that reducing supply of software – moving the supply curve left, either because the software ages or because Agile adoption is slowing things down – will result in a greater overall spend for less software. This might be good for outsourcer suppliers but isn’t so good for in-house development.)

Blog revisions: economics

Although I don’t think I’ve ever stated it I operate a “no revisions” policy to this blog. I don’t take things down, and I rarely modify past entries. OK, I might change it in the 10 minutes or so after I first post to fix typos and gaffes I see once I see it online but otherwise I avoid doing so.

But my recent posts on software economics, supply and demand, contained inaccuracies. Or rather the graphs I published didn’t follow economics convention. The logic was (mostly) right but the graphs were wrong. I rushed out one fix and breathed a sigh of relief.

Then last night on my way back from Riga I noticed another flaw. I won’t go into details but I’m now fixing/fixed it.

Several times in the past I’ve attempted to capture my thoughts on software economics but nothing I’ve ever written has seen the light of day. As I continue this analysis I’m finding more insights I hope to share. I’m also – possibly – making errors.

I hope other readers who think they know economics can help debug my posts. They will be better for it.

In the meantime, sorry.

Software supply over time

Having outlined the theory of supply and demand in the software market I want to spend this, and the next few posts examining what this analysis can teach us. I’m starting with the supply curve and will look at the demand curve later.

First I want to consider what happens to a software system over time if nothing else is done. (Consider this as a small detour before we consider Agile.)

Over time changes to software systems will add code, this means there is more code to maintain, more code for engineers to understand, more code for testers to test. Internally code quality tends to decay, some people call it software entropy.

Engineers leave the team and new engineers (might) arrive thereby loosing knowledge of how the system works. At least the knowledge is diluted. And if maintenance is outsourced or offshore such knowledge may be destroyed altogether. The new, cheaper, outsourced developers need to relearn.

Meanwhile the business environment seldom becomes any simpler. New business rules get added one place or another – increasing complexity. New systems need to be connected – either as data sources or destinations – which again increase complexity.

This all gives rise to the Big Ball of Mud pattern.

Finally technology changes. The operating system and databases which form the foundations of the system may be upgraded or replaced. In the worse cases the language the system is written in dies.

The net result of all of this is that the system becomes harder to maintain. Harder translates to more time and more time translates to more money. Thus the system becomes more expensive to maintain. Consequently the supply curve for the system moves to the left. For the same price we can now get less software.

Consider the graph below. We have the Supply of Software (Ss) and Demand for Software (Ds) curves as before. Now we add the Supply of Software over Time (Sst) curve. Over time, of nothing is done, the curve itself moves, all other things being equal we do not move to a new position on the curve. We get an entirely new curve.


Now it is possible to fight against this trend. And certainly there are plenty of tool vendors out there who will happily sell you a tools which they claim will move the curve in the opposite direction. (In economics terms we break the “all other things being equal” assumption.”)

But either way: unless you fight it things will get more expensive for the same quantity of software – or you get less software for the same money.

Supply & Demand in software development

(Whoops, I’m publishing a revision of this blog entry – something I don’t normally do. I realised after publication that I had mislabelled the graphs – they were correct but did not follow economists convention hence this revision. The core argument still stands although I have had to modify the reasoning slightly. Sorry.)

I’m proud to say I am, or at least was, a Software Engineer. I’m proud to say that I’m a third generation Engineer. My farther and grandfather got their hands dirty with the oily sort of engineering. But I’m also a frustrated Economist. Economics forms part of both of my degrees and on a couple of occasionsI’ve been temped to become a real Economist.

So I am always disappointed when someone talks about Software Economics. I have yet to find a serious study of software economics. Most of the studies, books and papers about “software economics” would be better called “software accounting.” They are about apportioning costs and adding up numbers. Economics is not Accountancy.

I have long believed software engineers and their managers would benefit from a better understanding of economics. In fact many of my clients will be used to hearing me refer to the supply side (development) and demand side (requirements, analysis, etc.).

I find it very useful to think of software development in supply and demand terms and use the tools of economists to understand what is happening. Usually thinking like this shows there supply and demand to be mismatched.

(This blog post that has been a long time coming. Several previous attempts have floundered because there is so much I want to say about software economics – and thinking in supply and demand terms. So while there might be little in this post which is earth shattering – especially to those of you who have studied economics – later posts will build on these ideas and analysis.)

Lets start with the fundamental problem which economic theory addresses: the allocation of scarce resources. After all we have scarce resources in software development so lets use an Economists tools: supply and demand.

Lets have a look at the supply curve:


The line marked Sn is a normal supply curve. When price is a bit greater than zero individuals will start supplying their services and companies will come into being to supply the market. As the price increases more individuals and companies will be attracted to the market and supply will increase, more resources are brought to play.

Note two things here:

  1. Economists usually draw these curves for a product within a market. Here I am not examining the supply of multiple copies of a software product, rather I am examining the supply of software development capacity for a unique product. The marginal costs of supplying existing software are as close to zero as to be zero, the marginal costs of supplying new software products – i.e. the capacity to create a product – is significantly larger than zero and that is what we are examining here. In software terms we need to consider a software product, perhaps a single program, perhaps a “project” or a small system.
  2. If you are not an economist don’t worry about the fact that these “curves” are straight lines, the basic analysis still holds, we hold actual curves for an advanced class.

The software supply curve – Ss – starts the same way. When price is zero nobody supplies – perhaps not entirely true if we consider open source but close enough. As price increases more resources are brought into play and supply increases.

Software development is not cheap. If you are buying software developer services they are rarely cheap. The only time you get “cheap” software is when you buy (some) off the shelf stuff. Consequently when the price is low there is no supply of custom software.

But – and this is the BIG BUT – supply raises very slowly. Two people might write twice as much code as one but when they work together the generalised form of Brook’s Law comes into play: adding people to a software development effort slows a team down. Therefore supply responds slowly to price increases – what economists call inelastic.

Now consider the demand for new software:


Here Dn represents demand for a normal product, when the price is high there is little demand for the product. As the price falls the demand increases because more people can afford it. (Remember an Economist’s definition of “Demand” is “A want with the ability to pay”. I may want a new iPad Air but if it is more than I can pay there is no demand – some might call this “latent demand.”)

For normal products, in time, the market will “clear” and balance will be reached when the curves meet:


At some price (Pn) the quantity supplied (Qn) will match that demanded. Now economists accept that this might not happen instantly – and there are various models for that – but in the scheme of things the time it takes for the market to settle is not a big issue. It will happen eventually.

Until that happens all sorts of problems will ensue, some people might make a lot of profit, some people might go without and some people might have to pay a non-financial price, e.g. queues will form. All good stuff we could consider but lets leave that for another day.

Returning to the demand for software. People and companies do not want software for its own sake, they want software because of what it allows them to do. What Economists call a “derived demand”.

The problem is, and the reason I’ve drawn the the Ds curve as highly inelastic is that we are faced with an ever increasing demand for software. Processor power doubles every 18 months to two years (Moore’s Law) which means the things our computers are capable of doing – with the right software – is forever expanding. When we get this right the benefits can be massive. Which increases the demand for software…

  • How many readers wanted to read newspapers on their telephone three years ago?
  • How many readers knew they needed to watch TV on an iPad five years ago?
  • How many readers took digital pictures with their telephone and posted them online on a social network to instantly share them with friends and relatives seven years ago?

So lets look at the software supply and demand curves together:


For me, the problem in software economics:

  • Demand is rampant but inelastic so as price rises it does not fall off very fast
  • Supply is severely constrained and is very difficult to increase (particularly in the short run) so is also inelastic
  • Consequently the market only clears at high prices and slowly: consequently markets take a long time to reach equilibrium, which in turn means we need to consider the tensions arising in a market which spends so much time out of equilibrium. Thus the time lags which normally only play a small part in classical economic analysis are more significant.

Each of these statements deserves further examination and explanation in their own right – future blogs, maybe.

More importantly, and also deserving of its own blog entry, is the question: what can be done to bring this market into equilibrium?

That is the question I find myself wrestling with on behalf of clients, and it is one I will return to.

Sprint, Iteration or Marathon?

A shot blog on terminology…

I have always found it hard to differentiate an Iteration from a Sprint, so much so that I commonly say they mean the same think. They are synonymous. I use the two interchangeably. The difference is historical, term “Iteration” originated in XP and “Sprint” in Scrum.

To me both mean: a short period of time in which work is done.

Occasionally people have attempted to differentiate the two terms but I’ve never been convinced.

At Agile on the Beach, in a private conversation, Rachel Davies suggested a difference which I think stands up:

“Sprint means a fixed period of time during which the team commit and work towards a fixed goal which does not change. Iteration means a fixed period during which the team undertake some work – no commitment, no fix work.”

Most of the time the difference probably does matter but I like Rachel’s differentiation. It ties Sprint quite closely to Hard Core Scrum.

I really should try to stick to Iteration.

Actually, I think the real Sprints occur when:

  • A team starts a new piece or work and they have no idea what they are up against. They are sprinting to maintenance mode. Risk is highest when sprinting, until the team have their walking skeleton – a thin slice of functionality that does something tiny
  • Or when a team are first trying a new way of working (probably Agile like). They have a short period of time where the rest of the organization doesn’t know what they are doing, or if they do will extend good will to let the team try. A honeymoon, if you like. At the end of that time the team need to be able to show something better. Otherwise the good will is gone and with nothing to show for it people feel let down Again risk is high.

Real software isn’t about sprinting, real software development is a Marathon. You need to pace yourself. The danger with constantly sprinting is that you burn out.

Real software development is a marathon run in laps. We call the laps iterations.

Beyond Projects, Beyond #NoProjects

StopNoProjects-2013-10-23-08-01.pngMy recent “#NoProjects – why projects don’t make sense” post stirred up a fair bit of discussion, both on the blog and especially on Twitter – check the #NoProjects hashtag. But, while that post railed against “projects” it didn’t say much about what we should do instead. Indeed as was pointed out it might be better to advocate and rally behind a positive alternative rather than negative idea.

So let me try and put in place the outline of how I see a #NoProjects world working.

(Strictly speaking it might be better to use the hashtag #BeyondProjects but a) #NoProjects has already built up momentum, b) #NoProjects actually describes what we are talking about quite well and c) #NoProjects has 4 fewer letters than #BeyondProjects.)

Stable teams: first off the teams that do the work need to be stable and they need to be kept together over the long run. Of course teams will sometimes loose people and they will sometimes expand. But over the long run we want team members who will live with their creation and grow with their creation.

Teams rooted in business: These stable teams needs to be based with their business users and customers. There should no divide between “the business” and “IT”. IT shouldn’t be hired guns who get called up when there is a problem.

Increasingly, as more and more everyday business depends on technology “the business” is a technology business. IT departments as we know them may cease to exist in time.

(Naturally there are some differences between Beyond Projects in a corporate IT environment and in a software vendor environment. I won’t go into the details here. But, on the whole it is corporate IT departments who have a project obsession and practice corporate psychopathy. Continuity, if not stability, is usual the norm for software vendors.)

Business as usual (BAU) is the source and destination: Everyday business, business as usual, is the source of requests for technology changes and the destination for such changes. Many of these changes will be small – incremental – but others will be big. The people who do the work will be involved with uncovering the need for change and in working with the change when it occurs.

The need for change management will decrease considerably because IT will no longer be inflicting change on unsuspecting users. Instead technologists will be bringing requested improvements to willing customers.

If you need change management then it too will be based in the business lines of work. So too will be testers and business analysts. In fact the role of business analyst will become far more important because they will be charged with work with real stakeholders and helping them find ways to improve the business processes, products and delivery. BAs will look more like internal consultants than the order takers they are sometime used as.

Continuous stream of value: the result of this model will be a continuous stream of value. Technologists will be delivering improvements to the systems regularly, every few weeks if not every day. The batch size for work request and delivery will be one.

Again, as more and more businesses become IT businesses – business which can only exist and compete through the use of IT and IS systems – the value delivered will be bottom line value allowing the business to compete and stay ahead of competitors.

Portfolio management: this is not to say that all lines of business – and technology teams – will exist for ever. Some lines will need be to closed. Some teams will need to survive with less technology. Conversely, work streams which are seeing growth and performing stronger than the wider company will benefit from more resources.

The activity of reviewing work streams, increasing capacity, reducing capacity, starting new initiatives and terminating existing ones needs to be pursued more rigorously than before.

True portfolio management needs to be practices on a regular basis – at least every three months. And it needs to look at value delivered, potential future value and costs. Portfolio management which looks at progress against plan, or measures success as “on time, budget and scope” has no place is the Beyond Projects world.

Train1small-2013-10-23-08-01.jpgLike trains: trains run on schedules and so should software projects. When trains leave the station late and arrive late they are poor performers. Just the same goes for software work. We want work which begins on schedule and arrives on schedule.

When this happens co-ordination becomes simpler. The train schedules are known weeks and months in advance. Yes they change sometimes but not often. When you know the train you are going to get you arrange your journey around that.

When you have to take connecting trains you know how much time you need. You might allow a buffer or you might take a risk and run between platforms. How many of you readers have missed a train or a plane recently? Humans are very good at working to deadlines and very poor at estimate how long activities will take.

Co-ordinating multiple pieces of work between different teams becomes a process of putting the features/functionality you need from another team on their train. You inject work into the other team. And the receiving team will be able to tell you their schedule and whether the train you want to put a feature on is overloaded. They might even offer you a discount for going off-peak!

Project managers: obviously without projects there are no projects to manage. But does that mean the end for the people we call project managers?

I think not, there is still work to manage. I disagree with many in the Agile community – and particularly the Scrum community – because I don’t think all management work goes away. There might be less but I think those who argue “you don’t need managers” don’t really understand management work. (In truth most managers don’t either. Go and read Managing by Mintzberg then we can talk about what managers actually do.)

Many of the skills good project managers have will still be needed. They may take on another co-ordination role or they may become business-as-usual managers. Rather than having “Project Manager Call Centre Renewal Project” on their business card we might see “Call Centre Development Manager”.

Management roles will still exist but they will manage real work.

Goodbye matrix management: with projects gone and technologists based in the business much matrix management should disappear. Matrix management has never looked like a great idea, at best it is confusing at worst it is dysfunctional.

There will be more line management and there will be more need for business line managers to understand technology. Some of those surplus project managers will be well positioned to take up the new roles.

(Indeed I suspect that the proliferation of project managers in the last 20 years has much to do with the reduction of middle and junior managers that occurred in the 10 years before hand. First corporations cleared out their management ranks, then reinvented them under the cover of “projects.”)

There then are the basics of #NoProjects, Beyond Projects. I’m sure there is much more I could say and much more I will say in time.

If you have any opinions on this please add them below, I’d really like to hear what people think. And especially why you think I’m wrong, what have I missed? Go on, tell me!

11 Myths & 2 Truths of Agile – Infographic

Abi Crafter at Countersoft liked by “11 Myths and 2 Truths of Agile” blog entry so much he turned it into this Infographic. Thanks Abi!

(Some of you might have noticed that a reworked version of that blog appeared on Agile Connection as Top Twelve Myths of Agile Development.)


By the way, notice I’ve linked to Abi and his company Countersoft. Abi did something I like, Abi gave me something, I’m more than happy to give him a link for that. I don’t necessarily endorse his tool but I might well look at it.

I regularly decline – or plain ignore – requests to review particular products in this blog. Similarly I mark comments which don’t really say anything but include a link as spam. Unfortunately most such comments seem to come from Indian companies which reduces my opinion of the Indian software industry.

#NoProjects – why projects don’t make sense

In the last few months Steve Smith, myself and others have been Tweeting a lot with the hash tag #NoProjects. We have independently come to believe Projects are a smell, they are bad for our industry (the technology industry). Steve set out his thinking and now it is my turn.

Right now this is little more than a bullet point list, I’m presenting to PROMS-G in February (“The End of Projects”) where I will present a more coherent argument. Until then here goes.
Lets start of by defining “A project”.

The Project Management Institute says:

what is a project? It’s a temporary group activity designed to produce a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. … The development of software for an improved business process, the construction of a building … — all are projects.
And all must be expertly managed to deliver the on-time, on-budget results, learning and integration that organizations need.”

PRINCE2 defines a project as

A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.

Actually, PRINCE2 has two definitions of a project:

“project management is the way of managing change. Everything from the Olympics to organising a wedding can be considered a project. It describes the activities that meet specific objectives and can be used to introduce or improve new or existing products and services.”

Bearing this in mind I suggest the project model does not fit software development:

  • Projects have end dates – successful software doesn’t end, it not temporary. Finished software is dead software, software that isn’t used and doesn’t change
  • Successful software is continually developed and improved, the team is not temporary, it continues to exist (although it might change composition and the imposition of the project may at times destaff it)
  • Resources change: sometimes the people decide to leave of their own accord, sometimes the wider organizations decided to remove people or add others
  • The project model implies we can define what needs doing before we begin and that it won’t change. Software development uncovers need as it proceeds.
  • Project thinking implies that the problem can be defined independently before the solution: in software development the creating of a (partial) solution can lead to a redefinition of the problem being addressed.

Those points might be enough to persuade you the project model is not a good fit for software development. I go further, I think the project metaphor actively damages software development and destroys business value:

  • Project success criteria are “On time, On budget, On scope” and not business value. These criteria become a distraction and a barrier to hide behind – a “social defence” to use the jargon. Work should be value seeking and judged by the value/capability/benefit/[whatever you want] rather than arbitrary criteria which seemed good one day in the past.
  • Corporate Psychopathy: why disband a performing team just because a project has ended? Why start a project by pulling together a new team who have never played before?
  • Destroying team destroys knowledge – knowledge has value, knowledge exists in heads not documents
  • Project thinking induces short-termism – around quality, around productivity and around teams especially. Project thinking builds pre-fab houses when it should be building to last
  • Large batch size: projects lump lots of work together and attempt to manage it all as one large unit. This is inefficient (software has dis-economies of scale), breaks flow and delays delivery which delays value realisation
  • Project thinking makes BAU a dirty word; BAU is not a dirty work, BAU is where the action is: if it is worth doing it is worth doing more of, if it is not worth doing then close it down. Use portfolio management rather than pre-defined cut-offs. (BAU = Business As Usual, a common corporate term)
  • Projects inflict change on people (employees): why not seek their involvement? They own the work, they are BAU, the work stream should be seeking to improve itself as part of its daily work
  • Continuous improvement is continuous. Projects stop continuity, projects break flow and reduce effectiveness. Continuous improvement should be part of the fabric of everyday work, supported if need be by technologists.
  • Project thinking create scheduling projects: “Project B after Project A has finished, but if A is late….” – define work streams and feed them work
  • Projects confine change to projects and freeze change elsewhere
  • Start-up costs: bureaucracy, administration, etc. of starting a project mean the project model is expensive and slow at taking action. Project setup costs detract from value and the time it takes to “launch” a project detract from responsiveness. On a small work effort the costs of creating a project may be disproportionally high which may detract from attractiveness of doing the work. Similarly the time it takes to get a project scoped, a team assembled, everything kicked-off, performing and delivering creates a barrier to seizing value.

I recognise that a lot of what is called “a project” isn’t, it doesn’t fit the definitions at above. That simply makes things worse. Calling something a project when it isn’t is at best sloppy thinking, at worst it imports the problems listed into work that would otherwise be free of them.

Then there is scaling: so much of the “scaling agile” debate revolves around projects. If instead you accept standing teams dedicated to improving business as usual many of the scaling issues simply go away.

Projects are accounting codes to bill work back to. Projects are for accountants. Leave them at that.

Ask not “When will it be done?” ask instead “When will it start delivering value?”

Pessimistic about Agile in retail banks

Almost exactly two years ago I wrote a strident blog entitled “Agile will never work in Investment banks”. Its a blog post that keeps getting rediscovered by those who agree or disagree with my position and just such event has occurred on Twitter with Kevin Burns @martinburnsuk and several others @kev_austin @sandromancuso @gordonmcmahon

During the intervening two years I have had many conversations which support my point of view. Most of these conversations have been with people who have more, and more recent, experience in banks than I do. In particular I found Peter Pilgrim’s blog closely aligned with my own views.

Conversations with the likes of Andy and Chris (you know who you are!) and others have led me to believe that while retail banking might be more hopeful it isn’t a massively better there. In part that is due to the colonisation of retail banking by investment banking that has occurred over the last twenty years.

Lets be clear: although investment banking and retail banking share the word “banking” in their title they have nothing else in common. I’ll leave it to John Kay to say something about the why they are in conflict. (Broken link).

The move by many investment banks to occupy retail space has been purely opportunistic, they have sought cheap funds and to embed themselves in the economic fabric so they become “too big to fail” and “systematically important institutions”, thereby guaranteeing Government bail out, thereby reducing their funding costs and increasing banking bonuses. (See The Bankers New Clothes for a discussion of the many problems with current banks and solutions.)

If you wanted to summarise my argument in one line I’d say: Too big to fail means too big to manage.

Now there are two caveats on my original post which I want to make clear before expanding on the discussion:

  1. Agile is interpreted by many in banking to mean Iterative Development – see my recent “3 Styles of Agile” post. This can work to some degree. Simply adding the technical practices, improving software craftsmanship, can improve IT. However if an Agile ever becomes more than – incremental or evolutionary – there then conflicts will be created within the management regime which may lead to its own destruction.
  2. Incremental and Evolutionary Agile can exist in banking, and have existed in many banks I know of but only in the short to medium term. This kind of Agile requires a guardian angel. Again this will create conflicts, while the guardian angel is strong enough the team can be protected. However given time either the angel is successful and will presented with a better opportunity (probably at another bank in which case he might have the team follow him) or he is not successful and will be pushed to one side and his creation will be dismantled.

Turning specifically to retail banks, and thereby extending my argument. On the one hand I don’t believe retail banks suffer with quite the same rent-seeking culture found in investment banks so I’m more hopeful of them. But on the other hand retail banks have an additional set of problems:

Legacy retails banks are dependent on Cobol mainframe systems. This brings several problems. Firstly while you can do some Agile like things in a Cobol environment there are many things you can’t do.

Specifically TDD: as far as I can tell several attempts have been made to create a CobolUnit (this CobolUnit may be the same to different) and they are all pretty much dead. No action since 2009 or 2010 on those links.

We can’t expect the OpenSource community to come to the rescue here. Few people write Cobol at home and the generation of people who write Cobol are different to the OpenSourcers who created JUnit, nUnit, etc.

Unit IBM or MicroFocus get interested in a CobolUnit then I don’t expect much to happen – it seems IBM might be moving in this direction. But generally I don’t see the incentive for either unless they can see money.

Second these Cobol systems are ageing. They have patch upon patch applied to them and by some accounts are reaching the end of their lives. Much of the technology they are built with just isn’t as flexible or modifiable as the current generation. There is only so much you can do with a hierarchical IMS database or a mainframe batch processing system. (If you could do these things, and you could do them as easily as modern technology then we wouldn’t have needed to invent modern technology.)

Since retail bankers were early adopters of computers some of these systems are among the oldest systems in use. Many of them have been patched together through mergers and acquisitions making things even more difficult.

True I’d a great proponent of never rewrite and I think it would be a mistake for banks to rewrite these systems. Indeed, given the chronically poor management skills in these banks authorising a rewrite would be a waste of money. Which means you are damned if you do, damned if you don’t.

Third, compounding the first two: the people who wrote these systems are nearing retirement age. Not only do they understand the technology but they understand the business too. When they are gone these systems are lost.

Banks could have alleviated this problem by training replacements but they don’t generally do this. Actually they have made things worse in the last 20 years by outsourcing and offshoring work thereby discarding their own experience and acerbating the generation change. Some of the knowledge might now reside in the outsourced and offshore but getting this into the bank will prove difficult and expensive.

The solution for the banks is to buy off-the-shelf systems. But this is incredibly difficult so…

Fourth, buying an off the shelf product means not only process changes but potentially product changes. That lands the retail bank with change problems. They will need to customise off the shelf software and that isn’t cheap either.

Fifth, new “challenger” banks like Metro bank are already buying off the shelf. As the costs of maintaining legacy systems or migrating to new systems escalate these banks will have a greater and greater advantage over the legacy banks.

And its not just challenger banks: Paypal, Zopa, Funding Circle and a host of other online payment and loans providers are applying technology to reinvent banking. In doing so they are eating the retail banks market. (And the banks can’t respond because of the reasons listed here.) In other words: the banks are suffering from disruptive innovation

Sixth – something I just hinted at – the quality of IT management in banks is absolutely appalling. Again investment banks have made retail banks worse because the big money was in investment, anyone who was any good and wanted more money had an incentive to move from the retail to the investment side. Retail IT has been robbed of its best staff.

Management quality is not entirely down to investment banks. Banks are about money management after all. Promotion to the senior positions comes from the banking side, not the IT side. Almost by definition the senior managers in banks don’t understand IT. It also means that IT managers sooner or later face a ceiling on progression.

Many of these problems have been made worse because investment bankers controlled retail banks. Investment banking is essentially a rent extracting activity, and they have managed retail IT just like that. The existing IT has been milked and without adequate investment. Hence problems like well the documented RBS outages and Lloyds payment problems.

To make matters worse banks are where the money is so they have been preyed on by major systems companies and tool vendors. These companies sell technology fixes which may – or may no – address a problem but do little if anything to build capacity. Put it this way: banks are major buyers of automated testing tools which aren’t used.

You see my argument?

I’m sure Agile could help with some of these problems – not all but some – but the way I see it the problems facing the banks mean Agile will have a very hard time.

Finally, as others have pointed out many of my arguments can be applied to other types of large corporations. I agree, I confine my arguments to banks because I think the case is clearer there, banks are all very similar, because banks exhibit more systematic failures than most and banks are something we should be worried about – as customers, as tax payers, as citizens in economies that depend on banks.