What if you don’t want to pivot?

Sometimes when the world tells you to pivot, you really need to stay the course.

Anyone who has read Eric Ries’s book The Lean Startup knows that as soon as you get a better idea what your customers want, you should “pivot” and act on your learnings.

Except it isn’t that easy. What if the world says pivot but you don’t want to? Does that mean you’re wrong? Too married to your idea? Are you going to be one of those entrepreneurs who wastes their time building something nobody wants?

Here I would like to share some thoughts around pivots. Specifically when entrepreneurs should pivot, when they shouldn’t, and why personal ideas need to be treated differently from speculative ones.

The Last Thing the World Needs Is Another Book on Agile

That was the advice I got from an ex-colleague of mine when I asked if he would consider writing the foreword for my book The Agile Samurai. From his point of view there were already enough books on agile and the last thing the world needed was another. And of course, from his point of view, he was right.

• A ton of books had already been written on agile.
• Agile had been around for a long time.
• Everyone was doing it (or so it seemed).
• And there wasn’t anything new that really needed to be said.

Taking these data points, and naively applying the concept of the Lean Startup pivot, it would have made sense to pivot the focus of my book to something sexier or new.

Except I didn’t want to.

I was married to the concept of this book. A simple 200-page distillation easy enough for management yet deep enough for aspiring teams. I didn’t particularly care if no one was going to read it. This was the book I wished I had when learning agile. It didn’t exist. So I was going to write it.

It was after writing Samurai that I read Eric’s book. And it was here that I realized that if I had blindly followed some of the Lean Startup practices (which I mostly agreed with), Samurai would never have been written. What bugged me was that I couldn’t explain why.

I know writing a book isn’t the same as forming your own full-on startup, but the question remained. Why did some ideas seem easier to pivot on than others?

It wasn’t until I came across a presentation by Adrian Smith that I found the “ideas” I was looking for.

Speculative vs Personal Ideas

There are two types of ideas when it comes to startups. Speculative and personal.

Speculative	Personal
In it for the money	In it for yourself
Would abandon quickly	Would never abandon
Have a choice whether to build	No choice—have to build
Hard work	Hard play
Requires resources of others	Requires only you
Objective, data driven	Emotional, logic doesn’t apply

Speculative ideas are all about the money. You see an opportunity and you go for it. Customers aren’t responding? No problem, pivot and experiment until you discover what they do like. Pivoting, objectivity, competition and hard data rule here and this is where the concepts of The Lean Startup and other formal methods shine. It’s nothing personal—it’s just business. This is the realm of the speculative idea.

Personal ideas are the exact opposite. You aren’t in it for the money. You pursue them because you want to. No one is paying you. Most likely no one ever will. It’s your passion. Your love. It may be your obsession. You don’t care if anyone is looking. It’s that itch you have to scratch. That mountain you have to climb. It’s not work—it’s play. And you can’t wait to get home from whatever it is you do during the day so you can immerse yourself in it for a few hours before you collapse and go to bed.

Danger Zone

And this is where people can get hurt: treating speculative ideas as personal, and personal ideas as speculative.

Treating speculative ideas as personal ones is exactly what Eric is trying to shield us against with the principles outlined in The Lean Startup. He nails it when he says there is nothing more wasteful than companies building things nobody wants. We become so enamored of our idea that we think if we simply build it others will come. Then, of course, they don’t and the rest is history. The principles of The Lean Startup serve us well here.

But the Lean Startup pivot can be applied equally naively too. If you’ve got a personal idea, don’t pivot just because the world isn’t with you. Some of our greatest inventions and creations have come about precisely because founders saw things differently and refused to pivot when the world was telling them to.

They couldn’t find validation for what they were doing because it didn’t exist. Even if they could have shown their product or idea to others, few would have got it because no one would have understood (e.g. Twitter).

And this is the most dangerous time for a work of art. Most are killed just before the finish line because we become afraid. We are afraid of what it will mean to finish. We are afraid of success. We are afraid of failure. We are afraid of what others will think. We are afraid of not following the tenets of a popular book.

And it’s this fear that kills our most cherished ideas. And I fear that when applied naively, the pivot will become another excuse to quit before our ideas see the light of day.

If this topic fascinates you I recommend Steven Pressfield’s The War of Art.

Is Your Idea Speculative or Personal?

Look—startups are hard. I don’t pretend to have any magical insight or formula for making them easier. Eric’s book is excellent and I have personally failed in two startups that would have definitely benefited from his advice.

But if it’s personal, gives you great joy, and you can’t wait to get home to work on it, enjoy it while it lasts! For you have something special. Something that most haven’t experienced since childhood. The sheer joy and flow that comes from creating. And this is something that should never be abandoned.

“We think the Mac will sell zillions, but we didn’t build the Mac for anybody else. We built it for ourselves. We were the group of people who were going to judge whether it was great or not. We weren’t going to go out and do market research. We just wanted to build the best thing we could build.”—Steve Jobs

Thank you Adrian Smith for this presentation on Agile for Startups.

Links supporting not pivoting
If I made another Monkey Island

Advertisement

The way of the Spartan Warrior

There’s more to successful projects than time and money, but if you ask the people with the money, they’ll tell you that time matters a lot.

In this post I am going to show you one sure-fire way to quickly figure out how realistic your budget and schedule are and how to reset expectations like a pro when you need to.

How much can you afford

One of the great strengths of agile development is the leeway you get in building any given feature or story.

You can build it cheap. You can give your customer something with just a few bells and whistles. Or you can build them the Taj Mahal if they want that.

This looseness around high-level stories gives customers a lot of flexibility when making decisions about features. They can go light on user interface spit and polish if they are building a back-office invoicing system. Or they can invest heavily in look and feel for the tablet application insurance adjusters are going to be taking with them to into the field.

The challenge for you (and your customer) is to get a sense of how much they can afford right at the start. We’d all like the deluxe version of whatever it is we are building, but not at the expense of the budget or the schedule. As Steve Jobs likes to remind us, “Artists ship.”

To help our customers figure out this balance, we need a way of quickly confirming that we

• have enough time and money to build the system they want, and
• have a sense of how much they can afford in terms of bells and whistles that would improve the product and experience.

One way to get there is to start Spartan.

The Way of the Spartan Warrior

The Spartan Way is built around one really simple, common-sense premise: If we can’t build the Ford Focus version of the system with the time and money we’ve got, there’s no way we can afford the BMW.

So the way we figure out what we can afford is to build a few bare-bones core features, measure how long that takes, and then take a fresh look at the plan and see how realistic things are looking.

Once you can see clearly that the current plan doesn’t support the scope of what’s on your plate, having this conversation with your customer is much easier.

Yes, we’d like to build the world’s greatest automated invoicing system, too. It’s just that we can’t get the bare functionality in place (much less any of these other whizbang features you’re asking for) with this schedule and timeline—we’ve tried!

No wishful thinking. No guessing. The truth is self-evident.

This is really the crux of agile planning. We don’t know when we are going to be done until we build something of value, measure how long that takes, and then update our plans accordingly. I realize that some people (i.e., executives) don’t like hearing this, but this is the reality of software delivery. All we are doing here is eliminating as much schedule risk as we can up front, giving them a heads-up early on about how things are looking.

What to do if the plan is wrong

If the the plan is wrong, we have two options for bringing reality back into the fold:

1. We can reduce scope (recommended).
2. Or we can flex on the date.

Reducing scope is how agile developers prefer to keep their commitments and avoid the pain that comes from asking for more time and money.

There is always going to be more to do than the time and money allow (that’s just the reality of any interesting project). And if we keep adding features we’ll never ship anything.

So when given the choice we’d rather fix our dates and flex on scope.

If, however, there is a core set of bare-bone features that just have to be delivered as a whole, we can commit to delivering that core set of features. We just have to be a little flexible on the date.

Even in this scenario we will still need to flex on scope a bit (because new things are always going to come up). But we can go in with the understanding that these high-level core features need to be there and that we are going to ship as soon as these are done.

Pushing out the date a little is OK, but it’s not a good habit to get into. For one thing, it’s just too easy. Secondly, it puts your project in danger of delivering no value. Until you get it into production you haven’t an ounce of value, and agile hates that.

Summary

So if you suspect that your project has some scheduling challenges, try building a few spartan core features, see how long that takes, and update your plan to reflect that reality. If things are going well, swell. Keep on truckin’.

Otherwise, work with your customer to set them up for success by either reducing scope or suggesting they be prepared to wiggle a bit on dates.

Doing this early will enable you to have this conversation with conviction in an open and honest way. And your customer will appreciate knowing the facts at the start of the project instead of near the end.

Enter the world of The Agile Samurai

For the last two years I have been pouring my heart and soul into a book that just went beta with the Pragmatic Programmers called The Agile Samurai.

It’s been a two year labor of love that contains all the harsh lessons, war stories, insights, and tricks of the trade myself and many others have gathered over the last ten years.

If you are new to agile, or you know someone who is just about to start their very own agile project, please consider sending them to the URL below

http://www.pragprog.com/titles/jtrap/the-agile-samurai

and give them the tools and insight I wish I had when I started my journey 10 years ago.

(abstract from the back page)

Get ready to kick some software project butt.

Enter the world of the agile samurai, where the most dire of software project situations are dispatched with ease and grace. By learning the ways of the agile samurai you will discover:

* how to create plans and schedules your customer and your team can believe in
* what characteristics make a good agile team and how to form your own
* how to gather requirements in a fraction of the time using agile user stories
* what to do when you discover your schedule is wrong, and how to look like a pro correcting it
* how to execute fiercely by leveraging the power of the agile software engineering practices

By the end of this book you will know everything you need to set up, execute, and successfully deliver agile projects. If you’re a project lead, this book gives you the tools to set up and lead your agile project from start to finish. If you are an analyst, programmer, tester, usability designer, or project manager, this book gives you the insight and foundation necessary to become a valuable agile team member.

Packed with best practices, war stories, and hands-on tutorial exercises, The Agile Samurai slices away the fluff and theory that make other books un-agile. This book will make a difference.

Beyond Budgeting

The budget is a tool for repression rather than innovation. – Bob Lutz, Ex-CEO, Chrysler

The budget is an unnecessary evil. – Dr. Jan Wallander, Honorary President, Svenska Handelsbanken

The budget is the bane of corporate America. – Jack Welsh, Ex-CEO, General Electric

Annual budgets may sound boring to many, but their impact on society, how we work, and our output as a nation are huge.

In their book Beyond Budgeting – How Managers Can Break Free from the Annual Performance Trap, Jeremy Hope and Robin Fraser paint a very compelling picture for doing away with the annual budget, and moving to a move agile, decentralized value creation model altogether.

Hope and Robin argue that budgets have been hijacked by a generation of financial engineers that have used them as remote control devices to “manage by the numbers.”

They go one to say that “budgets have been turned into fixed performance contracts that force managers at all levels to commit to delivering specified financial outcomes, even though many of the variables underpinning those outcomes are beyond their control. This leads to undesirable and, in many cases, unethical behaviour.”

Examples of dysfunctional behaviour due to annual budgets include:

x always negotiate the lowest targets and the highest rewards.

x always make the bonus, whatever it takes (even if that means stuffing the distribution channel with “sale-or-return” products.

x never put customer care above sales targets.

x Never share knowledge or resources with other teams-they are the enemy.

x Always ask for more resources than you need, expecting to be cut back to what you actually need.

x Always spend what’s in the budget.

x Always have the ability to explain adverse variances.

x Never provide accurate forecasts.

x Always meet the numbers, never beat them.

x Never takes risks.

The solution

Hope and Fraser argue that the way out is to enable managers to focus on continuous value creation instead of merely trying to “make the numbers.” (I’m paraphrasing here).

When it comes to setting targets, choice high-level KPIs such as return on capital, frees chase flows, or cost-to-income ratios.

When it comes to rewarding people evaluate teams based on how they compare with industry benchmarks, their peers, and prior years.

For managing resources, make resources available and accessible to front-line teams as and when required through fast-track approvals.

To bring about these changes a change in core philosophy will be required. The fixed performance contract is based on central control. It assumes the absence of trust.

The relative improvement contract is based on self-regulation. It assumes that teams can be trusted to manage their own affairs (within agreed boundaries) and to be fully accountable for their results.

Summary

It’s hard to explain, and I am not doing the book justice. But if you are looking for a more lean, less wasteful, agile way to create your budgets, Beyond Budgeting may be the book you’re looking for.

Good reading for those of you looking for a more agile way to approach capital expenditures and budgets at your company.

Sharpen your saw with newsgroups

Today, in the agile community, there are dozens of newsgroups spanning many topics. Here are a few interesting ones I regularly track and follow:

Extreme Programming:
http://tech.groups.yahoo.com/group/extremeprogramming

Domain Driven Design
http://tech.groups.yahoo.com/group/domaindrivendesign

Lean agile
http://tech.groups.yahoo.com/group/leanagile

Lean development
http://tech.groups.yahoo.com/group/leandevelopment

Agile testing
http://tech.groups.yahoo.com/group/agile-testing

Agile usability
http://tech.groups.yahoo.com/group/agile-usability/

Do a favorite newsgroup? Do share.

Horizontal vs Vertical slicing

I recently started playing a bit of a release manager role for some projects at work, and one of the interesting conversations I’ve been having with people are the merits of slicing projects horizontally vs vertically.

Horizontal slicing

With horizontal slicing, projects are broken up roughly along architectural lines. That is there would be one team for UI, one team for business logic and services (SOA), and another team for data.

One advantage of slicing your application horizontally, is you get good communication and consistency within each slice. Everyone does things the same way.

The downside of slicing your projects this way, is that until you integrate every thing together, you really haven’t delivered anything of value.

Your customer can’t go into production with screens, services, or well normalized database schemas.

Only when all the layers are hooked up do they offer any value.

That’s why agile is so big on slicing projects vertically.

Vertical slicing

Agile is very big on the concept of one team. There is no UI, SOA, or data team. There is only one team, focused on delivering a suite of features for the customer.

The other advantage of slicing vertically is you are more efficient. You don’t have the overhead, and effort that comes from trying to coordinate activities across multiple teams. No need to negotiate for resources. You’re all on the same team.

No. Not always.

Whenever you have legacy systems (mainframes), core business entities consumed by many across the enterprise, or anything where the technology dictates how the application needs to be built, you may be better off slicing that body of work horizontally.

That doesn’t mean you can’t work with them in an agile fashion. More that they will have a certain way of doing things, and you will have to adapt.

So go vertical when you can. And horizontal when you have too.

Thanks to John Kordyback for sharing his thoughts on this subject.

Deliver something of value every week

Stuck in a rut? Can’t seem to ship?

Try delivering something of value every week.

Doing this will require you and your team to do certain things.

You have to break big problems down into smaller ones

A week is a relatively short period of time. You can’t possibly do everything in a week!

To get anything done in a week, you have to break big, scary, complex problems down into smaller, simpler, more manageable ones.

At first this can appear daunting.

But once you crack it, you will find the big problems aren’t as bad as you thought; and that you can deliver a lot of value in one week’s time.

You are forced to focus on things that are valuable to your customer

How do you know what’s valuable to your customer? You ask.

When you look at a software project through your customer’s eyes, it’s easy to see how little of what is traditionally offered has little or no value.

Sure you need documentation. Sure you need plans.

But they are only in support of one thing—working software.

By delivering something of value every week, you are forced to get lean and ignore anything that doesn’t add value.

As a result, you travel lighter and only take what you need.

You have to make sure that what you are delivering works

Delivering something of value every week implies that what you deliver had better work.

That means testing—lots of it, early and often.

Testing isn’t something you be slough off till the end of the project.

It’s not something you can delegate.
The buck stops with you.

When you deliver something of value every week, testing will become a part of your daily life.

You are forced to get feedback

How do you know whether you’ve hit the target if you don’t regularly engage and ask your customer how you are doing?

Feedback is the flashlight that cuts through the fog and keeps you on the road as you’re barreling down the highway at a 100 miles per hour.

Without it, your customer loses the ability to steer. And you end up taking a lot of wrong turns.

You have to adapt

Stuff happens on projects. Things change.

What is really important one week can be de-scoped the next.

If you create a plan and follow it blindly, you won’t be able to react to the curve balls.

That’s why when reality messes with your plan, you change your plan – not reality.

You have to be accountable

When you promise to deliver something of value every week, you become accountable.

That means owning quality.
Owning the schedule.
Setting expectations.
And spending the money as if it were your own.

Because, at the end of the day, it is you, your team, and the expectations you set, that will determine whether your project succeeds or fails.

You can’t delegate this. Nor would you want to.

Warning! Not everyone likes working this way

Delivering something of value every week is not for the faint of heart.

It puts the spotlight on you like never before.
There is no place to hide.
Every week you sit down with your customer, and show them how you’ve spent their money.

Some people don’t like this level of visibility.
They don’t want it.

But for a team struggling for direction, and not knowing where to begin, it’s an awfully good place to start.

So if you find yourself in a bit of a rut, or your team is struggling to get something out the door, hit the pause button. Take a step back. Ask yourself what it would take to deliver something of value every week.

Then trust your instincts, and do what needs to be done.