• Home
  • /
  • DevOps Forum

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.

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.

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.

More details coming soon

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.

More details coming soon

More details coming soon

More details coming soon

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.