Here's the thing. It doesn't matter how good a contractor/freelancer is, unless they've worked with us regularly, and know the rest of our team "intimately", they're not usually as effective as our full time staff. 

At Fudge, we use external resources only when it's absolutely essential. Partly for financial reasons, but mostly because they're just not as effective as full time staff.

Our Scrum teams are made up of specialists, all with varying levels of experience. One thing that they have in common is their familiarity with the rest of the team. On average, we've worked with each other day-in-day-out for at least 3 years. That's 8 hours a day, for three years.

Communication

A team that spends most of their working day together knows how the rest of the team thinks and behaves. If someone's grumpy, they'll know to either leave them alone, or they'll know what to say to cheer them up. They understand the strengths and weaknesses within the team, so if someone's stuck, they'll know who to ask for help.

Through no fault of their own, temporary additions to the team don't have this understanding. You can only get that by spending time with each other.

Accountability/Responsibility

This is a big one. Scrum encourages the team to take collective responsibility for the project. If something's going wrong, we don't blame someone, we figure it out together. When we start a project, we build a team around it that'll be there from start to end. Part time outsiders cause problems:

• They probably aren't familiar with the general history of the project
• They won't know the client personally
• They don't have as much of an interest in the success of the project beyond their contract period

Performance

We work quickly at Fudge. We can do this because we've been working together day in, day out for years. We know who's good at particular things and how quickly they might be able to complete a task. Scrum is a major reason for the speed that we work, but mostly, it's the personal familiarity that Scrum has encouraged. External people may work quickly independently, but without knowing our processes and personal traits, they usually slow the team down.

Conclusion

I read somewhere that if a team is working well, they'll have 'in-jokes'. They'll be able to have a conversation amongst themselves for ten minutes, and you won't have a clue what they're talking about. This is a good thing, trust me.

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 :-)