RSS - Rogue Surgeon Sydrome

The surgeon model as advocated by Fred Brooks is the second most efficient method of developing software. The analogy is with the surgeon who is the focus of the whole show during an operation - the one that all the other members of staff are there to support. In many small technology companies, essentially, you have one surgeon/founder/guru who writes all the code himself, or certainly writes all the difficult stuff himself. Quite often the surgeon was the one who came up with the idea for the software or the business in the first place, it's his drive, his creativity and willingness to do something different from the herd that is the reason that there is business at all. If the surgeon is good this can be a very effective way of getting software written. For a while.

There's a problem though. The surgeon model doesn't scale. At some point a successful piece of software is going to need a lot of boring, non-charismatic things done to it, like multiple language support and multiple platform support. At some point the organisation is going to grow and start to hire people who aren't doing it for love, but for money. Somewhere around 10-15 people organisations can no longer be run charismatically (because everybody just loves being in the founder's gang) and have to start being run bureaucratically (because people do the job they are paid to do). Accounts staff, sales staff and business development aren't the kind of people that the surgeon/founder - as someone I know delicately put it - wants to go to lunch and eat noodles with. To avoid these problems many new media and technology companies get stuck at around 10-15 employees, vaguely hoping that they'll be bought out by some Silicon Valley conglomerate. With no other growth/exit strategy they stagnate. It can be unpleasant to watch and even more unpleasant to experience.

This is a very tricky situation to be in and there aren't many good solutions. Quite often the "Surgeon" in this model is a founder of the company. The kind of person who founds a company isn't the kind of person who wants to follow rules. That's how they got where they are, by not following rules. Sometimes for other employees this can be very inspiring. Sometimes it can be very tedious. People who have had to work with Steve Jobs have called this the "Hero shit-head roller coaster". At one company that I used to work for, the "Surgeon"/founder would resort to chanting "Ooh! Aren't we grown up!" whenever the issue of pensions was raised at board meetings. This was infuriating for the other board members who had grown up, had wives and children and would really quite like to not have to survive on Pot Noodles for the last 20 years of their lives.

You can bring in "professional" developers and "professional" project managers - these are people who rely on process rather than charisma to get the job done. But very often they don't sit well with the people who are already there, gathered around the surgeon. When I suggested to one company that I talked to that they deal with this problem by hiring in outside project managers they said "Yeah, we tried that - he got eaten alive." You can bring in professional management and then fire the founder. Apple did this and that didn't work out so well either. What companies really need to do is restructure in a way that allows the company to scale and remain creative. The surgeon/founder should be given a role where he can carry on doing what he's good at - doing new things, breaking the rules, in business speak R&D.

Agile processes can help ease the passage through this difficult period. Pair programming allows the surgeon/founder/guru to spread his knowledge of the software around the development team. Test driven development and refactoring reduce the demands on the surgeon/founder and leave him free to do what he's best at - thinking good thoughts, breaking the rules and coming up with new product innovations. But Agile can't be the whole answer. You're probably not supposed to say this, when you work for an Agile training and consultancy company. Things will only really move forward when the founder and others on the mangement team admit to themselves and each other what they actually want from their careers and make sure that this is something that their position in the company can really provide. Maybe this is an Agile process because Agile is all about having those awkward conversations sooner rather than later.

This isn't just a problem in software development. I've been talking it over with Dave Dawes who works with social enterprises in the Health sector and he recognises it as a common problem. In many fields, amidst all the hullabaloo about the need to support entrepreneurship, the need to support successful organisations that are ready for the second wave sometimes gets lost.

Baby Steps: Agile and the Small Creative Business

The founding idea of Agile Lab was to take innovative thinking from Agile methods such as XP and Scrum and introduce them to a wider constituency.

We worked together with an organisation called Creative Northants to understand the issues facing five small creative businesses in Northamptonshire. None of these businesses had any connection with software development or computing. We visited each business at their premises and interviewed them about the challenges that they faced as creative businesses in Northamptonshire. The resulting report was described by our client Will Pearson at Creative Northants as "excellent" and "very helpful".

We identified three areas in which these small creative businesses were having difficulty: business networking, marketing and knowledge of IT. We are obviously not the first to identify this kind of problem, especially with regard to marketing. A great deal of arts funding seems to require the businesses to produce a "business plan". Several of our interviews had been required to produce such plans to get government funding. None of them had delivered on these plans. In one case we heard of a major arts organisation that had been required to produce a detailed business plan in order to get funding, but had then not taken any steps to execute the plan for over two years (and counting).

At Agile Lab we felt that there were ways of helping these organisations without the need for a detailed long-term plan. Using the extreme programming principle of "start from where you are" and "you can always do something" we ran a workshop for our five interviewees. For each category of business networking, marketing and IT knowledge we asked them to write a short statement of something that they would like to do in that area - in Agile we call these statements "stories". We then asked them to write a "test" - how they would know when they had done that thing. This is something that is very different from a test for a piece of software. A piece of software either works or it doesn't, a conversation at a networking event make take years to pay off. We also asked them to estimate how much effort each task would take. Then (if you know anything about Agile, this won't be a surprise) we asked our workshop participants to prioritise their stories and come up with a set of stories that they feel they could deliver on in a period of three months.

Three months later we ran another workshop. In one-on-one interviews we carried out a retrospective on the iterations that our interviewees had put together. We were pleased to see that each of our participants had made progress in line with the iterations that they'd outlined. Each of our participants had done some marketing and some networking. Using the Agile concepts of story writing, prioritisation and iteration planning we managed to break an intimidating task that was at risk of not being done at all into manageable pieces.