Some people assume that Scrum's approach to planning lacks documentation. They assume that the lack of a massive functional spec document means you're making things up as you go along. That's wrong, obviously. User stories are awesome, but they're not the end of the process.
A few months ago I did (along with the other partners at Fudge) a talk at Northern Digitals about a project that went wrong. It was the worst six months of work we'd ever been through. Sounds dramatic, but it's true.
As far as I'm concerned, most of the problems we encountered were caused by the 200 page functional spec that we laboured over for months. As far as we knew, the client understood and agreed to everything we proposed to build. We had a signature after all. We were very wrong.
The project that went wrong made me re-think our approach to project management, design and build. Everything really. The biggest impact from my perspective came from the adoption of the empirical approach to planning that Scrum provides.
Last night was the Manchester Digital AGM. If you don't know, Manchester Digital is the independent trade organisation for digital industries in the North West. The AGM gives the members a chance to comment on the organisations performance from the previous year and debate any future plans.
In addition to this, an election is held to form the organisation's council for the coming year. I'm pleased to say that I was elected to the council last night.
We just came back a meeting in a lovely bit of Wales.
It was a long old trip, so we thought it'd be best to stop overnight and get some rest. Luckily, we managed to avoid the local Travel Lodge and picked a place called Fforest.
We stayed in one of their Croglofts which are traditional Welsh crofters cottages, converted to make them a bit more comfortable. They have lots of places to sleep at Fforest, depending on how close to nature you like to get. If you prefer to camp, check out the Domes. They're the coolest tents I've ever seen.
The people there are great too. We had a cup of tea in front of us, and some awesome music playing within two minutes of saying hello. As soon as the sun starts shining, I'll be going back, hopefully for a bit longer than just one night.
Here's a few snaps of our stay.
I passed through my Certified Scrum Master training early last year. Since then I've been practicing daily, running teams at Fudge.
I've always got a Scrum book in my bag (currently Agile Retrospectives) and I read as much material as I can get my hands on.
If you think that passing through a Scrum course, or reading a couple of books will set you up to be a solid-gold-scrum-god, then you're mistaken.
Updated to reflect first two weeks traffic
We launched a site a couple of weeks ago (26th March) at Fudge that uses Facebook Connect.
It's the first live site we've worked on that uses Connect as a method of user signup. We assumed it'd help build traffic relatively quickly but the results surprised us all.
The site's called Face of Bank and was developed for Bank Fashion, a chain of high-street shops. It's main aim is to recruit potential models for use in their advertising etc... Users sign up, gives us a little personal info, then pick a photo from their Facebook albums. Users then browse entries and vote for who they want to win. Again, the user signs in through Facebook first. Pretty simple.
As you'd expect, the target audience for the campaign fits in pretty well with Facebook's main demographic so we assumed it'd build traffic without too much effort.
Scrum apposes the hierarchical approach that many project management techniques subscribe to.
Instead, a Scrum team trusts and relies on each other to provide help and advice. A Scrum team takes collective responsibility for a project and we trust each other to do the best work possible. If a mistake happens, then the team will rally around to collectively solve the problem.
I've had lots of conversations with people about Scrum. After an hour of me trying to explain the whole framework, I usually see confused faces staring back at me. So, instead of doing that, I thought I'd explain some comparisons between Scrum and a traditional project management process (waterfall). I'm not going to go into the advantages or disadvantages of either, but hopefully you'll see a few reasons why we practice Scrum at Fudge.
The same goes for designers/developers.
At Fudge, we trust everyone to do the best they can. We also trust them to tell us how long they think something will take, and how difficult it’s going to be.
Something that we try to avoid, is putting pressure on our teams to deliver more than they think is possible. It doesn’t matter how loud you shout, if something’s going to take a long time, apart from assigning more resource to the task, there isn't much you can do about it.
We also try (unless it’s life of death), to keep our working days at a reasonable length. Forcing people to work an extra three hours a day, isn’t going to result in an extra three hours of quality work.
At Fudge, the days of the “hero programmer” ended as soon as we implemented Scrum (Google it). We don’t want people to grudge coming to work because they had stay late the night before. They won’t be motivated and they won’t be productive.
Here's a description of the type of situation we used to end up in: Hero Culture.
Instead of this, we help our teams to deliver as much as possible while keeping standards high. We do this by investing in time-saving techniques, tools and technologies. We try out methods of working to see their effect. If it works, it stays, if it doesn’t we adapt and try something new.
If you want to get more out of your team, help them to work smarter, not longer.
If you trust your team to tell you the truth and deliver to the standards you require, you’ll have a happy, productive bunch of people.
