If there's no accountability, there's not learning from failure. This is wasting your time.

Each failure teaches you about...

Your process

Your team

Your perception of your customer

Your understanding of your product yourself

You make a "myth" of your product and customers... the only way to prove/disprove it is to ship and find the truth.

Even the customers don't always remain. They come and go. You might need to change your product in response.

Extract lessons. Do retrospectives for everything!

Find:

Not only what happened

but also how to make it better in the future (so you make better projects)

Catalog lessons. Create a repository of lessons learned. It can be a simple google doc. This is hard, but it creates a culture of sharing and not feeling bad when things fail.

Idea: the FAIL WALL. Show the mistakes you've made (in post-its, in a visible space).

Bob Sutton: "most creatives learn more from setbacks than from competitors."

Fail faster and cheaper. Minimise the cost of failure. Reduce the time you spent on building and shipping an MVP. So you can spend time tweaking and iterating and shipping again in response to clients' feedback.

Use things like paper prototypes. Don't build the whole future.

Ship it → Prove it → Tweak it... and back to Ship it again!

Roll to a small % of customers. Test and measure. If it's OK, roll to more. If not, adjust and roll again.

Concept: the MVP LOOP, while you finish the idea.

The investment won't go down to 0, because there's maintenance costs, etc.

The lesson of Spotify now: shipping in a rush, without the right data, wrong assumptions, a lot of investment that resulted in losing customers, and not knowing why.

Think: what is the purpose of these documents? It shouldn't be for the sake of process.

Why should you document?

To create a common understanding on the team. Concept: the wall of common understanding. Everyone in the team should know about this. E.g. containers and tech stack, components, other essentials. What you explain to new timers and stake holders and doesn't change often.

To surface and understand complexity === things that aren't trivial, but are critical. More like text + graphics than a wall of text. Creating docs like this help you check you're not creating unnecessary complexity.

To build "widget kits", to explain things later. It's very useful for things with lots of history, it can be used to have conversations about the software.

To create empathy

between decision makers and developers. Brings tech requirements to discussion. Empathy driven development. Working without docs is anxiety producing.

between product people and developers. Explain the logic behind product decisions, and surface rules behind decisions.

between your developers, and other developers. Explain past architecture decisions for the future. It's otherwise hard to explain past decisions. You don't want to blindly follow a path that was set before by someone without explaining why. An example of how to do this: keep simple markdown files with the status of the decision, and the consequences.

This is where lead developers bring value: look up for those moments: will this be hard to change in the future? But describe the problem, not the solution. E.g. "we want to improve repeatability" vs "we installed a test runner".

To encourage creative problem solving. Two sides of the brain - different ways of thinking about problems. Concept: solving problems on the "back of the napkin" (Dan Roan). "The hand is mightier than the mouse". Once you solve the problem, throw the picture away.

A reluctance to document prevents you from "napkin viz", and this prevents you from solving your problem.

Question: how do you keep documentation up to date?

You can generate diagrams automatically but they aren't normally useful

Anything not necessary to keep the software running will be eventually out of date.

Document as little as possible.

Make it visible. A wall, a readme for newcomers.

Include it in "rituals" (weekly refresher of docs, etc)

Create ownership through collaboration: not just one person writing docs.

Do something your future self will thank you for.

Mathias Meyer - Building and scaling a distributed and inclusive team

How they're building a diverse distributed team at Travis CI

A push for remote helped increasing diversity, by hiring from different backgrounds. But there are two challenges: communication and culture.

Communication challenge

They use

github

slack "good morning!", plus lots of channels for cats etc

google docs

little email, not by design--it just happened organically

In slack, they have 'Chat Ops'. Channels for deploying: you can deploy software by talking to a bot. This:

increases visibility

reduces barrier for junior developers: no need to learn new tooling, if they already know slack

In GitHub

they track discussions in open issues.

hand off between timezones ("when Europe goes to sleep hand off to the US")

issues are used for onboarding: an issue with tick list for the first week. Each new joiner has an outline of what is going to happen.

used as "procurement" e.g. conference requests etc

This creates visibility, rather than emails. The problem is they have lots of repositories, and can be hard to follow. They try to keep things in issues, rather than emails.

They have a "how-we-work" repository to discuss salaries, diversity, etc. Concept: it would be "continuous integration for company culture".

Concept: Inclusive decision making.

Book: "the open organisation". Hear as many perspectives as possible. You benefit from diverse participants. It takes longer, and some discussions are never fully done (... like software).

Concept: distributed teams incur a tax on communication.

Put offline discussions into writing.

Book: "Turn the ship around" by David Marquet. Don't move information to authority, move authority to the information. People need to be able to make quick decisions without waiting for approval.

Less oral communication means more accidental documentation.

Concept: distributed facetime.

Monthly all hands (it's a Hangout)

Continuous improvement talks every ~2 weeks (instead of brown bag lunches). People attend if they are interested in the topic.

Don't attribute to stupidity or malice what is explained by a simple perspective (i.e. you may be missing context)

YMMV

Sabrina Leandro - Big rewrite strikes again

Lessons from big rewrites: big learning is "how not to need a big rewrite again"

Why does code need rewriting? The only "done" code is the code that is not in production anymore

over engineered

slow tests

not enough tests

not structured

Sarah Mei's code that is like "the hoarder's house" - no space to do things

"If only I could throw it all away"

Is this the right time to rewrite?

Invest in maintainability, but find the right time. Does the product have business value today?

Find the business case in rewriting. If you can't, you just want to experiment and learn, so maybe find something else to learn on. Look for business value with stakeholders, product owners, clients...

A good reason can be "easier to onboard"

Sell the rewrite. Have a one clear business case:

how will the world be after this is finished

find allies outside team

make pain visible, with graphs or metaphors

do repeat yourself (clear message) each time you talk to different people