This is a bit of a distraction from the usual fare on my blog (and no jokes that the usual fare on this blog is no posts…). However, I stumbled across the concept of “Agile” development recently, and I believe the concepts of this working methodology are extremely far-reaching (though currently they are only really known about in the world of software programming). And far more interesting than you’d expect anything to be coming out of the IT world. (You can tell I’m non-IT, can’t you?)
Where I heard about it was at the 2010 Tessitura Learning and Community Conference, which was a highly stimulating and enjoyable experience like the 2009 one (my thoughts here). This year I decided to attend a session there titled “Agile in the Arts”. I thought vaguely the session was going to be about the consulting team that was working with Tessitura on their Next Generation project, but instead, I saw speakers from the IT departments of various arts companies that use Tessitura software, and they were all raving about a new system of working they had adopted called “Agile methodology”.
Slide after slide flashed on the screen, going on about Kanban boards, scrums, sprints, standing meetings, pair programming and the sheer joy of whiteboards. I wasn’t sure, at first, what I was seeing, but it was quite clear that computer programmers, in the last 10 years, had invented more rituals than the Roman Catholic Church had come up with in two millennia.
However, as I started to cotton on to what the terms referred to, I started to realise that these “Agile teams”, as they call themselves, had come up with some startling new methods of dealing with common problems we encounter at work. I got really fired up by the whole session, and the next week, I went and paid an exorbitant amount of money to get hold of a book on Agile methodology (there are quite a few out there, but you’ll only really find them lurking in the IT section of a large bookstore).
There are many, many components to the methodologies (and the one in particular that I read up on was a system called Extreme Programming – XP for short), but I want to share with you the basic concept today of the “iteration” and how I’m attempting to implement some agile ideas at work.
(Officially, what I’m doing isn’t considered true Agile, because technically all Agile methodologies are used by teams – there’s not really anything that refers to individuals. But, seriously, this stuff is way too good only to be used by companies with more than one IT staff. In fact, it’s way too good to be only used by IT staff, period.)
In Agile teams, they work in blocks of time – sometimes called “iterations” (in XP), sometimes “sprints” (in another system called Scrum). I’m going to call them “iterations”. Every iteration, the programmers attempt to produce a fully working version of what they’re building. Iteration by iteration, they add features, until it’s all complete.
The opposite of this is the old way of doing things – the waterfall method of planning. Waterfall planning is where you plan everything out beforehand, go away and build it, and then come back and see whether you like it. The problem with this is that you have no idea until the end whether or not the “customer” (the person you’re doing the work for – either an external customer or someone in your company) likes what you’re doing until you’ve actually built the thing. In the Agile world, however, you’d come up with a smaller version of the final product, that had less limited features, see what the customer thought of that part, and if things are going well, go back and build some more.
So, for instance, if a project is 10 weeks long, under normal circumstances at the end of 2 weeks, you might not have anything to see. However, under Agile methodology, you would get to see something fully working by the 2nd week and could decide whether things were progressing.
The benefits are immense. For the customer, you get to have close tabs on what’s being built. If you change your mind or your business needs change, you can get the programmers to switch track really quickly.
But I think Agile’s best invention is the concept of “stories” and “velocity” as a way of ensuring that programmers don’t get overloaded with work. Instead of thinking of their work as a series of IT tasks, programmers are asked to work with their customers to create “stories”. So instead of “build a database to hold customers and sales” the story might be “As a marketing team, we’d like to be able to see how our sales are tracking week by week”.
At the beginning of every iteration, the programmers demo the stories they finished last week, and then prioritise stories for the next week. The best part of this process is that customers are the ones that are encouraged to write the stories (and literally write them – on an index card). The programmers give the stories “points” that estimate how long they will take to complete. Then the customers work out how they want to spend their points for the next iteration. The catch is that the can only spend points up to the “velocity” – the number of story points that the programmers completed last iteration.
What a great idea! This straight away gets rid of the estimation problems that can occur. As someone who has to make estimates on things that are hard to estimate on a regular basis, I can see the benefit of this. I tend to underestimate things, and take on more than I can deliver. Other people might be more cautious and want to overestimate things. But the idea of velocity is that people’s estimates to be consistently under or over on a regular basis. So thus if people tend to underestimate, they’ll soon find that their velocity points drop and they’ll only take on the amount of work they can compete. If people tend to overestimate, they’ll get through more points in an iteration and next time they can take on more. It’s a constantly improving feedback loop.
So I decided that I’d give the following a try at work:
- Iterations of a week long – from Thursday morning through to Wednesday.
- Turning people’s requests into stories.
- Giving those stories points.
- Using the weekly Tessitura meeting that we have established to work out which stories have priority for the coming week.
To test all this, I tried using the index cards and stories for managing my own workload for a week and a half before we started to give me an idea of my own velocity. I think it will take a month to work out a reliable figure, and how to estimate properly, but it’s been a good discipline and I’m keen to see how it goes.
If all this works, and my workload adjusts to less frantic levels, I’ll maybe come back and let you know how it’s all going.