This is the story of 15 teams and one monolithic application going from bi-annual releases to fortnightly releases in 4 months time achieving a state of Continuous Delivery.

The reason for that move: the cost and time for testing quality into the software product, and stabilising and releasing the product during each bi-annual release were skyrocketing.

Continuous Delivery involves a long list of technology and organisational changes that you have to apply to the unique circumstances of your organisation. Where do you start?

This is where The Improvement Kata, Value Stream Mapping and Theory of Constraints are helpful tools to choose which changes to apply first. However, because of the short time frame, the plan ended differently and turned into fear mitigation. Which worked wonderfully well.

After this session, you’ll understand how The Improvement Kata, Value Stream Mapping, Theory of Constraints can kick-start a Continuous Delivery program and mitigate fear.

Folks who should attend are anyone involved near and far in designing, creating, testing, deploying and releasing a software product.

Feature branching is again gaining in popularity due to the rise of Distributed Version Control Systems (DVCS) like Git and Mercurial. With DVCSs, branch creation became very easy. But it comes with a certain cost. Long living branches break the flow of the software delivery process impacting throughput and stability.

This session explores some of the reasons why teams are using feature branches, what problems are introduced by using feature branches and what techniques exist to avoid them all together. In conclusion it explores what is exactly evil about feature branching. Which is not necessarily the problems they introduce. But rather the real reasons teams are using them for.

The key takeaway is an appreciation of a different branching strategy and how it relates to Continuous Integration.