After a period of testing, tweaking and optimization the Phoenix Project – ServiceNow business simulation was officially launched during ServiceNow Limitless IT seminar which was held in Amsterdam on the 14th of September. The simulation was originally developed by GamingWorks and ported to ServiceNow by Plat4mation. After a general introduction of the ServiceNow platform and the Phoenix Project simulation, the simulation was played by 30 participants with even more people attending.
“It is my mission to show customers the transformational benefits that platforms can bring to their organization and think about ways to achieve those benefits.”
The simulation is aimed at making teams familiar with DevOps with the help of the ServiceNow platform. No prior knowledge of DevOps is needed to play the game: participants can learn as they play. Jan Schilt, founder and director of GamingWorks, summarized this as “to create a culture that embraces asking”. DevOps is as much a cultural change as it is a way to organize workflows.
While participants only played part of the first round of the simulation, which consists of a card game, the ServiceNow part of the simulation was comprehensively explained by Ingrid van Sluis, management consultant at Plat4mation. As Van Sluis explained, the ServiceNow part of the game is a real life example of how ServiceNow can help organizations to work according to DevOps principles. With the implementation of a few additional modules, organizations that use ServiceNow can utilize the platform to engage in DevOps; the Phoenix Project – ServiceNow demonstration makes tangible how.
From muddling through to taking the reins Why DevOps is also about cultural change became crystal clear during the simulation at the event. At the start of the session, the participants were divided in two teams of 15 members. One team member of each team was named the product owner, whose role was to decide how the team will utilize its resources and which projects had priority. The rest of the team consisted of members from different departments and with different responsibilities, for example application development, testing, change management and operations. Their mission was to make a struggling fictitious company succeed.
After a general introduction and some time for preparation, the teams started their work on a creditcard Point of Sale. One of the walls in the room was set up as a makeshift Kanban board to organize the backlog and manage the flow of work. Both teams decided to start with a stand-up, a well-known scrum technique that is designed to encourage face-to-face communication. First on their list: figuring out how to organize a steady workflow without overextending resources or making errors.
Most participants initially struggled with the new responsibilities they had just taken on. As they had to decide how much resources were available and which requirements needed to be fulfilled to deliver a functional product, chaos erupted. Although the product owner had the final say in the prioritization of work, a lengthy discussion on this topic ensued. To make matters worse, an incident disrupted the deliberations of the team.
The team had to quickly decide whether the incident was critical to operations, which would have meant the development of a new product would grind to a halt. At the end of the round, both teams eventually had mapped out a workflow and allocation of resources that should lead to a functional product. However, one team neglected to upgrade the IT-infrastructure, which meant the creditcard Point Of Sale they had just developed could not be taken into operation. During the second development cycle the teams had learned from their mistakes and were able to successfully develop and deploy more products.
A continuously changing and learning culture So why were teams better able to succeed during the second try? One of the main characteristics of DevOps is a learning culture and open communication. Participants quickly grasped this fact by experiencing what happens if communication is distorted. Thereby they took the first steps to a lasting cultural change. As one participant summarized it: “You need to understand each other’s responsibilities and respect that. You really have to work as a team. You cannot just push work downstream. You need to understand what the others concerns are.”
Fundamentally, DevOps is as much about people as it is about processes or technology. The difficulty lies in the orchestration between methodology and the right tools and tailoring them to offer maximum support to teams. As became clear with the presentation about the ServiceNow part of the Phoenix Project Simulation, the right aggregation and presentation of information, combined with a unified workflow for all team members can put technology to work to encourage lasting cultural change within organizations.
Experience DevOps yourself Curious about the Phoenix Project– ServiceNow simulation? Contact us!
Save
Sign up to our monthly Flow@Work Exclusive newsletter to get free access to our expertise and lots of tips and tricks to make work flow on the Now® Platform.
