Monday, December 21, 2009

Events for next year

I have some speaking events booked for next year which might interest readers:
  • 23 February, Jax conference London: I’m updating The Future of Agile presentation for the conference
  • 23 March, BCS PROMS-G group London are running a repeat (with updates) of BCS Bristol’s Agile Spring School, if you miss The Future of Agile at Jax then catch it here
  • April 2010, ACCU Conference, Oxford: New presentation bringing together some ideas into 10 Steps to Agile Requirements
  • 20 May, Software East in Cambridge: Just a date in the dairy so far, details are still being sorted out
I hope to see you at one of these.

Happy New Year and all the other seasons greetings!

Wednesday, December 09, 2009

Banks spend a lot on IT but its a mess

Living and working in London means a lot of the software people I meet and talk to work in financial services. It amazes me the number of programmers etc. that banks employ. And you hear stories, some really awful stories about the state of IT in banks. And I’ve seen a few in my time.

So, for all those readers out there who have to work with banks and other financial services companies I recommend you get hold of a copy of this weeks Economist and read “Silo but deadly.” This article lends some weight to those stories I hear in pubs, at conferences and during training courses.

Some highlights:
  • Financial services companies are estimated to spend $503bn on IT this year, thats more than Governments, more than manufacturing and more than any other sector
  • The chief risk officer at Deutsche Bank says: “Banks are essentially technology firms”
  • SOA architecture is a problem, that’s Spreadsheet Oriented Architecture
  • Data quality is a recognised problem
The articles suggests that the woeful state of IT in banks may have contributed to the recent problems. This is something I’ve suggested other links before now, e.g. the Moody’s bug.

Personally, I think one of the reasons why banks and other financial companies have such poor IT goes back to that quote above: Banks are technology firms but they don’t view themselves that way. As a result the way they don’t necessarily take the right approach to people or projects, and they don’t take the right short-term v. long-term view and so on.

Lest we get too negative about our industry you might also want to read this recent survey from McKinsey which suggests IT isn’t doing such a bad job, and outside the IT department corporations are pretty happy with IT on the whole.

Friday, December 04, 2009

Requirements, requirements everywhere; no clue on what to do

Twice this year I have visited companies which want to try a more Agile way of working but who have requirements coming of their ears. I’m talking hundreds of pages of requirements. Sometimes as use cases and scenarios. Sometimes as big meat documents written by expensive consultants and bearing names like “Requirements Specification” or “Business Design.”

Its hard to argue with such requirements documents, in part because its hard to read them and understand what they are about. The thing they have in common is a level of detail. They go into great detail on what needs doing and how you might go about doing it.

Its not the first time I’ve seen such documents. I’ve been on similar projects before. One variation is a project I saw last year were the documents were not requirements documents but strategy documents. Several big name consultancies had been into this (media) company and do strategic work around a new product. Lots of presentations, lots of SWOT analysis and so on.

What all these documents have in common, apart from being expensive, is that they are worse than useless. They give the impression that things are know but they aren’t know. They knowledge walked out the door, what you have is a snapshot of someone’s understanding. But its a snapshot that nobody can really take in because its so big. And it is a snapshot that is rapidly aging.

As I’ve said before: the bigger a document the less likely it is to be read, and if it is read, then the bigger it is the less that will be remembered of it.

To which we might add: the bigger the document is the more there is to go out of date.

Yet because these documents exist people feel compelled to use them. They may even be mandated to use them. They don’t feel they can say to their boss: this was a useful learning exercise, no we will do it for real. So we then embark on a process that try to use documents which only get in the way.

Having someone investigate requirements or strategy can be useful. But think of it as a learning and feasibility exercise. And above all: don’t let that person leave the project.

At best these documents are historical reference source; as worst they are an obstruction.

Set a clear goal for the work and work out what you need to do to meet it. As Tom Gilb says, this should fit on one page of A4.

As you work towards this goal you will uncover requirements. You might want to note them down but remember there is no point in running far ahead of the development team.

Once you have something up and running - even in demo - what people think they want will change. So start small, get something working and get a team that delivers.

Just say No to big requirements documents. Say Yes to short, concise, goal to aim at.