How to improve a team's velocity?

By way of wrapping up my velocity mini-series (Two ways to fill and iteration, Filling an iteration too well, and Velocity Targeting and Velocity Inflation) I’m going to end with some advice on how to improve a team’s velocity.

Bad news first: there are no silver bullets, there are no easy answers, there is no quick way of doing this.

There is no big fix, there are many, many, thousands, of little fixes which cumulatively add up. Each little fix improve your productivity (velocity) a little bit. Over time these add up to big improvements.

To use economic logic: this is about improving the supply-side. The supply-side argument (largely monetarist) suggests the way to solve unemployment is not to increase demand (Keynes style) but to loosen and liberalise the labour market. There is no single action which can do this, instead there are many small changes that need to be made to make the labour market more flexible.

But back to software…. how might you improve you velocity?

Well, Things to do to improve code quality is a good list to start with. Improving code quality makes teams more productive because they spend less time wading through swamp and scratching their heads.

Of these the thing that comes closed to a silver bullet is: Test Driven Development. TDD is something of a silver bullet, it does improve things BUT (big BUT) it takes time to learn to do it properly. Expect to take time, don’t expect it to happen over night, spend the time and money on training, coaching, setting up a continuous integration server and such. It will pay back, sooner than you think.

How on the heals of TDD is refactoring. In fact the two go together.

Adopting TDD and pursuing refactoring may throw up another problem which people would rather keep quiet about: developer skills levels. Some developers just don’t have the mastery of their tools required. A friend of mine who does TDD coaching tells me it usually ends up as OO coaching more than TDD coaching. So, invest in developer training, buy them books, send them on courses, bring in coaches, set up book study groups and other exchanges were developers can learn to do things better.

I would avoid adding more people to a team. We know, from Brooks Law, that at least the short run that will slow things down. But you can give existing people more time to actually do work. Try reducing the number of meetings you hold. If you have a regular planning meeting and daily stand-up meetings there shouldn’t be a lot of other meetings you need. Certainly there should be very few “all team” meetings.

And if your stand-up meetings are taking more than 15 minutes a day then look to shorten them. Any size team should be able to complete a meeting in 15 minutes if you approach it in the right way – see Three Ways to Run a Stand-Up meeting.

I often meet teams who feel that two weeks is too short a time to do anything useful, and they often question that frequency takes up too much meeting time. Rather than length an iteration it is better to shorten iterations. Teams get to review work in progress and take corrective action more often. There is less time for changes to disrupt planned work. It is good practice at both fitting work in short periods and at making planning meeting more effective.

In time, when you are good at iteration planning I might lengthen them, but it is rare I would let iteration last more than two weeks.

Next get serious about removing impediments. Too many teams live with impediment, accept them as a fact of life, something they can’t do anything about. Each impediment (or block if you prefer that name) reduces velocity a bit. If you want a higher velocity fix your impediments.

I don’t need to say it but I will: retrospectives. Do them, and action the ideas that come out of them.

Finally, just: Concentrate on doing a better job and the velocity, productivity and points will follow. The numbers are there to provide feedback, show you are going in the right direction. Don’t worry about the actual numbers, just keep improving.

10 things to know about Kanban software development

1) Kanban software development originated by David Anderson. Many of the practices and heuristics have been seen on other Agile teams before but they were first described as a cohesive whole by David.

David’s innovation was to explicitly limit the work in progress. This had been done by other Agile teams before but in Kanban there is a well-known limit on the number of work items which may be worked on at one time. The limit is usually quite low, in the teams I have worked with the limit is approximately the same as the number of developers on the team or slightly less.

2) Many Agile teams use a white board to track work during an iteration. Typically this is divided in to three sections: “To do”, “In progress” and “Done.” When a physically limit to work in progress is imposed it becomes useful to split this down further. Work in progress could be: in development, in test, in analysis or in other states. Each of these may have its own limit.

Thus, the second innovation in Kanban is to split the board into many other columns. Sometimes buffers are placed between the limited columns, these may be labelled “ready”.

3) The Kanban test: In November 2008 on the Kanban mailing list, I asked: “What is the defining characteristic of Kanban that make”, in response David Anderson said:

“For me it is simple… Are you limiting work-in-progress? Are you signaling to pull work from an upstream process? If it is a WIP limited pull system, it is kanban!”

Which give a test for Kanban and is pretty much points #1 and #2 above.

4) The Kanban approach was summed up by Karl Scotland when he said (on Kanbandev again):

“a subtle difference between kanban and typical agile processes such as Scrum. Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile. However, being agile itself is not important – it just happens to be the best way we (or at least I) know at the moment.”

5) The best place to learn more about Kanban is the Kanban dev Yahoo list.

6) There are currently no books on Kanban software development. There is one that comes close, Corey Ladas ScrumBan – Essays on Kanban Systems for Lean Software Development. I’ve read this book and I’m not rushing to recommend it.

7) Kanban derives more directly from Lean Thinking and Lean software development then many of the previous Agile techniques. Once you apply the innovations in 1 and 2 above just about everything else follows.

8) Kanban teams focus more on work flow, the time it takes to get work from one end of the pile to the other. In the extreme Kanban teams dispense with work estimating (which do not add value), iteration planning meeting (planning is an ongoing process), fixed release dates (they release when it is ready) and scheduled retrospectives (they have a stop-the-line approach to address a problem when it is seen).

9) Originally the Japanese word Kanban is two words kan and ban; kan means visual and ban means card. Like many people I talk about Kanban cards but strictly speaking I’m duplicating myself.

In Lean systems the cards are used to pass information, to signal when limits are reached, to signal an out-of-stock situation or some other trigger for action. Thus Kanban has come to mean more than it literal meant, and now the word is used as the name of a method it means even more.

10) Whenever I blog about Kanban I get more hits on this blog. It seems people want to know about Kanban. Actually, I just discovered that at the moment this blog appears on the first page in Google if you search for “Kanban software development.”

The lesson: Kanban is still new and still in its infancy.

For my previous description of Kanban see Making sense of Kanban (and some doubts), Agile and Lean – the same but different, Notes on a Kanban software development experience and there are some other pieces too if you search the blog.

Notes on a Kanban software development experience

kanbanboard08.jpg

I’ve mentioned the Kanban software development method in this blog before. For those who don’t know its “the new kid on the block” in Agile circles – although the originator (David Anderson) would be quick to point out it is designed to be a Lean development method.

Last year I did some consulting with a large online travel agency. I was involved with helping five teams “get Agile.” This presented an opportunity to try out Kanban in the wild. What I found was: it works, and I feel it is a better models of my own approach to software development than other methods.

What made this engagement more interesting was that I was able to start one team using the Blue-White-Red Agile (BWR) development method I’ve described before and two teams using Kanban so making for an interesting comparison.

The BWR team had been tasked with a project for which a large functional specification had been written. The spec wasn’t perfect but the organization expected them to complete it. BWR allowed the team to break the spec down and attempt it piecemeal. Some upfront estimates were made and a burn-down chart created.

(It almost looked Scrum like, that is, if you ignored the Project Manager, Development Manager, Team Leader, Architect and second Project Manager who joined the project later – and lets not forget me as Agile Coach. Its hard for a team of five developers (and a Product Mmanager) to be self-organizing when there is an equal number of self-organizers.)

This worked well. In the first few weeks I took a lot of heat because I refused to let a completion date for the work be given. Simply we did not have enough date to go on. Once the data started to come through I could do that.

The two Kanban teams were in a different position. Although they had “projects” to do most of their work was sustaining work. There were systems in place and issues needed fixing. Many of the things the company called “projects” were really to small to be worthy of the name – but that’s another story.

As a result the teams had more diversity in their work and more variability. Work would just appear – and disappear. They would have been hard pressed to keep to an unchanged task list (backlog) for a one week iteration, let alone a four week sprint.

This is the first good point about Kanban: its easier to handle changing work loads.

The teams still did “iterations” but the planning meetings quickly changed. Some work would be planned out but this could be usurped at any time. The iteration became the basic unit of comparison, allowing two periods to be compared. This meant that the start/end of iterations meetings were rather more of a review and retrospective session than planning session.

In future I think I would nominally keep iterations for this reason. They are useful time periods to review work and provide a regular review/retrospective point.

Second good point about Kanban: its easier to pick up.

On the whole I found the two Kanban teams needed less training, instruction and coaching than the BWR team (some of whom had been on Scrum training courses.) However, there was some work needed to map out the correct process flow for the Kanban teams to have on their boards.

For anyone creating a Kanban board some advice: big boards a better, involve the team and use coloured tape – insulation tape works well. In the past I’ve just drawn lines on the white board, with Kanban there is more movement and the lines are lost so I used insulation tape to create hard barriers.

A Kanban board

I expected the work in progress (WIP) limits in Kanban to pose a problem. I was expecting managers and others to want to break the WIP limit. This didn’t happen but I found developers breaking the WIP limits.

Developers broke the limits not because they disagreed but because they were accustomed to starting new work when they hit a problem. For example, a developer is working on item X, they come to a block on X so start on Y. In the extreme they block on Y and start on Z. You now have three partially done pieces of work. Trying to instil a “resolve the block” approach was difficult – largely because this organization was overloaded with managers and developers had been “taught” not to resolve these type of issues themselves.

In this organization lots of things blocked. Blocked on other teams. Blocked on IT support. Blocked on administration, etc. etc. I didn’t like it but I added a “blocked” column to the Kanban board. I also added a tally sheet to identify the biggest reoccurring blocks. I then tried to have the managers feel responsible for resolving the blocks. This was only partially successful because managers were themselves blocked because there were so many other “managers” who wanted their time. (The organization used talk as a substitute for action.)

All the teams held daily stand-up (Scrum) meetings and I encouraged the team manager, product manager and BAs to have their own pre-meeting to ensure the prioritisation queue was full and correct. This worked well.

I had the teams tracking cards by making a note on the back of the date as it progressed across the board. The date when it entered the priority queue, the date when work started and stopped, the date when it went for sign-off or test and the date when it was “done.” This data (when complete) was fascinating and started to reveal issues and opportunities, and give an idea of flow. In fact there was so much date I was overwhelmed.

In conclusion I find myself remembering Karl Scotland’s comment from a few months back. Karl had a quote which was something like: “The emphasis in Scrum is on being Agile and improvement follows; the emphasis in Kanban is on improving and being Agile follows.”

In the past I’ve shied away from labelling a team as doing “Scrum” or “XP” because I was aware they were not going it completely and we weren’t seeing all the benefits. I don’t feel that about Kanban, I’m happy to call these teams Kanban. Yes they had problems but we were resolving them. The teams were on a journey.

As anyone who has read Changing Software Development will know, I’m an advocate for incremental improvement. While Scrum (and XP, etc.) hold out the promise of overnight Agile – one big bang and your there – I see Agile as a journey not a destination.

Project plans (part 2 of 3): Turn the question around

As my last post was a moan I promised to give some advice on how to go about project planning. There is a lot to this and I can’t possibly give all the details in a short blog so I’ve split this into three blog posts. Still there is a lot more I could say.

Turn the question around
Instead of a confrontational question and defensive answer have a rich discussion.

When someone asks “when will it be ready?” turn the question around – (1) When is “it” needed by?

When does your business need a product to use? What are the important dates for the company – end of quarter? end of year? trade show? competitors? contract signing?

I always prefer running a project were there are hard business driven milestones to make. Dates which mean something.

Next (2) What is needed on these dates?

Unfortunately too many conversations in the software business seem to involve someone saying “I need everything and I need it yesterday” – not a very useful position, and if its true you should start looking for a new job because there is no way anyone can make that happen.

Look at each of those date and define what is needed. What are the qualities of the thing that is needed? What is the minimum marketable product or feature for that date?

At this point you know: what is needed, how long you have, and who you have to do it.

Yes, I slipped that last one in because its true: you have the people you have and in the short run your resources are constrained because of Brook’s Law and because hiring people takes time.

So within these parameters the engineering team can now come up with options. How can this need be met within this time with these people? This activity separates the real engineers from the rest. Engineers create solutions within these parameters.

Wikipedia (today) says: “Engineers are concerned with developing economical and safe solutions to practical problems, by applying mathematics and scientific knowledge while considering technical constraints. As such, the work of engineers is the link between perceived needs of society and commercial applications.”

And if you cant? Then go back to the “customer” and discuss it. Find a smaller feature, extend the time (shoot for a different trade show), find an alternative way of delivering.

(Tom Gilb has some good examples of engineering solutions into tight constraints and his impact estimation tables can come in useful here.)

Vision
All work needs to be guided by a bigger vision. You can call it a vision or a goal if you wish I don’t mind. Personally I like the term BHAG – Big Hairy Audacious Goal. You’ve got to know where you are going to give context to everything else.

There are two ways to run a project. The first – exemplified by Gantt charts – is to get all the pieces of string you think need to do the project, lie them end-to-end and see where you get to. If you read my previous post you’ll see why I don’t like that approach.

The second way, I’ll call it the BHAG way, is what I discuss above. Decide where you want to be, when you want to be there, what is will look like and then find a way of getting there. How you get there is called engineering. It is what engineers do.

My favourite example of the BHAG way? The Digital OpenVMS team committed to a delivery schedule and said “We don’t know how to achieve this, but we commit to finding a way.

Project plans (part 1 of 3): Why I don’t like Gantt charts
Project plans (part 2 of 3): Turn the question around
Project plans (part 3 of 3) – Planning cycles
Run Scope Creep backwards

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.

Christmas reading: Classic essays on software development

 

There are many, many books about software development. The technical ones alone (e.g. Java, C++, Apache, .NET, etc. etc.) take up meters and meters of shelf space. The ones about project management take up a bit less space but they are still plentiful, and the ones about people in the process take up even less space but are longer lasting.

It is the later category that interests me most theses days. Some books seem perennially relevant and may never go out of print, books like:

Mythical Man Month by Fred Brooks
Psychology of Computer Programming by Gerry Weinberg
Peopleware by Tom DeMarco and Timothy Lister

But often you don’t need a full book to make a point. On these occasions an essay or journal article will do. Often they make the point better simply because they are shorter. Unfortunately these tend to be overlooked too often – books get all the publicity. I would like to highlight half a dozen essays which I think are perennially relevant and often overlooked. In some cases this is because the articles can be hard to get hold of or, more likely, people don’t know they exist.

1. How do committee invent? by Melvin Conway – the origin Conway’s Law. Although written in 1968 this piece is truer than ever. Arguments made by Conway explain much of what actually happens in software development. I’ve examined and looked at this subject myself elsewhere.

Conway suggests that organization that create systems (not specifically software systems) will create copies of their organizations. So, if you have one developer writing the entire system it will be all entangled, few interfaces and difficult for anyone else to work with. And if you have half a dozen developers who don’t communicate you will get six different coding styles, and six versions of most common functions.

What Conway didn’t foresee is that many of system now create the reverse force. Organizations are limited by the systems they use, thus their structures become copies of the systems in use.

2. Worse is Better by Richard ‘Dick’ Gabriel – this started as a keynote talk, became an essay and then a series of letters in which Dick argued anonymously with himself.

If you are one of these developers who think the best code will always win the day you need to read this. Dick suggests that sometimes the solution which is technically worse is economically superior. In a similar vein see Brian Foote’s Big Ball of Mud pattern.

3. No Silver Bullets from the author of Mythical Man Month, Fred Brooks. This piece came out in the mid 1980’s. The Wikipedia summary is here, otherwise you will need to by the Anniversary edition of Mythical Man Month to read it.

Brooks argues that software development is hard, and there is no ‘silver bullet’ which will make it easier. No language, no operating system, no methodology or any other tool will fix it. I have been told that Brooks has since said the if there is a Silver Bullet it is Agile Software Development but I can’t find this quoted anywhere so I don’t completely believe it.

4. A Rational Development Process and How to Fake It by Dave Parnas. Originally published by the IEEE this also appear in Software Fundamentals: The Collected Papers of David L. Parnas. You might also find some copies stashed on the Internet. Dave Parnas deserves to be more widely read by software engineers today so it you haven’t read much of his work buy the collected papers, well worth reading.

In this paper Parnas argues that while we may want to use a rational development process, and while it makes sense to do so it is impossible. This is because software development requires intuition and inspiration – or as I would put it learning. And since you can’t schedule these things or guarantee they will happen the chances of following a rational process are negligible.

However, in order to make our work accessible to those who come after us we need to fake the development process so it looks like we followed a rational process.

I like the logic, I agree with much of it but I have one disagreement. Each generation of software engineers comes along and believes the previous generation were rational and get confused by what they find. They slowly learn that they cannot be rational – causing a lot of angst. They also wonder how the previous generation made such a mess. So frustration is built up.

5. Cathedral and the Bazaar – by Eric Raymond: an explanation of Open Source software. And an explanation of why software created in corporations is frequently a mess. I don’t think Open Source is the answer to all our problems, but I think it is an answer to some and is here to stay.

6. Enrollment Management by Peter Conklin: until recently this was one you really have to hunt down, but it is worth it. Originally published in the Digital Technical Journal (Digital as in DEC or Digital Equipment) in 1992 it was republished by the IEEE in July 1996. HP now have back issues of the Digital Journal online so you can read it here.

This piece tells the story of the Alpha AXP programme in the late 1980’s and early 1999’s. In theory, on paper, on GANTT charts the project couldn’t be done. The author tells how enrollment management was used to engage those working on the project. Although written in 1992 this paper is about Agile development. And it is about Agile development in the large – over 2,000 engineers worked on the project.

I wrote about this article before, a few years go. One of the small stories in this paper always brings a smile to my face. The OpenVMS team committed to a delivery schedule and said ‘We don’t know how to achieve this, but we commit to finding a way.’

So there you have it. Six essays I recommend you read. And if you only have time for one? Well, chances are you know about Open Source and the Silver Bullet so I recommend you read Enrolment Management or A Rational Process, and if you push me more I’ll say: Enrolment Management.

 

Book review: Agile Project Management with SCRUM (and rant)

It is difficult to say anything bad about Agile Project Management with Scrum (Schwaber, 2004). It is a short book, lucid and easy to read. It sticks to its topic – managing projects using scrum. Rather than present Scrum in depth (which I think he has done elsewhere) Schwaber walks us through a set of small case studies and reflections on each one.

If this book has a failing it is: who will read it? – I’m not sure. There is probably not enough information here for someone to implement Scrum but I find it hard to see what someone experienced with Scrum would learn.

For me it was a late introduction to Scrum. I can’t ever recall reading a book dedicated to Scrum. But I picked up the basics of Scrum somewhere, probably websites, articles and conversations. So I would suggest this book is best for someone wanting to an introduction to Scrum, and specifically wanting an idea of how Scrum works in practice.

Which brings me to the question, Why Scrum at all?

I found that Scrum kept coming up more and more and I felt the need to get the introduction I never had so to speak. It is clear to me now (if there was ever any doubt) that Scrum is the management side that is missing from XP.

My own Blue-White-Red process is in effect an example of Scrum and XP (both modified) being used together. Looking back the roots of Blue-White-Red are difficult to work out. I think it was inspired by XP and Scrum and takes many practices form them but it was equally influenced by what I had done in the past and seen work. Perhaps more importantly it was influenced by a bunch of ideas I’d picked up on my MBA, specifically Lean manufacturing.

Unlike Scrum Blue-White-Red is there for anyone to pick up, use, abuse and modify as you see fit. Scrum isn’t, Scrum is actually Scrum ™, and it is now surrounded by a host of Scrum certifications (Scrum Master, Product Owners, etc.), courses, books, alliances, etc. etc. Scrum has become its own little marketing platform.

In some ways this is good, by doing this Scrum can satisfy business that want to adopt some defined product, it allows Scrum to tackle CMM(I) type organizations and it allows people who want to do Agile to get on courses and learn the skills. But this is also leads to rigidity.

I recently met a Scrum Master who was having trouble with the process. I suggested a one week iteration rather than two week. She saw how this would help but knew the rest of the company used two. She expressed doubts about keeping her meeting schedule (as prescribed by Scrum) in one week. I suggested some changes, at this point she worried that she was deviating from the Scrum process too much.

At the end of this book are the rules of Scrum. Schwaber says: here are the rules, follow them, when you are good at them then (and only then) can the team think about changing them. Scrum needs this, if it was as free as Blue-White-Red it wouldn’t pass muster with CMM(I) and a certificate would be meaningless. But, it also builds in rigidity and people get worried about deviating from the rules.

For me there is an element of The Punk Ideal in Agile, some of it is just about getting our there and doing your own thing, your own way. Who cares if you get it right or wrong? The only mistake is not trying.

At this year’s XP Day conference Keith Braithwaite said something that struck a cord with me, and I’m paraphrasing here ‘cos I don’t remember word for word: ‘I’m not really part of the UK Agile set’ he said, ‘I never worked for Connextra or Thoughtworks.’ And that’s the point, neither of us waited to work for an Agile organization, or to be blessed with a Scrum certificate, we just got on with improving things.

Too many people sit around waiting for something to change, waiting for someone else to fix their problems, waiting for the magic dust that will make everything all right. That’s one reason why so many IT projects go wrong, people wait for someone else to fix it. In part our school system is to blame but that’s why the Punk Ideal is so important. Again, this takes us back to Post Modern Programming. There is no one ‘right’ way of doing this, there are many competing ideas of what right is.

So here is my advice: learn everything you can about XP and Scrum, they are good. Consider them resources to better your understanding. Then go and do Blue-White-Red.

Right now I’m adding two statements to Blue-White-Red:
• Blue-White-Red is open source, I can teach you it but there will never be a certificate
• Blue-White-Red is jazz, it is improvisation, no two performances should ever be the same

If you aren’t doing something different to what I have described you aren’t doing it properly. Like the English language, there is only one rule which is never broken, the rule is: every rule is broken at some time.

Recruitment and customer experience

Wednesday’s Financial Times carried the monthly technology review. A couple of pieces caught my eye, both individually and when put together.


First this report In an e-world, IT controls the customer experience (subscription required) makes the point that if your business is conducted online then your customer experience is an electronic customer experience which in turn means the customer experience is decided by the IT department. This is a point I’ve made myself in the past – although I’ve never came up with such a compact phase to describe it.

In posts in January 2006 and December 2006 I sounded off against poor travel company web sites. My customer experience is poor because the web sites are poor. It doesn’t have to be this way but unless the IT department think about the customer experience, or the people responsible for the product involve themselves with IT this is what happens. Unfortunately IT departments have spent years refining their image as uncooperative.

Given the increased use of e-commerce by all businesses – not just those like Amazon which only exist on the web but everyday companies like the travel companies I dislike – then any business that does any e-retailing has this issue. The online brand can damage the off-line brand.

The second piece that caught my attention was this one Can HR handle IT recruitment? According to this article human resource departments do not have the skills and experience required to hire IT people. The story rings true from my own experiences and from many anecdotes I’ve heard over the years.

Although these stories all ring true I’ve also known several good HR people. People who have their heads screwed on and want the best for the business. Plus I’ve read a fair few HR text books and articles and I know HR people aren’t really as bad as IT people make out. So what’s going on?

Well I have some possible explanations.

Theory 1: Many companies have bad HR departments. There are some good HR departments out there but possibly most of them are not worth the salaries we pay them.

Theory 2: Everyone has these problems with HR, it isn’t just IT. HR is just badly understood by the rest of the business.

Notice that these explanations are not incompatible. Neither are they incompatible with the FT article. Which raises the questions: What are HR actually doing? Why aren’t HR departments getting to grips with IT and trying to rectify the problem? After all, strictly speaking, it is the HR departments job to hire people so it is they who have the problem. They can’t blame IT for this problem.

Put all these theories together and you get: HR is important, HR doesn’t understand IT, many HR departments are poor, many HR departments fail to hire the right people. As a result many IT companies do not hire the best staff. And because good IT depends on good people few companies will have good IT.

Proof for this theory comes from Google and Microsoft. Both of these companies have built hiring machine. They both need a lot of IT staff and they have made sure HR can do the job properly.

So the lesson is: If you want good IT you start by fixing your HR department.

Finally, put those two articles together.

IT controls the customer experience but HR do not know how to hire the people IT needs. In other words: HR departments do not know how to hire people who create the customer experience. Am I the only one who sees this as a serious problem here?

Does (system) documentation work?

OK, I promise this is the last entry on the Nurnberg funnel, after this I’ve worked it through my system…

In my entry on Nurnberg funnel and system development I wondered is system documentation actually works. Well I missed one piece of evidence that it does work. Go into your local bookstore, Waterstones, Borders, even Amazon online and look at the books on computing. Specifically look at the technical books that describe things like programming languages, operating systems, APIs and the like. If system documentation does not work how do we explain the existence of all these books?

After all, publishers are in the business of making money. If these books did not work – i.e. did not help learning and transfer knowledge – then presumably nobody would buy them, there would be no profit in publishing them and consequently they wouldn’t be taking up real-estate space in the book store.

So how do we explain these books if technical documentation doesn’t work?

I don’t have any figures on what is happening but here is my guess.

Firstly a whole load of this documentation does not work. Many books get bought despite being bad. Many more books are bad and simply don’t get bought, publishers swallow the loss and pulp the books. I would guess this category covers many many books. Lets take a stab and say 40% of all technical books.

A second category of books do work and they work for exactly the reasons Carroll outlined in the Nurnberg funnel. They are written along the lines of minimalism. My guess it that a lot of those “For Dummies” and similar books fall into this category. Still, this type of book represents a small percentage of all books. Lets say 5% – probably an overstatement but it keeps the numbers easy.

OK, I still have 55% to account for – and I’m deliberately not saying if these are percentage of books sold or books published.

Next up I think there are some books which do not directly take on board the minimalist ideas but have a similar approach and work for similar reasons. I’m specifically thinking here of patterns books like Design patterns and Pattern Languages of Program Design 5 (to which I was a contributor).

In part patterns are popular and accessible because they start with a problem and describe a solution. This is a little like the task orientation that Carroll advocates. I’m sure patterns books are not alone here but there aren’t very many books in this category so lets just say another 5%.

This also starts to hint at another explanation and one which must account for many of the remaining 50% of books. Simply minimalism is but one technique for creating documentation, it works particularly well in one field – user manuals – but it is not the only one.

For example I know of one other method, story telling. This is usually advocated as a management or knowledge management activity to be conducted verbally. (See books like The Springboard and Storytelling in Organizations). However there are technical books out there that take the same track.

For example, I found the original version of Inside Windows NT quite story like. Although perhaps this is a sign of how techno-geeky I was in the mid-late 1990’s. Somehow the second edition of the book never had the same plot or interest for me.

Less technical books about technical subjects are better examples of story telling. Take The Soul of a New Machine for example. This is a must read, I left it far too long before I read it but its right up there with The Mythical Man Month, Peopleware and The Psychology of Computer Programming if you want to know how software (and hardware) really get created. But Soul of a New Machine is also a story, it can even be bedtime reading.

Books like these are more the exception than the rule so they are few and far between. Lets say 1% are story books.

Another category is reference books like Charles Petzold’s “Programming Windows”. I defy anyone to actually read this books cover to cover, you delve into when you have a specific problem or need to know some specific detail. But reference books probably constitute a lot of the books written, say 20%.

That takes me to 71%. I still can’t account for 29% of books. I give up.

The important thing is that people read books for different reasons. Our motivation for reading one of these books will be different to the motivation for reading another. That will change the way we approach buying and reading books.

Which in a strange way brings us back to minimalism. People use Petzold’s books when they have a task to accomplish. People pick them up under certain circumstances and like a Dummies book expect to get something specific from them. But that doesn’t mean all books should be written in the minimalist style. Minimalism is just one of many styles.

So actually, we’ve come back to one of the re-occurring themes of this blog: know your customers, service their needs with a product that is designed to meet those needs.

Products development doesn’t end when the code is written, compiled and burnt onto a CD. It has to include the documentation, service and support that is supplied with the products. It also means ensuring that future product development can continue, whether through just-in-case documentation or just-in-time networks of people who know.

Unfortunately obvious solutions – like big thick manuals – are not necessarily the best solutions. We need to be on the look out for new solutions and new ideas.

And we need to understand the costs and benefits of all this. This is difficult bit because so often we don’t know the numbers and we can only speculate on what they are. But somehow we need to put all of that together.

IT does matter – at least sometimes

Ever since Nicholas Carr wrote “IT doesn’t matter” there has been a well publicised debate on the real value of IT in modern businesses. Sometimes Carr is right, commodity hardware and commodity software is good enough, there is no competitive advantage to be gained by going beyond cheap commodity products.

But sometimes IT does matter. Sometimes IT can be the source of competitive advantage, sometimes it can help you do things you couldn’t do otherwise. I’m always on the look out for these instances and the front page of today’s Financial Times gives a great example.

The London Stock Exchange (LSE) has just announced half year profits up from £26m to £76 – yes a three fold increase. This is on trading volume up 42% to 744bn shares. And the reason? An improved IT system.

Over the last 10 years stock exchanges – and related institutions – have switched to electronic trading systems. These have multiple advantages over the old “open outcry” systems: accuracy, speed, process automation, etc. etc. Perhaps one of the biggest benefits is that electronic trading systems allow fully automated trading, a computer programmed with the right algorithms can conduct the trading. This is more than just automating the process it is a radical change in the basis of share trading system and has helped hedge funds reach their current position.

Earlier this year the LSE introduced a new version of its trading system, SETS. In reality this probably meant a software upgrade, perhaps a hardware upgrade, maybe even bandwidth upgrades. The hardware is commodity boxes (Sun boxes I think) and the bandwidth is purchased from regular communication providers, the software is the interesting bit, this is specific to the LSE. A change to the system usually means a software upgrade, and sometimes this can go wrong – like it did earlier this week at the London Metals Exchange (LME).

In the case of the LSE and its customers IT does matter, it allows them to do something different and it can make a big difference to the bottom line. But it comes with risk, it matters because your business now depends on this stuff, like at the LME.

This IT is expensive and difficult to get right – I know, I worked on the Reuters end of the LIFFE Connect trading system when it went live in 1999. As the LSE shows, when you get it right it makes a big difference.

However, IT also has its limits. Its all to easy to dream up some big new idea, some strategy and say “Technology will implement it.” Technology has its limits and this can effect strategy is a very real way. A good example of this is the problem Skype faces, describe by Robert X. Cringely in July.

Although most people think Skype is a pure peer-to-peer networking system it isn’t. Because of Network Address Translation (NAT) Skype needs to impose a server into most calls. These don’t have to be Skype’s own servers, they’ve worked out how to borrow server bandwidth from others but as the user base grows this will become a bigger problem.

For Skype there is no short or medium term way around this problem – their techno-business strategy means at some stage they had to get access to lots of server. Consequently it was almost inevitable that they had to sell out to a big player like eBay or Google sooner or later to get access to more public servers.

Meanwhile, Skype, and similar VOIP technology, is changing the business strategy of other companies, obviously traditional telcos like AT&T and BT are vulnerable, so to are mobile operators like Vodafone but also companies who simply use telephones – which is most of us – face change. Even if in the long term VOIP becomes yet another commodity technology it is causing change now, and that is strategy and that is important.

So, there you have it, another reason why I still believe IT is important. Ignoring IT in creating your strategy is wrong, letting it run the entire show is wrong, you need to find a middle way, which is were you need people who understand both.