Eating the Elephant

I love Man vs Food. 

It's indulgent, over the top, and somehow the host manages to accomplish ridiculous eating feats that you don't think are possible. 

And he does it one bite at a time.

Iterative development forces you to deliver some working piece of functionality every iteration. So realistically you can't go too far down the wrong path and lose too much time, because you'll be reviewing and readjusting your course every few weeks. 

How do you break down a piece of functionality into small enough pieces that they still deliver value?

Let's start with how you don't do it - When you're building tiered technology, you do not break it along those layers. For example - I would not have separate stories for the DB portion, The business logic and the UI. Each piece by themselves do not deliver any real business value. 

Remember - we're looking for fast feedback from the business - and demonstrating some DB tables, indexes and views isn't going to get you that feedback. 

As a general rule, people are pretty bad at defining what they want in any sort of detail. Those same people are usually much better at telling you what they do/don't like after seeing something. So build a small piece of it, show it to them, get their feedback, and then adjust. 

They may decide they don't really feel like Elephant for lunch; and that they're in the mood for sashimi.

Forget the handshake. Embrace the group hug.

In a work appropriate manner of course. I wouldn't want to see any of you get fired.

A lot of traditional project management revolves around hand-offs or handshakes; Sign-off's and documentation.

The entire cycle from Requirements Gathering -> Analysis -> Design -> Functional Specification -> Sign-off can usually be shortcut by throwing the right people in a room with a few whiteboards and telling them to have a conversation. 

In a past life, the company I worked for moved our Program Management Group under a VP who was tasked with improving product quality. His first initiative was to establish a "Product Creation Lifecycle" that involved passing 20+ gates before anything could be released. Each gate had upwards of 10 deliverables - The majority of which were never consumed. In theory it worked - We didn't release any more buggy code.

We didn't release anything at all.

Good Project management is about how you can speed up all the feedback loops in your process and get business value to the customer.

So rather than thinking about "How do I stop getting bad quality software into a customers hands" - Focus on how fast you can get good quality features to them.

Less documentation and reviews. More conversations.

Less process. More good people.

Less handshakes. More group hugs.

Whiteboards are your friend

I love whiteboards.

One of the first things I do on any project is get lots of whiteboards installed for impromptu design and troubleshooting sessions.

But they're damn expensive. 

On the last project though - a colleague introduced me to shower boards and i'll never go back. The coating on them makes them usable as a dry-erase board and you can pick one up for $15 instead of $500. Check out this happy guy.

3M have also started selling a sticky note version of a whiteboard that can be a less permanent fixture.

Glass walls and Windows are also great.

What makes a great team?

This is important in any environment, but even more so in the agile landscape.

One of the core principles of the agile manifesto is the firm belief in people over process.

There are less gates, silo's and places to hide. The work environment is usually open plan. Your team-mates can usually see everything you are doing. You spend a lot of time in face-to-face discussions and impromptu design sessions.

I've found that great teams are friends as well as colleagues. They actually like each other.They hang out at the pub or catch up on the weekends outside of work. This builds incredible camaraderie and loyalty. No-one likes to let down their friends.

Ask yourself - If you were going to start up and fund your own company - who would you hire? Which of your current team members would make the cut?

Why?

And most importantly - What are you gong to do about it?

Momentum is your ally

It's always harder to restart an engine than to just keep it rolling along.

So don't stop. 

With iterative development, you're always delivering frequently and the feedback loop is short. So what do you lose if you keep going? 

From experience, when you stop a bus, people hop off, go wandering and it's like herding cats to get everyone back on board.

By all means, take a breather, re-adjust your course based on what you've learn't, but don't. ever. stop.

Most of the time the person that recommends you to stop, form a steering committee, and re-establish the project plan is probably the person that that needs to be kicked off the bus.