Skip to main content

What is Marslander all about?

 The challenges faced by ITSM organisations in the coming years are about developing new ways of working that are more aligned with business needs and that provide a more agile approach to providing products and services. Now more than ever we need to develop end-to-end capabilities requiring improved communication and collaboration across cross -functional teams.

 Recently we invited leaders across different corporates in India to experience the new business simulation of Marslander in Bangalore. This blog reflects their experience, learning, and value they received in applying service management to the digital enterprise.

How does it work?

 The simulation demonstrates how to move from a traditional ITSM way of working towards a more ‘Digital’ way of working. This simulation starts with a traditional ITSM setup with a Service Desk and Incident Management and Problem Management. After the first 2 rounds, we let the team transfer to a more team-based way of working.     

VeriSM Model

The team will use this approach in case Mission Control brings in new business demands. [Apply VeriSM Model]

Define: the team will explore the consumer needs, define the required outcome, build/design the service and implement. This is all done during the ‘improvement cycle’ of the simulation. After this, we start the execution of the round. We provide the service, we improve, we measure and maintain. We record our performance and manage the different situations

Why did we play this business simulation?

 In this simulation, the team must achieve the Mission Goals. This will lead to revenue and business value. For this, the team must focus on the customer and must understand how to support the business in achieving these goals. We will look at flexibility, quality, continual improvement mindset, customer centricity

 Marslander Simulation – Synopsis

The mission of your team is clear: “Launch a rocket containing the MarsLander, bring it to Mars and collect valuable data for Universities and Research Centers”.

Your challenge is to support the Mission Center during this mission so they are able to achieve all of the mission goals. The Mission Director is managing the Mission Center and leads a team of Flight Operation, Navigation and Communication experts. They manage the flight plan of the mission in order to achieve the mission goals and fulfill the contracts with the customers.

The Mission Support Team consists of Support Engineers, Test Engineers and Change Management. They will fix all issues that occur during the mission. The Development Team develops applications, features and fixes. Vendors are supporting the Mission Support Team with data communication services and data storage services.

The Service Manager is responsible for service design, service execution and service improvement.

This simulation is about exploring and experiencing how you can transform your current IT organization into a more Agile and Lean organization.

Measure

We measured different aspects like solving time (total, per service), customer satisfaction (total per service) and revenue. Each round of the simulation discussed the outcomes of the mission.

The Simulation is broken down in to 4 rounds.

Round 1 : Planning your Backlog

Round 2 : Launch and Heading to Hardy

Round 3: Continue to Mars

Round 4 : Landing on Mars

At the start of the Simulation, the team had some issues, requests and projects as backlog to plan for the work ahead. The team had aspects of planning , execution and reflection for every round.

 

Reflections from Round 1

The Product Owner took the lead in orchestrating the team for the Mission. There was a detailed planning for over 45 minutes

  1. Team recognised the need to Focus on Outcome (Goals, common understanding of shared vision and expectation)

The outcome of the actions of the team is on creating a profitable mission by selling  the requested data to the end users (universities and research centers),                whilst at the same time ensuring security and integrity of the data

    2. LEAN (Applying lean to improve the flow and TOC)

a) Lack of understanding the flow. Workflow was drafted but the execution of flow was not tested with the backlog of work (e.g Issues, Requests, Projects)

b) Development team was not aware of how the flow of work will come including from vendors and resources to execute the same.

c) Aggregation of Issues/Requests and Projects had to be streamlined with different approval and workflow process. One size might not fit all

  1. Each and every team focused on their specific deliverables and action item (Silo Culture). There was also no consensus on definition of done [Agile]
  2. General apprehension of how can I contribute without becoming a bottleneck and fear of failure was evident as each and everyone do not want to play the spoilsport [DevOps]

Management Mesh

 

During the ‘design’ of the service the team explored different aspects of the mesh. We look at the environment (processes, tools), the different practices (lean, agile) the emerging technology (service improvements), Resources and capabilities.

Kata/Kaizen

Continual Improvement is part of every round of simulation. Between the rounds we expect the team to execute this improvement cycle. We can stimulate the teams to create their own improvement backlog to capture the improvement opportunities.

  1. Team decided to focus on just enough process and information to execute the flow knowing dependencies, interfaces and aligning with big picture (Agile Service Management)
  2. Mission Goals was considered as the magnetic compass driving all decision making ability by the team. (Shared Vision and Goals – Big Picture)
  3. Teams will need to apply LEAN principles. They must create and maintain a constant FLOW of work. The whole team (support, development, test and change) must work as a team. Issues will flow from one end to the other resulting in quick and errorless solutions. They have challenge teams to remove waste from the process. Team discussed about various aspects of waste [DOWNTIME] Quality at the source ensures that every team member will focus on quality before it sends work to the next downstream stakeholder.
  4. Agile – As self organising teams, it was critical for everyone to have a shared understanding of definition of done and they debated and agreed with the product owners.
  5. DevOps – Team emphasized on third way of DevOps to applying continuous experimentation and learning . The Product owners supported the team in their endeavor to go ahead and express themselves without being too much worried on failure. Failing fast and Fail early was clearly communicated to all the stakeholders. It was also decided to have quick feedback loops to prevent defect passing downstream.

 

Reflections from Round 2

a) First In – First Out – Issues, Requests and Projects were handled on first in –first out basis. The shear magnitude of the requests along with time constraints created break in process, flow, resource and capabilities (Absence of end-end view)

b) There was no clarity on priority of issues and projects to enable correct decision making. Team did solve issues, requests and executed projects but did not gain revenue or customer satisfaction. (Business Impact and Service Value)

c) Need for Shift left was felt to enable the teams get things done earlier in the lifecycle and prevent defects pass downstream (DevOps First Way)

d) Resource Utilization – Development team was swarmed with work and witnessed theory of constraints (Theory of Constraints)

e) Lack of Categorization made it difficult to find solutions for problems (Visualization and Kanban)

f) Amps, Velocity, Fuel and other critical parameters were not focused due to volume of work. Invariably, these parameters had impact on downtime and repeat incidents. [Service Automation]

 

Continual Service Improvement from Round 2:

  1. Priority Clarity – Any work (Issue/Request/Project) could not be taken without approval from Product Owner (Flight Operations/Navigation and Communication). This meant that any decision taken by the respective owner was trusted and executed with the required priority.
  2. Team decided to address Theory of Constraints using following 5 steps: (TOC)

a. Identify the bottleneck

b. Exploit the bottleneck

c. Subordinate

d. Elevate

e. Repeat

  1. Shift Left – Bringing the resolution closer to the customer. This can be done by creating Service Teams or using the Product Owner more often to prioritize the workload in the backlog
  2. Team decided to develop a visual board using Kanban to keep track of Issues, requests and projects. This meant to have an integrated dashboard where the entire team is aware of the progress, activities and limiting WIP limits to deliver faster value [Visualization – Kanban Board]
  3. Service Automation:During the simulation, the Service Manager had some service improvement opportunities. Two of them were related to service automation. One of them is about automating the control of the amperage in the rocket, the other one is about the automation of data communication control. Team decided to focus on control of amperage to prevent further occurrence of incidents

 

Reflections from Round 3

  1. Knowledge Sharing was critical between cross functional teams in order to complement each other to get work done. (Knowledge Management)
  2. Aligning with Mission Goals was strategically important to create the most important service value (Business Goals)
  3. Making Goals visible for everyone to see helped in getting collective ownership by the team. (Big Picture and Balanced Score Card)
  4. Test driven development was done to improve efficiency and effectiveness in delivery (TDD & Continuous Integration – DevOps)
  5. Resource Utilisation became better when the team decided to pass on Low Complexity and Low Risk changes to the Service Operations team. This way they had a good view of the backlog, velocity and interdependencies. [Delegation of work – Service Teams who do not only support but also do development work in the wake of DevOps]
  6. The Change Management also had a good view on the Change Calendar and were able to execute the most important changes that had high impact, complexity and risk while the rest were easily handled by the service operation teams.
  7. Culture Change: During reflection between the rounds, team discussed the typical culture aspects (sense of ownership, knowledge sharing, fear of failure, experimentation, visualisation, prioritisation, retrospectives) during the rounds.
  8. Governance : Team explored aspects such as transparency, accountability, responsiveness and effectiveness while making the service teams deliver true business value

Due to time constraints, we had to stop at round 3 to hear their experiences on playing Marslander. The Dashboard shows the Mission Goals of Round 3

The teams highlighted key takeaways & learning`s from the Marslander simulation as follows.

Ensuring services are aligned to business needs

Helping service teams to create high performing teams

Visualise work using KanBan

Increasing the flow of work

 Integrating vendors into our services

Operations team working closer together with development

 Continuously improving services to meet business value

Becoming a flexible service organisation that responds quickly to changing demands

Leveraging more customer focused,  ‘customer thinking’ into our teams

Managing workload and how to reduce unplanned work

Increase customer satisfaction and employee morale.

 

If you are looking at how to get your service teams organised for the digital age in the wake of IT Management best practices and create value as an organisation, don`t hesitate to try Marslander business simulation. Contact us at info@wordpress-129153-2119642.cloudwaysapps.com