Scrum vs Kanban

Is this an Alligator or Crocodile? Read this article to find out (Oh... and you might learn about Kanban and Scrum too!)
Is this an Alligator or Crocodile? Read this article to find out (Oh… and you might learn about Kanban and Scrum too!)

What are the differences between Scrum and Kanban anyway?

When you’re studying two similar animals from different species – I don’t know, lets use crocodiles and alligators – it’s easier to spot the similarities than the differences. I’ll give you one now and reward you with another difference for reading all the way to the end of my article.

Crocs can lift their bodies off of the ground, gators can’t. Did you know that?

This is a similar problem for those of us that are beginning to explore the world of Agile, Scrum and Kanban. Are they the same? From the same species? What are the differences?

It’s so easy to see the commonality, because the distinctions are nuanced and harder to spot. If you’re not careful you’re unable to spot one from another.

Let me help you explore some of the diversity between Agile/Scrum and Kanban

Back to the beginning…

Before examining Agile/Scrum and Kanban it is worth pointing out that there are many distinctions to be drawn between Agile and Scrum. They aren’t one and the same thing and there is probably a whole other article for a whole other day to write them up.

For the purposes of this article I want to draw your attention to the suitability of Kanban in IT Operations and to achieve that I can leave Agile and Scrum lumped together.

The first place to understand the contrast between Scrum and Kanban is to look back at the roots of each method.

Scrum was born out of a line of iterative software development methodologies stretching back to the 1960’s and ‘70’s but coming into prominence in the 1990s as a pushback against the heavyweight Waterfall project management practices. In the ‘90’s methods such as Scrum and Extreme Programming became popular and in 2001 the Agile Manifesto was written to bind these disparate practices under a common banner.

But remember that Agile/Scrum was initially formulated to solve a Software Development Lifecycle problem.

Kanban incorporates a number of practices codified by the automobile manufacturer Toyota as part of TPS – The Toyota Production System – a precursor to the wider Lean movement which emerged in 1990.

These roots are based in business process, in manufacturing, in the process of refining raw materials into a valuable product through manual and automated labour. In converting chunks of rubber, steel and glass into gleaming, shiny cars rolling off of the production line.

Whereas Agile/Scrum was formed to provide an alternative to heavyweight Software Development Lifecycle methodologies, Lean has been more aligned to core business processes – seeking efficiency gains and quality improvements.

My objective here is to speak to you as IT Professionals considering adopting a Lean or Agile approach to IT Operations. It’s worth pointing you towards the works of David J Anderson who in 2010 wrote “Kanban: Successful evolutionary change for your technology business”, informally known as “The blue book”. This is the specific variant of Kanban that you want to study and learn more about.

So wait.. Kanban is not Agile?

If we are following strict definitions and examining Agile/Scrum and Kanban as if they were two separate animals… no, Kanban is not an Agile practice. It is a Lean practice.

But Kanban delivers a lot of the same benefits into an organisation that Agile promises to. And, as we’ll discover later in this post, does it in an evolutionary way rather than throwing the rule book out and introducing strange, new practices.

You could say that Agile, if done correctly introduces Agility into an organisation. Notice the capital “A” there. Kanban introduces business agility with a small “a”

More importantly where Agile/Scrum promotes product development agility, Kanban is positioned to make the whole organisation more agile.

Kanban practices can be used across the organisation from marketing, sales, product development and customer support and value chains can be found stretching between these organisations. Best of all heavyweight processes such as Waterfall, change and release management can happily exist with the wider Kanban framework.

This is the “evolutionary” part of the description in Davids book. Taking existing business processes, defining them as part of a value stream and finding ways to optimise the work.

OK – tell me more about Scrum

Scrum is a lightweight framework that defines roles (like Product Owner and ScrumMaster), artifacts (like Product Backlog, Release Backlog and Sprint Backlog) and practices (like Daily Standups, Sprint planning and Sprint review meetings).

Teams following Scrum take a body of work – typically a list of features that are required to build a software product – and break them down into discrete units of work (called User Stories) that can be re-prioritised according to business needs.

By taking a small section of those units of work and committing to finishing them before a short-term deadline (known as a sprint – often 10 working days) the team can focus on building the next small increment of the product before stopping, replanning and committing again.

Scrum is great! I’ve been successful with teams that have used Scrum to build products. But it is a fairly disruptive method and you won’t get 50% of the benefits by putting in 50% of the effort.

To be successful at Scrum you have to allocate people roles, train them and arrange your work according to the methodology. Expect to have backlog grooming sessions, to measure your work in story points and so on.

Scrum is a fairly prescriptive method that requires the team to bend around the rules in order to follow it correctly.

Much of the work in IT Operations is driven by external factors – servers experiencing hardware issues, ISP’s having intermittent connectivity issues. Although it’s nice to plan around the stability that Scrum promises – with a fixed sprint backlog of work – the reality is that teams have to deal with interrupt driven work and absorbing this isn’t a strong characteristic of Scrum.

There is another characteristic of Scrum that appears to make this activity very similar to Kanban… that is if you didn’t understand the difference between crocodiles and alligators.

The last thing to mention is that Scrum teams often maintain a “Scrum board” visualising their work on cards into lanes.

Scrum Board

OK! Tell me more about Kanban

Well, the last thing to mention is that Kanban teams often maintain a “Kanban board” visualising their work on cards into lanes.

Kanban Board
Kanban Board

Herein lies the difficulty in distinguishing between Scrum and Kanban when the most visible artifact for either method is exactly the same.

But there are significant differences with Kanban. Firstly it is an evolutionary method to introduce change in an organisation. Meaning that no additional roles or practices are introduced by organisations that adopt the method.

Existing roles and processes are kept but are wrapped into Kanban. Workflows are investigated and visualised to provide control around the work but we don’t change how people do their jobs or interact.

Scrum deals with the problems associated with Product Development and introduces methods to increase Agility.

Kanban examines the value stream upstream (perhaps into the sales and marketing departments where leads are generated) through the manufacturing/development/technical departments down to the point where value is released to the customer – how products are shipped or released.

It’s similar to the same way that a manufacturing process for a Toyota car is defined all the way from the raw steel arriving at one end of the factory through the refinement process until a car rolls off the other end. Kanban maps and provides controls throughout the whole value stream.

Imagine you are in control of new laptop builds in an IT department. Surely you have a value stream which starts with a request from HR notifying you of a new employee. Actions are taken – laptops ordered, imaged, configured, added to the various management systems. At some point later (much later??) the laptop is delivered to the employee. You’ve just described a value stream that can be visualised, managed and incrementally improved with Kanban.

Here is a visual outlining the differences between the two animals.

Scrum versus Kanban
Scrum versus Kanban

In summary

I promised to reward you with the last difference between crocodiles and alligators. Look at the snout – but presumably from a distance. Crocs have a longer, sharper “V shaped” snout. There you go!

But this isn’t the action that I want you to take away from this article. Your IT organisation should be investigating new ways of working and building a culture of high performance and continuous improvement.

Agile/Scrum and Kanban are all worth investigating. My call to action in this blog post – if you are in a position to suggest work improvements in your department – is to buy David J Andersons Kanban book and see how evolutionary change is possible in your corner of the world. (Amazon Link)

Most successful Kanban adoptions are lead from the “middle out”. That is junior managers taking the initiative and adopting Lean practices influencing those that carry out the work. Their successes often influence upwards as senior managers identify the resulting service improvements.

Who knows – buy the book today and in a few months you could be blogging your IT transformation using Kanban on the ITSM Review. I’m looking forward to that!

Image Credit

…It’s a Crocodile

Enterprise Release Management Tools Group Test

The ITSM Review will be performing a deep dive review of Enterprise Release Management tools.

This article provides an introduction to Enterprise Release Management (ERM) and a high level summary of typical functionality.

Notes

  • This group test will be conducted by Rebecca Beach, our ITSM Analyst, and Rob Spencer, Change and Release specialist and vice-chair of the UK itSMF Transition SIG.
  • We’ve also included a few examples of providers who offer ERM capabilities – please let me know of any other suggestions.
  • If any suppliers wish to participate in our Group Test please contact us before 30th September 2014.
  • Learn more about our Group Tests.
  • Read our back catalogue of completed Group Tests.

Thanks, Martin


Introduction to Enterprise Release Management

By Rob Spencer

How do organisations plan tens or hundreds of releases a year across project delivery, vendor patching, infrastructure changes and more? How do they manage competition for access to test environments, ensure they spot colliding production releases in good time and avoid overbooking their test teams?

How do they articulate this enterprise-wide release roadmap to senior stakeholders, customers and IT staff?

Traditional answers to these questions usually take the form of project plans and spreadsheets. They rely on regular meetings between project office, operations & technical staff to keep them in sync, and are rarely, if ever, accurate in real time.

Today, a new breed of release management planning tools is emerging. Enterprise Release Management tools are agnostic of functional requirements or constituent change requests, and they don’t manage the actual deployment of code. They simply allow the entire IT organisation to track and manage the entire portfolio of releases across all environments. They have the scope breadth of a Change Schedule, but go into more detail.

At their simplest, they are a single source of the truth for the multitude of spreadsheets they replace, but most can pivot this data to provide people with the information they care about in customised and intuitive views – from CIO roadmaps to a test manager’s forward work plan.

Ultimately, they give Service Operations a reliable, realtime view of all upcoming releases with at-a-glance assurance that the right governance has been completed for each. And since they span both development and operations, many are starting to be called DevOps Release tools.

ERM

What does an Enterprise Release Management tool do?

  • Plans (and scopes) a release – Allows the construction of an end to end release plan following a user-customisable structure which could map to eg. an organisations’ project governance gateways. Should be able to record both governance activities/milestones as well as physical activities in multiple environments (deployments, test runs etc). Ideally should be templatable and re-usable.
  • Plans ALL releases – Takes the individual releases and plots them against a common timeline to spot resource over/under utilisation, go-live collisions and tells operations when to brace for action.
  • Manages environment & resource usage – Pivots the data from all releases and show an environment – or resource -centric view of the same data. Helps answer questions such as “what’s happening in our Pre-Prod environment next week?” or “can I deliver everything I promised?”
  • Presents data in various views depending on audience – The steering committee has different needs to those of a test manager, and the project needs to be able to see anything relevant with a few clicks. Does the tool allow varying levels of detail to be presented over user-defined timescales in a clean and coherent way no matter the format?
  • And not forgetting… – Role based access to stop people from seeing the wrong things (or changing them), the ability to dynamically import and update change requests from other tools (data exchange mechanisms such as XML and RESTful APIs are becoming the norm in service tools).

Methodology

To test these, we’re constructing an entire fictitious company with a busy year of releases including new system deliveries, infrastructure refreshes, monthly & quarterly patching to cloud and on-premise services. We’re covering both agile and waterfall development & delivery methodologies, and even introducing some DevOps practice. We’re sharing this case study with the participating vendors, and we’re also going to make our own spreadsheet versions of the plans (which we won’t share with the vendors in advance). Our case study also includes some fairly thorny problems which a typical organisation could encounter eg. scheduling conflicts, people not following process and people whose idea of planning is far removed from the reality of their customers’ needs.


Here are some tools we are aware of in this area.

If anyone knows of any others please leave a comment below or drop us a line. I will update the list as we find new suggestions. Thanks, Martin

Agile CSI: continual service improvement done right

10034579444_60a0fdc982_zDon’t worry. I am not going to rant on about hypothetical methods or visionary statements. I will not explain why agile is important for the ITSM industry, nor will I explain why agility is crucial for business survival. After all, these are no-brainers, right? I will only use your valuable time to illustrate a practical experience on implementing continual service improvement (CSI), the agile way.

In the past few years I have been privileged to apply lean and agile principles, methods and instruments to many different (IT) service environments. Most of the assignments were focused on delivering more value to stakeholders, improving collaboration between functions and domains, and reducing change lead times. However, one of the most intriguing assignments revolved around creating a culture of continuous improvement for a professional services company.

The problem

First, here’s some context. The customer I am referring to, is in the business of providing professional infrastructure and telecom services to its customers. The IT director realized they had a huge problem, when their largest customer repeatedly complained about their supplier’s reactive behavior. Surely, the customer got what they asked for, but there was no such thing as proactive service management, let alone continuous improvement of processes and services. My customer thought that they had this covered by having an extensive description of a CSI process, according to ITILv3. Yet somehow, no real improvements were initiated, let alone carried out. I profoundly assume this does not surprise you.

ITIL

Looking at the core objective of CSI, I have always applauded this addition to the ITIL set. After all, it recognized the essence of having a flying wheel for improvements throughout the IT service organization and lifecycle. However, allocating a separate process and rather waterfall and administrative approach to achieving this objective, is why ITIL’s CSI falls short in so many implementation attempts. Similar to Imai’s Gemba Kaizen, successful continuous improvement in IT services involves small, bottom-up, incremental improvements, integrated in business as usual. In addition, ITIL fails to address the most important element of achieving continuous improvement: culture. For instance, as long as the culture of the organization does not reward improvements or even does not allow mistakes to be made, those mistakes/errors will be covered up, instead of being visualized, improved and learned from.

Agile

This is where the Agile way of thinking comes in. At this organization, we introduced agile principles (eg. multidisciplinary, self-organized teams), methods (scrum) and instruments (kanban) to address their improvement issues, and to grow towards a proactive service organization. We started off with scrum. First by ensuring all stakeholders had a shared understanding of agile principles, the scrum process and its relevance to support and operational environments. After that, we allocated the roles. The complaining customer picked up the product owner role, whereas the service manager became the scrum master. The primary people involved in the service chain (service desk, design, develop, test, operations, main supplier) were involved as team members.

Then, as a joint effort, the entire team investigated the current opportunities for improvements, both on processes and delivered services. All improvements were collected on a product backlog (i.e. an improvement backlog). We used a uniform format to write them down: user stories. The good thing about user stories, is that they are short and simple, yet always address the “why” question. This resulted in user stories such as below:

agile

In parallel, we used planning poker as an instrument to estimate the improvements. I find this a particularly useful way of estimating both changes and improvements. The relative measure (story points) appeals to the unpredictive and indeterministic nature of so many changes and improvements.

In two weeks time, we had the product backlog filled (i.e. “ready” for 3 sprints), and prioritized by the product owner. So yes, this means that the customer decided where improvements were to be made first. After that, we narrowed down the product backlog into a sprint backlog for the first sprint and started off with a planning session for that sprint. Here, we created tasks for the allocated user stories, which were added to the physical scrum board we had set up. Together with the other, obvious ceremonies (stand up, demo, retrospective), the scrum process was in place and led by the service manager (scrum master). Every day, the team members pulled their actions through the process, picked up and realized the improvements during the 3 sprints.

Results

After three sprints of each one month, 80% of all identified improvements had been realized. And implemented. Result: an engaged customer, visibly happy with the improvements made thus far and confident regarding the proactive capabilities of the service organization. But it didn’t stop there. Yes, we stopped using scrum. After three sprints the backlog almost evaporated. But at that time, it was still positioned as a separate instrument. That is why we incorporated all future improvements on the regular kanban board, which was already used for incidents, problems and changes. Improvements became business as usual. All team members, including the customer, were actively involved throughout the delivery chain, all aimed at continuously improving the service delivery chain. The people involved were all aware of the priorities of their work in progress, and the value of their daily improvements.

I hear you say: this sounds too good to be true. Of course, we encountered several problems along the way. Quite a few team members were skeptical with regard to using agile principles and instruments. Showing them the value of visualization, sharing tasks across the multidisciplinary team and providing insight into the entire delivery chain, really catalyzed their changing attitudes. In addition, it was certainly not easy keeping everyone on track and on focus for the improvements during the sprints, next to their daily incidents, project work and other engagements. Daily stand-ups, management attention and visualizing results have surely contributed here.

The future

Creating a continuous improvement mindset is all about stimulating a learning culture. You are never ready. The same goes here. Having a CSI mindset is not enough to keep learning effectively. Further improvements for this organization include the optimization of measurements, and a further integration of Lean and Agile elements, or from Rob England’s TIPU framework.

Agile CSI is only one example of how agile and lean principles and instruments can help the IT function deliver great services. ITSM has a key role in achieving this, by sharing practical experiences, good practices, but most of all creating the conditions for all stakeholders to improve their work, processes and services.

Want to hear more from me on this topic? Join my BrightTalk webinar on 10th September 2014.

Image Credit

Case Study: Domtar decimate ITSM tool configuration costs with codeless

CLICK TO ENLARGE
CLICK TO ENLARGE

One of the first articles we published on the ITSM Review back in 2011 described the market shift from consulting-heavy customized ITSM projects to the simplicity of ‘configure it yourself’ SaaS based offerings, and in particular the significant change in cost structure (‘The ITSM Pricing Ouch-o-meter).

Agile ITSM

Once upon a time the ability of suppliers to ‘darken the skies’ with consultants was a competitive feature. Nowadays organizations want sufficient autonomy to do things themselves, if not the mentoring pathway to get them there.

This independence provides agility. Ultimately the goal is to empower IT teams to stop on a sixpence and duck and weave as the business sees fit. To dramatically shorten the protracted cycle of budgeting and planning long term consulting engagements to turn the tanker.

The IT department shouldn’t disappear into the basement for two years to build the next big thing, but should trickle out increments to ensure they are relevant, timely and valuable.

So far, so groovy. But what does all this newfound ITSM agility do to the bottom line?

Opening the corporate kimono

The case study below, commissioned by EasyVista, digs into the financial impact of moving to a more agile ITSM system. Thank you to Benoit and Bob at Domtar for being so candid and sharing their financial data.

Kudos also to EasyVista for the confidence in allowing us to publish this case study verbatim. The responses below, which I hope you will find to be balanced and honest, have not been edited by EasyVista or exposed to the usual PR polish.

The transition to EasyVista

BEFORE

  • Previous Software: 10% of development in-house, 90% developed by external consultants
  • Development inhibited by costs and by the lack of flexibility in the tool.
  • Upgrades were made difficult by any customization.

After reviewing eleven different ITSM tools Domtar chose EasyVista.

AFTER

  • Implementation began in Summer 2012
  • Now 5% – 10% is developed externally and over 90% – 95% is configured in house
  • Significantly lowered / eliminated development costs

Codeless Economics

Hard savings:

  • Annual saving on ITSM Tool configuration costs: 89% (i.e. They are investing one tenth of their previous spend on changing their ITSM tool)
  • Reduction in ITSM tool annual maintenance: 75% (i.e. They are only paying 25% of their previous annual ITSM software maintenance bill)

Return on Investment:

  • The total first year EasyVista investment (software and implementation) was an estimated 113% of the previous annual maintenance and consulting bill. So in other words, Domtar were able to rip out the previous solution and replace it with a better system for just over the maintenance cost of the previous system.
  • In subsequent years maintenance is 25% of the previous contract
  • Consulting costs have been decimated.

Interview with Domtar

Q. Would you recommend this technology?

Yes. This technology has given us the flexibility to do everything we ever wanted. It is not perfect and like most things probably never will be. However, it has allowed us to reshape the way we deliver some of our IT services. It has allow us to integrate new way of doing things (SLA, Service Catalogue) that we thought would be impossible with our old tool. For the first time we are able to shape the tool to our process and not the other way around.

Robert (Bob) Stambaugh, Manager, IT Service and Asset Management at Domtar, South Carolina, USA
Robert (Bob) Stambaugh, Manager, IT Service and Asset Management at Domtar, South Carolina, USA

This tool has helped us transform they way we see service delivery, to better understand what we do and allowed us to push a vision for the future.

We want this tool to become the ERP of IT, to be the central repository for all the information, to be the source to answer questions about IT and to be more than just a ticket repository.

Q. Which feature(s) would you add to this product if you had the choice?

It is not so much an addition but some improvements. A more flexible self-service portal would be a great improvement. The portal is not configurable enough and a bit static. By giving it more flexibility we could have a better design and make it more user friendly. The way you order service is a bit confusing for end-user at first.

There is what they call wizards, which act as macros function and provide intelligence (Ex: complete a ticker, move an asset, assign a ticket etc.) Wizards do almost anything. They can be adapted but up to a certain point. It would be incredible if we could modify the existing wizard even more but most importantly create our own.

Q. Can you provide any examples of where the increased agility and responsiveness you mentioned have led to tangible improvements in service?

1. Rapid deployment cycle

We have a very rapid deployment cycle on any changes in the tool. We can implement any new configuration changes in an average on 1 week.

Some configuration can be done in a few hours while other requires more tests and will take 1-2 weeks. All this with minimal downtime (1-2 min for most changes).

We have a scheduled change every Thursday where we introduce fixes and improvement. On the other hand, some incidents are fixed live while people are in the system. In our old system, any changes would take several days to code and test (1-2 week total) and several hours downtime (4 in general) to implement.

2. Self-Service Portal

Our end users can now go online not only to enter service requests and incidents but also to track their tickets, something they could not do in the past.

This provides our end user with more flexibility on how they can communicate with us. Those who track their tickets by themselves also save a call at the service desk.

3. Workflows

Benoit
Benoit Tessier, Team Lead, IT Service and Asset Management at Domtar, Montreal, QC, Canada.

Every service (or tickets) is backed by a workflows to guide IT personnel through the process. It is no longer necessary for every IT member to know complex process by heart. The tool makes sure we go through every step.

Workflows make sure we engage the right people at the right time. The process knows when certain team are needed and are notified accordingly. Fewer mistakes are made and fewer things are forgotten.

4. SLO (Service Level Objective)

They were technically possible in the past but we felt they were easier to do in EasyVista. So for the first time we have SLO with our end-users. We do not call them SLAs because we did not sit down with our customer to agree on them. These are the objectives we have set for ourselves in the resolution of incidents.

We are proud to say that less than 10% of our incidents do not meet our SLOs. Something we could not do before. I would dare to say that pride was not even part of our vocabulary. The result is increased satisfaction and efficiency.

5. Reports, Dashboard and KPI

It was almost impossible to get the data out of Remedy easily or without Crystal reporting skills. This is no longer the case. The reporting tool in EasyVista gives us lot of information on operations very easily. We build hundreds of reports.

For the first time, we have numbers and information that let us understand what is going on in the fields. This has launched several initiatives for service quality improvement.

6. Service Catalogue

All tickets, configuration items and assets are linked to a service. This service chart is the basis of our IT management. It is also used for budgeting, resource planning, and project management. Everything IT does is linked to this service catalogue or service chart.

This allow us to understand what is in every service (CI, Asset, Applications etc.), what tickets are generated for every service, what requests are made for every service and of course how much every service costs. By reversing the process we can figure out how much each ticket costs.

This service centric approach has transformed the way IT delivers it services and allows us to answer the eternal question: What does IT do?


Domtar rate EasyVista

Q. Please provide a general rating of EasyVista:

8/10

Q. Please rate the ease of use and intuitiveness of EasyVista:

8/10

The back-end for IT people is very easy and good. Everything is easy to find and presented in one screen which make it simple. However, there is so much functionality available that it is sometimes hard to remember all the possibilities.

Q. What are the key strengths?

  1. The flexibility. We can do literally anything if we put our mind to it. Even stuff they thought would be impossible a first.
  2. It does not require any knowledge of programming language other than SQL query.

Q. What are they key weaknesses?

(None provided)


About Domtar

200px-Domtar_LogoDomtar Corporation

  • ‘The sustainable paper company’
  • Industry: Fiber-Base technology company
  • Headquarters: Montreal, QC, Canada, Operations Center: Fort Mill, South Carolina, USA
  • Revenue $5.5BN (TSX: UFS, NYSE: UFS)
  • Founded 1848, 10,000+ employees
  • IT Team 250 staff, Service Desk 11 staff
  • www.domtar.com

The Domtar IT Team at a Glance

  • 250 IT employees spread across North America
  • ITSM team is responsible for ITSM processes, tools and Asset Management
  • New ITSM tool implemented in 2012
  • Processes in place include: Incident, Service Request, Change, Knowledge, Procurement, Asset, CMDB

easyvista-infographic3

Patrick Bolger talks "why we have to do Agile NOW"

Patrick Bolger, Chief Evangelist at Hornbill Service Management, provides a summary of his presentation for the itSMF UK Conference and Exhibition entitled “The Good, the Bad, and the Agile”. Patrick discusses the need for Agile, it’s benefits, and why it’s not just for software development.

He also looks at how the IT landscape has changed in the past decade – it was once highly unlikely to see a company going from an idea to market captialization of $100bn in the space of ten years. This is now possible, we’ve seen it with the likes of Facebook, and Patrick talks about how companies need to keep up to stay in the game.

As well, Patrick discusses why Hornbill Service Management works with itSMF UK and the benefits the annual conference brings to his company.

Learn more about Agile at Patrick’s session at the itSMF conference in November:

Applying Agile principles to Service Management

rabbits
“A man who chases two rabbits catches none.”

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.

Focus

“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.

Alignment

“What if we found ourselves building something that nobody wanted? In that case what did it matter if we built it on time and on budget….” ~ Eric Ries, The Lean Startup

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.

Artful making

“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.

Self-organization

“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

“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.

elvisBecause they focus on a subset of all possible work and they have quality standards they can deliver work of a high quality which deepens that 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.

In summary

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.

Image Credit 1

Image Credit 2

Simple steps towards Agility and Service Management improvement

Dead as a...

There have been many hundreds of words recently written on the subject of Agile Development and IT Operations practices. For the average ITSM practitioner, however, a life where both are interwoven into the organisations day-to-day work seems as unattainable as ever.

Sure, you might work for one of the few organisations that practices DevOps. If so congratulations… you’re one of the cool kids. Maybe you picked up a copy of “The Phoenix Project“** and the authors words resonated with you.

“I should start introducing Agile and Lean concepts into my IT organisation”

It’s not as if these words have fallen on deaf ears as such – it’s just that most ITSM practitioners are struggling to join the dots in their head, not even able to mentally apply Agile/Lean/DevOps to their own environments.

It’s hard to see how you get from your current position today to a position of continuous delivery and business agility, along with the bragging rights on Twitter about how great your aligned development and IT Operations organisations are.

You now want to improve… So what can you do to get started?

I have two quick tips for those IT Operations folk that want to start taking steps towards Agility and Service Management improvement. These tips won’t transform your IT department overnight but they are both cheap and easy to implement (in fact you could do it this week).

Tip number 1: Hold retrospectives

The most valuable skill of a good Agile team is the ability to self-learn. Self-learners have a habit of looking at their performance as a team and can identify positive and negative characteristics from their recent behaviour. By learning from past experiences they pledge to improve in the future.

The mechanism for Agile teams to drive improvements is to hold regular retrospectives.

A retrospective is a time boxed activity (a meeting) that is held at the end of a period of work, or in Agile-speak an “iteration”.

Development teams often work in regular short bursts of work called “sprints”, which in my company are always two weeks long, therefore we hold retrospectives on the last day of each sprint.

IT Operations work is not normally neatly defined in two week iterations – you tend to deal with KTLO work (Keep the lights on – Incidents and Problems) and perhaps projects. However, you should avoid the habit of only holding retrospectives to find improvements at the end of projects or when things are going wrong.

If you want to take a few Agile steps in your IT Organisation my advice is that you open your calendar application right now and setup a recurring meeting for your team that lasts for an hour every two weeks. Take this time to review work from that two week period and identify improvements.

Build self-learning and improvement sessions into your schedule. Don’t leave opportunities for improvements to project post-mortems or to when things have already gone wrong.

So what happens in a retrospective session?

Firstly, it should be a facilitated session so you’ll need someone to lead the team, but this isn’t a daunting task (OK – it is the first time you do it but it gets easier after that). Secondly, it’s a structured session rather than an hour to ‘bitch and moan’ about the Incidents that came in during the last two weeks.

Retrospectives are structured meetings with a clear objective – not a general conversation about performance

The objective of a retrospective is to get a documented commitment from the team to change one or two aspects of their behaviour. Documenting these commitments is covered below in tip number two.

Changing the behaviour of a team is absolutely not as challenging as it first seems, people only need a few things to happen to change their behaviour: to have their opinion heard; to be able to commit to the change; and to be held accountable. The format of a retrospective allows for all of this.

Also with retrospectives we don’t focus purely on examples where things went wrong. I’ve been in many retrospective sessions where teams have focused on unexpected success, have researched the factors that contributed to that and committed to spreading whatever practice caused the success to a wider organisation.

Identifying what worked well for a team in the previous two weeks and pledging to repeat that behaviour is just as powerful as pledging not to repeat negative behaviours.

I mentioned that retrospective sessions are structured. This really helps, especially when a team starts out on a path of self-learning and improvements. The structure holds the meeting together and guides the team to its objective for the meeting – validation of existing working agreements and proposals for new working agreements.

Esther Derby and Diana Larsen, who both inspired me to focus on retrospectives with their book, “Agile Retrospectives: Making Good Teams Great“ describes the structure for retrospectives very well in the SlideShare presentation below. Take time to study and implement their meeting structures.

What should the meeting structure look like?

The recommended meeting structure is as follows:

  • Set the stage

  • Gather data

  • Generate insights

  • Decide what to do

  • Close the retrospective

Each element in the meeting agenda is an opportunity for the facilitator to engage the team and run exercises to uncover what worked well (to be repeated) and what did not work well (to be avoided).

By structuring the meeting and facilitating people through the process you avoid the temptation for people to use the time simply complaining and placing blame for things that didn’t go well.

The meeting structure drives the retrospective towards its objective – an actionable set of Working Agreements for the team to use.

Tip number 2: Use Working Agreements

In a previous role in IT Operations and support I often felt the sensation of “spinning plates”. As soon as we could put one fire out another would flare up. Our problems as a team were that different people worked in different ways which is a real problem in Infrastructure teams.

My solution at the time was to try and write an all-encompassing “rule book” which described how we as a team react to any given circumstance. We’d build this “rule book” up over time and end up with a comprehensive document to remove confusion on how to perform work.

I’m sure you can imagine the outcome – we started.. we didn’t get that far.. as soon as the rule book was of any decent size it became out of date and unwieldy.

What my team then really needed, and the way that my Agile development team now works, is to have a lightweight document explaining the rules of the road. We call this document our “Working Agreements”.

What should Working Agreements look like?

  • They should be small enough to fit on a single side of A3 paper

  • Agreed upon by the team

  • The output of retrospective sessions, worded to enforce good behaviour or to prevent negative behaviour

  • Should be reviewed during each retrospective – do we need this Working Agreement now or is it part of our standard behaviour.

  • Should be very visible in the area

Having a lightweight set of agreements that the team commit to and that are reviewed regularly are a great way to drive cultural and technical changes that actually stick! Rather than review meetings that mean nothing once the team leave the room.

In summary

Driving improvements to a team means you are trying to change peoples behaviour which is never an easy task. Teams will change if some basic needs are met. They need to be listened to, they need to commit to the change and they need to be held accountable for future behaviour.

This is possible in your IT Operations teams today – hold regular retrospectives to identify what works and what does not. Get the team to commit to working agreements which are agreed by the team, meaningful and visible.

Let the improvements commence!

** If you didn’t nod when I mentioned The Phoenix Project then you aren’t one of the cool kids and you better find out what it is… pronto!

Image Credit

Is it time for a two-speed ITIL?

Do we need faster access to new ITIL concepts?

At the UK itSMF conference this month, somebody asked me “What do you think the ITSM community are looking forward to next from ITIL?” As I tried to answer this question I realized that we don’t really have an ITSM community with a shared set of objectives.

We have many different people with different goals and objectives, and we all want different things from ITIL. Over the last few years I have seen an increasing divergence between two distinct groups of ITIL users and I think it will become increasingly difficult for the ITIL we currently have to satisfy both groups.

We all want different things from ITIL

One group includes training organizations, exam institutes, tool vendors, and organizations that have made investments in developing ITIL related solutions. These organizations are looking for stability, so that they can realize some value from the large investments they have made in ITIL related products, services and solutions. There was a major release of ITIL in 2007 and a smaller release in 2011, and they really need time now to consolidate their work and extract value from it.

The second group includes organizations that are creating and adopting new ways of working to create increased value for themselves and their customers. Some of these are using DevOps and Agile to deliver very rapid rates of change for their customers, some are using complex multi-supplier relationships to create value, and some are adopting BYOD to increase productivity of their users. These people and organizations are looking for ITIL to release new material to support them, and tell me that although the underlying concepts in the core ITIL publications still apply to them, they need significant and frequent updates to provide guidance that is suitable for these rapidly changing environments.

We cannot support all needs with a single set of publications

I think that ITIL needs to support both of these groups, as well as all the other shades of opinion in between, but I don’t think we can support such disparate needs with a single set of best practice publications. The solution I propose is to create a new set of “ITIL Fast Track” publications. Let’s keep the core ITIL 2011 publications unchanged for a few years, so that organisations that need stability can extract value from their investments, but let’s also create new ITIL publications to support those on the leading edge. These ITIL Fast Track publications could be based on leading edge practices and what’s happening in the industry now, rather than on tried and tested best practices. They would not be intended for exams, but to provide guidance on how to apply great service management practice in a way that works with the latest practices from other sources.

We could produce ITIL Fast Track Service Strategy with ideas from COBIT5 and recent work on supplier integration and management, ITIL Fast Track Service Transition and Service Design with ideas from DevOps and Agile, ITIL Fast Track Service Operation with guidance on how to use Rob England’s Standard and Case

A chance to create new ‘best practice’

The really good thing about this solution is that in a few years’ time some of the material in the ITIL Fast Track publications would have been tried and tested by sufficient organizations that it would become best practice, and could be merged into the ITIL core in a future update.

So what do you think? Would you be interested in reading ITIL Fast Track publications, or do you just want to stick with the ITIL core?

(A Russian translation of this article is available on the itSMF Russia website here: http://www.itsmforum.ru/news/all_interest/2012_12_13)

Image credit: © flucas – Fotolia.com

Can ITSM Projects do the Kanban?

In these uncertain economic times the watch words of the moment seem to be:

“Do more with (continually) less”

The effects of outsourcing both to clients of service providers and within their own organisations too means that support groups need to be as efficient as they can with (quite frankly) what they have left.

Could the visual scheduling tool LeanKitKanban, a web-based virtual signboard and card system, help Service Management support groups manage their time more efficiently and perhaps help bring about a more proactive approach to certain disciplines?

Lean and IT

Lean has its roots in manufacturing and production.  It is a practice that views the expenditure of resources for any goal other than the creation of value for the end customer to be waste, and therefore should be eliminated.

Value in this context an action or process that a customer would be willing to pay for.

Stretch this out to IT, and what Lean is trying to achieve is less wasted time by support resources and more efficiency in how they work. 

Kanban

Kanban is a Japanese words that quite literally means “signboard” and is a concept related to lean production, and looking at Just-In-Time production in particular.

In a production perspective, kanban is a scheduling system, used to determine what, when and how much to produce.

So, looking at it from an ITSM perspective, what are you working on, when are you scheduled to finish it, and how much more are you juggling.

At a glance, therefore, you can see where work is being bottlenecked and better utilise the team to reduce the overall workload.

LeanKitKanban

The key aims are:

  • Map out your organisation’s processes onto virtual whiteboards
  • On each board, processes are represented in vertical and horizontal lanes
  • Team members use Cards to represent work items which they can update and move across the board
  • The idea is that managers, customers, project managers can view this board for updates.

Pre-defined Board Templates

When you register, you get a number of pre-defined templates to select from, that best defines your business, so I looked at their IT Operations templates.

Of the two available, only Business Process Maintenance  seemed to come close to mapping processes across an organisation.

Using Cards

Within this template are categories of Cards:

  • Defect, Feature, Improvement, Task

Just looking around the template, you could have cards allocated to team members to look at:

  • Production Problems
  • Planned Business Need (with varying due dates and High/Low impacts)
  • Routine (Tasks)
  • Unplanned (Incidents)
  • Platform Improvements

How ITSM projects could use this

The idea sounds great but the practice needs a little thought.

The boards provided in the evaluation version are probably more geared towards Software Development or wider Business Process Re-engineering.

I like how team members show up against the cards so that you can see at any one time who is working on what, but what immediately struck me was duplication of effort.

Tool vs Kanban – Incident Ticket Lifecycle

I mapped out the key parts of the Incident management process, listing how an Incident Record would move through its lifecycle in a tool, versus how that same progression could be simply mapped in LeanKitKanban.

Process Steps

ITSM

KanBan

Incident Logging Incident Record Defect Card
Incident Categorisation Pre-Defined in Tool Free Text
Incident Prioritisation Pre-Defined in Tool 4 definitions in Template
Investigation and Diagnosis Assign to Team member Assign to tean member
Resolution and Recovery Update tcket as appropriate Update as appropriate but no auditing
Incident Closure Often auto-closure configured after resolution “Done” and archive functionality after a number of days

In order for someone outside the immediate support team or service management team to understand the progress of a ticket, they would normally be expected to have access to the ITSM tool, and to be able to see open Incidents and their progress as part of a steady state.

The idea behind LeanKitKanban is that it allows people maybe outside of that to have “visibility of progress”.

For Business As Usual, people outside the immediate support teams would normally receive Service Management reports with pertinent information.

Kanban and ITSM Solution Development

Moving away from Business As Usual, I thought I would consider its use when an ITSM solution is being developed and implemented.

Some tools do offer the capability to project manage development and testing work within the tool itself, but it does mean that people who may not ordinarily expect to use an ITSM tool would have to spend time working in it to work out progress.

Where software development is being managed using the Agile methodology, there is a useful board for that template.  If the ITSM tool itself does not provide Project/Development tracking modules, then this tool would be ideal for tracking tool development and customisation.

Putting it into practice?

LeanKitKanban have a good repertoire of reference clients on their website, although I think it lends itself more to the Software Development side than more traditional ITSM implementations.

In reality, however, time pressures on an implementation project are such that sometimes even visual summaries such as these may get discarded.

For every ticket that is being worked on, a corresponding ticket would have to be created in Kanban, so who would realistically do this, and maintain it?

It makes sense for it to be a Team Leader or Project Manager, in order to have a view of progressing work, and to keep the working team free from “management noise”.

In reality, most project management calls with teams revolve around a simple status Powerpoint with Tasks achieved, Tasks to do, Issues, so now it is the project managers that are faced with duplication of effort in maintaining reporting.

In order for this to work, this tool would need to be at the heart of project reporting and most likely a more comprehensive version than the initial trial.

To get the best from this tool, you would need:

  • Full buy-in from all levels of Project Management to have it as the tool of choice
  • It would need some customisation effort for anything outside of the templates provided – which are available in the Professional Edition pricing options
  • Some level of buy in from the teams having to provide input for the tool, as there is a danger for duplication of effort from the teams below.
  • It looks most suitable for development and implementation efforts rather than as part of ongoing steady state operations.

I would also recommend using the Personal Kanban board and template as part of the free offering, which offers users a chance to split tasks into 4 project lanes, and provides columns to help users track their to-dos.

For those spread across multiple projects, it provides a little more of a visual, virtual structure than scrawling To-Do lists on paper/sticky notes, and I am finding it helpful for working on distinct areas of work.

Further Information

Image Credit