Agile Lab to Run a Training Course at the London Games Festival

Agile Lab are going to be running an Introduction to Agile course at the London Games Festival in London in October 2008. This will be in conjunction with 01ZeroOne. More details to follow, nearer the time.

Change glorious change - why Agile is right for schools

A deputy head of a large rural primary school coming out of special measures recently described her working environment as one of continual crisis management. She talked about the way that they have to run the school pretty much on a week by week basis with continually changing priorities, an unstable staff base with a lot of absence and transience and with continual external interference.

A now ex-principle of a large academy school in London described the changing curriculum and increasing focus on creative, enterprise, innovative and project based learning as one in which teachers are now project managers as well as educators. He went on to describe the fact that projects have to cope effectively with continual flux in resources and with the time constraints of the timetable and therefore the notion that careful planning will somehow ensure success is a misnomer - it is the ability to deliver projects by coping effectively with continual change, reshaping and re-prioritising as you go that will ensure successful outcomes.

These two examples represent opposite ends of the spectrum in terms of school 'type' and current 'success status'. Yet despite this they both require internal process for leadership and management that can cope successfully with constant re-prioritisation, constant resource flux, limited time. They also need process that is light weight (teachers are time poor), easy to learn, flexible, works for external collaboration, is formalised enough that it can be reported upon and have success criteria built in, all of which is offered by Agile.

The following elements of Agile all map effectively onto the needs of schools:

1. Iterative working - by planning in terms of what can be achieved over a period of one month/half a semester/a term or whatever time segment works in terms of an individual school, Agile fits naturally with a school's 'heart beat'
   
2. Constant prioritisation - by recognising that demands on staff time and school priorities change on a term by term basis (or week by week in the case of a school on special measures), an approach that deals effectively with this is essential
3. Velocity - having a system built in that allows planning to respond effectively to constant change in time available to those delivering projects allows the project to fit the available time of those involved rather than the people having to fit the project and therefore massively reduces the risk of failure
4. Stories - the use of a narrative based needs and outcome communication approach allows Agile to work effectively as a planning and negotiation tool (particularly when used with inter-iteration re-prioritisation) with all stakeholders within a school community including governors, teachers, support staff, local authorities, partner schools and organisations, parents and pupils
5. Test-first - by determining how successful completion of tasks is to be recognised and negotiated before work begins, it becomes clear to understand what has been done and what hasn't and provide a clear progress reporting mechanism
   
6. Stand-up meetings - Agile works best with regular short meetings where people look at the stories they are working on, report on progress made and barriers encountered. These meetings can happen effectively in the coffee-length restrictions of break time, the 10 minutes available at lunch or before registration or before going home

This is just a sketch exploring how Agile would work in schools, but Agile grew out of the need for an approach that could deal effectively with constant change in needs and resource flux and does not allow these inevitable challenges to lead to failure. Therefore it would appear that Agile may well have a lot to offer school leadership and management.

What can Agile process provide to investors in innovation?

The idea of using an Agile approach to investing in innovation is nothing new. The BBC Innovation Labs have been doing this for many years through providing single iteration support to those with an interesting idea. The BBC invest in many companies producing a demonstrable first version of their idea before deciding to invest further. This approach massively reduces the BBC's risk as they are able to see both whether the idea has legs once it becomes demonstrable and if the development team are up to the job.

This use of single iteration development terms is used as a way of selling Agile development by providing massively reduced investment risk through only committing to a single iteration while delivering working code. This means that at the end of the iteration the buyer can take the code to another development team if they so wish. In the case of the Innovation Labs it is likely that the BBC would retain some degree of exploitation rights to the IP should they wish to take a good idea that was badly realised to another team.

The fact that Agile is so effective at marrying formalised project and product development management with creative and innovative process means that this is a no brainer for those that have worked in this way. Having talked to a number of investment organisations recently, it appears that Agile offers another potentially useful tool in addition to monitoring progress that can be tied to investment rounds as used by the BBC. This is effective communication.

The process of using stories and prioritisation enables the investor to see exactly what decisions are being made and to interrogate the rational behind prioritisation. If an investor takes part in the transition from iteration to iteration they have a clear picture of what is going on and are able to feel sure that their money is being spent realistically. The investor will also able to see the progress being made through the presentation of demonstrable tested development. This provides clear windows for investor communication while leaving the innovator free to get on with their work during actual iterations.

Therefore Agile's embracing and normalisation of constant change and risk (essential ingredients of innovation) combined with a process that effectively exposes this makes it a perfect process for allowing a better relationship between investors and innovators.

The Innovation Edge

The Innovation Edge, Nesta's 18 monthly conference, took place on 20th May 2008 at the Festival Hall. Jonathan Kestenbaum, Nesta's Cheif Executive, was determined to show just how far the organisation has moved on under his stewardship by reflecting on the difference between this gathering and the last one at The Business Design Centre in Islington in 2006, shortly after he took the reigns. I am not in a position to comment on whether Nesta is a very different beast to its previous incarnation, but if the key note speakers on show are anything to go on then they certainly seem to have moved up a league.

The key note session was chaired by Jonathan Freedland and began with Jonathan interviewing none other than Sir Tim Burners-Lee, the inventor of the world wide web. Sir Tim appeared every bit the modest unassuming and selfless socially motivated scientist that you one might expect from the person who invented arguably the most important innovation since the industrial revolution. He jokingly reminisced how his initial proposal to create the www was described by his manager at CERN as being 'vague but interesting' and how he was only able to work on it in down time between his important work.

Sir Tim was followed by Bob Geldof (no hyper link required) who stole the show with a witty, invigorating and critical speech that seamlessly bridged the conference theme of sustaining UK innovation with a call to arms on how innovation can do so much more to help people in Africa work their way out of poverty. He made the point that Europe should do more to use its innovation capital to help Africa. He reflected despite the fact Africa lies just 8 miles off the southern coast of Spain and Europe remains the richest continent in the world, China is investing so much more in Africa that European nations.

The afternoon began in similar big hitter style with none other than Gordon Brown providing 10 minutes of surprisingly relaxed informal comment and even a couple of jokes in support of UK innovation.

If Nesta is able to become as good as the speakers on show in effecting positive change and sustaining innovation then they really will have moved a long way in the last 18 months. I look forward to seeing how they appear in another 18 months time.

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.

Try everything once...

This post has been bothering me for some time.

I was tempted to point out that programming simply isn't like walking down the street. Programming isn't a straight race. In programming: fast!=good. But then, when I thought about it some more I realised that programming in a team is in some ways like walking down a busy street: like it or not, the best way for anybody to make progress is to have some sensitivity for the speed at which others are moving. In both programming, and in walking down the street: fast!=good.

Finally I wondered who would want to hire, or be on a team with, the kind of person who can't even walk down the street without getting annoyed. But maybe behind all this maladroit bluster is fear. This is what Kent Beck has to say about fear in the preface to his book "Test Driven Development".

• Fear makes you tentative [and so reluctant to try something new - like pair programming?]
  


• Fear makes you want to communicate less [like maybe not wanting to pair program?]


• Fear makes you shy away from feedback [like maybe not wanting to pair program?]


• Fear makes you grumpy [like getting annoyed with people you don't know for walking down the street?]

But what are his fears? Are any of them legitimate? It might be legitimate to fear that pair programming will mean that you will have to spend your entire working day explaining to some newbie where to put the semi-colons. For this reasons pairs should be changed regularly. It might also be a legitimate fear that some of our best ideas and our best problems to solutions happen when we're alone. A way of working that allows people to cook up ideas in private before they test them out in public is well-known in other collaborative fields - the so-called "Cave and Commons" approach. For that reason, pairing shouldn't be scheduled to take up the whole day. Programmers should be give time in their "Caves" to get their heads together and sketch out ideas. A friend of mine who regularly paired with someone and didn't take this approach said that he and his partner found themselves coming in earlier and earlier each morning to try to sketch out their ideas and find a solution to the previous day's problems before their partner arrived.

Pair programming is about learning from other people and letting people learn from you. Pair programming is about sharing the knowledge of a system around a team. If you're really worried that you're not going to learn anything new when you pair with someone, don't be. Ask any teacher, they'll tell you that you only really understand something once you've taught it to someone else. And that's assuming that you manage to find someone who really can't teach you anything. Chances are they will know something you don't know. They'll know a library you don't know of, they'll have worked on a bit of the system that you don't know. They'll know a keyboard short-cut in Eclipse, or (may a higher power preserve us) in vi. They'll have been taught the latest template libraries in their final year at college.

There are lots of reasons why this is a good idea. If a member of the team leaves for some reason, it reduces the chances that some part of the system will become impossible to maintain . It increases the chance that mistakes and problems that require knowledge of the whole system will be spotted. But it's certain that pair programming won't work if it's forced on people.


Agile Lab's Technical Aspects of Agile course offers developers a chance to experience pair programming in a safe, non-threatening environment. At the same time they improve their technical skills in test-driven development and their coding and architectural skills through refactoring.

Technical Aspects of Agile - Central London 8th and 9th July

We're running a course on the Technical Aspects of Agile on 8th and 9th of July at 01Zero One in Soho, central London.

The course will run for two days. The first day will deal with test driven development (TDD) and the second day will deal with refactoring. Throughout the course people will be asked to pair program.

We understand that for various reasons people can find pair programming daunting. This is a perfect opportunity to give pair programming a try in a safe, non-judgemental environment. We think you'll like it.