Lessons learnt in 2016

For the last year I have worked as a team lead at Platform45. The team consisted of seven developers and one designer. We produced bespoke web applications using a Ruby on Rails stack. My job was to optimise the team (read scrum master) and to make sure they do billable work (read product owner).

Here are some things I learnt this year:

  • Focus where the pain is. The ability to cut through the fluff and prioritise is priceless.
  • Communication will solve 99% of your problems. We always want to engineer lofty structures and processes when we face a problem. It is likely that a simple conversation do the trick just as well.
  • Learn how to talk about your needs. Stress is the feeling we get when we perceive that we have an unmet need. The only way you’ll get that stress gone is by being able to talk about your needs.
  • Have lunch with people. Time spent with colleagues is more valuable than trying to clear your inbox.
  • Small habits make a solid foundation. Be disciplined about the small things, and the big things will happen on its own.
  • Technical debt is terrifying. Make sure it doesn’t catch you off guard.
  • Pace yourself. You’re no good to anybody when you’re stretched too thin.
  • Customers rarely understand you when you say “agile” or “lean” (even if they swear they do). Don’t use fancy jargon when talking about these things. Use simple language, stick to basics. Talk about needs, values and principles.
  • You will often have to remind customers that estimates are hypotheses, and need to be treated as such. People tend to forget this.
  • Having a definition of ready is just as important as having a definition of done. Often the work required to get things “ready to be coded up” is invisible. Make it visible.
  • Having a historical velocity is non-negotiable. This might be obvious to some, but for many it’s not. Velocity is what allows the team to do work that is sustainable and predictable.
  • Our purpose as a team is to create value for our customers. It’s not to make sure our test coverage is a 100%. It’s not even to write code. It’s simply to create value. Everything else comes secondary.
  • It’s rarely a people problem. It’s mostly a system problem. Your culture is your system. Culture should be leadership’s number one priority.
  • Champion causes you believe in passionately. Don’t compromise. There will be people who oppose you. Don’t be scared of them. Make it possible for others to champion what they believe in.

2016 was a good year. Thanks to all those who made it possible!

Fix your budget, not your scope

Many software projects take on the form of a transaction between vendor and customer. A transaction is an exchange of value. The vendor supplies software to the customer that solves some problem (scope), costs a certain amount (budget), by some date (schedule). The customer (hopefully) pays the vendor.

In any exchange of value, there exists the possibility of an unfair exchange. That is the situation where one party gains more value out of the transaction than the other for some reason. This possibility of unfairness is the risk associated to the transaction.

Typical contractual agreements between vendor and customer distributes risk in a certain way.

Fixed bid

Fixed bid projects fix the scope, budget and timeline. To get to a fixed scope, budget and timeline, the following implicit assumptions are made:

  • We can know the entire problem upfront, before we actually start the project (scope). The vendor can then design a feasible solution and work out how many people will be required to build it (cost) and how long this will take (time)
  • The problem space will never change (scope)

In this model, all the risk is carried by the vendor, and very little risk is carried by the customer. In my opinion, the problem space is largely unknown. You discover the problem as you try solving it. By the same token, the solution has to be emergent. By trying to fix the scope upfront you do nothing more than speculate at a time when you know least about the problem and solution space. If the scope changes at all, the vendor would often carry the cost of the change.

Time and materials

With time and materials projects, the vendor simply charges the customer for any time spent. In this model, the customer carries all the risk. There are no guarantees for the customer around scope, budget and timelines. With time and materials the following implicit assumption are made:

  • The vendor gets paid no matter what they produce
  • The customer has very little control over the process

Fixed budget, scope controlled

At Platform45 we’ve been experimenting with another alternative called fixed budget, scope controlled (I first saw this term used by Atomic Object). It attempts to distribute the risk between vendor and customer more evenly. It makes the following implicit assumption: there will never be enough time or money to build everything you want (fixed budget), therefore, you have to carefully control what you build (scope controlled). It is fundamentally a lean approach. It distributes risk evenly between vendor and customer because the vendor knows what constraints they need to work in to solve the problems (fixed budget), and customers get full control over what is being built (scope controlled). The ability to “control the scope” is loosely based on the following list of principles and practices.

  • An estimation is a snapshot of understanding at a given point in time based on a given set of assumptions. Assumptions will change as we validate our learning (and so estimates will change)
  • Have short iterations / small batch sizes. This way you can handle changing assumptions and estimations without much waste
  • Vendor commits to solve a set of problems within budget, not to provide specific solutions. This allows the scope to be fluid enough to solve the problem within the budget constraints
  • There needs to be a continuous (at least once per iteration) negotiation between vendor and customer around priority for the next iteration
  • Vendor and customer continuously need to monitor budget and let that be a guide for prioritisation

It’s about being lean

As mentioned before, most of the above boils down to a lean approach. As a vendor, some intentional education around this to the customer often helps a lot (I have often daydreamed about buying a stack of Lean Startup books and handing them out to new customers as mandatory reading).

Three evolutionary stages of thinking about how we make software

Sarah Mei gave a keynote called “Factory, Workshop, Stage” at Rubyfuza this year. I loved it. She spoke about the conceptual models we use to explain the hard problems in making software. These hard problems are not about hardware, design patterns or vim versus emacs. The hard problems are about people, of course.

Sarah argues that our models of thinking about the hard problems in software are flawed. We tend to think of the software creation process as a factory. It’s in our subconscious, in our everyday language as software makers. We’re building product. Then we ship it. Then we maintain it. It’s the language of a factory: making some thing.

Here are some of the hard problems in software according to Sarah:

  1. The effects of hiring a new person
  2. The effects of a person leaving
  3. Adding more people to increase output levels
  4. How to measure productivity

Stage 1: Factory model

According to Sarah, the factory model does a poor job of explaining these problems.

1. The effects of hiring a new person. The factory model says each person only does one small job, and so is replaceable. There is almost no effect when a factory hires a new person. The factory model is not helpful in explaining the effects of hiring new person in the software world. 🙁

2. The effects of a person leaving. Again, the factory model says we just replace the employee. Not helpful in explaining when a skilled software engineer leaves a team. 🙁

3. Adding more people to increase output levels. In a factory, getting more people and machines will increase output. In software, getting more people and machines might actually make you deliver less. Not helpful. 🙁

4. Measuring productivity. In the factory, if you want to know how productive you are, just count the number of widgets. In software, just count the number of…what? Not helpful. 🙁

The factory model is not useful in explaining the hard problems in software. Sarah suggests it’s time for a new model. Sarah brings this idea home by quoting George Box: “All models are wrong. Some models are useful.” The current models we use to think about software are not only wrong, but also no longer useful.

The idea of a new, more useful model superseding an old, less useful model isn’t a new idea. Sarah gives us a history lesson from the 1800s. Back then, the miasma model explained the spreading of infectious diseases. The miasma model claimed that poisonous particles in the air gives the air a bad smell. Breathing this bad smelling air is what makes people sick. Smelly swamps were dangerous places because of this. Even though this model was wrong, it was useful. It explained a bunch of things to some efficacy. People in close proximity to each other get sick because they’re breathing the same air. Sewers keep smells away (and also reduces drinking water contamination). Closing your window keeps out bad air (and also keeps mosquitoes out).

Cholera challenged the usefulness of the miasma model. If smelly air spreads disease, how could cholera spread along sea routes? There was a need for a new model. Enter Louis Latour’s germ theory (1860s). Cholarea can spread along sea routes, because germs spread disease through a variety of vectors (including water).

Stage 2: Workshop model

The factory model isn’t useful, we need a new model. Some attempts at this have already been made. Sarah digs into how many people adopted the idea of software as craftsmanship. Sarah calls this the workshop model. Let’s see how it explains the hard problems.

  1. The effects of hiring a new person. Imagine a sword smith and his (or her) apprentice. They form a close-knit team. Hiring a new apprentice is probably going to negatively affect the sword smith. The same is true for a software team. The workshop model works! 🙂
  2. The effects of a person leaving. Like the hiring scenario, if a sword smith’s apprentice leaves, it will have a negative effect. The workshop model works here too. 🙂
  3. Adding more people to increase output levels. Two sword smiths working on two separate anvils will make more swords. Two programmers working on two separate computers will not make more software per se. The workshop model falls down here. 🙁
  4. Measuring productivity. You can measure the productivity of a sword workshop by counting the number of swords made. With software you can’t count anything. The workshop model isn’t helpful here. 🙁

So the workshop model scores 2/4. The workshop model focuses a bit more on the people than the factory model. But, fundamentally, the workshop model is still about making some thing (just like the factory model).

Stage 3: Stage model

This is where Sarah makes a brilliant departure. What would happen if we have a model that does not focus on making some thing? What if we saw making software as something less like a factory or workshop and more like putting a theatrical play together? Enter the stage model.

Putting a play together requires a bunch of steps. There’s a script and a director. Actors interpret the script. Next, actors do read-throughs where they decide how their characters will relate to each other. Actors then go away and do some self study. Then the rehearsals begin. Finally, it’s opening night and the actors perform the play.

Putting a play together sounds a lot more like making software. Different programmers (actors) will design a different solution to problems (script). The more they have built together, the more difficult it is to go back on certain decisions (rehearsals).  And finally there is the deadline (opening night) and user feedback (reading the audience). Let’s see how the stage model does with our hard problems.

  1. The effects of hiring a new person. If you bring a new actor into the mix, the entire dynamic of the play changes. It becomes a different play. Same thing in software. The stage model is useful! 🙂
  2. The effects of a person leaving. Same goes for someone leaving – it becomes a different play. If a member leaves a software team, you get the same kind of dynamic. The stage model works here too. 🙂
  3. Adding more people to increase output levels. You’re not going to make the play better or faster by adding more actors to the troupe! This rings true for software teams too. The stage model works. 🙂
  4. Measuring productivity. What does productivity even mean in the context of a play? How good the production was? How much the audience enjoyed it? The same applies to software: productivity is difficult to measure. The stage model works. 🙂

The stage model scores 4/4. Like Sarah says, we realise now that software’s end result is no more a product than a play about Macbeth is a product — it’s an interactive experience. Software is about people, it is not about making some thing. We’ve known that it was about people all along — the stage model helps us understand why.