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.

Balance

I haven't had much of a chance to write any posts lately. I've been on a project that has left me little time for other things, but on this Sunday I decided to take a step back.

There was a learning in Daniel Pink's The Adventures of Johnny Bunko; "persistence triumphs talent."  I had a boss that taught me this early in my consulting career, that putting in your 40 hours of billable time wasn't enough. It's the consultant that goes back to their hotel room at night and keeps working that is the one to get ahead. 

But where's the balance? Is there such a thing? Are we going to hit a wall at some point and decide we've had enough?

I believe that by getting away, it makes us more productive when we're at work. You need to have habits that take you away from work and lets you recharge. I'm a competitive runner/triathlete. It can be hard to get as much time as I want to train, but I do what I can. I don't head on a business trip without my running shoes.

Vacations are also important, again, getting somewhere where you can forget about work for a while. Last summer I spent 5 days climbing in Colorado. I pushed myself pretty hard physically but I sure didn't think about work and when I did get back to the office, I was recharged.

So if you're at work, work hard. Go beyond what is expected of you. But know where your next release point is.