DevOps Simulation Certified Trainer
Unique opportunity to get trained by the author of one of the most effective DevOps Culture simulation, prepare for DevOps Simulation Certified Trainer exam (DSCT) from CertiProf© and gain competitive advantage in DevOps training marketplace.
First time in India! The latest 2019 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 DSCT 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 DSCT 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.
Outline/Structure of the Workshop
Part 1 - Experience full 4 hours version of the simulation as a participant
30 min - Connection/Game Intro
10 min - Content: "Why" and "What" of DevOps
20 min - Concrete Practice - Simulation game: Part 1 “Feel the pain of the status quo”
20 min - Conclusion 1 : Debriefing the experience. Why do we need to change?
10 min - Content - Core DevOps Principles: The First Way
- The Theory of Constraints
- Typical bottlenecks in DevOps transformation
10 min - short break
20 min - Concrete practice - Simulation game: Part 2: First steps towards DevOps
- Shift-left on Security - learn about security issues before implementation.
- Build T-shaped skills with cross-training.
- Dev, Ops and Security are no longer silos.
20 min - Conclusion 2: Debriefing with 1-2-4-All Liberating Structure
10 min – Content - Core DevOps Principles: The Second Way
- One-piece flow
- CI/CD, deployment pipeline
- Typical impediment to Continuous Delivery
- Telemetry, Continuous Monitoring
- “You build it, you own it” mindset
20 min – Concrete practice: Simulation game: Part 3: Continuous Delivery of value with DevOps
- Enable better flow with reduced batch sizes.
- Accelerate the feedback loop with simplified deployment.
- Enable environment creation on demand.
20 min – Conclusion 3: Debriefing the experience with Liberating Structures (User Experience fishbowl)
10 min – Content: Core DevOps Principles: The Third Way
- Chaos Engineering
- Safety Culture
- Three types of Organizational Cultures (Ron Westrum)
- Why Psychological Safety is essential in The Third Way of DevOps
20 min - Concrete practice with Fear in the Workplace + Safety in the Workplace card decks
- Practice to recognize symptoms of toxic culture in the workplace
- Learn about individual, team and leadership level psychological safety enhancers effective in changing the culture.
20 min Final Debriefing with 25-10 Liberating Structure.
Key takeaways, what will you do differently when you get back to your workplace?
60 min - Lunch
Part 2 - Learn to facilitate the simulation
Concept: Base, emergent and hidden dynamic of the simulation; how to create safety.
Concrete practice: Introducing the game via Teach Backs, pair-share.
Concept: Room setup and scaling for a different audience size
Concrete practice: Plan your setup, get the feedback from your trainer and learn how each set up will drive new simulation dynamic.
Concept: Tips for Debriefing
Concrete practice: Review "Aha! Moments" post-its collected from participants of these simulations from 15 countries. Practice debriefing.
Concept: Facilitating Fear in the Workplace game
Concrete practice: Experience collaborative, competitive and a one-on-one coaching version of this game
Concept: Your DCST certification exam
Concrete practice: DSCT Mock-up exam with review
Conclusion: Debrief and Q&A
After taking this workshop you will be able to
Facilitate experiential learning of DevOps principles and practices including Continuous Integration, Continuous Delivery, “Shifting Security Left” and the Three Ways of DevOps.
Lead the class participants through a discussion of the power of cross-training, T-shaped skills and collaboration between Dev, Ops, Security and Business.
Highlight the connection between DevOps Culture and Psychological Safety.
Develop capability to effectively prepare and facilitate DevOps Culture Simulation (with Lego and Chocolate game).
Get certified internationally as DevOps Simulation Certified Trainer (DSCT), endorsing the knowledge and fundamental application of DevOps Culture via immersive simulation workshop.
Agile /DevOps Coaches, DevSecOps trainers, IT /Ops Managers and Directors
Prerequisites for Attendees
- Familiarity with Scrum terminology and IT related work experience
- Exposure to foundational principles of DevOps
- Keen interest in helping make DevOps topic accessible to techies and non-techies alike
schedule Submitted 1 month ago
People who liked this proposal, also liked:
Gunnar Grosch - Performing Chaos in a Serverless WorldGunnar GroschEvangelist and co-founderOpsio AB
schedule 1 month agoSold Out!
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!
Prima Virani - Building Resilient Security Log Pipelines with ChaosPrima ViraniSr. Security EngineerOpendoor Labs
schedule 1 month agoSold Out!
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.
Prima Virani - Security Practices for DevelopersPrima ViraniSr. Security EngineerOpendoor Labs
schedule 1 week agoSold Out!
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.
Gunnar Grosch - Building event-driven serverless applicationsGunnar GroschEvangelist and co-founderOpsio AB
schedule 3 weeks agoSold Out!
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.
Todd Little - Feedback Loops are the Key to the Learning MindsetTodd LittleCEOLean Kanban Inc
schedule 1 month agoSold Out!
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.
Todd Little - Exploring Little’s LawTodd LittleCEOLean Kanban Inc
schedule 1 month agoSold Out!
Little’s Law is an elegant explanation of the relationship between throughput, WIP, and cycle time. In a stable environment it gives us a good understanding of the performance of the system. In this workshop we explore Little’s Law through theory and the experience of simulations. You 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 we will experience why estimation of individual items is often not necessary in an environment where Little’s Law applies.
Ralf Westphal - TDD 2.0 - Situation-Aware Programming
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.
Ralf Westphal - Slicing - Requirements Analysis with the Developer in Mind
Starting software development from use cases and user stories sounds great. You get a more structured view of requirements and you get a less pseudo-accurate deliverable to transform into code.
Unfortunately neither requirements description was invented with developers in mind. Because neither comes with a mapping to code and its structures. Sure, it's just requirements, not designs. But still... How to move on towards code from a use case or a user story? The developer is pretty much left alone with that. Also requirements easily get dissolved in code like sugar in a cup of tea: the code's capabilities are increased, but there is hardly a link to the specific requirements. That leads to waste of all sorts and negative effects: meetings, overengineering, bugs, conflicts, false promises, overconfidence...
What makes developers happy, on the other hand, are scenarios like they get presented in coding dojos: clear, focused, close to code.
In my talk I'll present a lightweight, framework rooted in Agile thinking for processing requirements from broad/comprehensive to narrow/detailed in a way so that the subsequent creation of designs and code is well supported. You'll learn simple criteria for "good" requirements - and what to do when they are not "good" (yet). And you'll get acquainted with a "language" you can use with users/POs to drill down into requirements while getting hints for design and implementation. This is satisfying for both sides: developers feel valued with their background leading the process and produce tangible starting points for further development, users/POs feel understood and guided through a process of incremental refinement of their ideas.
Requirements engineering is a vast subject. But in the end it all boils down to: Does a developer understand where to start implementation or where to change code? And maybe even, how is incremental software development possible?
Use cases and user stories might be a good starting point, but their shortcomings in programmer guidance should be compensated. Users/POs and developers need to meet on eye-level.
Devdas Bhagat - How Spilgames migrated to the cloudDevdas Bhagat
schedule 1 month agoSold Out!
BeginnerSpilgames 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 contuinity, refactoring infrastructure, and the state of the systems today
Joanna Tivig / Peter Monkhouse - Shoot for the stars. Let Product owners rocket your productsJoanna TivigAgile Transformation LeaderJC Global PartnersPeter MonkhousePrincipalMonkArt
schedule 4 months agoSold Out!
In today’s challenging workplaces, organizations need to continuously focus on value delivery. Challenged by competition from all over the world, changing technology, increased diversity of the workplace and customers, organizations have to be agile. They need to adapt their products to these challenges to survive. But who is responsible for products? Product Owners. In this session we will explore key skills of successful product owners, how they link products to strategy, and which tools to use to be successful. This will be done using real life examples and applied exercises.
Ralph van Roosmalen - TeamsRalph van RoosmalenManagement 3.0 Facilitator & Agile Innovative EnablerAgile Strides - Coaching & Consultancy
schedule 1 month agoSold Out!
"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.
Ralf Westphal - How to Overcome the Addiction to so Called "Technical Debt"
Why is the fight against technical debt such an uphill battle? Why is it so hard to nip technical debt in the bud or at least keep it much better under control? If after so many years of the metaphor circulating around in developer circles little has changed, there seems to be an underlying unresolved issue.
This talk is dedicated to uncovering an inconvenient truth: There is no such thing as technical debt in the first place. Hence fighting it is like fighting against non-existing windmills.
But what about the deficient code situation the term is referring to. Isn't that all too real and painful? Yes, it sure is. But it should not be called a debt, because it does not accumulate like a financial debt which the term technical debt is alluding to. Rather it's a mess, a mess like that created by any addict.
Managers and developers thus don't need to learn to manage just another form of debt. Instead, they need to sober up. They need to get clean. They need to recognise what's happening in everyday software development under deadline pressure as what it is: the behavior of addicts.
In my talk, I will contrast the signature aspects of debt and addiction. It will become clear and will be supported by the audience's own experience why debt is the wrong metaphor and addiction is a much more fitting notion. And then I'll talk about interventions. How to climb out of the bottomless hole of addiction and get on the track of longterm high productivity.