Principles of Agile, Part 1

This is part 1 of a 12 part series on the Principles of agile

I've been working on a big project and as the project has grown, I've been thinking about how Agile is supposed to work and how my project is following (or in some cases not following) the principles that are part of agile. For this first article, I'm going to talk about

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

One thing I notice when I first start working with clients that are new to agile is their Big Bang mindset. When they start a project, they try to think of every possible requirement because they figure they have one chance to ask. This leads to large projects that take a long time to deliver. They have trouble saying no to features that they think they might need.

To counter this, I try to get the client thinking about multiple releases. Along these lines, not everything has to be in release 1.0. This is always more than a single conversation. As I teach them about user stories and and backlogs and prioritizing, I repeat the massage about small releases delivered quickly followed by another release.

Imagine you work in a shipyard unloading ships. You have 5 ships come in on Monday morning. Each takes 5 man-days to unload and you have 5 dock workers.

The Big Bang approach is to work on them all at once. With this approach you get everything done on Friday.

But what if you took the small release approach and had everyone work on one ship. It would get done on Monday (first small release). Tuesday is your next release and the second ship gets done that day. I think you get the picture. 

By taking the second approach, you deliver some value early and continue delivering value through the week. If the ships were full of cars, you would be able to sell cars by Monday, instead of Friday with the Big Bang approach.

The challenge I face is convincing the client this is a good approach. It's sometimes a challenge to figure out when to go live with that first release. No one wants to be told their feature is in the next release, something to deal with when you are working with multiple stakeholders. But once they understand this principle, the idea of small releases is more tolerable.

And as far as my current project, it is pretty big but I have gotten them thinking about the next release and some of our user stories are already being put in that release so we can keep our timeline for the first release, an improvement over the must have everything mindset they first had.