Open Thinkering

Menu

Tag: Mozilla

Minimum Viable Bureaucracy: Goals, scheduling, shipping

Posted on by Doug Belshaw

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:

Waterfall chart

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.

Minimum Viable Bureaucracy: Problem Solving and Decision Making

Posted on by Doug Belshaw

This is my fourth post on Laura Thomson’s excellent talk Minimum Viable Bureaucracy. In this one I’m focusing on the section she entitled ‘Practicalities’. All of the ideas in this post should be ascribed to Laura, apart from my random musings which I’ve tried to make obvious.

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; you should find the part relating to this post below. Slides are here and it’s all backed up at the Internet Archive.

[display_podcast]

Self-organising does not equal democracy. Just because no-one is in charge doesn’t mean everyone has an equal vote.

(Laura Thomson)

Decision Making

How do we solve problems in a chaordic environment? People coming from a traditional company might wonder how decisions can be made. The short answer is that subject matter experts emerge. People gravitate towards projects they’re passionate about and become experts in that subject.

The second part of this is that there shouldn’t be a single person who knows or can do everything – there should be a ‘failover’. You should actively fight against there only being one person who knows or does everything. After all, if that person gets headhunted by Facebook or hit by a truck then suddenly you’re left with something that nobody understands. Leaving it at this isn’t enough, however, as there are some things that nobody wants to do – e.g. running weekly team meeting. These things should be rotated so it’s not too much of a burden on any one person.

What do an OSS decision-making processes look like? Well, says Laura, they all tend to converge on a model that looks a lot like this:

This is a reasonable structure for decision-making in any context: have one person who knows everything with (more) other people knowing almost as much. Things get done this way.

Laura adds a note in parentheses to this: ‘self-organising’ does not equal democracy. Just because no-one is in charge doesn’t mean everyone has an equal vote. But then, on the other hand, nor does self-organising equal anarchy. Self-organising systems emerge and converge on a structure, but they are not structureless.

Problem solving

“You should never have all of your time filled with things that other people have made for you to do.”

(Laura Thomson)

Bike Shed

Many architectural problems are like bikesheds, says Laura: they’re the thing you talk about over beers with the team or every workweek – but you never get around to doing. People have many different, possibly divergent ideas and think it’s too hard to get to a solution. As a leader, therefore,  you should pick someone and give them a week to go away and have a go at it. Get them to see how far they get with making a prototype. The important thing to remember is not to leave them too long in isolation as they can go down “a hell of a rabbit hole”. It’s good to have a time box for this kind of thing.

Laura’s advice is that you that you should ‘come with code’ for bikeshedding problems. This means you can point to something and say “hey, I built this”. People who don’t like it will no doubt say that they would have done it differently but when it exists, it’s much easier to just agree with something. The problem then kind of goes away. Many of the hardest problems get to 80% by one person over a two-day marathon giving the project a proof-of-concept and some momentum. In turn, this gives other people motivation and clears the path.

The moral? Give people room to do this and be innovative.

Moving on, Laura says she sees some things that are “really toxic”. Things like having an innovation department  where all the ‘innovative’ work is done. This is “silly”. Another management anti-pattern is giving engineers a number of tickets without giving the engineer space to think about the product. It’s true they may not understand the users, but they understand the product pretty well.

Depending on the company, a portion of time has to be spent by the engineer doing the thing that they think is most important. It might be 100% of the time, or 60%, 40%, one day per week – but it should never be zero. “You should never have all of your time filled with things that other people have made for you to do,” says Laura. There are so many reasons for this. One of them is you miss out on some of the most innovative ways of doing things. The second is that it’s toxic for engineering morale. It will make people leave. It’s a ‘super-critical item’.

This is true not only for engineers but for anyone in an pretty much any kind of organisation. Spending all day just implementing other people’s ideas doesn’t lead to a sense of agency or happiness.

In summary, there are three things to remember about problem solving in a chaordic environment:

  1. Push responsibility to the edges
  2. Adopt open source models
  3. Give people freedom to innovate.

For the things that aren’t ‘bikesheds’ figure out where the interfaces are. Interface design is more critical than component design. For example, your API is more important than the implementation, every single time. This makes everything more modular, allowing you to drop innovative things in more easily.

In non-technical language, this is about looking at how ideas and projects connect. This is important as it helps the organisation communication well internally and externally, helping things move forward smoothly.

Laura’s architectural goals:

  • Decouple replaceable components
  • Have clear interfaces and APIs
  • Make sure you have good tests for each component

For operational problems within an open source environment, the same principles apply, with two additions:

  1. Evidence > guts
  2. Immerse yourself in problems

In other words, use evidence to make your decisions rather than gut feelings. And when you’ve got a problem, set aside time for you (or someone on your team) to be fully immersed in it and understand it.

You can follow Laura Thomson as @lxt on Twitter.

Images CC BY-SA Pierre-Yves Beaudouin & John Myers

Minimum Viable Bureaucracy: Practicalities

Posted on by Doug Belshaw

This is my third post on Laura Thomson’s marvellous talk Minimum Viable Bureaucracy. In this one I’m focusing on the section she entitled ‘Practicalities’. All of the ideas in this post should be ascribed to Laura, apart from the fanciful interpretation of them (which is all mine – I’ve tried to make this obvious).

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 her talk; you should find the two parts relating to this post below. Slides are here and it’s all backed up at the Internet Archive.

[display_podcast]

Communication practices are called practices for a reason.

(Laura Thomson)

In the previous section of her talk, Laura talked about the importance of scale, chaordic systems and trust. In this section she’s focusing on implementing these ideas in practice. She starts by talking about the importance of over-communicate everything, especially if working remotely. Tell people what you’re going to do, what you’re doing, and then when you’ve done it (and, importantly, how it went). A good tip: if you have face-to-face or IRC conversation and others aren’t present, then you should document it for the benefit of the rest of the team. This is important in non-technical environments too. Keep people in the loop.

Encouraging a culture of collaborative note-taking allows for what Laura calls ‘asynchony’ – in other words “I shouldn’t have to be physically present in time and space to know what happened.” She points to a presentation by John O’Duinn that you can access here (PDF) Interestingly, John’s presentation focuses on the importance of having ‘groups’ of remoties and makes a case for ‘aqui-hires’.

If you’re working in an office and some members of your team don’t work from the same physical location then it can seem like a hassle to document everything, remember to invite them to meetings, etc. The important thing to remember is that remote teams allow organisations to hire the best people, regardless of where they happen to live. It might be a annoying for those that are physically co-located, but there’s a good reason for it (more talent in the organisation). Remote working is effective when there are good communication practices and there are high levels of trust. In the long run it’s best to get used to ‘remote’ ways of working as the chances are any organisation will end up having more than one office.

Moving onto effective communication practices, Laura suggests the following:

  • Shared communication spaces
  • Every project should have a URL
  • Some kind of chat system that has logging (IRC/Campfire, etc.)
  • Etherpads and wikis for collaborative document editing
  • Bug tracking
  • Email (secondary – after the fact documenting)
  • Record as many meetings as possible through video, audio or shared notes
  • Record decisions made

‘Bug tracking’ might seem like a specific issue for software development, but there’s many way bug trackers can be used for other things. As an example, check out this recent bug (#914343) for transferring the Web Literacy Standard from the Mozilla wiki to Webmaker.org.

It’s a well-known fact that many meetings kind of suck. Laura believes that, paradoxically, team meetings can actually reduce communication. They can be a bit like an annual performance review where someone says, “Hey Fred, you did a terrible job this year, in March you did this thing that sucked”. But then you wait until December to tell him about it. If something is important, don’t wait for a weekly team meeting to raise it. It’s not the frequency of meetings, it’s the culture: the ad-hoc, asynchronous nature of the interactions/communications.

If you turn up to a meeting and never say anything you probably shouldn’t go to it. Try replacing the idea of meetings with conversations about the following:

  • Collaborative problem-solving
  • Maintenance windows
  • Triaging bugs
  • 1:1s
  • Show and Tell (people really enjoy doing these)
  • Post-mortems

If you have to have an actual meeting, make sure you have an agenda, a list of stuff you’re going to talk about (even if it’s just five bullet points). Limit the number of people at the meeting as “nothing good ever happened at a meeting with 20 people in it. Ever.” Limit the length. Try 30 minutes and if it takes longer than that, schedule another 30 minutes. And try to cluster meetings together – either all on the same day or same morning.* Record and take notes for asynchrony.

*This, of course, depends on shared calendars, which is a great habit to get into. You can share on a free/busy basis with most platforms.

When it comes to Minimum Viable (Project) Documentation, Laura’s advice is to aim for:

  • How to install code
  • How to make a change / submit code
  • What’s the roadmap (even a rough one for next week)
  • Changelog (version control systems often do this)
  • Glossary (helpful for new employees, interns, external contributors)
  • Where to get help (the most important)

Although this seems extremely software-specific, if you think about what these things would look like in your environment, it doesn’t take too much of a leap. Instead of ‘submitting code’ you could talk about ‘adding ideas’.

Finally for this section, Laura reminds us that it becomes more annoying to explain something for the tenth time to the tenth different person that it is to write it down. Documentation is important and saves everyone time.

You can follow Laura Thomson as @lxt on Twitter.

css.php