The Agile Planner

Why is iterative development so motivating?

2012-05-14T09:00:00+00:00

If you ask a handful agile developers why they work in iterations or sprints, most of them will tell you that they help them predict how long their work will take. While that's true, it isn't necessarily the most important benefit. To put it bluntly, I get more done when I work in iterations.

It's about commitment.

When planning a new iteration I only include as much work as "yesterday's weather" suggests I ought to be able to complete. In other words, I schedule as much work as I completed in the previous iteration.

If your estimates are consistently accurate (or consistently inaccurate, which is just as good) then your iteration represents a feasible goal; I know I can achieve it. I make a private commitment (just to myself) to deliver it.

The feeling that I really ought to be able to get everything done helps to keep me going. It also keeps me focussed and on track; when I'm working on my own there's nobody looking over my shoulder to point out when I'm about to disappear down a rabbit hole. Being aware of my progress through the iteration provides a good substitute.

Some might suggest that I'm using iterations like todo lists, but there's an important difference.

A traditional to-do list is not a commitment. It may feel safe to add every potential activity there, including things that other people push on you. The list is long, and the continuous inward flow ensures that all activities can't possibly ever be done. Without commitment, there is less motivation. It's really not an achievement to complete and remove one line from an inventory that is still enormous. -- Staffan Nöteberg

The quote is from Pomodoro Technique Illustrated from the Pragmatic Programmers. The Pomodoro technique has a lot in common with agile development. I use Pomodoros to keep my days focussed, and iterations to keep me working towards the bigger picture.

As a lone startup founder it can be difficult to sustain your motivation, but once you've felt the satisfaction of doing a solid day's work you'll want to repeat it tomorrow. It's the same with iterations; after delivering a solid fortnight's work I can see my progress. It's real. It's tangible. And I want to repeat it...

6 Lessons from Joel Gascoigne

2012-04-26T09:00:00+01:00

Last Thursday I spent the morning at the Leaning to Start Up event in Manchester. Joel Gascoigne, the founder of Buffer gave a talk covering some of the lessons that he's learnt from building startups.

I've been a Buffer user for quite a while now, and first came across the app when Sal Virani suggested I read one of the Buffer blog posts that explains how he tested the demand for Buffer. If you're thinking of starting your own business online, that post is well worth a read.

Thursday's talk included similar advice, along with plenty of new tips. Joel structured it around six key lessons.

Lesson 1: Be open, vocal, and share your progress

Joel's first start up was a site called 1 Page, which allowed you to create an online version of your business card. While 1 Page wasn't ultimately successful, the 18 months that Joel spent working on it weren't wasted. He blogged and tweeted prolifically about what he was doing and built up a substantial twitter following (1,700 followers).

Those twitter followers were very useful when he moved on from 1 Page and started testing ideas for Buffer. The statement that resonated for me was this (I'm paraphrasing):

Working on startups is a career path, and it pays to build your personal brand while you're working on your idea. Every app that you start builds on your brand. Even if your current startup isn't successful your personal brand and followers stay with you.

Lesson 2: Work on the side

You'll often hear people advising you to focus 100% on your startup idea, rather than working full or part time to pay the bills while building a business in your spare time. Joel started working on Buffer at home in the evenings, while working as a freelancer for two clients.

Once he'd demonstrated that there was demand for Buffer he built a very simple first version of the app. He offered a paid plan from the very beginning (with a simple Paypal button). As more people signed up to the paid plans he was able to slowly reduce his freelancing commitments to focus on Buffer.

Seeing people pay for it also provided plenty of motivation to keep going.

I've experimented with working on startups on the side and found that it didn't work too well for me. I suspect that my difficulty was due (in part) to me having validated my original idea less rigorously than Joel did. I've spent a lot of time experimenting with different ways to divide my time between client work and my startup, but that's a story for another post.

Lesson 3: Test assumptions

When working on a project for an employer you have (by definition) a validated spec to work to. When you're working on your own startup there's nobody to tell you what to do next. You just have a hypothesis, and its important to validate it yourself.

Joel read Eric Ries' blog while he was working on 1 Page. He decided to give Lean a try, but wanted to try it from scratch on a new idea. Lean can be difficult to apply rigorously; Joel jumped straight into coding Buffer before realising he was doing it wrong. He stopped and put a lot of thought into how to validate the idea.

Buffer's first minimum viable product (MVP) was just a landing page. The page implied that Buffer already existed, explained what Buffer did, and had a "Plans and Pricing" button to click if you wanted to buy it. Instead of a pricing page, people were shown a newsletter sign up page with a brief message explaining that Buffer wasn't quite ready.

Joel feels that you're missing out on a lot of validation if you've only got a newsletter sign up page, rather than a button for signing up or purchasing the product. If people haven't tried to buy your app, how do you know that the people on your mailing list are interested in paying for it?

Whenever anybody signed up to Joel's mailing list he emailed them personally, explaining more about Buffer and asking for feedback. He stressed the importance of their feedback in the email.

Having demonstrated that there was interest in Buffer, the next step was to find out if people would pay for it. A pricing plan page was inserted between the button and the newsletter sign up form, showing three pricing plans. A few people clicked on the paid plans, and Joel emailed them to find out how much they felt it was worth.

With the first MVP out of the way, Joel built version one in his spare time over the next six weeks. It was a very simple implementation, only supporting one twitter account per customer. The paid plans simply allowed you to add more tweets to your queue.

By the time the first version launched Joel had collected 120 email addresses on his list. Fifty people signed up on launch day (though not all were from the mailing list). They had their first paying customer within 3 days.

Lesson 4: Be curious, embrace serendipity

Joel skipped over lesson 4 while he was giving his presentation (I suspect he was short on time) and suggested we email him to find out what it was about if we were interested. So I did.

Once Buffer was making just enough money to support Joel and Leo (his co-founder), they became curious about all the buzz around the San Francisco startup scene. On a whim they jumped on a plane to California where they met lots of people working on startups. One thing lead to another and they ended up getting Hiten Shah and Guy Kawasaki onboard as advisors.

Embrace serendipity. Good point, well made.

Lesson 5: Focus on solving problems, not raising funding

If you're a first time founder looking for funding, the best thing you can have going for you (from an investor's point of view) is a product that has traction in the marketplace. Traction validates the idea.

If all you have is an idea (without a working demo) then you could also raise cash on the basis of the idea alone. You're less likely to succeed if you've got a working product that hasn't gained traction (investors will wonder "why not?").

Joel's advice to first-time founders looking for funding is therefore to build an early version of the product that solves a real problem. Solutions to real problems tend to gain traction.

Joel and Leo initially had no plans to raise funding for Buffer. It was only while talking to people in San Francisco that they realised that funding made sense for them. Joel had been handling all the design, development and system administration, and he didn't have any capacity to take on more work. An injection of cash (from a $400,000 seed round) allowed them to bring another developer on board to scale the business. There are now 6 people working at Buffer. They're turning over $35k per month, and are growing at 30% per month!

Lesson 6: Enjoy yourself

This one is pretty self explanatory, but by no means less important than the others. From my own experiences so far, it's vital!

It was an excellent talk, and inspired me to post more about what I'm learning while I'm building The Agile Planner. The data that Joel shared from Buffer's early days (such as how many people were on the list at launch, and how long it took to get the first paid subscriber) was especially motivating. Have you got any similar figures you could share?

Useful links

Buffer's article on how they stayed Lean: Idea to paying customers in 7 weeks: how we did it
Eric Ries's blog: Lessons Learned
The Lean Startup book

How do you name your startup?

2012-01-23T08:50:00+00:00

There are plenty of theories on how to name your startup. Back in 2005 Seth Godin wrote an article called "The new rules of naming" in which he said:

A long time ago, the goal of a name was to capture the essence of your positioning. To deliver a USP, so you could establish supremacy in your space just with your name. International Business Machines and Shredded Wheat were good efforts at this approach.

It quickly became clear, though, that descriptive names were too generic, so the goal was to coin a defensible word that could acquire secondary meaning and that you could own for the ages. That's why "Jet Blue" is a much better name than "Southwest" and why "Starbucks" is so much better than "Dunkin Donuts".

That was 2005, and Seth's examples were all for big successful companies, not small niche products. Do Seth's principles apply to niche products that are distributed on the web? I think not...

Patrick McKenzie of Kalzumeus Software recently wrote about how he has benefitted from buying "exact match" domain names.

What worked right: Exact match domain names. ”Hey Patrick, how is it that with no marketing budget and nearly no marketing work you rank #1 for [appointment reminder]?” I told everybody that I was buying the .org specifically because that would happen but apparently folks didn’t believe me.

He makes web apps for small niche markets and does very well out of purchasing domain names that match the keywords his potential customers enter into Google. It's a shortcut to getting good traffic from search engines if you're operating in a small niche.

A friend of mine has another technique for naming his apps, called FAB. It goes like this.

Write down the main features of your app.
For each feature, write down an advantage that it provides.
Then write down some benefits (to your potential users) of those advantages.

For example:

The Agile Planner allows you to put your index cards online (feature) that work just like real cards would on your desk (advantage) which means you can access your plan while you're out of the office (benefit).

When I started thinking about building the Planner I put together a quick web site in order to test whether there was any demand. My mate with the FAB technique loved the app, but not the name. We put FAB into action (it all sounds a bit Thunderbirds doesn't it?) and came up with "Plan Anywhere" and "Plan Simply".

This left me in a bit of a quandary. I had a shortlist of possible names but wasn't sure if I should I go niche specific, or FAB it up. It needed testing.

Testing product names with PPC

If you send some potential customers to your web site you can gauge their interest in your product by seeing how many sign up or join your mailing list.

My hypothesis was that if I sent an equal amount of traffic to several copies of the same web site (each with a different name at the top) one name would perform better than the others. I made four copies of the site and then started a PPC campaign.

I think this was a mistake. While I think testing with PPC is a great technique, I spent hours finding suitable keywords to advertise on. I then realised that my PPC skills weren't good enough to get me a substantial amount of traffic. I'd happily have spent a few hundred dollars on the advertising, but the clicks just weren't coming and I'd spent too long messing about with Adwords.

Running a survey

So I took a different tack. Why not ask people in my target market which name they think works best?

I setup a quick survey on wufoo.com and then contacted a bunch of agile developers that I've worked with over the years.

Here's the survey:

I asked two questions:

Imagine that you've just searched Google to find an agile project management app. Which of these product names is the most appealing? Which would you click first?
Can you put your finger on why you chose the name you did?

It took me ten minutes to setup, and an hour or so to send out to my network of agile developers. Here's a summary of the results for question 1:

The responses to question 2 were thoughtful, and very helpful. Here are a few extracts:

"Plan Anywhere" gives a me a reason why it's better than index cards, I can access it anywhere without having to lug the box of cards and planning board with me. That's my theory and I'm sticking to it, I assume my cheque is in the post.

Wow. Maybe this FAB stuff really works?

None really leapt out at me. Maybe you should test with adwords?

Touché!

[The Agile Planner]: While I find "Plan with Cards" the most fun, my gut drove me toward "The Agile Planner". It’s hard to say definitely, but here’s some thoughts that apply just to my personal associations: “Card(s)” connotes something light and throw-away, in spite of its relationship to the agile method. “Simply” — goes without saying :) “Anywhere” — seems like the focus is on mobility. Overall, I reckon “The Agile Planner” is both non-specific and solid sounding, enough to make me feel it would impose the right structure, whilst also flexing to my demands.

[The Agile Planner]: I think it nicely encapsulates what you are offering. cons: it's going to be difficult to google as there are many agile planning websites already... if you have a more unusual name it will be easier for people to find.

I'm hoping that once the site gets a few inbound links that it'll end up near the top of the search results for its own name.

"Plan with cards" sounds like Tarot.

:-)

[The Agile Planner]: Plan with Cards sounds like a solitaire game, Plan Simply sounds like a food menu app. Agile story cards sounds a bit like a kid's gymnastic game. Plan Anywhere sounds like a travel planner, and Agile Index Cards just is a bit of a gobful.

:-)

[The Agile Planner]: Good use of definitive article! And it's a perfectly descriptive name. Also lends itself to acronym.

Acronyms are an interesting point; who is it who suggests that your product name should be a verb, so that it can become part of a team's language? If this app became abbreviated to TAP, might be people start saying (as they discuss new features of their product) "let's TAP it..."?

If you took part in the survey, thanks very much for responding. I really appreciate it, and can now stop worrying about the name and crack on with getting it ready for beta...

How long is your startup runway?

2012-01-18T00:00:00+00:00

Something to consider when deciding how to launch your startup is whether you're going to build it in your spare time, or save enough money to cover your living expenses while you work on it full time. If you choose the second option you'll want to work out how long your money is likely to last you -- entrepreneurs often refer to this period as your "startup runway".

I've tried building a product in the evening and at weekends, and it's not for me, so I've saved up a bit of money and stopped freelancing to work on The Agile Planner full time. The first thing I did was to calculate how long I've got before the cash runs out.

For a company with one or two founders, it's a fairly easy calculation to make. You can see the spreadsheet that I'm using here (I've split one row in the spreadsheet into two halves, so it fits on the page):

If you fancy playing along you can download it for Numbers.app or Excel.

The calculation

Let's take a look at what's going on...

The first column is today's date. I'll be revisiting this calculation every month to make sure that my estimate is always up to date. Once you've worked out how much you've saved, enter that in the "Company Bank Balance" column.

Now we need to know how much it costs us to survive a month. I'm paying myself a small salary and have estimated how much money I spend each month.

How much money do you think you spend a month? I've entered my estimate into "Monthly Costs". If you're not sure how much you'll spend its time to start tracking it. I'm using Envelopes on the iPhone which is a low ceremony approach to getting a handle on where your money goes. The good news is that you don't need to remember to track everything for long; you only need to get a good feel for how much you ought to put in that spreadsheet cell.

I'm probably being optimistic about how much I spend a month, so I've assumed that I'll spend some money this month on things I haven't yet thought of and entered that number into "Unexpected Purchases".

The "Salary" column is simply the sum of all my monthly personal expenses. My company's outgoings are:

"Taxes" due on my salary (that means PAYE and NIC, if you're in the UK), and
"Services" that I might need to spend money on, such as freelance web design.

Imagine the worst happened, and nobody wanted to buy your product. How long would it take you to sort out an alternative source of income (i.e. get a job)? To leave myself a financial cushion I've assumed I'll be able to find another client project within six weeks, so I've worked out what I'd spend in six weeks and called that the "Get Work Threshold".

The number of months in your runway is just your bank balance, minus your Get Work Threshold, divided by your company's total monthly expenses.

Of course, Eric Ries defines the length of your startup's runway as the number of pivots you can make before you run out of money. Anybody have any idea on how to calculate pivots per month? ;-)

And so it begins...

2012-01-12T00:00:00+00:00

Well hello there, and welcome to the Agile Planner blog.

The Agile Planner is the project management app that I've always wanted somebody else to build. Given that it doesn't seem as though it's going to happen any time soon, I'll be doing it myself.

When using existing agile apps I either find myself cobbling together a combination of tools or fighting the processes enforced by whoever built the app. Neither option is acceptable to me.

Okay, so what am I trying to achieve here?

A bit of history

Back in 2002 I joined a small software company in Cambridge. I was the third developer.

When I arrived I'd just left a .com where I'd headed up the technical department. One of my responsibilities had included giving the board of directors a good feel for how long new features were likely to take to develop, and I'd had some success by multiplying all our estimates by 2½ before passing them on to the board. This approach seemed ludicrous to me at the time, but it proved to be quite successful in practice. I hated getting those estimates wrong; corporate decisions were often based on my predictions and any significant errors felt like a personal failing.

When I arrived in Cambridge I'd been reading about the Agile Manifesto and Extreme Programming, and had already adopted TDD and refactoring. At this point I still hadn't yet had a chance to try pair programming or working in iterations, but I was eager to try.

The agile approach to planning with yesterday's weather (the idea that you'll achieve as much work this week as you did last week) really appealed to me. I could see that tracking the team's velocity would be a big improvement over just using 2½ all the time. My new team was quick to adopt iterations and story cards.

We started to track our progress. Sometimes we found that our estimates for an iteration's work were quite consistent with what we'd achieved in previous iterations. But every now and again a story would take a lot longer than we expected, and our plan paid the price.

Why did this happen? It was because we'd made estimates without having a good understanding of the problem.

We started to be a lot more careful with our estimates, and something rather magical happened; yesterday's weather became significantly more useful. Iteration after iteration, we were able to deliver the same number of estimated story points (we used ideal days instead of craft units, but it really doesn't matter what you use so long as you're consistent).

Our iterations became so consistent that we almost knew how long features were going to take; we were no longer guessing, our estimates were as useful as facts. We were moving at a constant pace, and just as significantly, the work was done swiftly.

It was the most productive team that I've ever been in. I'll get into why we went so fast another time, but that also has a lot to do with our approach to making estimates.

We achieved speed and accuracy by following a simple process, but it's a process that isn't well supported by your typical project management web app. We used index cards and a Wiki, but the task of tracking our work and keeping the cards and Wiki in sync was admittedly rather painful.

I left that company and went freelance in 2006, but I've been applying the same techniques that we developed in Cambridge to predict how long work should take ever since.

Now I don't mean to toot my own horn, but if I tell one of my regular clients how long a piece of work will take they know they can rely on the answer. The surprise for me has been that it's still a relatively unusual skill in our field. Most of the people I've worked with over the last few years haven't been getting the kind of return from using an Agile process that they ought to.

I've taught the approach to others and it's safe to say that it works (i.e. it's not me, it's the method). I want to spread the word further.

So these are my goals with the Agile Planner:

I want to build an app that will make my life as an agile developer easier, and
I want to get the word out about the benefits of paying proper attention to your estimates.

Using LEAN

I'm aware that while I might be rather handy with Agile and software development, I've got plenty to learn about how to launch a product on the web. I'll be writing about my progress in the Building the Agile Planner section of this blog. I'm glad that I've finally started -- there's only so much you can learn from reading books like Start Small, Stay Small and The LEAN Startup (though both are excellent, and highly recommended).

At some point you have to just get stuck in and learn for yourself. Wish me luck... :-)