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.

Debunking some myths about Agile

I think I get quite a few comments on this blog and I publish most of them. Almost all of the ones I reject are spam/graffiti type, people looking to put a link to their site on my blog. Sometime I reply to a comment but not always, it depends on whats on my mind and how much time I have.

Last week a comment arrived on my Failures in Agile process entry from April 2007. Its worth pointing out that the comment has very little to do with what I wrote in the entry. Except for the fact that both my entry and the poster are concerned with “Agile failure” the content of the post seems to have little connection with what I wrote.

What’s interesting is that this post exists. Its a reminder that many people out there still believe a lot of myths about Agile development. The poster is right about some stuff but then just lists a bunch of myths with no supporting evidence or examples.

So lets take the post and dissect the myths:

• “Considering the reasons for failure you named someone may conclude there is no difference between Agile project failure and RUP project failure. In other words the software development approach obviously does not make difference.“

True: indeed I concluded this myself when I wrote: ”Failure of an Agile project looks a lot like the failure of a Waterfall or RUP project.“

The RUP folks increasingly claim that ”RUP is Agile”. There is long post on that subject but not today. If the RUP folks are right then you would expect RUP to fail like an Agile method because it is an Agile method.

There is a stream of thought that say that method doesn’t make much difference. Check out “Amethodical systems development: the deferred meaning of systems development methods” by Truex, Baskerville, and Travis if you want the full details.

It is widely felt that people, not process or method, are the key ingredient for successful software development. So how do you get good people? I think you need to grow them, develop your own developers. And I think the way you do this is through a learning culture. And I argue that Agile development has its roots in Organizational Learning so is better suited than RUP, SSADM, Waterfall, etc. to do this.

For my full argument: Buy the book, Changing Software Development.

• “The main bottleneck I came across is the failure to define good system requirements. In other words: garbage in - garbage out, principle applies here.”

True: Not sure it is always the main bottleneck but I think can be and it is always significant. This is one of the reasons I’ve devoted a lot of blog entried (and the odd conference presentation) to Product Management.

Although most Agile methods say little about requirements I think they do help. By improving deliver they free up management time and energy to think about that they actually want.

• “Agile wins more attention of management becacuse they discovered the way to shift the responsibility and blame for project failure to programmers...”

Not in my experience. I think managers have always blamed developers and developers have always blamed management.

But blame is not a very useful concept.

• “Downsides of agile:”

To the myths...

• “agile may only be used on small projects”
• “maximum 5 developers on project“

False: this myth started because the early writers on Agile hadn’t applied it to large projects when the wrote the first books.

I’m working with a large .com at the moment to introduce Agile to a large (50+) development team. Jutta Eckstein wrote about large Agile projects four years ago.

Software development always goes better with small teams. Since when did RUP, Waterfall, etc. etc. guarantee success? At the very least Agile is no worse than the next best methodology.

One of my personal mantras is: ”Inside every big project is a small project struggling to get out“. To find this project you need to a) be able to deliver, b) actually deliver business value.

• ”all developers must be higly skilled (no learning moments are allowed)”

First part: Highly skilled developers help any project go better. Agile is no different. (With the possible excpetion of Mongolian Hordes I’m not aware of any development technique that claims to do better with less skilled developers.)

Second part: False, Agile is all about learning, there are lots of learning moments. Again, buy the book, Changing Software Development - I’m not going to repeat myself.

• “developers must be in the same physical room with the project owner.“

False: there is a lot of experience with distributed development teams using Agile.
And once again, any development method goes better when teams are in the same room.

Frankly, distributing your development teams is always going to hinder your efforts. Putting them in one room is the most effective way. However sometimes you just can’t do it. And sometimes companies are prepared to take the productivity hit because the cost savings compensate for it.

This came up in the work I did on Conway’s Law.

• ”project owner must be available 24/7 since good programmers also work extra hours”

False: There is no law that says “good programmers work long hours” so the assumption is wrong. In fact, Agile emphases sustainability, you don’t get that by working people long hours.

Lets be clear: Agile does not mean working long hours. If you are working long hours you have a problem and you should fix that.

There is a problem with Karoshi (death by over work) in some cultures but this can’t be blamed on Agile or Lean. Yes it exists, yes it occurs at Toyota in Japan. No I have not heard of any stories of it occurring in Agile Software Development teams or at Lean enterprises like Dell or Amazon. Or even at Toyota outside Japan.

The original XP project, C3, did cause the near nervous breakdown of the first “Customer” - Business Analyst or Product Manager really which was a failure in C3. However, this does some way to supporting the view (held by myself and the poster) than knowing what you are doing (requirements) is important and thus you need more effort here.

To work someone to death or a breakdown is a problem that needs to be fixed.

• “agile does not support use of virutual teams or outsourcing constructions“

False: Where does this idea come from? I’d love to know so I can understand what to disprove!

OK, lets try...

”virtual teams“ - see above.
”outsourcing“ - ThoughtWorks has built a pretty big business as an Agile outsourcer.

• ”agile provides poor quality of software since documentation usually does not exist. If it does - it is written in "reverse engineering" style.”

False.

I have never seen any evidence that documentation leads to high quality software. Year ago I worked on rail privatisation, we had lots and lots of documentation, and then some more. The software was rubbish.

Agile provides high quality software because it simply wouldn’t work without quality. Look at TDD, pair programming, customer involvement, etc. etc. Its all about eliminating re-work, i.e. improving initial quality.

The tests produced by Agile developer are documentation, executable documentation at that but documentation all the same.

And reverse engineering documentation is actually the only sort worth having. Since design and requirements are emergent anything written in advance will change.

• “selling "agile project" as "fixed price & fixed scope" is mission imposible since scope of the project is not defined.“

False: it just means you need a different type of contract.

If Anonymous would like to reply to me please do, but please, next time you make some of these wild claims please explain your thinking or cite your evidence.

A book review of Changing Software Deveopment

The Agile Journal has a book review by Brad Appleton of my book, Changing Software Development. Thanks Brad! I think he put his finger on it.

Changing Software Development isn’t just another book about how to do Agile methods and techniques, its book about change and putting Agile development in the context of learning and knowledge.

Offshoring becoming more expensive

An interesting analysis in McKinsey quarterly about the increasing costs of off-shore manufacturing - Time to rethink offshoring. As is so often the case this piece is US centric, and it is about manufacturing not services, still, some of the data and analysis are worth looking at:

• Wage rises in China mean manufacturing workers now earn $4,140 a year up from $1,704 in 2003
• Weaker dollar also erodes the advantage (and since the pound is low at the moment the same is true in the UK)
• Higher oil prices mean getting raw materials to China, and finished products from there is also more expensive

They also hint at the delays in supply when you ship from China - because you have to order so far in advance and get stuff shipped.

In short, manufacturing high-tech products in China isn’t clearly cheaper any more.

And to proove the point, yesterday’s FT reports: “The latest cheap manufacturing site for European companies is not in Asia or eastern Europe but the US”. (Its a little more complicated than that but have a read for yourself.)

So what of the software industry? Lets apply this thinking, and extend it to India and elsewhere.

• Wages have been rising here too, I don’t know how much by but is manufacturing staff have more than doubled their pay IT workers can’t be far behind
• Weaker dollar has erodes the advantage (ditto the pound sterling)
• Higher oil prices mean flying staff between your offshore development centre and your actual location is more expensive

And of course you have the supply chain delays too. McKinsey doesn’t go into this angle greatly but there is a good analysis in Womack and Jones Lean Solutions: did you know stores have to order their Nike’s a year in advance? Bottom line: you can have lean manufacturing on the other side of the world but you face challenges if you want a lean company spread over that distance.

Regular readers will know I’m all in favour of developing software in India, Malaysia or wherever. However I think the benefits are exaggerated. Or rather, the downsides aren’t appreciated. Somewhere there is a balance.

Optimor: Mobile phone tariff comparison

Long story, I know a guy, who knows a guy who... gets us to Optimior. Their technology evaluates your mobile phone bills and recommends a operator. Their system is in alpha test and they’ve just analysed my phone bill. I won’t be changing operator soon but it looks good.