I make no apologies for blogging again about Product Management because it is important and because, on the whole. As I said in my previous entry, Agile methods have a very simplistic view of determining what needs doing.

In the short run the Alignment Trap tells us that it is better to focus on doing things right, but in the long run Lean thinking tells us we have to do the right thing – remember 80% of features aren’t used. So Product Management is a long run play.

That is one of two reasons why Agile methods tend to underplay requirements and “Product Ownership” – because you get a lot of benefits by ignoring them to start with. The other is that Agile methods largely originated with developers who generally tend to underplay the role of requirements. (The exception to the rule may be EVO which is quite keen to understand exactly what people want.)

The trouble with Product Management is that everyone has a view on what needs doing, thus, in the absence of a Product Manager (or BA if your that type of company) other people will fill the void –

• Developers sometimes try and fill the void but developers have empathy with the code and find it hard to untangle their feelings about the code from what the customer wants.
• Architects claim to fill the void because they have the “bigger view” but architects are – almost by definition – uber-developers so have the same problem as developers. But architects are also tasked with looking at technology therefore any requirements they come up with are likely to be technology not market based.
• Project Managers often try and fill the void but their training and inclination is very different. They have a tendency to view things through the prism of dates rather than business value.

In the UK confusion between Project and Product management is rampant. It is slowly getting better but many companies can’t tell the two apart. This is really sad but also really dangerous.

Project Management can always expand to fill more time: you can always redraw a PERT chart, or level it again, you can always add another risk to the risk log (“An asteroid may hit Earth and delay the project”) or you can always go and ask a developer “Are we there yet?”

Product Management on the other hand can always be shrunk to squeeze in. After all we all have views on what the product should do so stick a finger in the air and guess. (And the more senior the person doing the guessing the more likely their guess will be taken as truth.) It takes time to visit customers, talk about their needs, time to go to trade shows, investigate competitors, time to calculate ROI and so on. Far quicker to stick a finger in the air.

My personal rule is: one Product Manager to every three to seven developers. If your product is stable, changing little and in a quiet market then one Product Manager may be enough for seven developers. But if you product is developing, the technology is innovative and the market changing fast you need one Product Manager for every three developers.

Its a false economy to skimp on Product Managers, you may save money but you may well create the wrong thing. Far better to go a little slower and create the right thing.

Given how much work a Product Manager has to do its natural to look for ways to split the role up. The first split is to hive off outbound marketing to Product Marketing. In a small company or team a Product Manager may do both inbound and outbound marketing but once it grows you should split the two roles.

Another division is between Tactical and Strategic, and with this split the role fits well with the Agile/Scrum idea of Product Owner. The Tactical Product Manager takes on the Product Owner role.

I hadn’t thought much about this until a friend of mine brought some blogs from Eigen Partners to my attention. These guys explain it well themselves so I’ll leave you to read Agile/Scrum Software Development and Product Management part 1, part 2, part 3 and part 4.

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.

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.

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.

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.

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.

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.

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

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.

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.