Requirements, Agile and Scrum

Ryan Shriver - aka The Agile Engineer - has some interesting comments on the requirements in Scrum projects - and Agile more generally. I tend agree with Ryan’s comments for a couple of reasons. Firstly I don’t think Scrum (or other Agile methods) really understand them. Secondly there is a lot more to requirements than is commonly realised.

Because Agile largely comes from the developer view we tend to neglect the bit that comes before but actually that is even more important in the long run. In the short run it is not important, in the long run it is vital. Agile methods have too simplistic a view of requirements, its all “user stories”. As Ryan says, there is more to it than that.

Learning and Distributed teams

Andrés Taylor has some nice things to say about my book on his blog this week. Most of his blog is expressing concern about distributed teams and the discussion that follows is quite interesting too - Keith Briathwaite has continued on his blog. In my view distributed teams are generally a sub-optimal way of arranging your development process. However you may choose to organise in this way for several reasons. The main ones are:

1. You have no choice, for example: you need an expert in, say, database transaction processing on embedded systems and there are three guys in the world none of whom want to move to you Halifax Nova Scotia office.
2. You need your development team close to your customers and your customers are in different places.
3. Somebody somewhere has done a calculation that says the lost productivity is acceptable because the savings elsewhere. For example: having two developers in London and two in Bangalore is so much cheaper than having four in London that the 10% productivity loss is acceptable.

A few years ago we ran a focus group at EuroPLoP on Conways Law (What do we think of Conways Law now?) One of the insights I got from the focus group was:

• When ever you remove an informal communication channel create a formal one.

So.... Whatever the reason the important thing is to compensate for the distance. If you are saving so much money by spreading people out spend some of the money on flying people around to meet one another. Spend some of it on teleconferencing and video conference kit. Open the firewall to IM and Skype traffic.

Consequently companies that decide to spread their developers around should not then complain about travel budgets. If you are saving with the left hand you need to spend with the right so budget for it.

Learning to be Agile

Andrés Taylor comments remind me to confess to something. The title of the book is wrong.

The book, as published by Wiley is entitled: Changing Software Development: Learning to become Agile.

The title I thought agreed to was: Changing Software Development: Learning to be Agile. I’m not upset with Wiley or my editor, I only noticed this myself a few weeks ago (about a year too late). I’m sure if you look back through my blog entries you’ll see the mistake for yourself. I assume the small change was to improve the grammar (not my strong point.)

But, for me it changes the title quite significantly. Learning to Become Agile implies you learn then you are Agile. End of story. Learning to Be Agile - in my mind at least - can be read two ways. The first is as I just said, you learn then you are Agile.

The second is more subtle, and I’m not sure if I can express it. This is the “to be, or not to be” version. The implication goes both ways: true Agile implies you learn, learning implies you are Agile, think of it as “I learn therefore I am Agile” - in order to be Agile you must learn.

Maybe this second version is a bit of a stretch - does anyone else get it? - but for me its actually more important than the other reading and in many ways this is the true title of the work. Shame I never noticed the subtle change.

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.