Sure. My name is Dana Pylayeva. I'm a development manager and Agile coach at Rakuten Marketing. I've been in IT for the past 16 years. As you mentioned, in many different roles, starting on the development side and then, by chance, finding myself on the operations side. That really helped me to expand my horizon and actually feel what operations goes through every day when development has already completed their work.
That's what really triggered my interest in DevOps. In addition to that, I'm very interested in gamification and using and designing Agile games and playing them with my team.
It can certainly be because even in the Scrum guide, they call it Rules of the Game. In a way, Scrum is a game. It has certain rules. However, it doesn't limit you from expanding those rules or being more creative. Yes there are ceremonies but you can enhance Scrum for your work, bringing different techniques from other areas. Using Agile games definitely makes Scrum more engaging.
4. How does the game work and what goals do you expect participants in the game to achieve?
The game is a simulation of the entire product development process, all the way from business coming up with the requirements, responding to market demand, on to development teams building a product, building LEGO packages with chocolate. And then having operations team to take care of concerns like deployments, security, also building different environments. There's a lot of material that I'm using in this game.
Specifically, because by using things like LEGO, chocolate, and colorful props, it engages all five senses and studies have shown that when we process information, the more senses we engage, the better we will be at learning.
5. How has the reaction of the participants been so far?
It's interesting because at the beginning of the game, they feel confused. That's the whole point because at the beginning, they show how an organization that uses only Agile in the development side is struggling with delivering products faster to the customers. But as they go through the game, they actually find it really engaging. By the end of it, everyone is very happy. Everyone's excited. A lot of people come afterwards asking whether they can add that game to their toolkit.
6. So in a way, the game helps improve workflow among multiple teams, right?
Yes. That's the focus of the game, really using LEGO and chocolate to visualize bottlenecks in the process and help development and operations work together to improve the flow and get the product faster to the customers.
Okay. The advantage of Kanban is that you really don't have to throw away your previous processes. You can actually apply Kanban principles on top of Scrum, for example, merely by making things more visual. Using Kanban boards, adding WIP limits. Even if it's a Scrum type of framework, you can still use WIP limits.
Your developers are not taking more than one task a time and also restructuring the Kanban board so it's focused on the flow of work rather than people being busy. There are techniques like Scrumban, which kind of merges Scrum with Kanban and this game actually helps to see how you can make a distinction between the cadence of Scrum and the cadence of your release.
By introducing practices like continuous deployments or continuous delivery, you're able to plan [releases]. However, you're able to deliver faster to production.
Yes, absolutely. We all know that in Scrum there is a concept of potentially shippable product increment. Ideally, at the end of each sprint, the team delivers it and it can be shipped. A lot of times, what happens is it doesn't get shipped. Actually stays in operations area and it gets piled up sprint after sprint. Then finally, when it's time to ship, there could be conflicts in the code. There could be potentially even outages in production caused by all these conflicts. Yes, in a way all these potentially shippable increments that don't get shipped, they create deployment WIPs.
Manuel: I guess you end up with a large change in the end which is the accumulation of all the sprint deliveries that were not deployed.
Yes. We're creating bottlenecks instead of helping the work flow.
Yes. It's still the case for a lot of organizations and especially for those that haven't started looking at continuous delivery practices. They struggle because everyone gets inspired by Spotify's example "Think it, build it, ship it, tweak it." But they use all those practices to enable this type of work.
For an organization that doesn't [apply continuous delivery practices], this approach is really creating a problem because for operations, their idea is keeping the lights on. That's the conflict between ship-it-tweak-it and keeping-the-lights-on.
With this game, I'm actually showing how it's not just about starting to ship everything. It's also about bringing those practices and changing the culture of people so they actually start trusting each other. But to build that trust, you need to put practices that enable stability, that enable consistent flow of work and automation of deployments.
Absolutely. This game helps people like management to understand what is DevOps about because it's more difficult for them to get into DevOps concept when the conversation goes around very technical practices. It's not as easy to grasp what is the idea behind [DevOps]. But with this game, it's just a visual demonstration of how things change when you start to plan those practices and transition to DevOps culture.
Sure. One of the approaches, people call it "shift security to the left." Starting to think about security concerns earlier. I attended the session by Judy Neher where she was talking about abuser stories. It's similar to creating user stories for your own functionality. You think at the beginning of your planning process about, "If I'm a hacker, how am I going to break the system?"
By building those stories and bringing attention of the development team to those concerns earlier, you help to speed up delivery and also taking care of security.
I think everyone has to change the mindset because from marketing to business to even HR, everyone has to think differently. When HR is looking for people to hire, they need to know what Agile is and how people need to have a different mindset, different experience, to be productive in Agile organizations.
I think you really need all three but I would start with trying to visualize the current flow in an organization and see where the bottlenecks are. Because even if you start just automating your deployments, if you have convoluted and very complex deployments, you end up with convoluted automated deployments. You really need to think about how do you simplify the process, where my current bottlenecks are, and approach it from that standpoint.
It's actually one of my favorite books and the reason being when I came across the book, I just moved away from being a DBA manager back to development side. All these experiences with outages and waking up in the middle of the night to address emergencies was still very fresh in my mind. Reading that book, it was almost getting a flashback to that time.
However, that book was giving a way out. It was not just describing the nightmares. It was also saying that there is a way to be different and there is a way to solve this problem. By trying to share that new knowledge that I got from the book with others in a more engaging way, that's how I started thinking about what's the best way to talk about it? What's the best way to deliver the same message?
Then at the same time, I was taking the gamification course in Coursera. Kind of both came together and that's how the idea came to create the game.
It's not so much about difficulties in cultures. It's more about, in the US this movement has started much earlier than in other countries but any country, even if it started later, it was all driven by local enthusiasts. That's what's really amazing about this DevOps moment. That is all about enthusiastic people who are passionate about improving the work of development and operations.
These people, in Finland, in Russia, they started their own meet-ups, podcasts. They translated the book, The Phoenix Project, into their local languages and it's just amazing. That's how really all these local movements started because of people who were interested in moving it forward.
Yes. It was an amazing experience putting together a one-day conference. It was difficult and if I knew upfront, maybe I would have gotten more people to help but even then, it started as just a crazy idea on one of our New York Scrum user group meet-ups. What is the next step for us? Can we scale it up? Maybe we should try creating a local event for more people?
Something that started as a local event ended up being an international conference, there were people coming from five different countries. 250 people, 17 sessions, 3 tracks. It was amazing. People really appreciated and the main focus for us was really not about making money out of this conference. It was about bringing a new Agile event to the local community.
Making it really affordable. Because a lot of people in New York are working for organizations that may not necessarily agree with Agile principles just yet. We really wanted to give an opportunity to those people to come to the conference. Even though they have to pay from their own pockets but we made it affordable so they can get exposed to the ideas. They can meet other people from the same industry.
That's pretty much why I'm enjoying being a part of the community because of getting inspired from people in the community and exchanging ideas. Sometimes even when it really gets bad at your workplace, you go to a local meet-up and you share your pain. And you have support and it's important.
One last thing is that they say you become the average of five people that you deal the most with. When you deal with people in Agile and DevOps community, you become better. Hopefully, you're contributing to that as well.
Manuel: Great. Thank you very much.
Thank you. Thanks for having me.