The game for modern software development has moved on. We are no longer building systems that simply automate previously manual processes as we did at the beginning of the software revolution. Now we create new businesses, new industries. We revolutionize existing markets and create entirely new ones.

The organizations that succeed at this don't look the same — or operate in the same ways —  as more conventional firms. They are different and approach software and the role that it plays in an organization differently.

So, what does "Digital Disruption" really mean for the organizations that practice it and how do they use speed and efficiency as a tool, rather than just a cost-saving measure?

IT is no longer merely a "Support function" it is the business model.

How can you accelerate your journey in becoming a Lean Enterprise? What are the key aspects to consider when you start? What are the tools and techniques to use? How do you organize to make a meaningful business impact?

In this talk, Barry O'Reilly shares his lessons learnt from client engagements since the publication of Lean Enterprise: How High Performance Organizations Innovate At Scale. He showcases how he has helped enterprises rekindle their capability to explore, experiment and embrace continuous improvement.

He highlights the key issues holding organizations back from unleashing innovation, and demonstrating the countermeasures to achieve high performance at scale.

When the requirements change out from under your tech team, your code has to change. So it’s worthwhile to build your skills in assessing code maintainability, deciding whether to refactor, and doing the refactor.

In this talk, we’ll answer questions like:

• What does it mean for code to be maintainable, and how do we make code more maintainable?
• How do we know when to refactor — and how do we know when to stop refactoring?
• How do we sell stakeholders on giving us space to make a large refactor?

This talk includes both code samples and architecture samples from apps in use today.

We often think about speed and danger as being closely related, but we now have empirical proof that faster, smaller releases tend to cause fewer outages and less downtime for our software systems. How can we take that understanding and use it to build systems that allow for the fallibility of humans and systems? What makes speed safer, how can teams support each other with successful failures, and why do we hold to superstitions about control when we have proof to the contrary?

Continuous Delivery requires that we are able to deploy broken code into production without negatively affecting anyone, but how do we make that change in our beliefs and our teams? This talk is for anyone struggling with the tension between quality, speed, and accuracy. Audiences will leave with a new perspective on how small and fast a change can be, and how allowing change makes teams healthier.