Being agile is absolutely “the new black” in the IT industry, and more and more customers expect their service providers to be agile. But what does it actually mean to be agile and how do you set that in the right context if you’re a classical service provider which almost solely delivers ”operational services” via an IT service management (ITSM) tool? You need to land on Mars.
Being agile seems to be the new black in the IT industry, and customers increasingly expect their service providers to be #agile. But what does this mean and how do you achieve it? This article explains. Click To TweetExperiential learning with MarsLander
When I discovered the MarsLander simulation and started playing it with teams it gave me the best way of showing those teams what it means to be an agile team focusing on constantly delivering value to the customer and making those very important parallels to real life.
Suddenly you find yourself in a new and often uncomfortable situation where you’re on the way to becoming outdated and no longer fit-for-purpose – only sustainable in the very short term. Maybe not aware of what it takes to develop to be ”fit for the future” and able to meet customer demands of constantly adding more value, and at speed.
How to become agile
Organizations react to the challenges of being agile in many different ways. Some start with a vision and form that into a strategy for how to achieve the goal of being an agile organization. But some start by just telling their employees that they now need to be more agile because the organization is already way behind with a need to do something NOW.
Typically, employees can then be divided into at least two groups. The ones thinking ”Well, we’re already agile,” even without knowing exactly what that means. And the other group that has no clue about what they’re being asked to do.
This creates a challenge for managers. Often having to change leadership styles and behaviors to empower teams. Some managers think they can maintain old-style command-and-control leadership, some think that by telling teams they’re now empowered that these teams will adopt and embed these new ways of working themselves.
If you’re one of the organizations that must do something now, how do you then find out what to do and actually do it? Is there a shortcut to being agile?
Is there a shortcut to being agile? Find out in this article. #Agile Click To TweetA typical reaction is to find any possible shortcut to being agile because it’s the quickest and cheapest way of doing it. But even if this sounds like a good idea, it rarely is.
One example of a shortcut (to being agile) is when an organization starts removing important roles like the Scrum Master and the Product Owner because these roles are only seen as a cost. But if these roles aren’t present, then who is it that supports these brand new and immature teams? Who is it that handles the stakeholder management with the customers, who is prioritizing a team’s backlog, etc.?
It’s also common to underestimate the effort in training the teams in agile frameworks. To this, I can only say “NO it’s not enough to make a quick introduction to agile frameworks and then expect that everyone sees the light in a split second, or understands how to then go out into the real world and be agile.” Training can’t stand alone because it will not make a team feel and understand the real-life struggles in being agile, being put in the different roles, facing the customers, needing to break down silos and effectively collaborating, and very much focusing on adding more value. Because what does value actually look like and how do you continuously deliver more value?
Also becoming agile isn’t a simple “implementation,” it’s a journey, where training is one step. It also requires experimentation, practice, feedback, and making continual iterative improvements to become truly agile at all levels within the organization. It’s a journey that requires effort and time to learn, adapt, and improve. Importantly, not all teams can learn and improve at the same speed. Just like sports teams, teams often need coaching, and some require more intensive practice and feedback. Coaching needs to be aligned to help teams mature at a speed they can deal with.
Simulation-based learning can help with gaining agile experience, exploring, experimenting with new behaviors, practicing feedback, and coaching end-to-end teams including Dev and Ops. Set in the context of ITIL 4, MarsLander is an example of a simulation game for teams that helps to develop the new skills and behaviors for agile working.
How to land on Mars (using an agile approach)
MarsLander is played with the goal of landing on Mars in three sprints, delivering value to the customer during the game. But the team must also handle service improvements, events, issues, and risks in a balance with also gaining more revenue.
There are also different stakeholders who are all insisting that their work is the most valuable. But there are scarce resources, and the players can’t do everything. And, at the same time, the players have to learn new ways of doing things such as applying agile ways of working. “It’s just like reality!” is a common declaration from many of the teams playing the game.
When playing MarsLander with traditional operational ITSM teams it’s visible how the game challenges and frustrates them but also helps to develop them. For example, across the three sprints, an operations team developed from sprint 1: Fixing issues and events, to sprint 2: Focusing on service improvements, to sprint 3: Focusing on revenue growth, customer satisfaction, and risks. Helping to take the team on the journey of becoming more agile, maturing in iterative steps.
The benefits of playing MarsLander
If a team has the right coaching and the theory is applied in the simulation, with the teams confronted with real-life situations they recognize, then you gain a lot of agile insights and experiences in playing the game. On top of this, the MarsLander game is also fun and brilliant for teambuilding, especially when working with distributed teams. But the game also fosters a lot of important reflections and discussions.
MarsLander also provides the opportunity to experiment with roles. In one game, we deliberately matched the roles with profiles where we knew they’d be very challenged and might feel uncomfortable. It gave them a chance to experiment and explore in a safe environment. The result of sprint 1 also gave a clear picture of how this impacted the amount of work they were able to undertake. In the next sprint, we matched the player profiles to fit their personalities into the game roles and got a totally different outcome. They more than doubled the amount of work in the same time in sprint 2. In sprint 3, when they were much more familiar and secure within the team, they produced the same amount of work as in sprint 2 – in half the time. The main reason for this major improvement of team performance is that they got a Product Owner who, with steady and calm guidance, involved all the roles when relevant, kept the focus on the team goals, and secured effective collaboration and communication. In this game, the Product Owner was the game-changer.
This session showed the real importance of matching the right resources to the right roles for agile working. It’s, for example, a common misunderstanding that the Product Owner needs to be a very technically skilled resource. However, the noblest responsibility for a Product Owner is to be the link between the business and the customer and thereby present excellent communication and stakeholder management skills. A change of who is placed in each role can totally change the dynamics and results in a team. If we put people into roles that stretch their abilities, or roles in which they feel uncomfortable or uncertain, then coaching, mentoring, and feedback can be powerful enablers. However, what we experienced was that if we put the wrong personality in this role, the coaching or mentoring didn’t help.
Self-organized teams bring value to your company
When you have a team that’s working well together, collaborating, and communicating effectively, what happens if you interfere or demand something else to what they have planned?
Have you ever considered how easy it is to disrupt a self-organized team that has already agreed and prioritized their items in a backlog? #ITSM #Agile Click To TweetHave you ever considered how easy it is to disrupt a self-organized team that has already agreed and prioritized their items in a backlog? One MarsLander session showed how (unfortunately) easy it is to disturb the team and make them question themselves and whether they’re focusing on the right things to achieve their common goal. Whenever asking something new of a team, have you asked yourself whether or not this new request or demand fits into the overall goals and adds value, or if you might end up ruining (unintentionally) other agreed activities or projects with this “new” command to the team?
This creates a fine balance as to what we mean when we talk about an empowered team. Are they empowered to select and prioritize their own work within the guidelines of goals and priorities? Or do managers overrule them whenever the managers have something important that they want doing? Are the teams empowered to give feedback, push back, or argue from a business value perspective? Or does hierarchy always win – ”I’m a manager, you do what I say”? These are challenges when trying to adopt an agile culture.
It’s often a struggle to find the right balance in investing in improvements within an organization in contrast to delivering services and increasing revenue, this was also experienced by the teams playing MarsLander. But investing in improvements is an investment in the future. Just delivering on short-term is, of course, being sustainable but when do you then secure the competitive advantage of also being able to deliver value into a constantly changing future with new demands? Often improvement work is left undone, especially if we are unable to specify the value and benefits it will bring.
How do you work with this dilemma – constant revenue growth versus the cost of improvements in the short term and then delivering more value and increasing revenue in the long term?
You’ll get nowhere without support from management
Self-organized teams create so much value, but only if management supports and adheres to the agile ways of working. I often see that even though the decision to work in agile ways is coming from top management it’s often management that interferes and disturbs or demands parallel setups to be in control. Being agile requires another type of management to support self-organized teams and another way of measuring progress and results.
Being agile is having a new mindset and this mindset needs to be present at all levels to succeed. And mindsets don’t change overnight, it needs time and nursing to change people from traditional frameworks to agile frameworks.
Being agile is having a new mindset and this mindset needs to be present at all levels to succeed. #Agile #ITSM Click To TweetThe bottom line here is that if you want to be agile you need to invest the right amount of effort in doing this. And also accept that it may be uncomfortable and time-consuming. Yes, it’s a cost in the short-term training an organization in new ways of doing things, but it’s also an investment in the future.
To obtain the best result in training an organization to be agile, you need to combine theory with practical examples with a direct parallel to the real-life struggles. And you have to help teams to transfer what they’ve learned in training into their daily work, which may require coaching and reserving time to reflect and make iterative improvements. Remember – becoming agile is a journey.
The views reflected in this article are the views of the author and do not necessarily reflect the views of the global EY organization or its member companies.
