Definition of Done in the Age of DevOps Intel Agile and Lean Development Conference Piotr Żmijewski May 22 nd, 2014

Executive Summary We will try to find an answer to the following questions: -What does it mean that product/feature/functionality is done? -Is „time to deliver” still the same as it was 10 years ago? -Can I do anything to speed up releases of my product and still maintain the quality of it? -Is there any way I could maximize productivity and collaboration within my team? -Is following „latest and greatest” processes and practices enough to avoid a spectacular failure? If so, why do accidents in space programs happen?

Agenda Introduction Definition of Done DevOps DoD meets DevOps Is a success guaranteed? Conclusion and take aways 3

Introduction Who am I? Why do I speak about this topic? Who am I? Why do I speak about this topic?

Definition of Done: Why should I care? all stakeholders (team members) must share the same understanding on when a backlog item can be considered as "done" required to effectively plan, execute and monitor product development having a clear Definition of Done improves: –collaboration inside Agile team, –transparency of work, –quality of deliverables. 5 Image source: google.com

The definition of „Definition of Done”… DoD is a clear and concise, auditable checklist containing requirements that must be met in order to call iteration/release „complete”. defines scope of work, allows to track progress, brings transparency within team, conditions the completion of features, sprints and releases, is not static (but does not change during the sprint). 6

Definition of Done: Why is it important? Misunderstanding what the „done” looks like may lead to: schedule slips, missed milestones, quality issues, … … project failure  7

When can we say that the work is done? Features developed Code integrated and built Code reviews done Tests written and passing Documentation updated Binaries deployed … is that it? 8

„Time to deliver” Times change… A growing demand for the products to be released faster: once a year once a month once a week once a day once an hour … 9

Can we deliver software faster? „Typical” software delivery process: Main parties involved: 10 PlanDevelopValidateDeployMaintain Dev team QA team Ops team Ops team

„Not our problem” 11

Silo mentality Silos: no feeling of common goal „us” vs „them” limited knowledge sharing communication overhead blurred responsibility 12

DevOps Let’s merge all the disciplines into one team. DevOps = one team that develops and maintains a product for its entire life- cycle. „You build it, you run it.” All team members responsible for all activities: –Develop –Test –Release –Deploy –Operate 13 DevOps Dev QA Ops

Two-pizza teams Team that could be fed with 2 pizzas. Small size (6-10 people) –Engineers –Design lead –Technical product manager –2PTL Self-organizing & self-contained –free to execute relatively autonomously to maximize its „fitness function”, –sets internal priorities, –develops its own best practices, –no need to coordinate across teams. 14

DoD meets DevOps Dev mindset Features developed Code integrated and built Code reviews done Tests written and passing Documentation updated Binaries deployed 15 DevOps mindset Releasable Deployable Upgradeable Reversible Observable Recoverable VSVS VSVS

Do we have a guaranteed success? Is following „latest and greatest” processes and practices enough to avoid a failure? The rabbit story 16

Conclusions and take aways Share the same definition of done among all team members.You need to deliver faster.Break the silos.„You build it, you run it.”There is a chance you're missing something.Keep the rabbit story in mind. 17

Q & A 18