Here’s the scene: A problem has come up with one of your supply chain vendors, threatening to delay timely shipment of your product. At the same time, a potential opportunity appears that, with some exploration and investment, could lead to a new generation of products down the road. Which do you respond to first?

An informed guide to misconceptions of Agile.

I recently came across a rather misinformed document called the Anti-Agile Manifesto. Normally, I just ignore this sort of thing, but in this case, people I know who are in the exploratory phase of agile adoption were treating the document seriously. Because the thinking in this document, which is not uncommon, undermines the success of fledgling agile shops, it seemed worth discussing it.

First a definition: A story point is a measure of the effort required to build out a story. It has nothing to do with time. Points usually occur on a 1-to-5 scale (where 1 represents a trivial effort), but some prefer a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) because the further you get from trivial, the more the effort ratchets up. I can't emphasize too strongly that this measure has nothing to do with time beyond the broad observation that hard stuff takes longer. There is no way to map a point to a particular time interval.

In other words, you're estimating something concrete — a fixed set of features. To insist on meeting an estimate at a fixed deadline is to commit to building that set of features. That set is bound to be wrong, however, so the estimate is bound to be meaningless. Committing to the deadline is effectively a commitment to build the wrong product.

I'm not sure about you, but in my "real world," building a product that nobody's going to buy isn't a particularly important goal.

The Lego calendar is a wall mounted time planner made entirely of Lego. Take a photo of it with a smartphone all of the events and timings will be magically synchronised to an online, digital calendar. It makes the most of the tangibility of physical objects, and the ubiquity of digital platforms.

We work a 4-day week (M-Th, 9-6) because we think that information work isn’t like manufacturing. Another hour at the MacBook won’t yield another $1,000 in profit. We believe that smart folks can get five days of work done in four days. Simple as that.

Years ago I had a clear political opinion. I was a civil-rights activist. I appreciated freedom and anything limiting freedom was a problem to me. Freedom of speech was one of the most important rights for me. I thought that democracy has to be able to survive radical or insulting opinions. In a democracy any opinion should have a right even if it’s against democracy. § [...] § But over the last years my opinion changed. Nowadays I think that not every opinion needs to be tolerated. I find it completely acceptable to censor certain comments and encourage others to censor, too. What was able to change my opinion in such a radical way? After all I still consider civil rights as extremely important. The answer is simple: Fanboys and trolls.

Having been through multiple launches, seen companies launch at big conferences, and talked with many startups that have experienced the same effect, what I recommend – and what we’re doing at Origami - is not launching at all. Take the word launch out of your vocabulary – it’s a sign that you are gambling on your app and not building a long-term, sustainable company. Instead, put your sign-up page up or your app out because you need more feedback on your idea. Find an audience of passionate users, even if small, and reach out to their community through appropriate means. Try SEM and Facebook ads to find a target market. Experiment with business models and onboarding flows. Let the press come to you because they love what you’ve made.

For the software delivery process, the most important global metric is cycle time. This is the time between deciding that a feature needs to be implemented and having that feature released to users. As Mary Poppendieck asks, "How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?"4 This metric is hard to measure because it covers many parts of the software delivery process—from analysis, through development, to release. However, it tells you more about your process than any other metric.

Many large organizations have heavyweight change management processes that generate lead times of several days or more between asking for a change to be made and having it approved for deployment. This is a significant roadblock for teams trying to implement continuous delivery. Often frameworks like ITIL are blamed for imposing these kinds of burdensome processes. However it’s possible to follow ITIL principles and practices in a lightweight way that achieves the goals of effective service management while at the same time enabling rapid, reliable delivery. In this occasional series I’ll be examining how to create such lightweight ITIL implementations. I welcome your feedback and real-life experiences.