The DevOps Agile Skills Association (DASA) recently hosted a webinar with Paul Wilkinson, co-Owner of GamingWorks, in which he discussed The Phoenix Project Business Simulation and how it maps to the DASA Competence Framework. We received so many thought-provoking questions during the webinar, that we ended up running out of time. Fortunately, we were able to get Paul to share his insights around each of these questions right here on our blog. If you didn’t catch the webinar, watch the recording here first!
The Questions
- Who should participate in the simulation – only people in Developer and Operations roles? Do other IT and/or business roles need to take part? Skip to question
- DevOps, as you mentioned, is a full learning and transformation process that can take years. Some business requirements go beyond a single DevOps team and involve interaction with traditional IT+Ops teams. What approach could be used to address this? Skip to question
- I think the biggest issue is not just moving towards the DevOps culture, but also the lack of coding capabilities in general. Current IT department staff is unable or unwilling (culture) to learn how to code and in the market these capabilities are also very hard to find. This means there is a need to focus on coding skills instead of on understanding the business. Do you agree? Skip to question
- When should we do the simulation after DASA DevOps Fundamentals? Skip to question
- Some enterprise companies rely on contracts that suppliers must follow to maintain the system, or do the development. Suppliers can be completely different and they have their own SLAs… so this can be a great barrier. What advice do you have to help overcome this? Skip to question
- Which is the process to accredit an Approved Training Organization (ATO) to deliver the Simulation? Skip to question
1. Who should participate in the simulation – only people in Developer and Operations roles? Do other IT and/or business roles need to take part?
This is precisely one of the issues with the name, “DevOps”; it is self-restricting. DevOps is an end-to-end capability which should certainly also include the Business, Security, Testing, and QA. For this reason we have added these roles into the simulation as well. We often also play with Business Product owners to confront them with a need to balance new features with technical debt.
By playing with the all of the end-to-end stakeholders, everyone is confronted with dependencies they have on each other and they can discover that DevOps is broader than simply Developers and Operations.
Choosing the exact roles and actual participants is dependent upon what the organization is trying to achieve in terms of learning objectives or the problem they are trying to solve. E.g. “I want to convince the business they must also prioritize technical debt, not just force through new features”, “we need to show the importance of testing and test-driven development”, “we need to break down the silos between Dev, Security, QA and Ops”.
2. DevOps, as you mentioned, is a full learning and transformation process that can take years. Some business requirements go beyond a single DevOps team and involve interaction with traditional IT+Ops teams. What approach could be used to address this?
Often what we see is that organizations are adopting Agile as a first step in their journey and then discovering that the ‘smooth, fast flow of feature deployments’ stops, or slows down at Operations. Often Operations skills and resources are shared by multiple Agile teams, and so this then becomes a constraint. In the simulation there are three business owners (product owners) who share IT resources. In this model the business owners realize sometimes other business features get priority, this can stimulate a need to create a more dedicated market, or business unit focused DevOps teams.
3. I think the biggest issue is not just moving towards the DevOps culture, but also the lack of coding capabilities in general. Current IT department staff is unable or unwilling (culture) to learn how to code and in the market these capabilities are also very hard to find. This means there is a need to focus on coding skills instead of on understanding the business. Do you agree?
I agree that coding skills are a critical capability, I agree that not everyone in Operations wants to become a coder. I agree it requires a focus on developing these skills, however I disagree that it negates the need for business understanding. People want to have a purpose; to be motivated and inspired by what they do. Last week I was in the USA where one organization presented the pride people take in their work when they can see how what they have done has impacted their business and customers. This is the culture for the future. IT IS the business. Reinforcing a culture in which we are IT people, we do technology, we do code, we do software, is a risk to achieving Digital Transformation.
4. When should we do the simulation after DASA DevOps Fundamentals?
There are various ways of doing this. One is to do the simulation directly after the DASA DevOps Fundamentals whilst the theory is top-of-mind. This helps participants to translate the theory into practice immediately.
Another way can be to do DASA DevOps Fundamentals and then let people go back to work and try to use the theory first. Often in doing this, they will identify barriers and come up with additional questions. After this period of testing they can play the game and answer questions, gaining a deeper level of theory and sharing real life experiences.
Some organizations who have not yet gained commitment for DevOps or DevOps training do the simulation first, to create awareness and buy-in and to identify key areas they want people to learn more about, which helps target and shape the follow-up DevOps training program.
5. Some enterprise companies rely on contracts that suppliers must follow to maintain the system, or do the development. Suppliers can be completely different and they have their own Service Level Agreements (SLA)… so this can be a great barrier. What advice do you have to help overcome this?
This is definitely an area in which DevOps can realize its full potential and promise for faster deployment of new features. Suppliers have a different release schedule, which means they are not keen on updating a feature for one user. So, features are either denied or packaged for major releases. Some Suppliers recognize the need to adopt DevOps principles and practices. This is something you need to be aware of. Some have no intention or desire to do so, which you must accept as a risk. This then becomes an executive level decision. Some are ‘insourcing’ their applications and hiring more internal staff so that they maintain control over the type and frequency of code deployments. There must be a compelling case to demonstrate the value potential that is lost by not doing this or the value gain realized by doing it.
This is what makes DevOps a long, transformational approach for organizations and a re-architecting of their software platforms and portfolios. As I said above, this is an executive level decision, closely coupled with a true strategy for Digital Transformation rather than tweaking one or two low-hanging web applications to be transitioned to DevOps teams.
6. Which is the process to accredit an Authorized Training Organization (ATO) to deliver the Simulation?
We have two options for an ATO to become a partner. One is to become an Authorized Reseller. This means you can offer the simulation but will need to hire a Certified Trainer to facilitate the simulation. The second option is to become a Certified Delivery Partner(CDP). To become a CDP one or more trainers must follow a 2 day Train-The-Trainer(TTT) program, followed by a half day or full day delivery of the simulation observed by a Master Trainer who will certify the trainer. This can be on-site at your own location or can be part of an Open TTT organized by GamingWorks. The costs for the TTT are dependent upon whether you want an in-house TTT or you want to participate in an open TTT with other ATO’s/ACO’s.
A CDP must also sign a contract with GamingWorks and pay a license fee per game used. This license fee is based upon the number of games you hope to sell and the Geographical region you operate from.
If you would like to know more about becoming a GamingWorks partner and the costs please contact us at office@gamingworks.nl
DASA DevOps Fundamentals
Provides an extensive introduction to the core agile DevOps principles covering the essential knowledge and skill competences that have been defined by DASA.
