Projects' Little Helper

AKA “Being agile without Going Agile”.

Ye olde project wiki

In 2004, I started working on a project where the lead developer said, “I’d like to use Extreme Programming“, also known as “XP”. This bemused me slightly, as it conjured up images of white water rafting, and ironing in strange places. I went along with the idea though, and I found what I could on the web. At the time, there was a lot less material out there than there is these days. In particular, I remember gleaning what I could from the Extreme Programming wiki.

This project was my first involvement in what could be called an agile project. The lead dev and I had daily 15 minute meetings, we broke up features into smaller pieces, we had a list of features (which the business ordered/prioritised), we had 2 week iterations, and we increased our shared understanding on a wiki. We also had a form of acceptance criteria for the different functions on each page of the product.

We didn’t officially call it “Agile”, we just said to the business, “We can deliver what you want more effectively if we do it like this.” Because we had framed it in this way, we didn’t need air support from upper management. The business stakeholders, didn’t have time to dislike the idea, because we just started, and began to show them results as quickly as we could, as often as we could.

I had a hybrid role in all of this. I was called the Project Manager, but in reality I functioned across a variety of roles. As well as doing “PM” stuff, I also performed Business Analyst, (sort of ) iteration manager, and Product Owner duties. I also functioned as a (kind of) user experience designer. I used a pencil and A3 sheets of paper to create paper prototypes/wireframes, which is something that I advocate to this day, as one of the best techniques to use on a project. I also went out to customers and ran test of early versions of the product.

It’s still one of the projects that I look back on most fondly. A few years later, that product got “updated”, by a different team, who switched it to a different system. This supposedly increased the features available to users, but in reality confused, and didn’t add any value for them. There was a backlash about the “improved” version, such that the company decided to roll back to the version that all of the customers liked, used, and found valuable. It remains one of my finest moments at that job!

Unfortunately, I had to go back to “Standard Operating Procedure” on my next project. I’ll tell that story in a future article, that has the working title, “Retrospective, Retrospective, Retrospective!”