The digital age, and all the behaviors it brings with it, means that organizations need to up their game if they’ve any hope of keeping ahead of their competition. With this requiring them to embrace change, to be flexible, and to respond quickly to changing demands as an absolute must. They need an Agile approach to service design, creation, delivery, and support. But what does “Agile” mean? This blog will explain.

In the digital age you need an #Agile approach to service design, creation, delivery, and support. But what does “Agile” mean? This blog by @Joe_the_IT_Guy will explain. Click To Tweet

The origins of Agile

Let’s take a trip back in time. It’s 2001 and seventeen software developers have come together to talk about the barriers and complications that surround their role. They want to make software development easier for themselves and others like them. Out of their discussions the “Manifesto for Agile Software Development” was born.

In a nutshell, they agreed that the old-school methods for software development weren’t cutting it and accepted that things needed to change. In particular, the rigidity and ineffective communication meant that customer expectations weren’t being met, and time and money were being wasted.

The Manifesto for Agile Software Development

Their solution – the Manifesto for Agile Software Development – was built upon four important values:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan.

It’s important to note that what’s on the right of these statements is not to be ignored, rather that what’s on the left is more important and should be given priority focus.

I’ve witnessed organizations dismiss documentation altogether and begin a project without any kind of plan in place, all in the name of Agile. So, let’s make this clear, Agile doesn’t suggest that you completely ignore the right-hand side of its values. Instead, it’s designed to lead you toward considering what’s most important and where to apply your main focus.

Let’s explore each value in a little more detail.

1. Individuals and interactions over processes and tools

Of course, Agile sees the value in processes and tools but it recognizes that without the right people in place, no matter what processes and tools exist, they’ll often be ineffective. This rings true for IT service management (ITSM) too.

#Agile sees the value in processes and tools but it recognizes that without the right people in place, no matter what processes and tools exist, they’ll often be ineffective. Click To Tweet

Agile promotes a step-back from the traditional micro-management of people and instead pushes for self-organized teams that interact face-to-face on a regular basis. For example, daily scrum meetings are suggested as a way to encourage communication, track progress, and reveal any potential blockers such that they can be tackled quickly and effectively.

Tools and processes are enablers and will always be important, but people and interactions are the real drivers. So, trust your people to do what’s required. If they need to step outside of a process to progress, then let that happen and see what comes of it. Again, it’s something that would work in ITSM.

Organizations can get stuck when they stick to a process believing that it’s best practice. In reality, best practice cannot and should not be applied to all situations, oftentimes you’ll be required to collaborate and experiment to find the best way through.

Tools and processes are enablers and will always be important, but people and interactions are the real drivers. So, trust your people to do what’s required. #Agile #ITSM Click To Tweet

2. Working software over comprehensive documentation

No, it’s not an excuse to never write documentation again. The assembled software developers flagged that extensive documentation was one of the barriers to progress they were facing. There weren’t enough hours in the day to get detailed documentation in place, to keep it up to date, and to deliver perfectly to customer expectations.

Something had to give and what Agile says is that it’s more important to deliver working software to your customers than it is to have comprehensive documentation neatly written and packaged away.

Write the documentation, yes. But only include what’s truly important and actually adds value to the reader, anything else can go. Instead, use the time to concentrate on delivering a product/service that will exceed expectations and keep customers happy.

3. Customer collaboration over contract negotiation

Sure, sort out the basics of your contracts but don’t forget about your customer during the creation process.

Agile aims to deliver a high-quality product that satisfies customers. In fact, customer satisfaction is a top priority of the Agile mindset. But high satisfaction levels can only be gained by delivering a product or service that meets expectations and demands, and here’s the kicker – it’s very likely that your customers’ needs will change throughout the process. And if you’re not collaborating with them for the duration of the development process, then how are you going to know what they actually want?

Hence, Agile focuses on delivering in incremental stages. That’s to say that it splits up projects into smaller cycles, delivering bit by bit and getting feedback at each stage. The benefit here is that anything that’s not working for the customer can be detected immediately and acted upon.

Compare this to the traditional “Waterfall” software development method that completes a project in full before delivery. Here, on delivery, if something isn’t meeting the customer needs it will likely take an awful lot of work to undo and recreate what’s been asked for.

4. Responding to change over following a plan

Of course, you should always have a plan – you need to know what you’re creating, who’s going to be involved, how things will look, what will happen and when, etc. But, and it’s a big but, you need to be flexible, and that’s what being Agile really means. Be flexible, don’t just accept change, embrace it, understand that just because you’ve made a plan it doesn’t mean that you can’t veer from it.

Sure you should always have a plan, but, you need to be flexible, and that’s what being #Agile really means, says @Joe_the_IT_Guy. Click To Tweet

When you’re collaborating with your customers effectively it’s more than likely that they’re going to make requests that didn’t exist at the outset. Or they’re going to realize that they want something different from what they originally requested. The beauty of adopting Agile is that this can happen, and your teams won’t have a meltdown. Instead, they’ll be ready to react and respond accordingly.

Agile’s 12 principles

To support the four values, the Agile Software Development Manifesto sits atop twelve principles:

1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Deliver working software frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done – is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.

There’s a lot to Agile, but I hope that this introductory blog has helped you to discover a little more about what it means to be Agile and why it’s worth taking notice. Especially when people start to talk about the need for Agile Service Management (which I wrote about a while back). You can also read more about Agile in my A-Z of Agile blog, which covers the key points and terms in greater detail.

So, what do you think about Agile and its greater adoption from an ITSM perspective? Please let me know in the comments.