The principles of chaos engineering have been battle-tested for years using traditional infrastructure and containerized microservices, but how do they work with serverless functions and managed services? In this session we'll cover the motivations behind chaos engineering, how we perform chaos experiments, what some of the common weaknesses we can test for in our serverless applications are and run some actual experiments in a serverless environment. Join as we move from talking about principles to performing real chaos engineering experiments for serverless!

Unique opportunity to get trained by the author of one of the most effective DevOps Culture simulation, prepare for DevOps Culture Certified Trainer exam (DCCT) from CertiProf© and gain competitive advantage in DevOps training marketplace.

First time in India! The latest 2020 version of this popular simulation (ran at 45 conferences in 15 countries).

This train-the-trainer workshop will prepare you for many successful facilitations of DevOps Culture simulation and give you access to the licensed training material (PowerPoint slides, handouts, flipcharts design etc). You will learn to run effective debriefing with your groups and help them connect learning from the simulation with solutions to the real-life challenges in their organization.

The simulation is designed for a broad audience, enabling participants to gain the insights into the “Why” and the “What” of the DevOps before jumping into the “How”. Through this powerful role-based simulation, participants experience the benefits of cross-training, learn to eliminate silos, "shift left" on security, adopt systems thinking and practice optimizing the flow of value from business to development and to IT operations.

Become one of the DCCT holders - DevOps change agents who are able to create the DevOps Culture simulation experience, providing participants with additional insights into taking the next steps to embracing DevOps mindset and leading organizational change. Guide your workshop participants through the experiential discovery of the following practices: optimizing flow, amplifying feedback loop and growing safety culture. Deliver real-life examples from medium to large size organizations, latest findings from the State of DevOps report and key ideas from “The Phoenix Project” by Gene Kim.

This unique simulation uses cognitive neuroscience principles, game design theory and elements of “Training from the Back of the Room” framework.

Learn from the game creator, prepare for DCCT exam from CertiProf© (included in your registration) and help make DevOps culture experience accessible to all – business stakeholders, C-level executives, IT management, techies and non-techies alike.

In this talk, we utilise the tools of Functional Programming to provide robust and resilient software components. We start off by defining Functional Programming and investigate how this itself can improve the quality of software. Once we have committed to programming in this style, we explore some of the tools that naturally arise. These tools will be explored using a variety of programming languages, since these techniques are available in many popular programming environments. Some examples will also introduce Haskell syntax.

1. Using static types to provide a reliable indication of the behaviour of software, including up to proof of correctness. We will use the technique of parametricity to demonstrate this reliability[^1].
2. Using property-based testing for high coverage testing with minimal programmer effort.
3. We will also have a look at the trade-offs that are made between types and tests and discuss a reasoning framework on making optimal decisions on when to use each.

[^1]: Wadler, Philip. "Theorems for free!." FPCA. Vol. 89. No. 4. 1989

At the core of the agile mindset is learning. Continuous learning is only possible through active feedback loops. Linear approaches do not support learning and are doomed to fail in a world of uncertainty. The key is maintaining healthy feedback loops which incorporate new knowledge which enables learning leading to success. An iterative approach with broken feedback loops is similarly doomed.

From Todd’s background as a Chemical and Petroleum engineer the idea of feedback and control loops was natural and to a large extent how he got involved in the agile community. Todd will explain the basics of feedback loops and how they can enable agility and learning, or when broken they can destroy agility and enable other behaviors such as organizational politics.

This workshop covers Knative, Kubernetes-based open-source platform to deploy and manage modern serverless workloads. It provides a set of middleware components that are essential to build modern, source-centric, and container-based applications that can run anywhere: on-premises, in the cloud, or even in a third-party data center. Knative components are built on Kubernetes and codify the best practices shared by successful real-world Kubernetes-based frameworks.

Each of the components under the Knative project attempts to identify common patterns and codify the best practices shared by successful real-world Kubernetes-based frameworks and applications. Knative components focus on solving many mundane but difficult tasks such as deploying a container, orchestrating source-to-URL workflows on Kubernetes, routing and managing traffic with blue/green deployment, automatic scaling and sizing workloads based on demand, and binding running services to eventing ecosystems.

The workshop goes into details of how Knative enables you to focus just on writing interesting code without worrying about the boring but difficult parts of building, deploying, and managing an application. It shows how developers can even use familiar idioms, languages, and frameworks to deploy any workload: functions, applications, or containers. We also touch upon Cloud Run (a managed Knative offering) and software architecture patterns for modern serverless applications.

DateTime: This workshop is scheduled on Oct 17th from 9 AM to 1 PM IST and 18th from 10 AM to 12 PM

For the last few years, I have been diving into what Collaboration really means. I have been collecting stories and examples and discovering patterns across our industry.

In this session, I walk the room through a Collaboration workbook where participants think about Collaboration via a series of different lenses. We will ask ourselves what collaboration means to us, and share our stories of great collaborations we have been a part of.

I will also share aggregated data from my research and share my own insights.

Little’s Law has been used in queuing theory for over half a century. It is an elegant explanation of the relationship between average throughput, Work in Progress (WIP), and cycle time. In a stable environment it gives us a good understanding of the performance of the system which can used for forecasting.

But where are the story points and estimation? Certainly, size must matter. But does it? In this workshop we explore Little’s Law through theory and the experience of simulations. Each attendee will come away with a better understanding of Little’s Law and the core assumptions necessary for it to be applicable and useful in forecasting. Through the simulation you will experience why estimation of individual items is often not necessary in an environment where Little’s Law applies.

How do you allow teams the freedom to pollute the data lake, and protect the security, privacy, sanity and usability of data?

Giving teams the power to choose what they measure means giving them the power to drive org-wide changes.

Gatekeeping through Data engineering is too slow and centralized.

Totally DIY, you can't control costs, privacy or integrity.

This talk will cover both the organizational and technical structures we use at Grofers to enable agile data governance and analytics in a team of over 300 in tech and analytics.

Effective organizational security is a shared responsibility and yet, a big number of organizations suffer from testing security issues at the last minute or not at all. In this talk, we discuss secure best coding practices for developers to improve an organization’s security posture.

Chaos Engineering is an up and coming method used by SREs for autonomously introducing random failures into a system and measuring whether the service degrades or fails. This talk discusses how security teams can use Chaos Engineering principles to develop, test, and maintain resilient log pipelines.

Mangle is an open-source project that enables you to run chaos engineering experiments seamlessly against applications and infrastructure components to assess resiliency and fault tolerance. It is designed to introduce faults with very little pre-configuration and can support any infrastructure that you might have including K8S, Docker, vCenter or any Remote Machine with ssh enabled. With its powerful plugin model, you can define a custom fault of your choice based on a template and run it without building your code from scratch.

In this workshop, you will learn how to inject faults on infrastructure and on a running Java application.

Chaos Engineering is the discipline of experimenting in a distributed system to identify the weakness in the Architecture and Design of a system which helps in building the resiliency to attain High Availability. Kubernetes being a de facto standard for container deployments and orchestration the applications running on Kubernetes platform should be highly available and resilient to failures.

In this talk will walk through a real-time use case of how we encountered an issue with Kubernetes platform that impacted applications running on it and we built resiliency for it. With Nodes and Pods being ephemeral in Kubernetes there are high chances for application users/clients to get network connection errors, such as 5xx in case of HTTP requests, when a node restarts or a pod gets terminated and how we resolved it.

There are many tools available that create chaos in Kubernetes. This talk covers about the need to do chaos engineering in Kubernetes based on the use case discussed and how it can be done.

This workshop will first introduce Functional Programming concepts using the Haskell programming language syntax and tools.

We will then present a series of exercises that utilise the static type system of Haskell and with some guidance, solve the exercises. Subsequent exercises will introduce property-based testing using the hedgehog library. Finally, we will tackle some exercises where a trade-off must be considered, and solve those using both types and property-based tests.

The focus of this workshop will be on introducing the tools for achieving software resiliency and robustness. The techniques learned here may be applied in other programming language environments.

DateTime: This workshop is scheduled on Oct 12th and 13th from 1 PM to 5 PM IST (4 hours each day)

Serverless applications are usually made up of functions interacting with fully-managed services, so you can develop applications without having to think about servers. This enables us to build applications that scale quickly and reliably based on incoming requests, often in the form of events that go well beyond API requests and scheduled cron job type rules. In the event-driven model, the components communicate with events and that helps you adopt some of the best practices for distributed systems by default. In this talk, we’ll explore what events are, the different types of events available to your serverless applications, where they come from and how to utilize them to build applications that can provide more value to your customers. All of this with a lot of architectural pattern examples.

How do we learn the right thing at the right time and in the most cost-effective way? How do we organise the process, new insides and decision making at scale?

Learning is the core activity in any environment of uncertainty - innovations natural companion and proven by many failed startups and projects. Most managers and teams agree on this but organising, storing and using what has been learned is often a challenge. We will be exploring the fundamentals of how to tackle this issue and make learning more manageable, transparent and shareable. We will explore what it means to gather relevant data in the most cost-effective and fastest way. With the goal to enable decision making in an information-poor environment.

Report Cards are an essential tool for any innovation team that wants to take learning and innovation management seriously. As such many different report cards are in fluctuation. You will be leaving this workshop knowing what the essential parts of a report card are and why. You will use it on a problem yourself to maximise your learning.

Elijah assisting organisations with their Innovation Practice, Management and Strategy.

Spilgames went all in to public cloud in 2018. At that point, there were no example of actual migrations, just a number of business studies showing the benefits of public cloud. This talk covers the business reasons of why we went into public cloud, the IT side of the migration including business continuity, refactoring infrastructure, and the state of the systems today

Product managers and software developers often have different ideas of what Agile is and can be. There is also a strong bias in the Agile industry to treading the known territories of the past over innovating and improving towards better.

In today’s session we play a game that challenges us to think differently about what agile is and can be. We want to show you different ways of working and generate ideas that you can take back to your teams to drive further and better improvements.

Things you will learn from this session;

• Is Scrum a best Practice?
• Are estimates waste?
• Do we know what value looks like?
• How does improvement happen on teams?

We are going to play a game.

In this game we are going to pitch Scrum teams against other non-scrum teams and see who can do a better job of delivering customer value early and often. Come along and learn something new about how systems and frameworks help or hinder people’s ability to delivery good outcomes.

Come and join a team. Have fun. Learn something unexpected and be delighted.

The #NoEstimates movement has been going since about 2011 and challenges us to think differently about planning and estimating, and how we organise teams. In 2013 Chris Chapman invested a game to play that investigates the value of estimates and how they can help or hinder us. This game’s pay-off is wider than estimates though and can teach through experience how systems and frameworks help and hinder us.

This game dives into how we interact with systems and processes, as well as estimates, and enables us to think differently about how we act within the governing frameworks our workplaces provide us.

Are you "doing it" the TDD way? Really? Are you getting the results from TDD as you expected? Yes? Great, check out one of the other exciting sessions at this conference.

No? Then: How come? Isn't TDD supposed to be easy? Just do the red-green-refactor dance and all code's gonna be functional plus clean.

Sorry, but I beg to differ. It's not that simple. And there are many reasons for that as I'll show you in this talk.

My main objection is, that TDD as it's commonly explained and demoed, is ignoring the plain and simple reality of problems being of very, very different difficulty. Or have you ever seen a TDD demo beyond the usual code kata exercises like "Fizz Buzz" or "Game of Life"?

Hence in this talk I want to present a bigger picture. I'll classify programming situations according to the Cynefin framework and put TDD in perspective. It will become clear where TDD might be a good fit and why - but also, where TDD is overtaxed.

And since TDD is only a fit for a small subset of problems, of course alternative approaches to test-first programming will be presented.

This presentation is about building a culture for innovation that enables the design and delivery of great products and experiences to customers.

Innovation needs to be part of the entire organisational culture – not concentrated in a single person or hidden away in a dedicated office.

Innovation needs to be everyone’s business.

This happens when leadership gets out of the way and provides employees autonomy to do something different.

This happens when failure whilst innovating is not subject to punishment or humiliation because there is an environment of psychological safety.

Failure is celebrated as an opportunity to learning. Every failure is seen as a step closer to success.

A culture for innovation is one in which there is recognition that constant change is the norm and embraced as the only way to remain relevant in the era of continual disruption.

"Teams are becoming a basic building block for many contemporary business organizations, with one survey finding 68 percent of Fortune 1000 companies using self-managing teams"

- Lawler, Mohrman & Ledford

Our world is getting more complex every day, and change is the only stable factor. It is impossible to solve the problems as an individual. Teams are required to deal with the problems we have to solve. This could be developing new products, serving customers, research new tools, etc.

We all probably worked in a great team once. At that moment we maybe did not realize it but when working in other teams we realized how great that one team was. Great teams don’t just happen. There are many models that can help you to build great teams, and still no guarantee!

In this talk, I address several things that are important related to great teams.

To start with, what is a team? I first want to create a common understanding to make sure everyone has the same view on a team. Just having six people in a room, doesn’t mean they are a team.

Should there be a maximum of six people in a team? Or is it 15 like Dave Snowden writes? Or should it as it is described in the Scrum Guide? We will look at different models and make a conclusion about the optimal team size.

One of the most important characteristics of a team is diversity. Many people think about gender when they talk about diversity. Diversity is much more, in this talk I will describe what makes up team diversity. Diversity has advantages. However, I will also address the disadvantages of diversity in this talk. I will share and exercise that teams can use to calculate their diversity score and help them to increase diversity.

Many organizations and people performed research about what makes great teams. For example, Patrick Lencioni (Five dysfunctions of a team) Google (Project Aristotle) and the Rocket Model. All this research has value, and there is also overlap. I studied different models and combined them into one. Great teams have conflicts, clarity in the team, trust in each other, understand the impact, are Reliable to each other and care about results. I will dive into these six topics and give examples, as also tools and practices to improve the topics.

I will close the talk with the Team Decision Matrix. More and more teams are expected to be self-organizing and are empowered by management to make decisions. However, management would like to know how they make decisions, and the team is often wondering how to make decisions. The Team Decision Matrix describes five approaches to decision making. I will share those approaches with the audience, and also show how they can use this to coach their team to provide clarity in decision making.