Regular readers of my blog on The ITSM Review, or over at ScrumProUK know that I enjoy exploring the gap between the worlds of IT Service Management and Agile development methodologies.
Today I wanted to go back to basics, back to square one and start over by explaining why you – as a reader from the world of Service Management or corporate IT – should care about Agile principles and what it can bring to your organisation.
I’m glad to see one commonly held misconception being broken down and disproven recently. The assumption that an organisation cannot be both Agile and IT Service Management orientated.
Even the oldest, most stubborn and most skeptical of Agile critics (his words!!) are coming around to the idea that an organisation that can excel at both disciplines. Hurrah. There is a growing Google+ community dedicated to it – Kamu: Uniting DevOps and ITSM.
To introduce principles to those that are unfamiliar, I’m taking inspiration from Tobias Mayer who identified 5 benefits of Agile (in this particular case Scrum) that will help me orientate you.
“A man who chases two rabbits catches none.” ~ Roman Proverb
A core principle of popular Agile methodologies such as Scrum and Kanban is to limit Work in progress. Scrum teams, for example, will agree to take on a small subset of work from the overall backlog within a timeboxed period, normally between 2 and 4 weeks.
By limiting the teams focus and attention on what is most important you enable them to complete work to the appropriate quality standards; and by limiting work in progress we train teams to finish work, rather than start additional work. With focus comes attention to detail and less mistakes, a higher level of quality and ultimately happier customers.
Look around your IT department today as you read this article. Do you see teams that have more work than they can handle? (Probably). Do those teams have a clear understanding of what is most important (probably not)?
How can Service Management teams adopt the Agile principle of providing focus for their teams?
Start by understanding your work. Where does it come from? How does work arrive in your department. Visualise your work by using a tool like LeanKit, Trello or Kanbanize (all have free editions for you to try). Use one of these tools to identify which work items are the most important and challenge the team to finish those items.
By reducing the scope of work that a team is paying attention to you’ll see a change in behaviour, delivery time and quality.
Agile teams work with the principle that plans will change; that we will understand more about the work once we near completion and that no amount of planning really prepares us for the road ahead.
This is true for software development projects where Agile is accepted but of course it’s also true for IT maintenance and operational projects too. How many of your projects delivered exactly as predicted on day one?
Knowing that business requirements will change frequently and that the assumptions made before work begins are normally wrong, Agile teams handle this by working in iterations.
By planning months into the future with “just enough” detail and by focusing in granular detail on only the next 2 week sprint, a team can easily absorb changing business requirements.
By meeting with the business on a frequent basis, by examining the overall plan (in coarse detail) and by re-prioritising against the current business requirements Agile teams achieve alignment with the business. They can plan for the next iteration in detail knowing they are working on the most important thing based on todays knowledge.
It’s no use being perfectly aligned at the start of the project and not having a system to cope with the ever changing demands. Changing requirements in a project are a good thing – it means we will have a better solution in the end.
Do your IT project teams try and control changing requirements… do you welcome them?
How can Service Management teams achieve alignment with the business?
By structuring work so that teams can focus in the short term but change direction to react to business demands. For Service Management teams this might mean short term focus on a set of metric goals to solve a particular business problem. Just having the routine of sitting with the business and reviewing priorities is a great first step.
“I don’t test my code often but when I do I do it in production” ~ Internet meme
Earlier I mentioned Focus as a principle of Agile teams and that by concentrating on a small subset of work that is most important to the business we can train teams to deliver. Rather than having lots of work open and diluting the teams attention.
There’s another benefit in limiting Work In Progress with regards to quality engineering. Imagine a team that has no control over its work and everything is urgent. The team has no Focus and no Alignment with the business – no understanding of what is truly important.
That team is likely to produce low quality work. By trying to complete everything at once they’ll often do just enough to call it done. This results in risk lurking in your infrastructure; the worst kind of work that will leap out on you when you aren’t expecting it. Work you thought was done… but isn’t. Rework!!
Agile teams use the system of limited WIP as well as technical practices and standards to get work done once so they can move on to the next task.
Could you improve the quality of work by defining standards and shielding your team by limiting work in progress?
How can Service Management team promote artful making?
Have a “Definition of Done” for common activities. Not a huge, heavy operations manual that no-one will ever read but a collection of one-page definitions of what it means to be done with a server build, a software installation, a Problem ticket.
Make the definition of done visible and easy to use, your engineers will know when they are finished with a piece of work before moving on.
“None of us is as smart as all of us.” ~ Kenneth H. Blanchard
The best architectures, requirements, and designs emerge from self-organizing teams. Teams that are not controlled but enabled. Teams that stay together long enough to form an esprit-de-corps and that trust each other enough to have passionate debate and disagreement without destroying the teams culture.
The worst experience that an engineer can have is to be presented work that was designed by someone else, work that has no scope for flexibility or creativity, and worst of all to be told how long it will take.
Have you ever worked on a project where the scope, implementation and deadline were predetermined by those that aren’t actually going to do the work? How does that even happen??
Agile teams are self-organising within the constraints of the organisation in which they operate. They receive requirements that describe the business need (The “WHY”) and acceptance criteria (“The WHAT”) and they, as a team, determine the solution (The “HOW”).
Self-organising teams scale much better than command-and-control style teams, where a manager delegates and defines the work.
Why would you want to have your expensive managers involved in assigning tasks and resource levelling? Members of a self-organising team know when they have spare capacity for more work and they pull work into their queue.
How can Service Management teams become more self-organising?
I think this is a simple one – do you have managers that delegate work or leaders that coach teams to success? If you have the former is that the best use of their time and skills? Give the team an opportunity to own their work and determine their own destiny, within the constraints of your organisation.
This loss of control by managers might result in a team more invested in its success, more motivated and higher performing.
“Rhythm is something you either have or don’t have, but when you have it, you have it all over.” ~ Elvis Presley
Agile teams are focused on the regular delivery of value into the businesses they serve. By limiting work to sprints, usually between 2 and 4 weeks long, they are able to continuously deliver work building a partnership based on trust.
Short time-boxes focus teams on an objective they have to meet – by self-organising they control the scope of work that is achievable within that sprint. When I started delivering work to a company using Scrum I asked my stakeholders which attribute of the work they valued most.
Was it the speed or the volume of work, or the number of features we delivered? No – organisations rely on predictability and working in set time-boxes, or sprints, makes your team predictable.
Compare this to projects that defer the delivery of value until the end of the project. Rather than release early and often they buffer the features and aim to deliver all in one large batch.
If that deadline is delayed two unfortunate things happen – firstly trust between the team and the business is eroded. And secondly the value represented in the features that are done but not released cannot be realised until all work is delivered.
Do you have a trust between the IT organisation and the business which is built upon a rhythm of regularly delivered work?
How can Service Management teams get that sense of rhythm?
I love the idea of working within constraints. It focuses the mind and makes people be creative. Even if you don’t work in software engineering define a series of 2 week “sprints” for your Service Management team.
Declare an objective for the two week sprint – “we are going to reduce the incident backlog to under 50”. Let the team self-organise and think about your teams objective for the next sprint.
Thanks for Tobias for his 5 attributes of Agile teams that I’ve expanded and commented upon. My aim here was to outline the benefits of Agile to teams outside of the world of software development. I hope that readers that work in IT Operations and engineering can compare the way they work currently against these ideals – all of which are simple and cheap to implement and realise.
Ultimately the ideas of focus, alignment, artful making, self-organisation and rhythm promotes a culture of learning – about the work you handle, about how the team performs and how you interact with the business.
Combine these 5 principles with the idea of regular, structured retrospection and I think you are well on the way to having a highly performing team.
I would love to have a discussion with you in the comments or on Twitter. Or come to the Kamu Google+ group and discuss with your peers there.