One-Man Agile

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 2^nd 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.

Tessitura in Texas

Those of you following me on Twitter or Facebook over the last week would have noticed that I was saying an awful lot about Texas and an awful lot of stuff about other things that may or may not have made sense, depending on whether you worked in the arts or not.

So I thought I’d give you all a quick update on a week spent in San Antonio at a conference run by a very specialised and unique software company. You have been warned.

For those who are completely new to Tessitura, in the bad old days – say, about 10 years ago – performing arts companies used to use ticketing software to, believe it or not, sell tickets to shows. Their primary concern was making sure that Customer X got the tickets they asked for to a show. That was it.

However, in the world of performing arts, there has also been a long and honourable tradition of trying to collect donations from patrons. They get sent letters asking for money, rich patrons get invited to special events, meetings are made – and all sorts of information is stored for this purpose. Birthdates of prospects, the names of their spouses and children, what type of food they like to eat, their tastes in music – all of this is vitally important for the fundraiser.

So in these bad old days, the fundraising team (the correct term now is “development” team) would keep all this information in files, on cards, in notebooks, and if they were computer-savvy – they might even use a spreadsheet.

Meanwhile, in the corporate world, the tools to deal with this kind of stuff were becoming more and more powerful. Software known as CRM (Customer Relationship Management) was developed that could easily keep track of this sort of thing, and the corporate world used it extensively to monitor its sales efforts.

Some arts companies even started using CRM software, but an obvious problem existed – even though the CRM software was a good place to keep track of information and tasks related to chasing money – it was still missing the vital concept of knowing about ticket buying information – which was stored on the ticketing software.

The New York Metropolitan Opera, back in 2001, decided to deal with the problem. They spent several million dollars to come up with a piece of software that combined a state of the art ticketing package with the tools commonly used in CRM software. They called it Tessitura, an opera term for the range of the voice. They rolled it out across about half a dozen organisations.

However, the demand was so great for this, they realised they were onto a winner – so they established a third party company that could just focus on software and the organisation now known as the Tessitura Network was born.

My company just signed up Tessitura earlier this year, and so we’re relatively new to the whole software. But I was privileged to be able to attend the Tessitura Learning and Community Conference which is held yearly – this year in San Antonio, Texas.

Things really started to come together for me at this conference. While I had a fairly good idea of how Tessitura worked from being involved in the project to roll it out, it was incredible to be able to go to this conference and meet up with all the Tessitura staff and hundreds of people from the other companies using this software.

There’s two things that made this conference stand out for me:

1) The Tessitura bbusiness model is absolutely amazing. It’s a non-profit software company. So it exists purely for the purpose of making the best ticketing software in the world for the arts/cultural world. And it really listens to its users. While there was certainly a teaching aspect to the conference, where Tessitura staff offered teaching on various modules of the software – there was a huge emphasis on hearing what people wanted in the software. In a very democratic process, Tessitura canvasses its member organisations every year  for changes that they would like to see and then gives every company 40 votes to cast towards the changes they would most like to see.

2) As well as the attitude of the company, the community side of the conference was fantastic. Many of the presentations during the conference were made by users, showcasing innovative ways they had used Tessitura to aid their business. This ranged from some quite technical stuff through to some simple tweaks and reports that people had produced. Not only that, you only had to have a few quick conversations with people to realise that everyone there was ready to share their expertise.

In some ways, the conference did my head in, because it was so much information and we’re so new into the process. But in other ways, I now have at least a full year’s worth of stuff to explore. So I think that makes it a worthwhile conference for me.

The other half of it was that it was just plain fun being able to visit San Antonio, Texas. This is home of the Alamo – an old Spanish mission where a small group of Texans were holed up and ultimately slaughtered by an invading Mexican army in 1836. It was this massacre that fired up the Americans enough to defeat the Mexican army later (and ultimately invade Mexico in 1840), and a really well-preserved and moving part of history.

Then there were the people. I must admit that having an Australian accent (used strategically), can be a great boon in disguise – so I was shouted at least one dinner and several drinks over the course of the week, by the fine folks of the Nashville Performing Arts Center and the Arsht Center (in Miami). All in all, it was great fun, and I’m looking forward to being able to implement some of the things I’ve learned and also keeping in touch with the people I’ve met.

Finally, it was quite an eye-opener of the sheer joy of Twitter. (Okay, shut up, Dave – just because you’re right on this one, doesn’t make you right on everything . . .). There was a conference hashtag set up, and over the course of the week, most of the tweeters at the conference caught up with one another, and we probably all came out with at least a dozen new followers each. All very fun.

Anyway, that might explain a bit more of the background. Now on to a movie review . . .