All the rage in entrepreneur circles at the moment is the concept of the Lean Startup. The term, coined by Eric Ries, is a startup that achieves validated learning through the build-measure-learn loop. What is validated learning? Learning what the customer actually wants so that a useful product and a sustainable business model are built.

It may not appear that the Lean Startup and DevOps are related. Obviously, with a statement like that, I’m now going to tell you how they are. It starts with small batches.

Small batches are the practice of having cross-functional teams work together on the smallest units of work possible while pushing that work to the customer as soon as possible. In working this way, the product gets to the customer quickly, allowing the business model or product direction to be validated.

The common model today is large batches. Instead of a small team working cross-functionally to push a product in front of a customer, the team specializes, with various team members completing their phase of the product before passing it on to the next person in the chain. If at any point a fault is found, the product has be sent back down the chain while those up stream ideal, waiting for the product to reach them. All the while nothing is getting put in front of the customers, so no feedback is being gained. Eventually the product will reach the customer, but if any flaws are found or the customer rejects the product, the entire process is repeated, leading to long lead times before customer behavior can be learned.

Contrast this with the small batch process, where small changes are continually pushed to the customer. This leads to quick feedback and rapid turn around times, resulting in a better product.

Lean startups embrace small batches as I’ve just described. DevOps is the same. DevOps is about embracing small batches, but the batch in this case is a narrow part of the overall process: pushing a product from development to deployment to seeing it in use.

DevOps is about allowing production behavior to quickly feed back to developers so that development can adjust quickly to situations in production. Often times the fastest way to make this happen is to have developers occasionally serve as, or even to be, the operations team. As with the lean startup, the potential efficiency of an individual unit (developers, operations) might appear to be undercut, but the efficiency of the system as a whole (developing products that work in production) is sped up.

When developing a system it is easy to envision how a system should run, but that doesn’t mean that is how the system will run. Often unavoidable differences in hardware and traffic lead to differences in how the system actually performs with how it was envisioned to perform.

DevOps is about tightening the same loop as the Lean Startup: the build-measure-learn loop. The only difference is the narrower focus of DevOps. With the loop as tight as possible, knowledge gained from the actual system is fed back into the next iteration of the product so the system becomes better in small, but tight, increments.

DevOps is a subset of the Learn Startup. Both are a reaction to today’s fast changing world and the need to create a system that can optimize the whole quickly, even if that means undercutting what appears to be the efficiency of the individual unit.

Both DevOps and The Lean Startup are about eliminating waste.

Waste / CC License

I’ve only touched the surface of the Lean Startup and DevOps movement. For more on DevOps and to read the article that inspired this one, see the Ars Technica article Google CIO and others talk DevOps and “Disaster Porn” at Surge.

For more on the lean startup, read Eric Ries’ blog on the topic, or read his recently published book, The Lean Startup.

DevOps and The Lean Startup

The essence of strategy is choosing what not to do.

- Michael E. Porter

It’s a good quote, but there’s a better one that cuts more to the heart of the matter:

No.

Attempting to say no and actually saying no are what many of us spend our lives doing.  When you often get in trouble, it’s because you said yes.

You said yes to a feature that turned out more complicated than you thought.  Now you’re working overtime to complete it.  What if you had said no?  How much would users care?

You said yes that you’d attend the meeting because someone asked you, but you learned nothing.  What work could you have done if you had said no?

The scenarios are endless.

No is the best response in many places, although sometimes the word no isn’t said at all.

I didn’t have time to write you a short letter, so I wrote you a long one instead.

- Attributed to Mark Twain, but there is debate about that.

What if you had said no to something else, so you had time to write that short letter?

Omit needless words.

- Strunk and White

Omit needless code.

- Kevlin Henney

Omit needless features

- Paraphrase of Steve Jobs.

The actually quote from Steve Jobs:

I know you have a thousand ideas for all the cool features iTunes could have.  So do we.  But we don’t want a thousand features. That would be ugly.  Innovation is not about saying yes to everything.  It’s about saying NO to all but the most crucial features.

- Steve Jobs

You hear this advice all the time.  If saying no is the way to go, then why  are we all so bad at it?

We’re like cats: the shiny new object always holds allure over the old and dull.  I can interest my cat with balls and bells, until the moment the laser pointer comes out.  The balls and bells are forgotten because the shiny non-catchable dot has appeared.

We’re all chasing laser pointers instead of balls and bells.  The ephemeral laser pointer promises a better future, whereas the balls and bells represent the solid here and now.

I recently tweeted this:

Let’s get something straight: no feature is ever “must have”.

Here are some of the replies:

Disagree.  Just need to understand context.

There are some features that are must-have, though not nearly as many as we think. I’m certainly guilty of this.

Both are a failure to say no.  We all fail to say no at times.  Think about this: what if we didn’t have that feature?  What’s the worst that happens?  Things stay as they are.  The world doesn’t end.

If you can’t say no, you end up thinking business software is messy and ugly.  Features accumulate and code spaghetties.  Technical debt piles on.  It’s a world of trouble, all of which results from not saying no.

Switching from business software to the personal, there’s a piece of advice oft repeated: follow your passion.

It’s clear by now where I’m going with this.  Follow your passion is another way of telling us to say no.  How do you follow your passion without saying no to everything else that might interfere?  If you don’t say no, you’ll find there’s little time left to say yes to what you want to do.

No is one of the simplest words in the English language.  It’s one of the first words that native English speakers learn to say.  Yet no is the hardest word in the English language to say to someone.

Knowing this, I challenge you: say no to someone and see what results.  Maybe saying no will become a habit for you.  As a result, the world will become a better place.

No

Book: Title

The title would be supplied by the user, but the product type would not be, it would simply be selected from a list.  This information would then be available to other users in various languages.  Since the title was user supplied, it was clear that nothing would be done to translate it.  Initially it was decided that the product type (book, in this case) would not be translated, but would be left in English.

At a low level this code interfaced with gettext.  There was some entanglement between the code that displayed the product type and gettext, which meant if a user where to view the page in a non-English language, then the product type would be translated.  But the decision had been to not translate it.

I was left with three options:

1. Do nothing – let the product type translate.
2. Copy the code to display the product type so that it wasn’t using gettext.
3. Rewrite how the application used gettext so that the product type code and the gettext code weren’t so wedded to other.

There were problems with each option:

1. This wasn’t the decision that was wanted.
2. This was easy, but now it meant the product type code existed in two places, and any updates would have to be applied in both places.  I could easily see it happening that an update made to one place wouldn’t be applied to the other.  This solution bothered me because it violated DRY.
3. This involved a massive rewrite that would solve the problem, but would take the most time and touch a lot of the application.

I went with option one:  do nothing – let the product type translate.  This meant I had to change no code, so it was the quickest and easiest to implement, while also not violating DRY.  This did go against the decision to not translate the product type, but after bringing up the issue with all concerned parties, it became clear that having the product type translate wasn’t a big issue.

The issue was resolved in the best possible way not because clever code was written, but because a non-technical solution was found.  Often, the first impulse for any developer (myself included) is to start typing and to stubbornly plough through any technological issues that arise.  However, sometimes the best way forward is to take the time to stop and ask people to consider their decision, because going a different direction might be easier and better for everyone.

The Best Solutions Are Non-technical

Teams with healthy idea life cycles are easy to spot: ideas flow between people easily and in large volumes.

Teams that innovate are great places for ideas to live – like happy pets, they’re treated well, get lots of attention, and are shared among people who care deeply about them.

The life of ideas is the responsibility of whoever is in charge.  He defines it by his responses and behavior, especially when he’s challenged by someone else’s ideas.

Teams with scorched deserts where creative jungles should be usually have the manager to blame.

– Selected quotes from pages 101-102, The Myths of Innovation: Chapter 7; Your boss knows more about innovation than you

Here’s another quote, that I’m sure you’ve heard: If you don’t have time to do it right, when will you have time to do it over?

Companies these days claim they want innovation.  IBM jumps to mind because of their commercials.  I’m reminded of the one of the guy in the super hero suit who runs around talking about ideation.  Unfortunately, this often doesn’t seem to be far from the truth.  Innovation is expected to happen at the snap of a finger, or during an hour long brainstorming meeting.

If innovation happens this way, how come our best ideas often come to us after we’ve slept on it or when we’re in the shower?

Companies don’t want to put in the time to do it right, so they’re often failing and hoping they have the time to do it over.

Innovation takes cultivation.  It doesn’t come overnight, it comes from a sustained culture that welcomes ideas.  It is that simple.  The more ideas, the more likely someone is going to find the magical combination that leads to the next great thing.

A corollary is that you can’t have innovation without experimentation.  I may offer you all the great ideas in the world, but if you never let me act on them, why am I going to keep offering up ideas?  You don’t have to indulge every idea I have.  I just need the occasional chance to explore further.  It doesn’t have to result in a final product or even a prototype.  It just needs to be enough exploration to see if the idea is viable.  That little show of confidence, that you have faith in me to let me pursue an idea for a bit, is enough to keep my intrinsic motivation charged, so I’ll keep suggesting ideas.

If you want innovation from me, treat me like a child. Let me play. It doesn’t have to be every day, or every week.  However, if you let me play, I’ll invent things you didn’t imagine, and we’ll be the richer for it.

For Innovation, Treat Me Like A Child

The dirty little secret – the fact often denied – is that unlike the mythical epiphany, real creation is sloppy.  Discovery is messy; exploration is dangerous.  No one knows what he’s going to get when he’s being creative.  Filmmakers, painters, inventors, and entrepreneurs describe their work as a search: they explore the unknown hoping to find new things worth bringing to the world.  And just like other kinds of explorers, the search for ideas demands risk: much of what’s found won’t be satisfactory.

- Scott Berkun, from The Myths of Innovation: Chapter 6; Good ideas are hard to find, p. 86

The quote above is why I advocate agile practices.  For me, it’s the number one reason to use agile: you can be messy.  You can explore and see what you discover, because you know that if it’s good, you’ll come back to it and refine it, and if it isn’t, you can throw it away with little time lost.

You can work with the knowledge that if you build up some technical debt, it’s okay; you’ll pay it off in the next iteration, before it becomes so large it bankrupts you.

Being agile enables risk, because the time blocks are small enough that there is time to recover.  And by extension, enabling risk helps to enable innovation.

Simply being agile isn’t going to cause you to suddenly be an innovation machine.  There’s a lot more to it than that, as Scott’s book points out, but being agile is a good start down the right path.

Iterating Innovation