Agile will never work in Investment Banking

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.

Cornish Case Study

In the last few weeks Michael Barritt of Oxford Innovation and myself have presented several versions of “Agile in Cornwall” - a case study of our work introducing Agile to companies in Cornwall.

All three versions of this Agile case study presentation are now on my website. I recommend the latest two version - Agile Business Conference and Agile Cambridge. The version from Agile on the Beach in Cornwall was supported with presentations from two of the companies concerned - Research Instruments and Sullivan Cuff Software. In fact, you can find my own case study of the work at Sullivan Cuff on the Software Strategy website. A video version of this will be available in the near future.

If this interest you, or you want to hear it not read it, then I’ll be doing a revised version of the presentation at Skills Matter in a couple of weeks - “Agile Cornwall case study: How the EU is helping Cornish companies get Agile” - a free event, registration required.

Layered burn-down charts

I’d like to conclude this Burn-down chart mini-series (Burn-downs are not just for Sprints and Advice for creating burn-down) by showing a variation on the classical burn-down chart I created with one of my Cornish clients. I’ve recently been advising an SOA project at another client to adopt a similar approach.

In fact, I’m finding this variation makes even more sense then the original, this is the Layered burn-down chart, here is an example:


I’ve redrawn this example to remove client details. What it shows are three things:

• First the classic burn-down, just look at the overall line declining.
• Second the velocity line as described in my earlier blog
• Third the different colours layers show different releases, let me explain...

This company had taken the product backlog and divided it into monthly releases: November, December, January and so on. By the way this was physical on cards and each month’s cards were held together with a bulldog clip.

The contents of a release can - and would - change. But the company felt it knew what it wanted and since the team knew their velocity they could take a stab at which release it would be in. If something new was added the question was simply: when in which release do you want it? And the related stripe on the chart would increase.

That by the way is why the three strips of work yet to do are approximately equal size. If one grew it was obvious, work needed to be removed - either thrown away, or moved to another release, perhaps one that didn’t appear yet.

This was fairly straight forward when the company (thought) it knew everything to be done and ball-pack estimates could be given. With my SOA client they don’t know what the future holds but they can produce a striped chart for the work they do know about. In their case I’m suggesting every stripe represents a requested service rather than a release.

As new services are requested, and estimated, extra stripes can be added to show the total work required. Together with the velocity and slope it should be easy to see when a service will be available to their customers.

Advice for creating burn-down - and other capacity measurements

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.

Burn-downs are not just for Sprints

One of the key tools in Agile is: make things visible. When you can see the thing you can share the thinking and reason able it.

Capacity charts - usually burn-down, burn-up or their cousins Cumulative Flow Diagrams - are amazingly useful things. They show you the state of a development effort. They show this in data. Data by itself is hard to reason with but put it in a graph and wonderful things happen.

It has recently come to my attention that what I thought was obvious about these charts isn’t. So this blog entry, and maybe a few more to come, I plan to discuss charts, and specifically burn-downs, in a bit more depth,

I always encourage, sometime coerce, teams into produce some graphical tracking of their work. For someone like me who’s favourite tool is an spreadsheet this is a piece of cake. But have to remind myself that not everyone finds this so easy.

Importantly there are two burn-down charts you might want to create: a Sprint burn-down and A Product Burn-down. It should be immediately obvious that these correspond to the Sprint Backlog and the Product Backlog.

Just to be clear:

• Sprint based burn-down chart which shows the progress in the current sprint towards completion of all scheduled work and shows work on a day-to-day basis.
• Product based burn-down chart which shows progress through some larger quantity of work, e.g. project, release, milestone. These are updated on a sprint to sprint basis.

Superficially both types of chart look the same, the difference is in the X-axis - Sprint based charts have days, product based ones have iterations. An example will help:



Now I’ve never found sprint based burn-down charts very helpful. Perhaps because my background is working on large development efforts which take months or even years to deliver I rarely see an actual delivery at the end of a sprint. We may have something to show but its only a step on the way to something bigger.

Or perhaps its the economist or statistician in me, trained never to read too much into one set of data figures, and I know we can all have bad days, so I don’t see the point of acting when yesterdays velocity falls.

But I know some people do find value in sprint burn-down so I don’t object if you want one.

However, I always see Product Burn-down charts as vital.

Except on the smallest pieces of work there will be something coming next and a product burn-down can give a good sense of context, overall progress and, most importantly, when you could be finished - especially important on large pieces of work. Armed with this information you can construct sensible release plans.

I recently came across two teams at different companies who had burn-down charts but the charts only covered the iteration (sprint). This seemed wrong to me, it doesn’t tell me much. On closer examination the explanation become clear: the product backlog for both teams wasn’t in a state you could use for a burn-down.

Now if you are taking a truly evolutionary approach this isn’t a problem, you re-evaluate iteration-to-iteration. But actually, few teams take a completely evolutionary approach and these two teams where far closer to the iterative style (i.e. they had original requirements documents to work from).

The lack of a longer-term burn-down was a problem and a sign of a bigger problem.

One enhancement I like to make is adding velocity to the burn down chart. Take this one for example:



This adds a second axis (in Excel you have to hunt around for this option) which allows you to see the team velocity sprint-on-sprint.

The key thing is, without this data, velocity and burn-down - and the graphs to understand it - each sprint exists in isolation. That might be OK if you are delivering every sprint and you don’t need to peek into the future. But the kind of work I see does need to look forward and this information is essential.

Finally, I’ve most of what I’ve said about burn-downs applies equally well to cumulative-flow-diagrams (CFDs). In fact I prefer CfDs and readily use them over burn-downs because they help show how work increases. However, I have also discovered that CFDs are not only harder to construct and update but also harder to explain to people. There is something obvious about burn-downs.

Anyway, you pays your money, you takes your choice. Its up to you.