This talk is a case study of our architectural evolution over the last 2 years.

Our start-up had licensed a customised warehouse management system in order to demonstrate our innovative new business model. The WMS had a traditional 3-tier architecture based on Java and SQL server, and was lightning fast with most of the business logic encapuslated in stored procedures.

Out our start-up we needed to be able to "test and learn" - ie rapidly develop and deploy new features and test them in the market with our customers. Based on the feedback we would identify tweaks to the business model, and fine-tune the functionality that our customers wanted.

We had a launch date 5 months in future, a need to scale rapidly, growing the team from 2 devs to 20 within 8 weeks. And we needed to be able to work in parallel on multiple features. Whilst ensuring that the application was secure, performant, and reliable.

The answer, according to a bunch of experts, was to adopt microservices.

Three years later, we have a suite of secure, scalable, and resilient applications running in AWS. We deploy to Production multiple times a day, and our MTTR is less than 30 minutes.

And we have Services. Some of them are "micro".

But reflecting on what we learned in that period, there are a lot of things that we wished we had done differently.

In this talk I'll walk you through the evolution of our architecture, explain some of the choices, and highlight what we learned, and discuss what we would do differently if faced with the same decisions today.

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.

This talk is a case study of our architectural evolution over the last 2 years.

Our start-up had licensed a customised warehouse management system in order to demonstrate our innovative new business model. The WMS had a traditional 3-tier architecture based on Java and SQL server, and was lightning fast with most of the business logic encapuslated in stored procedures.

Out our start-up we needed to be able to "test and learn" - ie rapidly develop and deploy new features and test them in the market with our customers. Based on the feedback we would identify tweaks to the business model, and fine-tune the functionality that our customers wanted.

We had a launch date 5 months in future, a need to scale rapidly, growing the team from 2 devs to 20 within 8 weeks. And we needed to be able to work in parallel on multiple features. Whilst ensuring that the application was secure, performant, and reliable.

The answer, according to a bunch of experts, was to adopt microservices.

Three years later, we have a suite of secure, scalable, and resilient applications running in AWS. We deploy to Production multiple times a day, and our MTTR is less than 30 minutes.

And we have Services. Some of them are "micro".

But reflecting on what we learned in that period, there are a lot of things that we wished we had done differently.

In this talk I'll walk you through the evolution of our architecture, explain some of the choices, and highlight what we learned, and discuss what we would do differently if faced with the same decisions today.

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.

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 12 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.

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.

Having kids was a bit of a shock! Twins more so. 

I was totally unprepared for becoming a parent and worried that I would be terrible at it. how to raise strong resilient considerate kids who could grow and prosper in today's rapidly changing world.

In particular, I was worried that I didn't know how to raise strong resilient considerate kids who could grow and prosper in today's rapidly changing world.

My solution was to buy a bunch of child raising books and do some research. I read a lot of books, (most rubbish), and discovered a few that were incredibly useful.

I noticed that the ideas in the books were applicable to building high-performing teams, and started applying the ideas at work during my 1:1s and coaching and mentoring sessions.

What I found was that applying these techniques meant that the teams became more flexible and resilient, and were able to deal with change more easily. They could self-diagnose issues in the team and had a set of tools for addressing clashes or personality conflicts.

In this talk I will present three models for understanding behaviour, active listening, and taking responsibility, that I lifted from the child-rearing books.

I'll talk through how to apply them in a work context and give some examples of what happened.

Ideally from this talk, attendees will hear a few ideas that will make them better leaders - especially for organisations which don't have a command and control structure, and where leadership comes through influencing and coaching in a flat agile orgainsation.

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.