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.

Read the rest of this post »

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.

Read the rest of this post »

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.

Read the rest of this post »

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.

A lovely example of how it shouldn't be

There are lots of apps out there designed to digitise the day to day activities of Scrum. Some are good, some are definitely not good.

One thing that I've noticed is that almost all of them try to replicate and replace the use of physical artefacts. Traditionally you'd see things like story cards pinned to a wall and a burndown chart (sometimes hand drawn) somewhere near your team. I'll use Nigel Baker's (AgileBear) term and collectively call these assets your "information radiator".

I think that replacing physical assets completely, in favour of storing them in some kind of application is a bad idea.

Here's why.

Removing this information from your physical space reduces the need to communicate verbally. This is definitely a bad thing. Relying on email or on communication through some other tool slows down problem solving. I guarantee a discussion will resolve a problem quicker than an email conversation.

A new team, or a team new to Scrum should be encouraged to communicate verbally. Given the opportunity to fall back into the old routine of emailing, waiting for a reply and then trying to decipher the response, slows down the process of decision making. So, is there a need for a digital alternative to physical artefacts?

Yes, in some cases.

At Fudge, we often work with product owners and team members in different countries and time zones. It isn't possible to have a single physical location for this information. What we do instead, is replicate the physical space in a digital format. We keep these two synchronised and distribute a revised digital version regularly, so that regardless of location, a team member knows what's going on.

Like I said, there are good and bad apps to help with this, but I won't mention either, other than Glu, a product we're working on at Fudge :-)