7 things to avoid when applying agile mindset to ITSM

There is no script you can follow while transitioning to an agile work environment. There are, however, experts who can help smooth the transition. Steven Happee is one of them. Steven has coached a variety of organizations in their agile transition and is here to tell you which pitfalls to avoid.

Steven Happee’s love for agile blossomed in the nineties, when he developed software in a small, multi-disciplinary team, in a way that would now be called agile: a lot of contact with customers, quick value delivery, and transparent work processes.

Now, twenty years later, he helps organizations make the transition to become more agile and learning-oriented. He uses his extensive experience as product owner, scrum master, developer and manager to conduct valuable experiments. Based on his experience, Steven shares the 7 most common pitfalls for agile transitions.

1. Only looking at the agile transition top-down

You can approach agile transformations in two ways: top-down and bottom-up. A bottom-up approach means the team takes initiative, often in IT, to implement a more agile way of working with a single team.

For top-down, the initiative comes from the manager, CEO or CIO and the goal is often to make a large part or even the entire organization more agile. The top-down approach is relatively new. These past few years, agile has become a hot topic and more and more CEOs and CIOs are thinking about it.

But a bottom-up approach is usually more successful. This is something you see in IT teams, where the agile mindset comes from originally. Someone in the team wants to experiment with agile, the manager is enthusiastic and a scrum team is formed. When this team performs well, more teams might follow and the organization becomes curious.

An approach that combines bottom-up and top-down works best: a team takes the initiative to implement a more agile way of working and finds a sponsor at the top of the organization.

2. Using the waterfall method for your agile transition

Ten years ago, there were a lot of people who believed that you needed to use Prince2 for an agile transition. First you make a design, implement it step by step, create milestones etcetera. This a paradox of course.

Fortunately, most people these days are convinced that an agile transition needs an agile approach. The transition to agile is a complex project after all — meta-agile as you may call it. People start to work differently together, your way of working changes and your tools are different. It’s best to have an iterative transition with a multi-disciplinary team and a change backlog. An added bonus is that you set the right example

3. Being too strict with agile techniques

Agile frameworks like Scrum offer techniques to apply an agile mindset to your daily work. A backlog, retros — they’re all very visible. But these techniques are just the tip of the iceberg. It’s the visible aspect of agile working. They are based on certain assumptions on how to organize your work, and these assumptions fall back on principles from the Agile Manifesto or Modern Agile.

Some people have the tendency to be very strict with these techniques, but without understanding the underlying principles. That can cause friction. Some techniques might not work for your organization, so it would be a shame to follow them religiously. In the end, you need to embrace the agile values, not the techniques. That’s why it’s good to explain the underlying principles to someone who wants to do something with agility, so they can fall back on them.

4. Creating variations on existing techniques too quickly

Yes, you need to make agile techniques your own. But not from the very start. The agile world often refers to ShuHaRi, a Japanese martial art concept on how to make something your own in 3 phases. You start by strictly following the existing technique (Shu). When you’ve internalized the rules, you can make variations (Ha), until you reach Hi: you’re subconsciously competent and there is no longer a need for rules or techniques.

You often see that teams start varying on existing techniques, or collect elements from different frameworks: cherry picking. You hear a lot of excuses for this: ‘I know the theory and I know it’s not going to work for us’ or ‘We like to experiment, so we’re combining some different techniques’.

It’s good to experiment, but make sure to vary from a solid foundation. Work with an existing method for six months or one year and experience what it’s like. How do sprints work? What is a good retro? How do we formulate customer value? Only when your foundation is solid, you can start varying.

5. People working in an agile and project team

Agile working and project-based work have fundamentally different starting points. For agile you have the same teams, with team members who know each other’s strengths and keep evolving together. You give the teams work. With project-based work you have work and you search for a temporary group — you bring the teams to the work. This cannot be combined with each other.

6. Think of an agile transition as an IT party

What often happens, is that people have limited views on the impact of agile working. Agile is not limited to the IT scrum team. An agile transformation is a cultural shift that impacts all processes and people in your organization, from Finance to HR to management. When teams become self-managing, what changes in the role of team leads? How do you assess people in scrum teams? Are yearly budgets and scrum teams a good match? In most cases, more and more teams in the organization want to start working more agile as well.

The sooner you understand that an agile transformation impacts the entire organization, the easier the transition. Many managers see agile as a chance to implement a culture shift, like working more customer-oriented or more ownership from employees. Managers often have tried a lot of methods to change the organizational culture. With agile techniques, changes like a customer-oriented focus or sense of ownership are more a by-product of an agile mindset.

7. Scaling up too soon

There is a lot of experience in the agile world with agile working on a team level. But if the team is up and running, how do you go up to two or three teams? Or twenty? And how does agile work in departments like Sales or HR? That’s a puzzle the agile world is trying to solve right now.

There are multiple frameworks for scaling up agile teams, like the Spotify model, SAFe (Scaling Agile Framework) and LeSS (Large Scale Scrum). The most important lesson: if you don’t have to scale up, don’t do it. See if you can manage to let the teams work independently from each other. Don’t start thinking about scaling frameworks until there is no other way. Some organizations want to scale up the minute the first people are enthusiastic. Don’t do it. Only fix things when there’s friction.

More about Agile?

We’ve been exploring this topic a lot recently and want to share all we know! Have a look at our Agile ITSM e-book: