Batman, SIAM and Mean Time Between Ass Kickings: SITS16 Recap

It’s the London Olympia baby! Last week was the 2016 Service Desk & IT Support Show or SITS for short. SITS is a annual, free event in central London dedicated to all things tech support and ITSM related.

 

DevOps Needs Leaders – Daniel Breston

The first session we attended was run by fellow Batman super fan and all round ITSM rockstar Daniel Breston.

 

 

Taking all of 5 seconds to get a Batman reference into his content, this was clearly destined to be my favorite session of the day. Daniel opened by talking about the iceberg of ignorance, in other words, the further away you get from service delivery, the few problems that you see. Daniel continued by discussing how one of the biggest challenges faced by managers is taking the time to improve.

Daniel introduced the ITIL, Agile and Lean triumvirate explaining how it’s not enough to have best practice, we must be responsive to the needs of the business and efficient in the way we deliver enterprise services.

The next part of Daniel’s presentation focused on how DevOps is a way to do better faster safer on a continual basis. Daniel talked about the need to focus on the entire value stream of better faster safer from strategy right through to operations.

Daniel went on to talk about measurements and advocated putting your business reports in a language your company understands for example from zero to we got this! He also introduced a brand new metric which I think our friends at AXELOS towers should be all over in terms of including it in the next ITIL refresh.

The final part of Daniel’s session focused on behavior. As Daniel put it “DevOps starts with management talking to people and finding out what their problem are.” Daniel talked about the 3 ways to manage effectively environment:

  • You built it, you run it
  • Project to product
  • Strangle the complexity – lose the nonsense

His final point? Don’t forget to celebrate your successes along the way, preferably with beer!

The Pros and Cons of Public and Private Cloud – Sarah Lahav, SysAid Technologies

 

Sarah opened her session by talking about the recent LinkedIn hack; asking her audience how many of them were able to understand if their personal data had been compromised from the e-mail response issues by LinkedIn – ie the importance of asking the right questions.

Sarah went on to talk about the public cloud and private cloud and the pros and cons of each approach. Public clouds are typically easy to use, flexible and operated by a third party but may be unreliable and less secure than an in house solution. Private clouds are organisation specific, customisable and more secure but can be more costly and require in house expertise.

The next part of the session looked at how a hybrid model can give organisations the best of both worlds without increasing risk. Sarah went on to talk about case studies of the SysAid product from General Cable. Fluortek and LAN Airlines who has the impressive statistic of being able to handle seven times the number of Incidents since using SysAid.

Sarah concluded by explaining with the evolution of SaaS and cloud, it takes new skills to manage your estate effectively, Sarah’s advice? Every organisation is different so in terms of cloud provision, capture the requirements of your organisation and then plan accordingly.

 

Transforming The Service Desk With SIAM & Lean – Joe Bicknell, ServiceNow

The final session we attended was Joe’s session on Service desk transformation. Joe opened with the frankly terrifying statistic of outside the workplace, 84% of requests are automated, inside the workplace only 33% of requests are automated. The upshot? The average employee spends around 15 hours of their working week faffing about trying to  battle the admin mountain.

 

Joe went on to explain the ServiceNow way of thinking “we believe everyone in your organisation requests something and everyone in your business is a service provider in some way.”

 

Joe used ServiceNow to demonstrate how ITSM can be applied to the entire organisation, streamlining processes and removing silos. His top three takeaways?

 

  • Own IT Service Management in your business; it’s the key link between the front and back office.
  • Change the way you work, don’t use technology to compliment what you do
  • Take the workshop to your organisation and start to take Service outside of IT

 

Did you go to #SITS16? Let us know in the comments!!

 

Image Credit

BEYOND20 SIXTEEN – Beyond Practice: Exploring, Discovering, and Driving Business Value

Ahead of the BEYOND20 SIXTEEN conference next month I caught up with Chad Sheridan, CIO of the USDA Risk Management Agency to talk about his session  Beyond Practice: Exploring, Discovering, and Driving Business Value.

Chad-Sheridan-Headshot

Chad’s session will explore the leadership and cultural changes needed to make Agile work, especially in a government environment. Chad will share his own experience of driving business value, enabling a culture change from command and control, top down leadership to a more organic model, trusting and empowering people to do their job. As Chad said “while it’s great to change from the top down as CIO partnering at the exec level, we need a whole team of change agents. It’s not a one person battle, it’s a multi threaded effort to win hearts and minds. Be ready for resistance – this is a fundamental change for the business to accept a value driven IT partnership.”

The session will look at how to drive effective organisational change to create a culture of safety and trust so that value and transformation can happen. Chad will take his audience on the journey from IT as an order taker to an enabler; moving from technical practitioners to curators of business value. Chad will also talk about how embracing Agile and DevOps means embracing uncertainty as a competitive advantage, using it to drive innovation.

 

You should attend this session if:

CIOs, leaders of Agile practices, DevOps practitioners and anyone that wants to drive change in their organisation.

 

The official bit:

The conference overview of Chad’s session is below:

DevOps, Agile, and ITSM implementations often focus on practices and tools, many times forgetting the primary purposes of these efforts—delivering business value. How do we deliver on the vision from The Phoenix Project, which proposes to end the “dysfunctional marriage” of IT and the business as separate entities?? Put on your explorer gear as this session walks you through the jungles, swamps, mountains, oceans and deserts of the digital world, searching for understanding and the means to move from IT practitioners to purveyors of business value.

 

Image Credit

Featured Image Credit

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

The ITSM Diet

krispyI am undergoing a very personal transformational change right now. I am trying to learn how to eat in the real world and maintain a healthy weight. I had really let myself go.

No exercise, eating too much, eating the wrong things and not caring. The results: 360 lbs.; the inability to walk at least 50 feet without wheezing; acid reflux; and an impressive expanding waistline. I felt horrible. My body simply hurt all the time.

After much self-loathing, I made the decision to change. Now, I control my calories, carbs, fat and protein levels and I get 60 to 90 minutes of exercise in a minimum of 5 days per week. I made my health issues a “big rock” in my life (see Stephen Covey’s “Put your big rocks in first”).

The results: I currently weigh 320 lbs., I’ve lost 4 inches on my waist, and I feel a heck of a lot better.

The funny thing in all of this, people keep asking me what “diet” I’m using. Okay, here it is –  I eat less, make better food choices, and exercise as much as I can. Disappointed with my answer? I find that many folks are looking for me to give them some “magical” advice like “oh, I lost the weight by following the Krispy Kreme diet”. There are no silver bullets. You have to eat right and exercise.

So, what’s the point in relation to ITSM?

The point is this; you must build and follow a plan for an ITSM initiative to work. There are no simple solutions or silver bullets to make adoption easy. Be prepared to work hard, suffer some failures, learn from those failures and iterate, just like you do with a diet.

In order to be successful in ITSM adoption (or in your diet) I recommend following the key “exercise and eating” tips and advice listed below.

Don’t fall for hype

“Just follow our simple x step plan every day, and we’ll guarantee you will lose weight”

I’ve seen ITSM blog posts and consulting statements that indicate the same thing “…just follow our advice and you’ll be doing x process in no time” or “buy our product and we guarantee you will be ITIL compliant”. If it sounds too good to be true, it probably is. Any offering of a “quick fix” probably will not work. Think about the long term and what you want the program to achieve. Learn good habits.

Always evaluate

I don’t do “diets” but there are items within the multitude of diet plans out there that do make sense for for certain individuals. ITSM is no different.

If something works, adopt it. If it doesn’t, forget it. For example, Problem management as detailed in ITIL® doesn’t fit well with how my organization works. We therefore adopted LEAN 8-step method as the primary way to execute our problem management but use the information in ITIL® to ensure our process is as robust as needed.

Build a plan that works for you and helps you achieve your goals

There are many ITSM frameworks out there and no rules that say you have to use a specific one. My advice is that you read, learn, and research.

You may need to use ITIL®, LEAN, COBIT®, USMBOK®, and/or combinations of the aforementioned to build your plan. Don’t do something just because someone else says you should do it. Know what you are trying to achieve and select the appropriate framework to work toward it.

For example, my company uses many different frameworks along with ISO/IEC 20000, with ISO/IEC 20000 as an indicator of “world class” IT operations. Despite this, we have attempted on four different occasions to start the adoption process for Configuration Management. What we found is teams did not understand what to do with CIs or how to move them through a change process. We therefore took a step back and spent more time looking at our Change process, and are now starting to have tabletop discussions on moving a CI through a change.

In doing this exercise, we found our teams had different execution of change, different ideas on what a CI is, and different ideas on how to move a CI through a change cycle. These discussions gave us the opportunity to drop back and review all the frameworks for a “good fit” to help accelerate what we do.

If the plan is not working, change it

When exercising, eventually your body can become use to a specific exercise and become efficient in the activity. At that point, you can continue doing the same thing, but the results will not improve. An ITSM plan is the same. If your plan is not getting the results you desire, mix it up and try a different approach. Focus on a specific aspect and find the change that helps you get the results you need.

During the adoption of incident management at my company, we had team members onboard who had been doing incident work for many years and yet our design process kept missing key steps we needed to fulfill ISO/IEC 20000 requirements. Clearly we needed a different approach and so we went back to the beginning and built a checklist of items that the design team needed to complete prior to submitting deliverables. This helped us to identify the missing steps and fix the design process.

Measure

When it comes to exercising and being healthy, my FitBit gives me all types of data to help me determine if my behaviors match my plan. Data helps us measure where we are against our goals, which is important in any ITSM initiative.

What you measure is up to you, you cannot allow others to dictate what data you need to collect. Identify your goals, and collect and analyze data that helps you reach those goals.

At my company, we ask our service owners to identify “pain points”, the place where their team or their customers indicate something in the process doesn’t deliver the promised goods and/or causes them problems. We have found that focusing on a few key measures and “pain points” leads the service owner and their teams to think more holistically about the service and why they are doing what they do. This organically leads to continuous improvement, brainstorming and discussion about user experience.

Keep the goal in mind

It is easy to get discouraged when you go a couple of weeks without losing any weight, and the same is true in ITSM. Don’t lose sight of what you have done and where you are now.

Sometimes it may seem easier to follow the same path as you always have and get the same (bad) results to achieve quick “outcomes”, but how does this help overall? Remember, incremental improvements over time lead to reaching goals.

Relax

One of the toughest issues I have with weight loss is overthinking the situation – I can become my own worst enemy. The same is true with your ITSM plan. Work the plan you built, and if something doesn’t work so what? Try something new! Be mindful of your situation and don’t be afraid to change. It will all work out in the end so just remember to breath and relax.

And a bonus tip!

Be as transparent as possible in any ITSM initiative or project, routinely discussing your success, failure, trails, and tribulations. This will help you to stay grounded and on top of where you really are in your process/project. Use your measurements to remind yourself and others of the progress you have made and make sure you understand the deliverables and timeframes.

Final Though

ITSM adoption, just like maintaining a healthy lifestyle, can be tough. It takes planning and execution, measurement and analyzing data, and it also takes support. Remember, don’t fall for the hype; always evaluate; build a plan that works for your situation and change it as required; measure your progress; relax; and always keep your end goal in mind.

Image credit

ITSM User Personas

Persona: "the aspect of someone’s character that is presented to or perceived by others"

During my time in IT Service Management I’ve read my fair share of process and policy documentation. In fact, I think I’ve had the misfortune to read more than my fair share.

Process documentation is important, don’t get me wrong. Without someone taking the time to write down the intention, expected steps, outcome and quality checks within a module of work you don’t really have a process at all.

I was having a conversation this week with someone that was sure they had a process for something. It transpired that what they had was an unwritten set of best practices that everyone understood and followed. The outcome was actually fairly good and repeatable but by no sensible definition was this a process.

In fact the moment of realisation came when I asked if the best practices had changed over time. Of course they had as the team had learned and improved itself. But without proper documentation outlining the new steps to take nothing was truly repeatable. There was no real process.

Lean Process Documentation?

So, I am an advocate of writing documentation to support a process. But does it have to be so verbose, heavy in language, formal… and lets be honest. Boring?

Lean principles teach us how to identify “waste”. Any more than the responsible minimum is waste. Do we actually need to include difficult to read text in our process documentation? If they don’t add value to the reader surely they are wasteful and can be removed?

There are some practices that I use in my role in product development that I think would be really useful to IT Service Management professionals that are willing to take a fresh look at their process documentation.

User Personas in Action

A user persona is a method of representing an individual that is involved in a process. For example in your Change Management process you will have a number of different people to think about:

  • The person requesting the change
  • The person that peer reviews
  • The approver
  • The person implementing the change
  • The person who does a post implementation review

Each of these people have different requirements, concerns and objectives when working within the Change Management process. Does your process documentation accurately represent these people?

Each user persona should fit on a single side of A4 – An example, ‘Angie – Change Manager’ is below.

User personas represent real people within the process and I’d recommend using photos of your actual users. It’s a powerful thing in design meetings to have a set of personas pinned up on the wall and to actually see the faces of the people you are making decisions on behalf of.

Each persona has a short summary and then four sections.

  • What she’s thinking
  • What she’s hearing
  • What she’s saying
  • What she’s doing

The sections show the users concerns (“thinking”), the conversations that other people would start with her (“hearing”), the conversations she would start with others (“saying”) and her day-to- day actions within the process.

ITSM Caricatures

A persona should be a “caricature” of the different people that act the part within your process. You might seek out these people and interview them to discover what they are thinking, saying, hearing and doing. If you interview 4 different Change Managers and discover that they all have different concerns your “Angie the Change Persona” would be a representation of a person that has ALL of the concerns. You are aiming to discover the extreme points of view that these people exhibit and document them.

We try and use personas throughout our product development process – when we design a process defining these is a critical early step and we rely on them during Acceptance Testing to ensure we are getting feedback from all people.

Back2ITSM Personas

A few months ago I mentioned personas in the Back2ITSM Facebook group and got a good response. As a community resource I’d love to see a set of User Personas that cover all the roles in common ITSM processes. Imagine knowing that you need to write a new process for Configuration Management. Heading over to Back2ITSM to download a set of user personas for each role in the process would be a huge head start.
I’d love to see process documentation move away from mimicking legal documents with reams of dense text and move towards a more user centric representation of users requirements and concerns.

After all – your process affects real people. Lets find out who they are at the design stage and make the process more suitable for their needs.

Image Credit

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