• Home
  • /
  • DevOps Forum 2018

The DevOps Institute (DOI) is the premier source for aligning industry standard quality DevOps training and certification services for enterprise IT. The Institute is led by a Board of Regents who will oversee DOI’s offerings in an effort to codify and promote DevOps’ best practices and standards to enable enterprise IT to deliver more value faster to their customers.

Jennifer Thomson is an IDC research director with over 20 years of experience in the IT industry. Jennifer provides insights on the investment strategies and decisions of European enterprises around application development, deployment and testing engagements. Her research explores the new rules for application development and deployment in a digital economy; application modernization strategies; the evolution of QA & testing; and the role of automation, analytics and AI.

Your customers value timely delivery of good quality products and service. Business managers and stakeholders want to make sure that they see progress and get real benefits from the Agile transformations of their organizations. Employees enjoy working in an environment of respect, transparency and balanced workload.

The Kanban Maturity Model is about evolving organizational agility and takes into account these three groups of expectations. It is focussed on managing work (projects and services) and developing a culture of collaboration, customer focus and continuous improvement. It is a guide for change agents, project and service managers and business owners interested in demonstrating meaningful and useful results continually.

In this talk I am going to introduce the KMM and explain the organizational maturity levels based on real world examples. In addition. I am going to share with the participants how we continue the development of the model and what they can expect in the next months. The presentation will be interesting for Agile coaches and practiotioners, Kanban practitioners, project and service managers, business managers and organizational change agents.


Teodora Bozheva is a co-author of the “Kanban Maturity Model: Evolving fit-for-purpose organization” book, together with David Anderson. She has more than 25 years of experience in the field of Software Development. She has personally undergone all the challenges in managing large projects and meeting tough schedules with limited resources. For more than 15 years, she has been providing training and coaching on Kanban, Lean, CMMI and Agile to companies in different industries. With insights and practical guidance, she helps them combine and adjust the methods for their unique contexts to improve their management practices, deliver better products and services faster, and adopt continuous improvement culture.  Teodora is a Co-Founder, and principal trainer and coach at Berri process, a training and coaching company based in Bilbao, Spain.

Test Driven Development seems very much like pure technique, but that’s just because technique is easier to point at than what it really is: attitude. When you lead your teams towards TDD, you need to focus on their worldview and let them use that to build technique. GeePaw explores five essential premises leaders need to understand to guide their teams into full-on TDD.

The Money Premise — We’re in this for the money.

The Judgment Premise — We’ll rely on individuals making local decisions.

The Correlation Premise — Internal quality *is* productivity.

The Chaining Premise — We’ll test mostly in very small parts.

The Steering Premise — Tests & testability are first-class design participants.

Does the idea of continuous delivery seem like a far away dream? Within the grasp of only small companies and new startups? In this session, Nayan will take you through a quick journey of two very large and old organizations that went from painful 6 month deployments to continuous delivery. He will describe some of the key strategies they used and lessons they learned along the way.

What does testing and quality look like in a Continuous Delivery world? Who does what and how? Is there still a need for testers or do developers do all of the testing? Is it really possible to achieve quality when you deploy to production many times each day? What should testers do when there is no time for a “testing phase”? These are some of the questions many in the testing community ask as the software development industry moves toward this new paradigm of design and delivery.

Continuous Delivery is a radical change in the way we build and deliver software and it requires a radical shift in the way we thing about and achieve quality. Join this veteran Agile coach as he shares his experience. In this presentation you will learn what has worked for several large organizations that have made the transition to this new approach.
Join Cheezy as he walks you through his Continuous Delivery World. He will start by building a definition of Continuous Delivery and explain why a company would want to go through such radical changes.  Next he will walk through in detail the three fundamental areas within an organization that must change – Development, Operations, and Product Management.  Not only will he talk about the details of those changes, he will give you the tools necessary to build your own roadmap. Finally he will talk about organizational changes companies can introduce that will make it easier to achieve this goal. If you are curious about Continuous Delivery or are in the process of adopting this advanced form of Agile this is one talk you will not want to miss.

In the days before Agile, programmers were often arrogant. They acted as if a business domain was complicated or messy only because the people in that business were not clear thinkers. So our programmers wrote code for a “rationalized” domain — for the way the world *should be*, rather than for how it is. Then — if they were lucky — the programmers would move on before everyone discovered the good reasons for most of what they’d ignored.

Agile programmers are supposed to be more humble. They are supposed to want to learn the domain — not with the goal of “fixing it”, but so they can effectively collaborate with their customers: understanding what they want, being able to explain alternative implementations in understandable ways, and so on.

Learning a domain is a skill, just like anything else. But it’s not something people are normally taught. Instead, programmers are just dumped into a project and told to learn the domain, somehow.

But actually people have been learning complex and subtle domains for thousands of years. This talk will talk about two ways that they’ve done it — ways that you can apply to your next project.

We build software to create value, value for our customers, value for organizations, value for us.  Getting that value sooner is better than getting it later.  Getting that value at a predictable rate is better than hoping it will show up soon.
In this talk, one of the founders of the Agile Software movement will show us how we build our software will change how we get the value we want.