I’ve previously written about Kanban for The ITSM Review. I described the differences between Kanban and Scrum, preferring the former for it’s more pragmatic approach towards roles and ceremonies and it’s wider application across a range of types of work.
“Kanban from the Inside” defines a model for managers wishing to introduce an evolutionary shift towards business agility, improved quality and to achieve flow.
The Kanban Method, as codified by David Anderson, focuses on existing business processes and introducing change through focus on quality and reducing work-in-progress. The work itself remains unchanged at least initially. Done by the same workers in the same way but being measured and visualised in an effort to find “flow”.
Inspecting quality and reducing work-in-progress leads to a shift in work being delivered more often, where organisations can then focus on balancing business demand against throughput and improving prioritisation techniques.
You can see that Kanban doesn’t require a revolution in the way that you work, it’s a series of steps taken over time.
In his book Mike describes four “Foundational Principles” and six “Core Practices” that teams work through.
The Foundational Principles describe the mindset and attitude that leaders take towards adopting Kanban
Start with what you do now
Agree to pursue evolutionary change
Initially, respect current processes, roles, responsibilities, and job titles
Encourage acts of leadership at every level in your organisation – from individual contributors to senior management
Throughout the book Mike provides real-world, pragmatic, examples that support these foundational principles.
With chapter titles such as “Understanding”, “Agreement” and “Respect” he deals with the dangers of changing workflow without first understanding (remember… evolutionary change), how to secure a commitment to change, and how to deal with existing roles and responsibilities respectfully. Always a challenge whilst you are acting as an agent of change in an organisation.
The six “Core Practices” are more hands-on and dogmatic.
Limit work-in-progress (WIP)
Make policies explicit
Implement feedback loops
Improve collaboratively, evolve experimentally
Following the existing literature about Lean and Kanban, Mike talks about how to apply techniques to work to shift an organisation to focus on quality, flow, learning and experimentation.
Mikes “Kanban from the Inside” is in no way an alternative to Davids “Kanban: Successful evolutionary change for your Technology Business”. I was thinking of the best way of describing why you should buy both books to read.
The best I could come up with was this. If you enjoyed Robert Downey Jr in the Sherlock Holmes movies you’re more likely to enjoy Benedict Cumerbatch’s portrayal. Watching one doesn’t detract from the other.
Mike’s book is a great accompaniment to David’s. If you are interested in starting with Kanban I would seriously recommend buying both and starting with the Blue book (David’s).
The blue book is a little more gentle on the beginner I feel. It takes you through the introducing change into a organisation in a very thorough way. Mikes book is more formulaic and is a hands on guide to the individual techniques involved.
Although Mike takes his readers through a journey, it takes some effort and concentration to keep up with him. This isn’t a criticism of writing style or narrative – it’s because this is a practitioners guide and goes deep into some very interesting areas.
The book progresses through three parts: Explaining the Kanban method; describing other methods that are useful in applying Kanban more effectively; a step-by-step implementation guide in part 3.
In an evenings reading you aren’t going to progress from Drum-Buffer-Rope to Critical Chain Project Management without going to bed with an overactive mind. This is more a manual that you’ll keep referring back to as you progress through your adoption.
This isn’t taking anything away from “Kanban from the Inside”. It’s a great book and it’s already earned a place on my desk. I’m buying more copies for my team leaders.
If you are looking for more quality and efficiency from your teams I’d absolutely recommend this book and David Andersons “blue book” as a pair of books that have the potential to change your organisation for the better.
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.
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.
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.
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!
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.
To introduce principles to those that are unfamiliar, I’m taking inspiration from Tobias Mayer who identified 5 benefits of Agile (in this particular case Scrum) that will help me orientate you.
“A man who chases two rabbits catches none.” ~ Roman Proverb
A core principle of popular Agile methodologies such as Scrum and Kanban is to limit Work in progress. Scrum teams, for example, will agree to take on a small subset of work from the overall backlog within a timeboxed period, normally between 2 and 4 weeks.
By limiting the teams focus and attention on what is most important you enable them to complete work to the appropriate quality standards; and by limiting work in progress we train teams to finish work, rather than start additional work. With focus comes attention to detail and less mistakes, a higher level of quality and ultimately happier customers.
Look around your IT department today as you read this article. Do you see teams that have more work than they can handle? (Probably). Do those teams have a clear understanding of what is most important (probably not)?
How can Service Management teams adopt the Agile principle of providing focus for their teams?
Start by understanding your work. Where does it come from? How does work arrive in your department. Visualise your work by using a tool like LeanKit, Trello or Kanbanize (all have free editions for you to try). Use one of these tools to identify which work items are the most important and challenge the team to finish those items.
By reducing the scope of work that a team is paying attention to you’ll see a change in behaviour, delivery time and quality.
“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.
“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.
The best architectures, requirements, and designs emerge from self-organizing teams. Teams that are not controlled but enabled. Teams that stay together long enough to form an esprit-de-corps and that trust each other enough to have passionate debate and disagreement without destroying the teams culture.
The worst experience that an engineer can have is to be presented work that was designed by someone else, work that has no scope for flexibility or creativity, and worst of all to be told how long it will take.
Have you ever worked on a project where the scope, implementation and deadline were predetermined by those that aren’t actually going to do the work? How does that even happen??
Agile teams are self-organising within the constraints of the organisation in which they operate. They receive requirements that describe the business need (The “WHY”) and acceptance criteria (“The WHAT”) and they, as a team, determine the solution (The “HOW”).
Self-organising teams scale much better than command-and-control style teams, where a manager delegates and defines the work.
Why would you want to have your expensive managers involved in assigning tasks and resource levelling? Members of a self-organising team know when they have spare capacity for more work and they pull work into their queue.
How can Service Management teams become more self-organising?
I think this is a simple one – do you have managers that delegate work or leaders that coach teams to success? If you have the former is that the best use of their time and skills? Give the team an opportunity to own their work and determine their own destiny, within the constraints of your organisation.
This loss of control by managers might result in a team more invested in its success, more motivated and higher performing.
“Rhythm is something you either have or don’t have, but when you have it, you have it all over.” ~ Elvis Presley
Agile teams are focused on the regular delivery of value into the businesses they serve. By limiting work to sprints, usually between 2 and 4 weeks long, they are able to continuously deliver work building a partnership based on trust.
Because 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.
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.
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.
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.
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!
When I went to my first itSMF Regional Seminar last month, I never would have believed that I would be putting those words together!
The event (hosted by Attenda for the London and South East region) was focussed on End to End Service Management, as well as that all important networking element.
According to outgoing Chair Jane Suter, their last attempts hadn’t been quite as successful, revolving around groups moving from room to room. However, on arrival, we were handed slips of paper with what looked like safe-combinations on them, and corresponding numbers were dotted about the venue, the idea being that at the various breakouts, we proceeded to the relevant number on the list to meet with like minded numbers!
This worked really well until we got to lunch time when we actually missed out one session altogether and the feedback session for the last one took a while – but it was actually a very valuable session.
I suggested that they should build in the time to do more detailed feedback, because after each presentation, and then each networking session, we were encouraged to look at the subject matter and incorporate those into our introductions.
I’m sure it’s an approach that has been done before, but was a pretty effective mechanism and a good icebreaker, especially for a few of us who were first-timers at these events.
The Role of the new CIO in an End-to-End Service Management Environment – Mark Fowle, Attenda
This was a well presented and well thought out presentation, not pitching Attenda, but putting forward their perspective based on their customer base.
The presentation focused on how the IT Director role was perhaps drifting away and being replaced with that of a Chief Information Officer as a key contributor – moving away from pure technical focus and looking to solve business problems.
When I put this in context with a CIO pitch a week later at the itSMF UK Software Tools Forum in Manchester – the focus of is very much on achieving business outcomes, setting and achieving meaningful Key Performance Indicators (KPIs).
Enforcing Service Management practices through interoperable systems – Neil Forster, Attenda
Neil’s time was perhaps a little shorter than he had intended, as he ran us through how Attenda put a management layer over the top of their third party tools to provide them with platform to get information to their engineers, when they need it.
Neil focused in three key areas – Event Management, Incident Problem and Change Management, and Service Knowledge Management
They have developed mechanisms to have their engineers check for likely “best bet” matching tickets, and with links to knowledge based articles approved by team leads.
His key message was the presentation of information at the point of need, as well as embedding knowledge in the process.
Service Management in an Agile/SOA environment.
The final speaker of the day was Graham Youngs, from Tata Consulting Services –I had been on the periphery of an Agile-run software development project for an ITSM deployment and until that project the only scrum I had heard of had everything to do with Rugby Union and nothing at all to do with ITSM!
In fact what it focusses on is speed of change versus quality of service, and what I could draw from my own experiences was that a good Agile project manager is as much a key to a development team’s success.
In my own experience, although there were attempts to break down the barriers between development and operations, it still needed flexibility and a firm hand from the agile/development management side to keep members of the team focused on their immediate role as well as the bigger picture.
A friendly environment and easy to network thanks to the “speed dating approach”
Things to improve
The structure of the networking breakouts were relevant to the day’s theme and I think that they should allow some feedback time on the sessions as the group become very interactive at that point, making the seminar worthwhile.