Credit crunch #2: Old banks for new

This might be a little off-topic for this blog but a) its a damn big story, b) says a lot about business and c) a lot of software developers are connected with banks. That’s my excuse so....

There are a couple of aspects of the bank rescue plans that trouble me.

First one: Now is the ideal time to open a bank. Does anyone have a few million to invest?

I say this in all seriousness because at the moment banks won’t lend to one another because they don’t know if the other bank is holding any “toxic” assets. The public is nervous about investing with banks because there have been several failures. Yet plenty of people still want to lend from banks.

Thus, my New Bank Ltd. will have no toxic assets because it has no assets to start with. We will ensure it takes on no toxic assets. Therefore, the public will save with us, other banks will lend to us and we can make loans (i.e. acquire assets) which other banks can only dream of just now.

Rather than prop up failing banks Governments should be encouraging new banks to set up.

Next: Banks which are too big to fail. So what do the we do? Merge them with other (bigger) banks, e.g. BNP buys part of Fortis, Lloyds TSB buys HBOS, etc. As a result we have one bank which is much bigger than the bank which just failed. So, if this bank gets into trouble...

See what I mean? If a bank is “too big to fail” and we put it with another big bank we have a potentially bigger problem.

Put these two ideas together and I think it makes sense to re-create the lost smaller banks. All the big banks are home to banking brands which are still remembered by the British public and I think the same is true elsewhere.

Royal Bank of Scotland could devolve Natwest - or even go further and recreate the National and the Westminster bank. Barclays could return Martins bank and the Woolwich, HBOS could spin off Halifax (as a mutal?) and Lloyds TSB could split back to Lloyds and TSB.

The parent bank would be left as a “Bad Banks” holding toxic debt and owned by their current shareholders. They would exist to manage what is left and salvage what they can. The reborn Natwest and TSB would be clean banks. And all these banks would be small enough to fail without bring down the whole system.

Reflections of an Agile Advocate

I am speaking at the BCS SPA London group next month. It only seems like 5-minutes ago I was at the BCS building talking to the BCS PROMS-G group but this is a different group, a different audience and a different topic.

Actually, its getting hard to find big new things to say about “Agile” so I’ve entitled my talk Reflections of An Agile Advocate. I intend to look at the state of the “Agile”, identify some trends and suggest were we are heading next.

If you want to come along it is free but you will need to register.

Are you really doing Scrum?

I’ve spent some time recently looking more closely at Scrum. One of the things that has come across is that Scrum is quite tightly defined. In particular it is tightly defined around its basic rules and the concept of a self-organizing team. And there are those who would argue that if you move away from some of the Scrum rules, or compromise on the self-organizing team then “you aren’t doing Scrum.”

Personally I don’t care if I’m not doing Scrum, what I care about is whether what I am doing is effective, whether it is improving and whether the customer is being served. That is why I documented Blue-White-Red or BWR for short. BWR is not Scrum, parts of it look like Scrum and it could be seen as a step towards Scrum but it is not Scrum.

As I’ve said before Scrum is where most of the attention is at the moment. A lot of organizations are looking at Agile and saying “Lets try it” and then deciding “Lets try Scrum flavoured Agile.” Therefore, it looks like a lot of teams are trying Scrum.

Using the strict definition of Scrum most of these companies are not doing Scrum. They think they are doing “Scrum”, they may even say they are doing Scrum, and the Scrum alliance may be happy to count then as “doing Scrum” but using the strict definition of Scrum they aren’t.

For example, a friend of mine specialises in Agile in Banks. In the summer he was hired to help a Big UK/International bank adopt Scrum. But, I don’t think the bank are removing their project managers, nor are they embracing self-organizing teams they way Scrum mandates. But if you ask them they will probably say “We are doing Scrum.” My guess is they are doing something closer to BWR.

I have nothing against Scrum, in fact I like it. I believe self-organizaing teams are the best way to organise work. I’m happy for the Scrum alliance to have its definition, I’m happy to help people adopt Scrum. If Scrum “succeeds” then Agile is growing and I’m happy.

But strict-Scrum isn’t a good cultural fit for many organizations. Leave aside which is the better way to manage a team and look at what organizations do. Most organization use some form of command-and-control, they have layers of managers telling people what to do. For such organizations to claim they do Scrum is wrong.

Perhaps one of the reasons why it appears Scrum is the most popular Agile method is simply the number of job adverts for Scrum Masters and Scrum Product Owners. Look this example pulled from JobServe recently:

“Media Project Manager - Scrum Master: ... looking for a Project Manager (Scrum Master) to work for one of their leading media/publishing clients in London. ... You will have a proven record in the delivery of content focussed online/development projects and have Prince II Practitioner accreditation.”

Firstly, on the strict-Scrum definition there is no Project Manager. So if you have a project manager you aren’t doing Scrum. Conversely, if you are following Scrum then you have self-organizing teams so you are not doing Prince II.

I have no way of knowing whether this organization thinks it is doing Scrum or Prince II but it sounds like they are doing neither. Yet to the casual viewer it looks like someone else is doing Scrum (and Prince II). I suspect this organization is doing some form of Agile and is simply looking to set filters on the CVs that come in. Looking for Scrum Master certification is like looking for Prince II certification, it doesn’t mean much.

The new challenge in Agile adoption

I have another piece in this months Agile Journal entitled “The new challenge in Agile adoption”.

What is Agile? and Who owns "Agile"?

When I talk to people about Agile I’m always keen to try and define “what is Agile”. I have two standard answers.

The first is to say “Agile” has come to mean “better” - as in “we cannot get software out the door”, “our software development is a mess” or “our senior management are fed up with us” and something has to change.

These people want to do “better.” Some of these people and companies would have considered ISO-9000, CMM(I), or similar a few years ago, and they may look for answers in technical products: UML, Ruby on Rails, ClearCase or something.

Since Agile is the current buzz, and since Agile has a lower barrier to entry than ISO-9000 or CMM then these groups look at Agile to solve their problems and to make them “better.” Some of these people don’t really know what Agile “is” and really it doesn’t matter.

The second way I define Agile is with two, sometimes three, tests:

1. Agile teams are listening and responding to their customers: they are delivering (software) which adds value to the business and responding to changing needs (whether from an individual user or a large market)

2. Agile teams are learning and improving

Notice I don’t talk about practices, values or routines. If you are learning and improving I don’t care what you do because I believe you will get their eventually. And since their is no reason why any existing Agile method is right for your company you are free to create your own, one that fits with your organization and your culture. Provide that is you meet the first test and serve your customers.

For the record, the third test which doesn’t always apply to my customers but which I need to keep in mind is:

3. When all the consultants, coaches, trainers and other who helped you get Agile leave you do not fall back to your old ways.

The reason for saying this now is to point out that Nobody Owns “Agile”. There is an Agile manifesto, there are Agile values and Agile principles, there are lots of books on Agile but there is no one single definition.

This is a strength and a weakness. It allows opinions to vary and new ideas to appear but it also means that you get different versions of “what is Agile” and they don’t always agree. For example, in the UK I am often at conferences with people like Steve Freeman, Keith Braithwaite, Kevlin Henney and Duncan Pierce, we agree on almost everything. We each emphasis different aspects of Agile, we each have different concerns, we approach engagements differently and we see the future differently. Dig deep enough and you will find differences.

If someone owned “Agile” - like RUP and PRINCE2 are owned - there would be things which would be ruled out. There would be someone who would come up to me and say “What you say about X is wrong.” Agile isn’t like that, its a broad umbrella, you have to decide for yourself who and what is best for you.

Agile is a story, it is a story that changes in the telling. It is post-modern, by which I mean, there are multiple versions which are all, simultaneously “true” - there is no absolute for truth.

There are a few people who I have more serious disagreements with, and I really wish they wouldn’t call themselves “Agile” but that is the price you pay of this freedom.

Look again at my second test: Learning and improving. This applies to your own understanding and definition of Agile too. Our understanding evolve.

This has to be your own understanding, belief and principles. Look at my third test: you can’t rely on others for ever.

And this divergence of views, competition in some instances, and new knowledge should ensure we are all aiming to do better. Back to where we started, and I think if you talk to any of the people I mentioned above they will agree: doing Agile isn’t important, its the end goal that is important and that means being better.

The only thing that remains constant is that second test: serving the customer.

Markets might be a little out of fashion at the moment but nobody is seriously suggesting a return to an Agro-economy or Communism Mark 2. The free market economy - or something that looks a lot like it - is here to stay and that means customers are here to stay.

Interesting piece on Kanban

I’ve written about Kanban Agile before, and got some useful comments so I was glad to come across this piece, Scrum-ban by Corey Ladas and Bernie Thompson. Worth reading to better understand what is going on in Kanban teams.

ACCU Conference keynote

I’m pleased to announce I’ve been asked to deliver a keynote at the 2009 ACCU Conference in Oxford.

Really this is quite an honour, when I look at who the other keynotes are they a serious names: Robert “Uncle Bob” Martin, my old friend Frank Buschmann and Baroness Susan Greenfield - yes a member of the House of Lords talking to the ACCU!

I think this keynote line up is very strong and shows the ACCU at its best. The line up shows three ACCU keynote traditions: internationally renown speakers from software development, someone from slightly outside the field who will make us think more widely and an ACCU member.

Right now I’m not sure what the title will be, I’m thinking about “7 Pillars of Agile Management”. Any suggestions out there?

Requirements led projects (not really a book review)

I’ve been trying to read Requirements Led Projects by Suzzanne and James Robinson for a few months and I think I’m about to give up. I’m about 150 pages into a 300 page book but I’ve been stalled for a while now and my attempts to re-start have not got far. This is a shame because I do like the book, and I don’t want to give it a bad review but if I can’t make it to the end then it has something lacking.

I bought this book because for the last year or so I’ve been very concerned about requirements on development efforts. OK, I’ve been concerned about this for a while but my level of concern has increased in the last year. So, I decided I should look into this subject some more.

Perhaps I read the wrong book. Write at the start to authors suggest their book Mastering the Requirements Process is the one to read if you want to know about writing requirements.

I briefly met Suzanne at SPA a few years ago and was impressed with her knowledge. I have no doubt that the two authors know there stuff and many people will find this book useful. But...

Firstly I haven’t been getting any real insights from this book. Its a problem I’ve found a lot recently, when you’ve been involved with as many development efforts as I have, and when you’ve read widely, it can be hard to find something really new and insightful.

Second, I think the authors have a bit of a mixed up view on who writes requirements. This is partly due to the book subject (projects and requirements) and partly due to the industry. To name the elephant:

Project Managers should not be writing or inventing project requirements.

Project Managers manage projects, they should be concerned with the when and who-else questions on the project. Those attracted to Project Management don’t (usually) have the analytical, inquisitive nature, or the training that makes a good requirements writer. The person who creates the requirements should be a Business Analyst or Product Manager. Project Managers need to be focused on near term deliverables. Requirements creation requires a long term (and possibly strategic) view.

However you wouldn’t know this from many job ads which confuse the roles of deciding what needs delivering with actually delivering it. I guess this book is written for project managers who find themselves in this situation.

On a small project the two roles could be merged provided you can find the right person. And there are a few people can do both roles. But these cases are the exceptions.

This book does set out to discuss requirements led projects so one might expect it to blur the Project Manager / Business Analyst divide but the authors blur the divide without acknowledging it. Sometimes they talk of the project manager gathering requirements and sometimes the BA.

It seems to me the authors are much more familiar with the Business Analyst as requirements writer and not Product Managers. As someone who champions Product Management I found their chapter on “Inventing requirements” to be quite naive. Product Managers are not mentioned and their is no sign that the authors know their techniques. The idea that nobody asked for a mobile phone so it was invented is very simplistic suggestion.

So, if your fairly new to requirements writing this could be the book for you. Unfortunately its not the book for me.

I’m reading some more about Business Analysts at the moment, and I’ve been sent some good links on product management so I’ll return to this subject soon.

Øredev

The nice people organizing Øredev in November have made me a postcard:


Allan Kelly at Øredev

Flights are booked and presentation prepared (just a little bit of PowerPoint, must try harder). I’m speaking on the Thursday, The Hitch Hikers Guide to Management.

Slides from Agile talk to BCS Project Management Group

Last week I did a talk to the British Computer Society (BCS) Project Management group - PROMS-G. They were a good audience, enught questions and points to keep it interactive but not so many that I didn’t get to the end of my talk!

I’ve now put the slides online - How and Why to Become Agile, as you might expect I tried to say something about the role of the project manager in Agile projects.

Someone (who has remained anonymous) has written a blog entry on the talk The role of Project Managers in Agile Projects.