Tag Archives: methodology

Life, The Universe, Startups, And Everything

Recently I finally figured out what I’m doing in my startup.

Not how to succeed — growing very large is still ahead of me — but how to know what to do next. Here’s what I learned.

I have two theories to test, a value hypothesis and a growth hypothesis.

Value hypothesis: if I present this to you, in this format, you will exchange with me something that I find valuable. Perhaps money. Perhaps your time.

Growth hypothesis: if I do these things, I will be able to present my value proposition to X number of new people.

One of these is called sales, the other marketing. But do not be concerned with business-sounding words. You don’t have to start reading tons of business blogs or building imaginary worlds with spreadsheets. In fact, that can be very dangerous, as it causes you to emotionally bake-in ideas that most likely are completely fallacious. Just look at it like all you have is these two very tenuous theories.

Your job is to make very precise and defined hypotheses — if I do X, Y will happen — then run a test on them to see if they hold up. You are a scientist studying a completely unknown field of study. Come up with two hypotheses, one value, one growth, then test them. If they fail, change the hypotheses until they pass. A failure is a good thing! But it means you need to decide whether to give up or pivot. Most new people to startups build some huge product — one hypothesis — and never really test it. Good startups build dozens of testable hypotheses and test rapidly. Bad startups take forever to get to a test. Or they run out of money long before they ever get around to it.

Here’s the critical thing: The goal is the passing test, nothing else.

Value hypothesis: if I show a bunch of people a bushel of apples while they are at the flea market, 5% of people will buy one for one dollar.

Growth hypothesis: if I give you half-off an apple in return for your wearing an “I bought the best apples ever at Joe’s Booth!” badge, you will bring by two other people who will also buy apples.

By creating and continuing to define these hypotheses, you build a self-sustaining system of creating value, or a business. One way to break down your two theories into finer hypotheses is like this:

lean-canvas

But there are others. As you make your hypotheses more and more detailed, you start creating a very defined structure to the test. This structure is your business model. A business cannot succeed — or fail — without creating and testing hypotheses. If you’re not testing hypotheses, you have an expensive hobby, not a business.

Want practical value? Create a Kanban board around the hypotheses you are testing, color-code your tasks to match up to what you are testing (Trello is really nice for this). Then you’ll know that every thing you do each day is for a reason. You’ll also be able to prioritize your time and energy better.

Write these down. Put them in a public, visible place for you. Everything you do — go to seminars, learn how to sell, read a book on startups, watch a video on programming, life, the universe, and everything else for a startup — everything fits into this model.

Use it.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Why your programming skills suck at project management

I was working with an Agile program doing planning last week, and we were all busy creating our release plans and beginning to scope out our product backlog. Every team was using big visible indicators of work, usually post-it notes and blotter paper.

Except one. As we started socializing our work, talking about dependencies and identifying opportunities to refactor, one team came up and presented their backlog on the projector using a spreadsheet. Everybody stopped while one person went down each line, item-by-item, for 100 items.

This kind of meeting, where somebody grabs a projector and folks stare at a wall for hours, is one of my pet peeves. But these guys were new and I saw it as an opportunity to coach them later on. I timeboxed their presentation to limit the damage, then we all managed to complete.

At the end of the day, when we were getting feedback, I got quite a surprise! The group who didn’t physically work with their backlog thought that all this post-it and physical stuff was so much rework. Why not everybody just complete their work ahead of time and we could all show it on a projector? Ten teams, all with hundreds of items on spreadsheets to go down line by line, all day long.

Yikes!

They also thought the 3 hours we spent doing the same work took too long! Go figure.

I had to come up with a respectful way to tell them that this is a bad idea.

“You know, the way you think about backlogs, a big hunk of data to be created and managed, is not actually the way they work. The wonderful skills you have as a programmer or analyst are actually not applicable here. The goal here is not to work with the data, it’s to work with what is between your ears. Your brain. We are optimizing the transfer of information using humans, not computers. That means that there’s a whole new set of rules to deal with.”

I don’t think they got it, but most of the other teams knew what was going on and had my back. So it worked out.

But there is a teachable moment here. As technologists we are used to moving data around on machines. This is a completely different universe from optimizing the behavior of people to understand and attack a problem. People are not computers.

There are a lot of little consequences from this. For instance, people can only compare so many items at a time, so we usually limit comparisons to 2 or 3 items. People can only remember so many items in a meeting, so we limit our lists to 20 or 30 items. People read more by body language than by words, so we put them physically together while planning. People are more likely to make good tough decisions early in the day, before they reach “decision fatigue”, so we front-load the work. And so on.

Some of this stuff, of course, is unproven pscyho-babble. Some is not. What the Agile community has been doing is empirically testing these various theories to see which ones work well and which ones do not. As practitioners we have a big list of “games” and principles the games are built on. We add some in, see how the team reacts, then adapt. That’s why Agile is different from other methodologies. Agile is a marketing term around best practices for iterative and incremental development. That vagueness is its strength, but it can also drive newbies nuts. It is entirely different from the kind of yes-no, off-on boolean logic most of us deal with in our jobs everyday.

Or to paraphrase a famous presidential campaign, it’s the people, stupid.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

What’s Agile To You?

As a project manager, architect, developer, and coach, I’ve worked on a lot of agile teams. As part of that experience, it’s always fun to ask folks: “What does the word agile mean?”

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Understanding Backlogs

I’ve never seen people get as wrapped around the axle as people who are new to agile and are creating and managing a backlog.

I’m not a famous author. Nor do I play one on TV. I’m just a coach helping teams get agile and get fast in their delivery of value back to the business. So if you’re a fanboy or a hero-worshipper there’s lots of better places to go. All I’ve done is make this work a few dozens times with all kinds of obstacles and problems along the way.

It’s been interesting to read about backlogs, however, and I’ve seen a lot of folks who are over-educated really screw the pooch. (an unfortunate phrase from my Marine past considering my previous post!) In backlogs, in particular, it seems folks are either too theoretical and not practical enough, or “practical” to the point of following a recipe and perfectly fine with filling out forms. If you’re in this boat, here’s a hint for how your project is going to work out: slow and tedious.

So what’s a backlog? How does it fit into a big organization? What’s the difference between a user story and a use case? How can teams get chartered effectively without delivering top-down “shall” requirements? How can the organization (not the product owner) make sure teams are doing what they are being paid for without controlling every fine detail? What’s a good backlog look like and what’s a bad backlog look like?

As usual, let’s go to the bullet points. If you have any questions, please comment and I’ll be glad to explain.

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.