Getting Started at a Startup
Start ups have some interesting challenges and conversely some exciting opportunities.
They have a limited runway of cash – this drives an intense focus on delivering value (before the money runs out)
They have no existing culture or processes – there is nothing to undo as they create a new culture
There is no existing code to build upon - there’s no legacy code to deal with, and you produce applications that match what you need to do
There is no set of commonly understood processes – you get to adopt whatever works well and that fits your needs.
This case study talks about the last 9 months of our start-up where we went from “no team, and limited functionality” – to launching a successful and thriving business backed by completely custom trading platform and fulfilment engine.
In the talk I’ll highlight the key trade-offs and decisions that we made as we developed the applications and give some insight as to how we made our decisions. I’ll cover off:
Our first task was to understand our key business risks and to prioritise our backlog to maximise our discovery on the highest risks first. I'll share a very useful technique that we adopted for mitigating the risks, as well as managing the risks if they become issues.
The second major decision was to define our culture, in particular the Delivery team's belief's and practices around agile. I'll cover off our discussions around MTTR vs MTBF, Continuous Delivery vs Continuous Deployment, Monoliths vs Services. As well I'll discuss the ways that we tried to organise the teams so as to leverage Conway's Law, and to enable rapid delivery of value for each stakeholder.
The third major task was to get a common understanding of scope and business needs, and to align that with the external dependencies from the various stakeholders. We used built several incarnations of a (Jeff Patton style) User Story Map to help get alignment on what our MVP needed to be, and to enable our stakeholders to understand how what our Release Plan might look like. The User Story map was continuously evolving, and I'll show three different versions that all served to communicate different information as we progressed the with the build.
And lastly I'll talk through how we built autonomous self-organising teams. In particular I'll show what we did in terms of ensuring that teams had enough context to make decisions. And I'll discuss how important "Trust" is to ensuring that teams can experiment and learn (and fail) as they progress on delivering the outcomes.
The fact that we launched our product in 7 months, was a direct consequence of the trade-offs and decisions that we made. Throughout the talk, I’ll reference the real challenges and complex situations that we faced, and provide some insight into what we built in terms of culture, processes, and teams, that enabled us to be successful.
From this talk the audience should derive a clear understanding of what is different about software delivery in start-ups, get some insight into how to approach trade-off decisions, and understand how to best leverage agile for their organisations. As well, I’ll talk about some of our mistakes, what we learned, and what we wished we had done differently.
Outline/Structure of the Case Study
This is a talk with a reasonable amount of interaction – I’ve structured it to present a trade-off problem – ask the audience what they would do – and then present and contrast what we actually did.
5 mins Introduction & scene setting
25 minutes walking through each major trade-off decision and discussing the choices
5 mins Summary and how to apply these ideas in their own context.
5 mins Questions
The audience should leave the talk with the following clear learning outcomes.
- Clarity in understanding how start-ups are different and need a different mindset and approach to agile software delivery
- Get some ideas of how to get started with a new start-up, or a new project,
- Understand how to decide what are the most important decisions to make first
- In particular, they’ll learn about building team culture, and how to accelerate team cohesion
- Lastly, they’ll learn some new ideas for managing risk, and understand how we successfully used agile practices to manage our delivery risk
People interested in applying agile in their own context, especially those from smaller companies