Tag: scheduling

This is another post on Laura Thomson’s excellent talk on Minimum Viable Bureaucracy all about the section she entitled ‘Goals, scheduling, shipping’. You should credit Laura with all of the ideas in this post, apart from comments that I’ve added in italics.

Posts in the series:

1. Introduction
2. Scale, Chaordic Systems & Trust
3. Practicalities
4. Problem Solving and Decision Making
5. Goals, scheduling, shipping
6. Minimum Viable Bureaucracy: Why have managers?

I chopped up the audio from Laura’s talk and you should find the part relating to this post below. The slides are here and everything is backed up at the Internet Archive.

[display_podcast]

“If something doesn’t work, just change it.”

(Laura Thomson)

Anti-estimation

Laura assumes everyone’s read The Lean Startup and the idea of Minimum Viable Product (MVP). She encourages people to apply this to everything. Literally everything. Make the smallest thing that could possibly work and iterate on it: not just in architecture or software, but in your processes and your company org chart.

Some examples:

• Create prototype – MMVP (minimal Minimum Viable Product)
• Decide changes to ship
• Get it deployable
• Ship MVP
• Ship v2
• (etc.)

You have to push back really hard to get to this because so many people are perfectionists. There’s a spectrum between purists on one end (“we want to ship the best possible thing”) and pragmatists on the other (“we want to ship it now”). You need a balance of both kinds of people on a team: if you have all purists they will never ship, and if you have all pragmatists “they will ship a steaming pile of crap”.

Why does estimation fail?

We’ve all worked on projects that went over a deadline. The thing is we know that up-front estimation (‘waterfall’) approaches are worse than agile-type approaches, but we don’t really know why. Laura’s opinion is that “agile methodologies are a way of secretly admitting that estimation is always wrong”.

It’s not too hard to estimate how much work you can do in the next 24 hours, or two weeks or six weeks, but it’s pretty hard to estimate how long something that’s going to take over a year is going to take altogether. There’s an old saying that “a one-week project takes three weeks, a three-week project takes three months, a three-month project takes six months, and a six-month project takes forever.” It will never ship. The goal, says Laura, is to break things down into small enough pieces so that you can do it in a reasonable amount of time.

Why do projects fail?

Here’s this huge thing that we want to ship:

So you build the project plan and then bask in smug self-confidence: it’s written down so therefore it must be true. This, of course, works really well until your project goes off the rails. The thing that’s wrong with the plan is that you didn’t know enough yet when you wrote it. All kinds of things happen over the course of the project that you don’t know about. For example, Thing 5 on your project plan turns out to be infernally difficult and to ship that item you have to come up with an optimal solution to an NP-complete problem. Or Thing 4 depends on someone else’s team – who have more important things to do.

Everything about Minimum Viable Bureaucracy so far is about bottom-up, emergent and chaordic systems – they’re grassroots and self-organising. Estimation, on the other hand, is by its very nature top-down. It’s somebody from a programme management office saying “this is how long I think this is going to take”. These two things are inherently in conflict.

There are some things you can try to resolve this tension – and the risk of trying something different is really low, because if you’re wrong 100% of the time, it doesn’t hurt you to try something else! Laura proposes anti-estimation. For example, if someone asks if her team can build something in the next quarter (of a year) she replies “Nope, because I don’t know what that is, but we can go away and investigate and at the end of the quarter tell you how hard it’s going to be.” Instead of writing a project plan, her team will build a prototype of what they think is the hardest part, because that’s the bit that’s going to take the longest. By doing this they get a much better feel for how hard the project is.

When you’re prototyping something like this you should set a timebox for it, “we’re going to build as much of a working thing as possible in this amount of time and then we’ll stop and think about it.” The same goes with writing a specification: take two weeks and talk to everybody and write down as much as you know. And with shipping: commit to shipping every week whether it’s perfect or not as long as the thing that’s being shipped it good.

There is a tendency in all of us to say “yes, I can do that”. Part of this involves looking at the five things on a project plan and starting with the four things we already know how to do. Laura says we should start with the unknown – putting the risk right upfront. Then we can iterate. If someone asks you to estimate how long something will take that you don’t know anything about say “no”. This is particularly important for consultants as if they say it’s going to take 30 hours and it takes 600 hours then “you have just worked for McDonalds wages”.

Laura proposes the idea of ‘never-done-ness’. No system is ever done – unless we decide to throw it out and replace it (in which case the new thing is never done). Everything is always in a state of growth and you have to constantly push back about this with your team. So with the perfectionists you say that the team is not going to build the whole awesome thing in one go, but break it into chunks and do a really good job on them before shipping them. And the next iteration is Awesome Thing Part 2. Aim for micro-quality rather than macro-perfectionism.

Another thing you should do is ruthlessly murder scope-creep. Laura’s favourite phrase is, “not in this iteration”. Doing small, frequent iterations means that:

• You get better at shipping (and everything involved) – you have to automate things because you don’t have a choice
• It takes less time to get things from idea to execution
• Your team gets better at improving products
• People whose work is blocked won’t be blocked for as long
• Perfectionists are happier because they know the next iteration is coming soon

Emergent processes

It’s as important to iterate on your processes as it is on your product. “If something doesn’t work, just change it.” Don’t say you’ll do it ‘one day’, fix it now! Talking about it takes more time than doing it. Start with what can be fixed today before you go home and “use dividends from small improvements to put down payments on larger improvements.”

Don’t aim for perfection: just change one thing at a time and try to make it better each time. One of the things Laura says to people is, “Everyone makes mistakes; one of my personal goals in life is to make different mistakes each time.” Make novel mistakes.

---

You can follow Laura Thomson as @lxt on Twitter.