© 2001.

Only ten years ago the agile movement formally started. I’m sure it was around informally before then. Now it’s an institution that is embodied in methodologies and programs from XP to Scrum.

It good to read the manifesto that started it all. To see the simplicity that launched a movement. Because overtime, as is human nature, we keep adding on facets, until we forget what the original item looked like. This can be for better or worse (think a person from the 50s would recognize a TV today as a TV, if it wasn’t on?).

One facet we’ve added is the concept of velocity. Jim Highsmith details nicely how the concept of velocity has been stretched so it chokes the agile process. A key quote:

Compounding the problem, the Agile movement has focused on high levels of customer involvement—basically a good thing—but we’ve gone too far. A large number of Agilists decry that they can’t get organizations to focus on technical practices—but why should that be a surprise when we encourage product managers/owners to make all the priority decisions and then measure performance using velocity?

This point is spot on. In my experience, product owners are often given complete control over priority, so technical optimizations or necessary muck work aren’t prioritized. Going back to the agile manifesto, read over the names of the original signers. They all have experience in the technical and the business sides of the equation. They intuitively know how to balance both. Now that agile has gained widespread adoption, teams do not necessarily have this experience.

The idea of the self organizing team needs to return to the agile movement. The team doesn’t have to be self organizing in that team members constantly change. That becomes too disruptive. The team needs to be self organizing in that the team picks the order of the work they will complete. The product owner might set priority, but it is the team that takes on the work and the order they complete it. There is obviously back and forth between the team and the product owner, but as the manifesto says: people over process. We trust that the team will organize itself, taking into consideration the wishes of the business, so that the work gets done as quickly as possible with the highest quality.

I think people often forget that agile is not a rigid system to be followed. It is simply a belief that change is constant, so we should favor a way of doing things that makes change easy.

In short, do what works for you so that you develop quality software on time. That’s the definition of agile, with all the trappings stripped away.

And so development starts / CC License

The Trappings of Agile

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

This is a refrain often heard in programming circles. Out of curiosity, I googled it to see if I could learn where it came from. The first hit leads to a 2006 post on Bob Sutton’s blog, where he lays out the origins of the phrase and the rational behind it.

The rational: holding a strong opinion means that you will put the work into understanding why you hold that opinion, so you can reasonably defend it. It is weakly held, because you want to be able to change it when the evidence proves it wrong.

Bob also has a list of 17 things he believes that runs down the side of his blog. It’s a simple, but profound list, that I couldn’t help but agree with. Unfortunately, Bob doesn’t provide a link to a page with only the 17 beliefs – so I’m rectifying that by posting them here.

1. Sometimes the best management is no management at all — first do no harm!

2. Indifference is as important as passion.

3. In organizational life, you can have influence over others or you can have freedom from others, but you can’t have both at the same time.

4. Saying smart things and giving smart answers are important. Learning to listen to others and to ask smart questions is more important.

5. You get what you expect from people. This is especially true when it comes to selfish behavior; unvarnished self-interest is a learned social norm, not an unwavering feature of human behavior.

6. Avoid pompous jerks whenever possible. They not only can make you feel bad about yourself, chances are that you will eventually start acting like them.

7. The best test of a person’s character is how he or she treats those with less power.

8. Err on the side of optimism and positive energy in all things.

9. It is good to ask yourself, do I have enough? Do you really need more money, power,
prestige, or stuff?

10. Anyone can learn to be creative, it just takes a lot of practice and little confidence

11. “Whenever people agree with me I always feel I must be wrong.”

12. If you are an expert, seek-out novices or experts in other fields. If you are a novice,
seek out experts.

13. Sutton’s Law: “If you think that you have a new idea, you are wrong. Someone else
probably already had it. This idea isn’t original either; I stole it from someone else”

14. “Am I a success or a failure?” is not a very useful question

15. The world would be a better place if people slept more and took more naps

16. Strive for simplicity and competence, but embrace the confusion and messiness along the way.

17. Jimmy Maloney is right, work is an overrated activity.

Do you agree with them? Should anything else be on the list?

Opinions and Beliefs

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

Moving recklessly leads to forgettable and bad experiences.   Functionality may be made available more quickly, but at what cost?  The interaction and interface, as well as the communication around the feature, have to be at least adequately completed, or else the new functionality will flop.

Customers remember bad experiences more readily than they remember good ones.  Bad experiences color perceptions of the company, which has ripple effects.  A customer becomes less likely to choose the company for business.  The company has also now created a greater barrier that they will have to overcome to win back the customer.  Not only does the company have to get their name back on the customer’s radar, they have to convince the customer that they will not have a repeat negative experience.  Easier said than done.

How is your company moving: quickly, or recklessly?

The Color of Recklessness