The Case for Constant Progress

aka Building the Right Thing at the Right Time is Right, Right?

At the risk of appearing to jump on buzzword-ish fads long after they’ve left the station. I am making a very loud case for Agile Development, Minimum Viable Products (MVPs), Lean Startups, Continuous Integration, Continuous Deployment, Continuous Delivery, Unicorns, and the Loch Ness Monster. OK, probably not the last two (at least not right now).

In the dark ages of my youth, we believed in Waterfall Development. It was good because The Business figured out exactly what was needed before The Developer wrote a line of code. Developers wouldn’t do the wrong thing because Line of Business People and Business Analysts had everything figured out. Coders just had to code.

But frell, requirements kept changing after development started and developers were always arguing about Scope Creep and Changing Requirements. Unsurprisingly, Large Projects failed with an alarming frequency.

Enter Agile Development, the promise of being able to build things in a way that allowed change.

Outstanding! Developers no longer have to stand against changing requirements, they can support them. No more the inflexible devils they, now they are the Vanguard of Progress! Huzzah!

Except for the fact that Agile Development alone doesn’t solve the problem.

Agile gives you the framework to accept change. You no longer need to lose months or years trying to document a problem in painful detail before you write code only to find out you’ve been documenting the wrong problem. But, gorram, Agile also gives you the ability to constantly write and ship code without solving any problem. Sprints are completed, Stories are accepted, but where’s the progress? Unsurprisingly, Large Projects failed with an alarming frequency.

Then a whole host of ideas converged. The amalgamated version, to which I personally subscribe, is derived heavily from the Lean Startup movement. There’s a ton of goodness baked into that movement, each piece deserving of extended explication, but here I want to focus on one aspect. To me, it’s the very heart of Building Good Things.

The Shining Truth is to figure out the core of what you need: the very heart of it. Ideally, this should be what makes Your Thing waaaaaay better than all the Other Things. Focus on that. Build it. Ship it. Let the masses have it. Let them break it. Let them love it. Let them hate it. But mostly, let them use it. Lean Startup calls that the Minimum Viable Product. I like that.

Unfortunately, I think too many people are caught up in the first word. Minimum. It’s the next two words that are the important ones for me.

Ok, I have my Viable Product. What comes next?

Progress.

What the frell you shout? Progress? Really Einstein?

Ok, I probably deserved that, but stick with me for a moment.

Just do that whole “Design it. Build It, Ship it. Give it to the masses” thing again. Figure out what would make Your Thing better than it is now. Maybe you have to throw this version of Your Thing away and build a New Thing, because The People have summarily declared that This Thing is Crap. You made a mistake. That sucks. But when you look at how people used Your Thing, maybe The Right Thing is buried inside. Or, maybe, it just gave you an idea for a New Thing or , if you’re lucky, most of what you did was right and you can build on it.

The Important Thing is that you never view what you’re doing as a path with an end. Don’t think “When I get to the Glorious Place with All The Right Features, I will be Done.” That path leads to Darkness. When there is a Done, there’s fear of shipping Not Done. Fear means you don’t ship enough. If you don’t ship enough, you can’t learn enough. If you don’t learn enough, you’re guessing. When you’re guessing, you’re probably wrong.

What have we changed if we follow this Path of Light? Large Projects can finally stop failing with alarming frequency.

How can I say this? Because you’re not building a Large Project. You’re building many, many, many, interconnected Small Projects. Small Projects can fail and nobody has to lose their job. Especially if the failure points the way to eventual success.

If you are a Builder of Things, really think about what I’ve said. It’s an opportunity to radically improve how you build.

As an Agency Builder of Things, Clients don’t love not having a Done, or a Schedule, or a Detailed Plan. Believe me, I get it. It’s scary to enter into an engagement and not understand exactly what you’re going to have at the end. It’s a bigger leap of faith investment. It pays off with results that closer to what you need and the ability to experiment with multiple ideas along the way.