The good news? The Lean philosophy of eliminating waste – anything that doesn’t add customer value – makes your IT service management more efficient and customer-centric.

A brief history of Lean

Lean is a philosophy that concentrates on cutting the so-called waste in your daily work to focus on what truly matters: delivering customer value. Anything that doesn’t add customer value is considered waste.

A good example of a Lean approach is McDonald’s Speedee Service System. Back in 1948, McDonald’s redesigned their kitchen to maximize efficiency. The end result? Hamburgers served within 30 seconds.

Currently, car manufacturer Toyota is the leading Lean exemplar in the world, thanks to the Toyota Production System (TPS), invented in the fifties to eliminate waste in Toyota’s manufacturing and logistics processes.

The benefits of Lean Service Management

The Lean approach also works outside of hamburgers and cars.

Even though Lean doesn’t offer any specific guidance for IT service management, its philosophy works well alongside other ITSM frameworks. In fact, ITIL 4’s introduction of the Service Value System relies heavily on the Lean mindset and terminology.

Lean Service Management’s focus on customer value helps you step into your customers’ shoes and think from their perspective. This makes adapting your IT services to meet increasing customer expectations easier. And eliminating steps in your processes that don’t add customer value makes delivering IT services more efficient, ultimately lowering resolution times and increasing customer satisfaction.

Remember: Lean is a philosophy, not a rigid, unchanging set of beliefs and methods.

The 5 principles of Lean Service Management

A Lean process is based on the following 5 principles:

1. Identify value

Specify the value your customer is looking for. What do they want or need? What problem do they have that needs to be solved?

2. Map the value stream

Identify which process you need to deliver this specific value to your customer. This is called a value stream. Challenge the steps within this process: do they help deliver value? If not, try to eliminate them.

3. Create flow

Make sure the value stream runs in tight sequence so the value will flow smoothly to your customer.

4. Establish pull

Deliver the value when your customer requests it.

5. Seek perfection

Repeat the process, striving to make it perfect. Note that the goal here isn’t perfection itself, as that’s unattainable, but rather the pursuit of perfection – also known as continuous improvement.

Use Lean Service Management flexibly

These Lean principles provide you with great tools to start improving your IT processes. But remember: Lean is a philosophy, not a rigid, unchanging set of beliefs and methods. It can change or look differently, depending on the context and on the unique needs of your organization. So, pick and choose the elements from Lean that work for you and start there.

This attitude is part of a little something we at TOPdesk call service flux: embracing change and using philosophies and frameworks flexibly to make iterative improvements to your services. All so you can adapt to a constantly changing world.

The post More efficient, customer-centric IT services? Try Lean Service Management appeared first on MCG - EN.

As opposed to ITIL, agile service management doesn’t provide you with extensive process descriptions you can implement in detail. Agile is a philosophy and based on it you determine how you want to set up your work. There is of course much to learn from other organizations. According to the agile service management principles by Dolf van der Haven, I’ll give you 6 practical examples on how to make your service management more agile.

1. Make sure everything you do adds value for the customer

IT departments too often put a lot of work into things that have little value for their customers. I recently visited an organization where the IT department had written an extensive manual for a new smartphone they offered. Sounds useful, but most of this information was already available on the internet. And the next OS update is going to make their manual outdated.

A more agile way of documenting is to keep the information in your manual limited to what is strictly necessary and first give these instructions to a small test group. Only describe company-specific information, like how to synchronize your work email with the new smartphone. Do you receive questions from your test group? Update the documentation before you officially start supplying the smartphone.

2. Always work closely with your customers

When designing services or processes, service organizations make a lot of assumptions about the needs of their customers. An example: for years, a facilities organization encouraged their customers to log a call when something was wrong with in the office building. They recently discovered their customers found it quite annoying to receive five to six status update emails after they logged a call. That was the reason many customers decided to stop logging calls altogether.

In agile service management, you involve your customers often and as soon as possible with everything you do. This way, you avoid working based on assumptions. The organization from the example has come up with a solution together with their customers. When customers log a call, they can tick a box saying they want to receive status updates. One question and a single checkbox could have spared five years of frustration.

3. The right people in the right place

Many IT organizations lean heavily on processes. The goal of working with processes is to guarantee a consistent quality of services, no matter who supplies the service. Sounds good in theory. In practice, it does matter who supplies the service. An unmotivated service desk employee probably leaves a less positive impression on the customer than a happy, motivated employee. You can’t cover this difference with a process.

An important part of the agile mindset is having enough time and attention for your team members. Your team only functions well with people who are good at the work they do, and when the work they do makes them happy. Is a team member no longer motivated? Talk to him or her. Maybe they’re happier in a different role.

4. Make your processes as flexible as possible

ITIL processes are usually not flexible. Take change management. A Request for Change needs to go through a set number of predefined steps. The only choice you have in the process is approve or decline. There is no room to change plans. If you want to change them, you need to stop the process, make a new plan and get approval.

Make sure that the processes you design are flexible enough to deal with ever-changing demands. This however doesn’t mean you need to implement every single change during the process. It does mean that you leave room for your team to deal with the processes as they see fit.

5. Design, implement and improve your services step by step

New software or services implementations can take up months, years even. When the implementation is finally done, you’ve gained so many new insights you probably want to change everything. But by that time there’s no more budget left, the project team members have moved on and it’s up to the application manager to process all the feedback on her or his own. Delivering new services in an agile way means you deliver something workable as soon as possible, collect feedback, and use this feedback to improve the product.

At TOPdesk we do software implementations step by step. We first set up a basic version of the call management process, and as soon as it’s operational, we go live. The process isn’t perfect, but we’re okay with that. While we continue working on the next process, we receive feedback to improve call management.

6. Keep your services and operations straightforward

Request process often contain a lot of unnecessary management authorizations. The IT department assumes that management wants control over every individual request. Or the IT department doesn’t carry any responsibility. This makes for a process full of authorizations and a manager who gets loads of emails with authorization requests.

The process shouldn’t be this cumbersome. It works better when the IT department asks the managers how much control they really want or need. They usually don’t really want to receive all those emails. An alternative solution: requests don’t need to be authorized, and managers receives a monthly overview of the costs. This way, the manager still has control over and an overview of the costs, but he or she doesn’t have to process a lot of emails. And the employee is helped quicker.

Tip: just get started and keep it small

I sometimes get the question: where do I need to start when I want to work more agile?

To be honest, that differs per organization. Take a close look at your current services and compare this with the agile principles. Where’s the friction? And what improvements are easy to implement? Start there. Make a small improvement. Ask for feedback. And move on to the next improvement. And read our Agile e-book

The post Agile service management in practice? 6 examples appeared first on MCG - EN.

In this FAQ, we answer four of the most frequently asked questions about agile working.

1. What is agile?

Simply put, agile is an approach to software development that helps teams be more flexible and deliver customer value faster. But most importantly, agile is a mindset.

The agile mindset is similar to that of a jaguar: its instinct is to survive. And to survive, a jaguar needs to be agile enough to react quickly to the movements of its prey.

For organizations, it’s just as important to be agile – especially now, in the age of digital transformation. Organizations need to be flexible enough to quickly respond to modern technologies and the ever-changing demands of the customer.

While agile working originated in software development, its mindset is applicable to all fields.

2. What are the benefits of agile working?

The main reason that agile was introduced into software development was to make large organizations more flexible.

For smaller organizations, responding quickly and meeting their customers’ needs is fairly easy. But large companies are typically a lot less flexible. They often use a waterfall approach for projects: a plan or design needs to go through different departments and management layers before it can be executed. The result? An unwieldy organization that’s slowed down by complicated processes and lacks innovation.

Agile working, on the other hand, strives for the least amount of bureaucracy possible. It makes organizations flexible, reduces response times and focuses on customer value rather than on hierarchy.

In addition, agile working empowers employees: the power to take initiative isn’t with the manager, but with the experts. In an agile working environment, you want employees to share knowledge, act on creative ideas, and come up with solutions – not just follow orders.

Agile service management means applying the agile mindset to IT service management. Nothing more, nothing less.

3. What is agile service management?

Agile service management means applying the agile mindset to IT service management. Nothing more, nothing less. To make this work, the original four agile values simply need one adjustment. With agile service management, instead of focusing on software, you focus on services:

• Individuals and interactions over processes and tools
• Working software services over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The idea is that you keep to these principles when designing and delivering services. Sounds straightforward. And in a sense, it is. But how do you apply agile service management in practice?

4. How does agile service management work with ITIL?

At first sight, agile and ITIL look like totally opposing concepts. Agile is all about flexibility and ITIL is an extensive framework that offers guidance and best practices for all five stages of the IT service lifecycle. But it’s definitely possible to pair agile service management and ITIL. You just have to do it right.

Most organizations are still built on older versions of ITIL, which don’t offer much flexibility. This outdated approach to ITIL attaches great importance to everything the agile mindset believes to be less important: individuals and interactions over processes and tools.

But the latest iteration of ITIL, ITIL 4, focuses less on prescriptive processes and more on guiding principles for delivering value. Unlike ITIL v3, ITIL 4 doesn’t tell you exactly which steps to take to deliver a service but focuses more on why you’re delivering that service – to provide value to your customers. A perfect match with the agile mindset.

And, while ITIL does have a reputation for being rigid and unnecessarily complex, that was never the starting point. The idea behind ITIL wasn’t that organizations would implement every aspect of ITIL to the letter. The message of ITIL was always: make sure to apply the framework in a way that best suits your organization. Or: adopt and adapt – a piece of advice that clearly aligns with agile working.

Ready to bring back speed, flexibility, and customer focus to your IT department?

Download the agile service management e-book to learn everything you need to know to make your IT department more agile – from seven common pitfalls of agile transitions to making your Service Level Agreements more flexible.

The post What is agile? Agile FAQ appeared first on MCG - EN.

In this blog I’ll talk about how to implement a single change in an agile way, as well as how to make all your department’s changes more agile.

Agile Service management vs Change management

We’re continuing our exploration into Agile Service Management – to find ways you can make your Service Desk operations more speedy and less rigid. So far, we’ve looked at how ITIL and Agile can work together, drilled into Agile Incident Management and also published a whole e-book on the topic.

Most recently, we’ve been exploring Change Management from an Agile perspective. Let’s continue exploring that topic. How does it work in practice?

How to implement a single change the agile way

Let’s start with how to make the implementation of a single change more agile.

Only describe your goal and preconditions

In an ideal world, you don’t fill out a full change request form when you’re first submitting your request. Your description only contains basic information. The most important things you need to include are your goal and preconditions.

Here’s an example: You often get multiple calls about a coffee machine breaking down or email servers being slow. You’d prefer not to get a bunch of calls about the same problem, so you want your customers to be able to see whether a problem has already been reported. Your goal is: showing customers which calls have already been submitted. But you also want to make sure your customers don’t get to see private information of other customers. That would be one of your preconditions.

Apart from the goal and preconditions, there’s not much you really need to know when you get started with a change.

Check regularly if your change is still meeting the preset goal and preconditions

Are you still implementing changes according to the traditional waterfall method? Then there’s always a chance that when you’re done, your solution turns out not to meet the customer’s needs. Because the waterfall method assumes that you directly execute the plan you’ve drawn up, without alterations along the way. There’s no room to adjust to new situations. And your situation can change. You may find out new information about what your customer really wants, or there might be new technologies on the market that provide a better solution.

So, while you’re designing and implementing a change, regularly check the following questions:

Does what we’re doing right now still contribute to the original goal?
Are we still meeting our preconditions?

Is your solution no longer sufficient? An agile process lets you make adjustments along the way. But maybe you’re already past the point where you could have changed course. If that’s the case, don’t be afraid to pull the plug on your change. Pulling the plug may be a hard thing to do, because you’ve already invested time and energy into it. But quitting on your change is still better than working on a solution that isn’t going to help anyone.

Get other experts involved with your change

Once you’ve got an idea of how you want to implement a change, have different experts take a critical look at your plans. What’s the impact of your change on other applications and hardware? Will the change lead to security risks? Traditionally, this sanity check would be done by members of the CAB when they evaluate a change request. According to the agile philosophy, it’s much better to let your team come up with their own solution. But if your team figures everything out for themselves, who will do the sanity check?

Freedom comes with responsibility. Don’t just give your team the freedom to come up with a solution, but also make them responsible for consulting with relevant experts to check whether their solution will work.

How to handle all changes in a more agile way

Your IT-department rarely works on just one change at a time. Even a small IT-department with just 6 to 8 people will often be dealing with 10 to 20 changes at a time. But that’s too many.

Run as few changes as possible at the same time

The solution is simple: limit the number of changes you’re executing at any given time. It’s easier said than done, of course. But it’s worth the effort. You kill multiple birds with one stone:

It becomes easier to predict the duration of changes. Working on fewer changes at once means you’re working with fewer variables, so you can better predict when you’ll finish a change.
The quality of your service becomes higher. If you’re able to focus more on the change you’re currently working on, you don’t make as many mistakes.
Working on changes becomes more fun for your team. You’re able to focus on your work and you see results quickly. Research shows that visible progress is one of the most important factors that determine happiness at work. Getting things done in time is much more motivating than feeling like you’re always working on a hundred different things and nothing is ever finished.

Changes vs. incidents: make a clear choice

How do you make time for changes when there’s also a constant flow of incidents coming in? Make a conscious decision about your team’s priorities.

Do you want to guarantee a maximum duration for changes? Then you have to dedicate a set amount of time that each team has to spend on changes. Which means you have to accept that incidents may be on the shelf a little longer sometimes.

Do you feel it’s more important that tickets get solved quickly? In that case you need to accept that changes sometimes take a little longer to implement. And that your team won’t be able to pick up new changes very quickly.

Has your change process become overly complicated? This is how to simplify it.

Explore more about Agile Service Management

Agile Change Management is still in its infancy. Have you experimented with it? Find out more ways to make your Service Desk be more efficient through Agile with our Agile ITSM e-book.

The post Agile Change Management in practice appeared first on MCG - EN.

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:

The post 7 things to avoid when applying agile to ITSM appeared first on MCG - EN.