Our journey into Agile, pt.2

Encountering Agile

Back in April 2008 I attended the Scotland on Rails 2008 conference in Edinburgh; I literally have the t-shirt to prove it.  It was an absolutely fascinating (read: über-geeky) conference let down for me slightly by the fact that I really didn’t have a clue what they were talking about most of the time as I had only just begun to explore Ruby on Rails.

It really was the most hardcore conference that I’ve ever attended. Most of what was said went way over my head as the speakers went into minute details about which new functions were available in Ruby 1.9 (does Ruby even have functions?! See: not a clue!), advanced class design, and there was even a talk called “Bonus Erlang Session”.  That could be the name of an experimental band from Germany for all I know.

But there were a couple of things that I really enjoyed, one was the keynote speech by David Black which was just inspirational (check it out on iTunes, it’s called The Flying non-Scotsman: or, My thirty-two year trip from the Borders to Edinburgh), the other was the number of speakers who kept talking about BDD (Behaviour Driven Development), SDD (Story Driven Development) and Agile.

 

The Art of Agile Development

The Art of Agile Development by James Shore and Shane Warden

 

O’Reilly had a book stall at the conference with a 10% discount.  So I bought this book: The Art of Agile Development by James Shore and Shane Warden.  It’s a great book that gave me a thorough grounding in Agile and XP practices and processes.  I thoroughly recommend it.

Planning poker

Fast forward a year and a half to December 2009 and there we were, a rather broken-looking Web team sitting around a table in Web HQ staring at a spreadsheet listing over 120 requested projects.

In The Art of Agile Development the authors write

XP assumes that customers have the most information about value: what best serves the organization. Programmers have the most information about costs: what it will take to implement and maintain those features… A successful plan needs to take into account information from both groups, as every decision to do something is also a decision not to do something else.

Taking that to heart, that we had the most information about costs, we sat down over two days and played planning poker using home-made cards with the list of projects.

Agile planning poker cards (PDF, 24.5 KB)

Planning poker (or the ‘planning game’) is normally used by teams to estimate individual tasks in a larger project, but we used it to estimate the size of projects themselves.

We looked at each project one-by-one on the list. Whoever knew what it was about would explain it to the rest of the group, something like

Okay, so this project is about replacing the virtual tour movies on the website, which are currently QuickTime movies, with the same movies but in Flash format.

Once we had enough detail we would silently vote on the complexity of the project.  We used homemade cards (you can download them above) using a sequence that was loosely based on the Fibonacci numbers.  Our cards used 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? and Break.

Each player would select a card and then at the same time everyone would lay their cards out on the table.  We were looking for a consensus of opinion.  As I was facilitating the process I would invite whoever laid down both the lowest and the highest values and ask why they scored it that way.

That’s where the real value in the process came in.  It gave everyone an opportunity to speak about every project.

Someone who scored it low might say something like:

“Well, I scored it a 2 because I’ve done this before and it was really easy. We just need the source Flash files and then we already have a media template for Flash movies so it’ll take no time at all”

Then the person who scored it more highly might offer something like:

“See, I gave it a 20 because it’s not as straight forward as it initially looks for a couple of reasons.  We do have a media template for Flash movies but it doesn’t allow us to embed multiple movies on the page. And then there is the issue about lack of Flash support for iPhones and iPads.  Should we be thinking about going down the HTML5 path?”

Having heard the evidence we would vote again until we had a consensus.  Sometimes we would end up with three 13s and one 20, for example, in which case I would ask the person who scored it 20 if he was happy for it to be given a score of 13 or if he felt very strongly about the 20.

It was a really useful exercise.

By the end of the two days we still had a list of 120+ projects but each project now had a value indicating how difficult or complicated we reckoned each one was.

Prioritization

We took this list to our boss and she prioritized them, according to the factors that she was aware of and how they fitted in with wider University priorities and projects. P5 was high, P1 was low.  Over 20 projects got binned straight away.

By the end of day three we now had a list of just under 100 projects but we now knew the approximate size or complexity and their priority.  The project list didn’t feel quite so daunting. We also, crucially, had the commitment from our boss that all new project requests should first go to her.

We then used this list to start disengaging from and postponing half- (or hardly-) completely projects that had a low priority.  Most people, to be honest, were very understanding.

Next post I’ll finish this series by explaining how we broke down our projects, what we’re doing now and where we’re hoping to go.  I’ll also take a look at Agile tools that we’re using.

Advertisements

Our journey into Agile, pt.1

Scrum sprint

Diagram of a Scrum sprint, taken from Scrum in five minutes from Softhouse

In November of last year (2009 if you don’t have a calendar to hand) we started to seriously look into using Agile methodologies to better manage and run our Web projects.
The crunch came when we realised that in many cases we weren’t delivering what we had promised to do, we were snowed under.  We took a day out to evaluate where we were and to our horror we discovered that we

  1. were working on over 20 projects concurrently.
  2. were not moving very quickly on any of them.
  3. had a backlog of over 120 projects, which we estimated would take around 13 years to complete if things continued as they had been going.

Something had to change.  We had to change.  We needed to stop saying yes to everyone about everything and we needed to find a way to more efficiently and effectively plan and manage our projects.

Agile

That’s when we turned to Agile for assistance.

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams

Definition of Agile from Wikipedia

Agile is something that we’d looked into a couple of times in the past. It struck a chord with us: iterative, incremental development was something that we did anyway.  We often practiced pair programming, we were using something akin to a Scrum task board, we had a daily stand-up meeting each morning, at times we would have ‘customers’ sit with us to iteratively work through a design.

Simply adopting certain methodologies doesn’t make you Agile though, but it was a good start. Iterative and incremental, if you like.

Almost Agile, even.

Oh, hang on …

Multiple projects

One of the things that we struggled with most was how to run multiple projects using Agile. Because everything we read talked about the importance of running only one project at a time.  Everyone that I spoke to from commerce or business about it stressed the importance of running only one project at a time, and everyone from higher education I spoke to stressed how impossible it was to run only one project a time.

Then I discovered this paper from Karl Scotland, formerly Development Team Leader at BBC Interactive: Agile planning with a multi-customer, multi-project, multi-discipline team (DOC, 225 KB) who gave me the confidence that it could work. In this conclusion he wrote:

The team is able to manage the various complexities of multiple customers, projects and disciplines by working in a way which allows them to treat the work as if there were only a single customer, project and discipline.  Thus they work on a single pool of stories which are shared by all the different customers, projects and disciplines.

So we could run more than project at a time, if we were careful.  We got planning.

Next week I’ll explain what we did next…

A few highlights from IWMW 2010

A couple of weeks ago I attended my fourth Institutional Web Management Workshop (IWMW 2010), which this year took place at the University of Sheffield. (Twitter tag: #iwmw10)

The event provides an opportunity for those involved in institutional Web management (mostly universities and colleges) to hear about case studies, share best practices, find out about new, emerging technologies and develop professional networks (mostly around coffee, in the pub, or sitting around a table in Pizza Hut with a handful of Welsh blokes looking very damp and hungry … it’s a long story!).

Turbulence

The theme of the event this year was ‘The Web in turbulent times‘ and as you might expect the message at times wasn’t entirely encouraging, particularly when one plenary speaker invited us to look around the hall and told us that a lot of us won’t have our current jobs this time next year. Cue nervous laughter.

I’m fairly confident that the magical St Andrews bubble that we inhabit in this small corner of Fife will hold out, particularly since we’re currently advertising for a new post: Website Migration Project Officer, but I certainly wouldn’t want to become complacent and I welcome anything that can help us to become more efficient and effective.

Mobile and Agile

It was encouraging throughout the conference to see both mobile Web and Agile practices popping up in a few plenary (keynote) presentations, as well as in workshops and barCamps.

The mobile Web is something that is clearly going to grow and grow, and it was both encouraging and inspirational to see how universities are addressing it.  It was equally encouraging to hear the debate between device-specific apps (e.g. iPhone apps) vs open-standards (e.g. HTML5-based apps). I don’t have an iPhone, and love my Opera Mobile browser on my Windows Mobile-based device, so no guesses on which side of the debate I sit on.

HTML5

One of the presentations that I was most eagerly looking forward to was HTML5 (and friends) from Patrick A. Lauke from Opera and he didn’t disappoint; you can view his slides here …

… except that I could have listened to him for another 45 minutes. And probably the 45 minutes after that too. HTML5 is one technology that I’m really looking forward to exploring more of this year.

Agile project management

When I signed up for the conference I chose to attend a workshop entitled “A little project management can save a lot of fan cleaning … or (Agile) project management for the Web” because we’ve begun to employ Agile methods in our project management and developments and I wanted to hear more about what an experienced Web team is doing.

The workshop abstract promised:

  • Common misapprehensions about project management.
  • Nightmare situations when dev work goes pear shaped.
  • How project management can save your sorry ass.
  • The ‘light’ project management approach.
  • Is agile a better model for the fast paced work of the Web?
  • Are agile and traditional project management complimentary or mutually exclusive?
  • Sexy web based tools to avoid the dreaded MS Project.
  • 100% death by PowerPoint free, guaranteed!

Unfortunately, the workshop also appeared to be largely Agile-free.  I was disappointed to discover when I turned up that about 50% of the workshop was looking at PRINCE2 project management, which follows a more ‘waterfall’ project management approach, rather than Agile.

I got the feeling that the person who was presenting the Agile aspect of the workshop had been thrown in at the last minute (which I guess fits in with the Agile Manifesto: “We … welcome changing requirements, even late in the development”!) but I’m not sure that it really did Agile, and SCRUM in particular, justice, unfortunately, and didn’t go into the depth that I was either hoping for or the abstract suggested that it might.  Unfortunately, the workshop didn’t do as it said on the tin.

WordPress

The other workshop that I attended, WordPress beyond blogging, was really encouraging.

There can be a tendency in some sectors to dismiss WordPress as not robust because it runs on PHP and MySQL (rather than, say, Java and Oracle database), but it was great to hear how WordPress is being used in other institutions (and for some pretty key services) and gave me a courage to return to St Andrews and explore how we might be able to use it in a number of projects that we’re working on.  Besides, there are currently 11.4 million blogs hosted on WordPress.com which is running their own software, so I guess they must be doing something right.

What I bought back

From most other IWMW conferences I’ve returned with something practical to try out: in previous years it’s been microformats, RSS auto-discovery, OpenSearch, etc.  but there wasn’t so much of that this time.  Maybe I just attended the wrong workshops and barCamps, but what I did bring back was:

  • A desire to start exploring HTML5 now.
  • Encouragement to blog more, and encourage the Web team to blog more (which is why we moved our 3 post WordPress blog from a self-hosted installation to WordPress.com!) Brian Kelly will be so proud of us!
  • Keep exploring Agile/SCRUM and build on the progress that we’ve already made.
  • Explore how we can use WordPress.

And of course, one of the most valuable aspects of IWMW was that I returned with existing friendships strengthened and new ones made.