AATC - Gamifying DevOps with Lego and Chocolate Game
•Télécharger en tant que PPTX, PDF•
3 j'aime•1,047 vues
New version of the game, facilitated at Agile Alliance Technical Conference 2017.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à AATC - Gamifying DevOps with Lego and Chocolate Game
Similaire à AATC - Gamifying DevOps with Lego and Chocolate Game (20)
Plus de Dana Pylayeva
Plus de Dana Pylayeva (20)
Dernier
Dernier (20)
AATC - Gamifying DevOps with Lego and Chocolate Game
- 1. Gamifying DevOps with LEGO and Chocolate Game Dana Pylayeva
- 2. Turn and Talk What’s your name? What’s your current role? DevOps with LEGO and Chocolate Game
- 3. Co-organizer FounderAuthor Agile Coach, CSM, CSPO, CSP, TBR-CT Dana Pylayeva @DanaPylayeva dpylayeva@gmail.com Introduction to DevOps with Chocolate, LEGO and Scrum Game NYC Scrum User Group Play4Agile North America Agile Coach Camp US 2017
- 7. Treplan Tarch review T tech debt Tretest Trework Trebuild Trefix Trollback Tre- release Goals Misalignment Leads to a Low Trust Culture Source: Lee Reid http://devops.com/2015/06/22/the-simple-math-of-devops/
- 8. Source: Puppet Labs: State of DevOps Report 2016 DevOps: Increased Speed
- 9. Source: Puppet Labs: State of DevOps Report 2016 DevOps: Increased Stability
- 11. What’s Your Favorite Definition of DevOps?
- 12. My Favorite One “A mix of patterns intended to improve collaboration between development and operations. DevOps addresses shared goals and incentives as well as shared processes and tools.” ~ Michael Hüttermann
- 13. 2017 - No Longer For Unicorns Only: Macy’s, Nordstrom, GE Capital, Disney, US Department of Homeland Security, IBM, Microsoft, Barclays Capital, Capital One, Target, Walmart… 2009 2011
- 15. DevOps Transformation Game Plan Sprint 1: Feel the pain: Cyclical Value Delivery with Scrum. Sprint 2: First steps towards DevOps. Sprint 3: Continuous Value Delivery.
- 16. Pick Your Role and Meet Your Team
- 18. Some Players Will Get Special Instructions. These Will Modify the Game!
- 19. Q: Will I need to ask Benjamin Business what needs to be built? A: Yes. He knows what sells best on the market.
- 20. Q: I am a developer. Can I just start building? A: No. You need a development environment. Ask Adam Admin to build it for you.
- 21. Q: What is the Definition of Done? A: 1. One LEGO Animal. 2. One number label. 3. One candy. 4. Package is closed.
- 22. Q: This PBI is Done. Can we deploy it? A: Not so fast! Robert Release needs to package it for deployment. Sara needs to run a security scan.
- 23. A: Benjamin Business will pay for products delivered and accepted in production. Q: How will we get paid?
- 24. Sprint 1: Cyclical Value Delivery With Scrum • Dev and Ops are separate teams • Sys Admin controls release schedule • Security tests are at the end of the Sprint
- 25. What Have You Observed in Sprint One?
- 26. Ready for DevOps? Where Do You
- 28. Typical Bottlenecks in DevOps Transformation 1. Environment creation. 2. Large batch size code merges. 3. Code deployment. 4. Test setup and run. 5. Overly tight architecture. 6. People unwilling to change.
- 29. Fix your worst bottleneck first! “Any improvements made anywhere besides the bottleneck are an illusion.” Gene Kim, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
- 30. Dev Ops Invite Operations Into Your Teams
- 31. Sprint 2: First Steps Towards DevOps • Invite Operations into your teams. • Build T-shaped skills with cross-training. • Start automating environment creation.
- 33. Split Work Into Smaller Batches
- 34. Simplify and Automate Your Deployments
- 35. Sprint 3: Continuous Value Delivery • Anyone can create an environment. • Enable better flow with reduced batch sizes. • Accelerate the feedback loop with simplified deployment.
- 36. What’s Next?
- 37. Pursue Further Feedback Loop Amplification 1. Telemetry – implement, collect, make visible to all. 2. On-call rotation – involve developers and architects. 3. Have developers initially self-manage their production servers.
- 38. Experiment and Practice to Reach Mastery
- 39. Would you like to facilitate this game in your organizations?
- 42. Links and Credits 1. https://www.getchef.com/blog/2010/07/16/what-devops- means-to-me/ 2. https://puppet.com/resources/white-paper/2016-state-of- devops-report 3. https://blog.newrelic.com/2014/05/16/devops-name/ 4. http://continuousdelivery.com 5. https://pixabay.com/ 6. http://www.shutterstock.com/pic-151104653/stock-photo- crazy-scientist-young-boy-performing- experiments.html?src=Vq0HbZwnUpigKG9b1ITx_A-1-1 7. http://vectorcharacters.net/
- 43. Level Up +
Notes de l'éditeur
- Welcome to Introduction to DevOps with Chocolate and LEGO game. You are about to participate in the end-to-end gamified simulation of product development. This workshop has been played in 7 countries and has been modified each time based on the feedback. I am looking forward to hearing your ideas and to getting them into next iteration!
- 1:33 Hello everyone, as you walk into the room, please pick a table and ask your neighbor 2 questions. What did you learn? Who at your table is using DevOps practices today? Who is just starting to learn about DevOps?
- 1:34 My name is Dana Pylayeva, I am an agile coach at HBC digital. Based in NYC, The game you are about to play was inspired by The Phoenix project as well as my own experience being on both side of the Wall of Confusion. First as a Java developer and later as a DBA manager.
- 1:35 How many of you have heard the term “Wall of confusion“ – Coined by Andrew Shafer, this term refers to common misunderstandings between dev and ops in traditional organizations. These include goals misalignment, tooling and processes.
- 1:36 Let’s look closely at what happens in a typical development organization. Typical dev organization is using Scrum. Scrum team is focused on delivering features faster. At the ends of each sprint they are expected to deliver potentially shippable increment of the product. They are throwing it over the wall and start the next sprint. What happens to it afterwards, is not their concern – they are DONE! Scrum Team – Focus on Delivery and Speed
- 1:37 What do we have on the other side of the wall? Life isn’t pretty – escalation procedure, on-call pager duty, monitoring – everything to ensure that current systems that generate revenue are stable, have adequate throughput. Operation team is focused on keeping the lights on. Operations resist change, they know, when all these increments accumulate in It operations, they can cause deployment issues and lead to post-deployment fires in production. Ops Team – Focus on Stability and Reliability
- 1:39 Why do we care about trust? Because in it’s absence we tend to introduce extra validation steps for each hand-off in the value stream. It doesn’t have to be this way!
- 1:40 According to 2016 State of DevOps Report by Puppet Labs, organization that use DevOps practices are able to achieve both – increase in speed and increase in stability.
- 1:41
- 1:42
- 1:43
- 1:45 DevOps movement came a long way since 2009. 2009 – 10 deploys per day at Flickr 2011 – 11.6 sec over 7 K deployments per day 2016 – Information from DevOps Enterprise summit. – all these companies are implementing Devops practices now and accelerating their delivery of services. And if the Department of Homeland Security can do it, so can you! Let’s get some experience with DevOps transformation by playing a close-to real life DevOps transformation RPG
- Inspired by The Phoenix Project and The Goal, this game will let you experience 3 sprints in the life of development and operations. We will simulate the flow of work through the enterprise, relationships between Business, Development and Operations and demonstrate the benefits of moving from cyclical to continuous delivery of value. Welcome to Chocolate and LEGO Enterprise. All of you are new hires now and will be introduced to your new roles. We have 3 development teams in organization, each of them is using Scrum framework. Who is familiar with Scrum? We have one operations team, one security team and one business team. Our organization makes money by building LEGO Animals and selling them to the market.
- 1:46 – 1:47 Please open the bags on your tables, take out the roles package and pick a role for yourself. Take 2 min to read about your role
- How do we know what and how much to build? Business team will determine the market demand – what animals are popular and how much they are willing to pay for those animals. Market demand is regulated at the Animal Stock Exchange. This is where the animal prices are established and the orders are placed in Sprint 1. Orders can be placed in the increments of the batch sizes. Based on a quality and a quantity of products delivered in Sprint 1, the market demand will be adjusted for Sprint 2. In the first sprint, each order from the market (for example, “5 dogs” or “10 giraffes”) is considered as one story. To generate business value, the story must be delivered to the market in its entirety. Scrum Teams need to be careful to not over produce as business will not purchase the items above desired quantity indicated. Team will work with the Product Owner to determine which story has highest value for the market and prioritize what to work on for the next sprint. ------------------- In Sprint 2, 3 the animal prices will fluctuate during the sprints, hence providing an incentive to the teams to deliver products to the market faster. Any quantity delivered by a team over the desired quantity number is counted as negative ( company will not be able to sell it = waste) Team will work with the Product Owner to determine which story has highest value for the market and prioritize what to work on for the next sprint.
- Finish at 1:52 Business will have a set of play money to be used for “payment” for accepted animals.
- 1:52 – 2:07 ###Sprint 1 In the first sprint, each order from the market (for example, “5 dogs” or “10 giraffes”) is considered as one story. To generate business value, the story must be delivered to the market in its entirety. Team will work with the Product Owner to determine which story has highest value for the market and prioritize what to work on for the next sprint. **Operations team** is a functional silo team in Sprint 1. Ask your **Security Engineer** to pick three random numbers between 1 – 20. These will be security bugs. When Scrum team is ready to deliver products into production, **Security Engineer** will “run the security scan”. If a product has a label with one of the three selected numbers, it will need to be returned back to a development team. **Release Engineer** will need to package features delivered into a deployment package and deploy them into production (place the small packages into a ZipLock back, write team name with a sprint number and deliver it to market analyst's table) At the end of the Sprint 1, participants will discover that deployments are not allowed until the next deployment window. Everything that scrum teams built is now stuck in the queue in Operations department and no value gets delivered to the market. In the Sprint 1 retrospective, **Scrum teams** will look at optimizations they can apply to their current process and the constraints that impede their productivity. ###Potential improvements 1. Invite **Sara Security** into the Scrum team. 2. Solicit an early feedback from the **Market**
- 2:07 – 2:12 How was your experience? Scrum Teams, how many product backlog items were you able to get done? This is great! Why are the customers unhappy? Did you get any product delivered to you? It took a long time to start – getting the stories, building environments… Then security testing at the end caused delays and rework. Then what happen – team built potentially shippable products, but wasn’t able to deploy due to the code freeze. They are getting no feedback. Why do you think there IS a code freeze? This is a function of deployment process being manual, brittle and potentially causing service disruption. With the Water-Scrum-fall it gets expensive to deliver changes and making them live in production. One of the advantages of embracing DevOps , is that you are able to re-define that!
- There is more than one entry point into DevOps world and all of them will require changes in technology, people, process and culture.
- Start with visualizing your flow. Get a better understanding of how a value delivering planned work moves through your organization. Learn to optimize that. Understand where unplanned work causes the most disruption and how you can minimize it’s impact. Think about all the places were you may have non-value added work and your biggest constraint.
- End at 2:17 Bring in Operations into your team! They know how your system runs in production, what are some of the challenges it is having. Leverage that feedback to make it more resilient #1 How many of you are familiar with Conway Law – Architecture of the system reflect the structure of organization. By making the structure of org and team more open and collaborative we are positioning ourselves better for improving the architecture of our systems #2 Enable everyone in the team to be a generalist – cross-train, build T-shaped skills
- 2:17 – 2:18 – explain X-training 2:18 - 2:33 – run the sprint
- Was this better? 2 min
- Rather than coming up with a bunch of features and planning a multi-month release, come up with new ideas continually and try them out individually on users. With enough thought, even big features or large-scale changes can be implemented as a series of smaller steps to get faster feedback, with the ability to pivot and course correct if needed. With a cross-functional team working to deliver these small increments in hours or days, you can be more innovative than your competition and maximize your return on investment
- With Continuous Delivery your software is always release-ready, yet the timing of when to push it into production is a business decision, and so the final deployment is a manual step. Ultimate feedback that we are looking for is the feedback from our end-users. Manual and infrequent deployments significantly reduce our opportunity to receive this feedback. Important step in your devops initiative will be environments standardization and automated provisioning. The idea is making things self-service so that everyone in the Scrum Team can build an environment, provision and deploy.
- Start at 2:38 – 2:52
- Shared on-call – everyone gets upstream feedback on architecutural or coding decision they’ve made
- Blameless postmortem and share learnings (Morgue) Inject failure to test resilience “Human error is the consequence of the design of the tools we gave them” Dr, Sydney Dekker