MarsLander at NXP Semiconductor

Published on Wednesday 21 March 2018

This article

This article is about the lessons learned from the NXP IT Operations team playing the business simulation MarsLander®. MarsLander® is the new IT Service Management simulation from GamingWorks and it all about making your IT Service Organization more Agile, Lean with a focus on the customer, fast moving markets and continual service improvement. We challenged the IT Operations team and the Agile / DevOps coaches from NXP to support the mission to Mars. During the retrospective we discussed the lessons learned from the simulation and made a direct link to their experiences during their own transformation.

About NXP

NXP Semiconductors N.V. enables secure connections and infrastructure for a smarter world, advancing solutions that make lives easier, better and safer. As the world leader in secure connectivity solutions for embedded applications, NXP is driving innovation in the secure connected vehicle, end-to-end security and privacy and smart connected solutions markets. NXP IT’s horizon is to fulfill the increasing demand of their customers, becoming better in what they do and ultimately making their customers happier. By combining People, Process and Technology they can make any IT change happen! How they get there is by working Agile, continuously learn and grow, test and improve. Therefore, NXP IT needs to operate as ONE IT, together with their service providers.

This is all captured in the so called Organize for Change program lead by Sebastiaan Laurijsse.

The base of the Organize for Change program was established by a close collaboration of NXP with Marleen Olde, Atos Consulting and Gaming Works. The ‘journey’ started with business simulations, active communication and inspiration sessions. And is still on the road…

About MarsLander

The mission of your team is clear:

“Launch a rocket with MarsLander, bring it to Mars and collect valuable data for Universities and Research Centers”._ _

Your challenge is to support the Mission Center, helping ensure they are able to achieve all mission goals. The Mission Director is managing the Mission Center and leads a team consisting of Flight Operation, Navigation and Communication experts. These specialists manage the flight plan of the mission in accordance with mission goals and contractual agreements with the customers and suppliers.

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 and maintains applications, features and application fixes. Vendors are supporting the Mission Support Team with data communication services and data storage services.

The Service Manager will manage the Service Design, Service Delivery and Service Improvement.

Overview of the experiences of the NXP team

Round 1 – preparation of the mission

Goal of this first part is to get a clear picture of the mission goals, the backlog of work, designing the first service and to make sure the whole team has the same picture of all roles and activities.

Lessons from NXP:

  • When starting your transformation journey, you are going to need a roadmap to create understanding of where your journey is going to. The lessons learned from the first round was that:
  • Make sure the whole team has a shared picture of the goals, the values, the work that needs to be done and the flow of work. When this is clear you can start working on how to get there.

Feedbacks from the simulation:

  1. We started with discussing the content (issues, problems, projects) while there no shared goal, shared value and clear flow of work.
  2. We worked as a good team, we were all involved, but when the discussion started about ‘who is doing what?’ we felt back to our ‘Silo’s’.
  3. You have to deal with different learning styles when teams of different roles and functions start to work together. The learning styles of Kolb are:
    1. Learning by : Feel and watch
    2. Learning by : Think and watch
    3. Learning by : Think and do
    4. Learning by : Feel and do
  4. We had our first visualization, but it did not work. We have to learn how to deal with ‘things that don’t work in the first place’.
  5. We had to experience how to involve the Product Owner into the service team. We had to learn to speak the same language, we had to share the values, the goals and expectations.

What did NXP recognize from their own journey?

The journey within NXP started with creating awareness among the employees and sharing the “why”, of the transformation. Values like “Working out Loud”, by making work visible in such a way that it helps others got introduced. The four cornerstones: Make Agile, Collaborate, Standardize and Automate became the guidance in continuous experimenting and learning. .

To direct value to their customer NXP IT learned that visibility and continuous focus on customer needs is an important topic. Like also was during round 1 of the Marslander.

Round 2 – launch the rocket and encounter Hardy IV (comet)

In this round the team must make sure the rocket will intercept the comet on time, with the right velocity and location and with enough AMPS to make all the pictures. But the Sales Director has a nice surprise, a new contract to sell an extra service to the customer. Can the team adjust the services to create this extra value.

Feedbacks from the simulation:

  1. The flow on the board differ from the flow in our team. We could not follow up the work, we did not know how the status and it was hard to set the right priorities.
  2. It was hard to make the right decisions in our second line support team. We received issues from Flight Operations and Navigation and Communication, but we did not know what should go first.
  3. We had challenge to deal with the planned and un-planned work. The Development Team was working on the planned work (new features, projects) and the Service Teams were dealing with the unplanned work (issues). The Development Team used all their capacity to develop new applications, as a result to were not able to allocate capacity to solve issues.
  4. We experienced the value of having good governance. Our tool showed in detail the performance of our team. The value we create, the average solving time and the revenue.

What did NXP recognize from their own journey?

During the journey NXP IT experienced emerging dynamics that required IT to work more closely together with their customers, the business. Agile teams, so called squads based on Products and/or Services where created. Each squad has one dedicated Product Owner, who is responsible for priority setting and stakeholder management.

The journey has its ups and downs but the continuous learning by experimenting becomes a more regular activity within the teams and within management.

Round 3 and 4 – Orbiting round Mars, landing and making the first trips.

In round 3 the team was organized like 2 service teams. On team to support FO and one team to support the NAVCOM. Both with their own knowledge and experience.

They also use the Service Improvement opportunities to train the NAVCOM team to build some small NAVCOM applications and do their own changes. The plan was to continue the training in round 4, to have the FO team also ready to build and change small applications.

In round 4, the team made the first trip on Mars. Again the Sales Director signed a new contract to sell 3D graphics to one of the customers. This required a huge update in our service.

Feedback from the simulation:

  1. By planning the training to teach the Service Teams to execute small applications and changes, we could solve issues much faster.
  2. Also, it made a lot of capacity available at the Development Team to develop those highly innovative applications to sell those 3D graphics.
  3. We had to update our visualization tool a few times to make it valuable for our team. It became more a Kanban Board showing the progress and the status of the issues, problems and projects. In this round it really helped to manage our work and make the right decisions.
  4. We were still a bit reactive. We missed the opportunity to fix the problems earlier so we could have less issues. Somehow we forgot to re-assess the backlog to make better decisions about value. There was enough capacity on the Development and Change planning to do the work.
  5. We solved the testing bottleneck by bringing test-activities back to the service teams. The results were to increase the flow and minimize the errors and rework (waste)
  6. We could have done better if we would have changed the system. By combining roles or put them closer, we could have reached a higher score.

What did NXP recognize from their own journey?

In round 3 and 4 of the simulation a clear goal and focus of each team was addressed. Besides that there was a mutual agreement on how to use the KanBan. Within NXP IT these are the next steps in the journey. Creating releases with clear goals and an estimation within the teams what they can achieve over time. The use of tooling gets more and more standardized and by continuous ‘Working out Loud’ teams learn instantly from each other. Slowly a change in culture becomes visible. Team members feel part of the squads and want to deliver as much as customer value as they can.

The Results and Lesson’s from NXP:

The key lessons from this workshop:

  1. Make sure you integrate testing in your team. Focus on quality at the source and first time right. Reducing rework, non-added-value activities and frustration in the team.
  2. Create autonomous teams. Train the employees to be able to do their work as a team. Minimize hand-overs to other teams, this will lead to waste and decrease of flow. Celebrate success.
  3. Create the right metrics to monitor the performance of the teams. This will help to govern your work, motivate the teams and know what brings value and what not.
  4. Visualize the work as much as possible. Make a clear Kanban board showing the different types of work. IT Projects, planned work (Applications and Problems), unplanned work (Issues, errors) and Improvement activities.
  5. Set priorities in the context of the work and not based on tables and flow-charts. During standups, discuss with the product owner (or service owner) and the team why we should do some of the work earlier than other? By sharing the why, the team will understand, and much more involved in the process to solve it on time. They become more the owners of the issues.
  6. We have to learn how to work with the different learning styles. One round went well and we were all motivated, then the next round it went not so well and we experienced the frustration in the team. Dealing with uncertainty, stimulate to experiment, make small steps and celebrate are crucial aspects to keep motivating the team.
  7. Product Owners are important roles in the Service Teams. The need to help the teams to be able to plan, execute and test the work they are doing. Share the goals, the value and expected outcomes. But also take responsibility to give the team space to experiment and learn. It’s about investing in the future.
  8. Give teams enough time to learn and experiment. Continual Improvement is only possible if we empower teams to organize and improve their own work. This requires effort, time and commitment.

The end result of the NXP team

In round 3 the team implemented the service teams. One for FO and one for NAVCOM. The decision was made to start training the NAVCOM team to develop their own applications in round 3 and do their own changes in round 4 (2 rounds service improvement plan). The reason to start with NAVCOM was: We must capture date from the 2 orbits round Mars and we must have the data on time to deliver this new service to customer. Since NAVCOM is responsible for these actions the decision was made to start with NAVCOM first.

It’s nice to see how the Customer Value went up in round 3, and how the Average Solving time went down for NAVCOM. But, in round 3 we did not implement development activities in the FO-team. That’s why this team stays a bit behind. However the total value went up in round 3 and the speed was much better than in the previous round.

In round 4, the whole NAVCOM team was empowered, and the FO team was trained to do the development activities. As a result, we can see that the NAVCOM-team solved the NAVCOM issues 1 period faster than the FO issues and the NAVCOM value went up to 75%.  The FO-team experienced a bottleneck since they were still depended on the Change Team. But this team had to use its full capacity to deploy al the new 3D features and could not execute the changes that were prepared by the Service Teams.

If there would be a next round, the FO-team would have performed better, since the next release of the service would have 2 fully empowered service teams.

The revenue stayed a bit behind target. In the first 2 rounds the teams could not finish all requests on time and lost some business opportunities. However, by empowering the service teams in round 4, the Development Team could build all applications for this new 3D feature and the Change Team could deploy all these feature on time. This brought the team close to the overall target.

Look at the monitoring tool in this simulation. This is what we need. Just a few key indicators to show how we are doing. This helps us to govern the IT Services to our customer

– Sebastiaan Laurijsse – Senior Director IT Infrastructure Services.

The Phoenix Project is a perfect simulation to create overall awareness about DevOps in all teams across the company. This MarsLander simulation is a perfect simulation to teach the service teams how to apply Agile, Lean, DevOps and Service Management principles in their own team.

– Larissa Hendriksen – DevOps consultant Atos