You'd think with all my video game experience that I'd be more prepared for this

Lean and Kanban for IT Operation: Kanban board

2012-01-18T17:13:00.000+11:00

People don't know what you're doing.

This is especially likely for non-technical "business people" but there may even be a large number of developers that have very little familiarity with what happens in operations.

The consequence of this is that there is a tendency to treat the operations team as if it's a magic bucket with unlimited capacity. If I don't understand what they do, then they're probably not doing anything.

To deal with this, you need to make the work, which is naturally invisible, visible. One way to do that is to setup a kanban board.

An example kanban board
Imagine a board with the following:

The work would be represented by index cards that would be moved across the board as the work progresses through the workflow.

A key point to be note is the Do-Wait cycle that occurs in In-Progress. The nature of operations work tends to exhibit this kind of phenomena where you do something and then you have to wait for a third party to respond.

The work is represented by colour-coded index cards based on the type of work:

Avatars are attached to the cards in order to communicate who is working on what:

If work becomes blocked, there is a blockage reason attached to the card:

If the work must be done by a particular date, that date is attached to the card:

Note that your specific kanban board can and probably should look different.

A few other examples:

Sysadmins Board from IT Ops Kanban: http://itopskanban.wordpress.com/sysadmins-board/

"Our first Kanban board for IT Operations and Support", http://www.systemsoup.org/2009/12/our-first-kanban-board-for-it-operations-and-support/

Spotify operations kanban board: http://www.infoq.com/articles/kanban-operations-spotify

Physical or electronic?

My personal preference is using physical kanban boards, however, every IT operations team I've worked with has eventually moved to electronic tools. This has usually been due to synchronising with geographically distributed team members.

The key thing to remember is that you are trying to expose your work to people external to the team, not just internally. So even if you use electronic tools, make sure that you also expose this on a large display, project it on a wall, etc.

I would also suggest at least starting with a physical board as it's usually simpler to start and faster to adjust.

What to do

Create your initial board with columns, avatars, etc. reflecting your understanding of the flow of work. I would recommend that this first version should be kept simple. Note that even if kept simple, you want to show what is actually happening NOT what you want to happen.
Modify the design of your kanban board as you realise that it is not quite communicating correctly and / or as the workflow evolves

A brief summary of solutions focus

2012-01-18T12:01:00.001+11:00

Common assumptions about organisational change
There are a few assumptions that are quite common for people involved with organisational change:

People don't like to change
We shouldn't jump to solutions until we fully understand the problem and why it is happening
Successful large-scale change requires revolution

If we believe these things then...

We should expect change to always generate resistance
We should spend a lot of time understanding problems
We should initiate changes with large change programs targeting all aspects of the organisation

Solutions-focused assumptions about organisational change
The Solutions Focused approach starts with different assumptions:

"Change is happening all the time; our role is to identify useful change and amplify it" (Gregory Bateson)
Detailed understanding of the problem may not actually help with the solution. No problem happens all the time, what happens when it doesn't?
Small changes in the right direction can be amplified to great effect

If we believe these things then...

"If someone starts to resist what you are doing, it is a sign that you have not yet found the best way to cooperate with them." (Paul Z. Jackson, Mark McKergow)
We should spend a lot of time understanding when problems don't occur
"Do not change faster or more than necessary" aka the change sparsity principle

Solutions-focus seems to me as a way to approach change with finesse rather than with brute, overwhelming force.

Three core ideas

Be as clear as possible about what is wanted
Harness what is already in place
Focus on what works over understanding problems and what doesn't work

Interesting solutions-focused techniques

The Miracle Question.
"Imagine that this session is over, you go home, do whatever you planned to do and then, at some point you get tired and go to sleep. Imagine that in the middle of the night, while you are still asleep, a miracle happens... and all the problems that brought you here today have been magically solved. But since you were asleep, no one told you. When you wake up, how would you discover that the miracle happened? What would you notice? If a miracle happened that solved all your problems, what would you notice that is different?"

The Miracle Question helps you create what is called a Future Perfect which, as far as I can tell, is pretty much the same concept as Ideal State / True North in Toyota / Lean circles. In fact, notice the similarity between the Albert Model...

... and the Improvement Kata...

Different graphical style, different word choice but otherwise the same emphasis on understanding the ideal state first, on the unknowability of the specifics on how the gap will be crossed, and on proceeding with incremental steps.

Scaling.
"Let's imagine a scale. The scale runs from 0 to 10, and 10 represents the state of affairs when you have reached your future perfect or desired outcome. Zero stands for when none of the things that you want is happening (or when the problems is at its worst). Where are you now?" (Paul Z. Jackson, Mark McKergow)

The point of this exercise is to highlight that you are almost never at zero, and if so, what are you already doing that's working? What know-how and resources do you already have?

Which then leads to the follow-up question:

"What would the next small step up the scale look like?"

Solutions-focus vs mastery?
One thing I'm wary about in solutions-focus is the emphasis that understanding why and resolving weaknesses are not important. This conflicts with what I understand about how expertise is developed, as well as how high-reliability organisations actually behave.

At the moment, I see solutions-focus as a very good way to initiate improvement for organisations of people. I'm not sure though about what happens for ongoing improvement, especially at higher levels of performance.

See also:

Coert Visser's blog, Doing What Works
The Solutions Focus by Paul Z. Jackson and Mark McKergow. There's a whiff of anti-science and lack of familiarity with the best "problem-focused" approaches (e.g., Toyota Kata) but this book is still quite useful to understand the approach.
Alistair Cockburn's summary, "Solutions Focus aka Delta Method"
The Miracle Question reminds me of Futurespectives
The overall solutions-focus approach reminds me of Positive Deviance

Building big things with lots of people who don't work the same way

2012-01-12T15:00:00.000+11:00

Let's assume that we're building the right thing.

In these cases, the actual user-exposed behaviour tends to be quite trivial while the bulk of the project is dealing with behind-the-scenes systems.

Let's assume that the project consists of multiple teams from multiple vendors who work in different ways.

One way we might respond to this would be to encourage or even attempt to force the teams to work together in the same way. This is generally naive and ineffective.

A more typical response would be to work out how to separate the work out into independent packages / components / services. This reduces communication overhead and helps isolate differences in work practices.

How would we determine the interfaces?
The typical approach to determine components and interfaces is to get an enterprise architect or bunch of architects together and get them to work it out.

The extent to which this approach is effective is highly dependant on whether the architects have previously built multiple similar systems. With large, complex systems, this familiarity is highly unlikely.

Instead, a safer approach is Conquer and Divide. Start with a smaller, combined team, and build the core of the overall system together. This should flesh out what actually makes sense in terms of separate components and interfaces. Once that is clearer, then the separate teams can split off appropriately.

Some of the biggest risks are about integration and schedule collapse due to dependencies
With a large, complex system built by multiple teams from multiple vendors, who work in different ways, by far the largest risks are related to separate components built by separate teams not working together, and schedule collapse due to problems with coordinating dependencies across teams. Again, this assumes that we're building the right thing overall.

How might we get early detection of integration problems?
My preference is to use automated interface / contract tests to explicitly capture behaviour expected from all teams. Both sides of an interface will know what they should expect and what is expected of them even if components have not yet been built yet. If an implementation problem requires a change in the interface behaviour, then we explicitly know that we must inform other teams.

How might we prevent schedule collapse?
If schedules are important then it is worth buying the insurance of building multiple options for critical components, that is . That is, implement a simple version first and then implement a more complicated but better version after. Because the simple version is built first, we have already protected ourselves from the scenario where another team needs to integrate with our component and we have nothing ready.

Lean and Kanban for IT Operations: True North

2012-01-11T17:57:00.000+11:00

As long as IT Operations is in constant fire-fighting mode, there can be no significant improvement. To help shift from a tactical to a more strategic focus, I find it useful to create a True North.

True North is about answering the question:

If IT Operations was perfect from the perspective of your customers, team members, and stakeholders, what would it look like?

Note that True North doesn't even need to be actually achievable because the purpose is only to provide direction.

What to do:

I've found that determining a True North tends to be just a discussion. Preferably all of IT Operations participates but at least leaders and influencers should be involved.

It's also useful to understand what industry leaders are capable of such as Etsy, Amazon, Netflix, Flickr, etc.

The IT Operations True North should be aligned with the larger organisation's True North but that may or may not exist. Do the best you can with what you do have.

Example:

See also Toyota Kata and Getting the Right Things Done.

Our ideal vs their ideal; our problem vs their problem

2012-01-10T17:41:00.001+11:00

For Agile / Scrum / Kanban advocates, questions about Waterfall vs Agile, Scrum vs Kanban might seem quite important and essential.

Just remember that most people don't actually care.

What we consider problems worthy of blog posts, multiple tweets, and e-mail flame wars are actually quite unlikely to be problems that most other people consider worthy of even thinking about.

If you want to help people, remember that your ideal is not their ideal and your problems are not their problems.

Instead... try understanding what their ideal is and therefore what their problems are.

Lean and Kanban for IT Operations: Quick and easy wins

2012-01-10T16:35:00.002+11:00

If the situation is severe enough, you won't really have time to wait for the ultimate solution. You need some quick and easy wins to buy yourself some breathing space first.

There are several of these kinds of tactics that generally work for IT Operations. Note that I generally expect the team lead or even people external to the team to be doing this as the operations team members in severe situations will be busy enough just doing the work:

Create a single, prioritised request queue (and limit WIP!). This includes walk-ups. This removes any confusion about what everyone is supposed to be working on and provides focus. As an example...

Clean up alerts. Review and remove alerts that you can't actually do anything about as an incident response. People should not be paged unless they can actually do something. Aggressively address causes and root causes of incidents to remove them permanently. A more manageable pager load means a more refreshed team and less mistakes that generate more problems.

Setup a problem board. Anything that gets in your way or slows you down goes up on the problem board. Capture frequency to prioritise what gets address first but otherwise aggressively contain then countermeasure.

Instead of teaching a whole bunch of things at once, teach one concept at a time

2012-01-10T10:10:00.000+11:00

As an Agile advocate...

...have you noticed that you've had to explain the same concepts repeatedly?

In many of my engagements I find myself having to repeat explanations of certain concepts, primarily Agile and Lean concepts, but also technical or business concepts. The most effective, sticky explanations tend to be a combination of a sketch and a narrative about the concept.

Would it be useful to have pre-prepared props to help with these kinds of situations?

I learned about One-Point or Single-Point Lessons from the Lean community. The basic idea is that developing people should be a continuous process; instead of teaching a whole bunch of things at once, teach one concept at a time (aka one-piece learning vs big-batch learning). In order to do that, create lessons based on a single point, typically on a single piece of paper, which is then reviewed during the daily meeting.

What would a good One Point Lesson look like?

Useful Prop: When a situation arises during an engagement, you will have a prop to hand out and reference to tell a compelling, sticky narrative around a single, useful concept.
Memory Trigger: Having a set of one-point lessons is a nice way to remind you of what might be a useful concept to introduce to the current context. This is similar to IDEO Method Cards.
Development Tool: For the less experienced, a set of one-point lessons provide a way to learn about what kind of concepts they are expected to understand.
Social Object: One-point lessons, if they are cool enough, are something that people will want to put up in their workplace. They are something that invites others to ask about, to start conversations about.

An example:

Notes:

Typical approach: get everyone to think the right way -> values and attitudes change -> naturally start to do the right things

NUMMI approach: start with behaviours (aka what we do) -> values and attitudes change -> everyone thinks the right way

"Define the things we want to do, the ways we want to behave and want each other to behave, provide training, and then do what is necessary to reinforce those behaviors. The culture will change as a result." John Shook

"It's easier to act your way into a new way of thinking than to think your way into a new way of acting" (Millard Fuller, founder of Habitat for Humanity)

"Act the way you'd like to be and soon you'll be the way you act." (Dr. George Crane)

Edgar Schein's (coined phrase "corporate culture") definition of culture:

"The pattern of basic assumptions that a given group has invented, discovered or developed in learning to cope with its problems of external adaptation and internal integration and that have worked well enough to be considered valid, and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems."

References:

How NUMMI Changed Its Culture - John Shook
Change models: Shook, Schein, Dreyfus and Constructivism - Allan Kelly

Eight guidelines for closing the knowing-doing gap

2012-01-05T15:57:00.002+11:00

From The Knowing-Doing Gap, a nice summary for closing the gap between knowing what to do and actually doing it:

Why before How: philosophy is important. Focus on Why (philosophy, general guidance) before How (detailed practices, behaviours, techniques)
Knowing comes from doing and teaching others how. "Knowing by doing develops a deeper and more profound level of knowledge and virtually by definition eliminates the knowing-doing gap."
Action counts more than elegant plans and concepts. Ready, fire, aim. Act even if you haven't had the time to fully plan the action.
There is no doing without mistakes. What is the company's response? Forgive failure. "Reasonable failure should never be received with anger"
Fear fosters knowing-doing gaps, so drive out fear. "Organizations that are successful in turning knowledge into action are frequently characterized by leaders who inspire respect, affection, or admiration, but not fear."
Beware of false analogies: fight the competition, not each other. Collaboration and cooperation over competition. "The idea that the stress of internal competition is necessary for high levels of performance confuses motivation with competition."
Measure what matters and what can help turn knowledge into action. "The foundation of any successfully run business is a strategy everyone understands coupled with a few key measures that are routinely tracked." Focus on measuring the business model / process (aka why outcomes are achieved) over the outcomes.
What leaders do, how they spend their time and how they allocate resources matters. "Leaders create environments, reinforce norms, and help set expectations through what they do, through their actions and not just their words.

Switch: How to Change Things When Change is Hard

2011-12-16T11:51:00.000+11:00

I've just finished reading Switch by the Heath brothers and I would highly recommend it. Very good story telling and very broad references.

A quick summary (using different words):

Identify What to Change To

Identify Positive Deviants: See also The Power of Positive Deviance and look into Appreciative Inquiry
Identify specific, critical behaviours
Point to the destination. Where and why.

Motivate the Change

See-Feel-Change over Analyse-Think-Change
Shrink the change. Aka the change sparcity principle: Do not change faster or more than necessary.
Cultivate identity and a growth mindset. See also Mindset.

Shape the Environment

Change the behaviour by changing the situation. See also Influencer.
Encourage habits using action triggers
Cultivate social motivation and support

Lean and Kanban for IT Operations: What are our skills?

2011-12-13T13:11:00.000+11:00

How much can we do versus what can we do
In order to understand our capacity, that is how much work we can absorb, we might measure how many work items we generally complete in a particular time period.

However, we know that not all the work items in IT operations are the same and not everyone can do any particular type of work at the same level of proficiency.

To truly understand what we can do, we need to have a clear view of the skills within our team.

Who should I talk to if I want to learn about X?
I normally frame this in terms of skills development. If I'm stuck or want to learn about a particular technology or technique, who should I talk to? If I want to best contribute to the team, what skills are we the weakest at?

What I like to use to help with this is a skills matrix, also known as a cross-training matrix.

For example,

What to do

Determine your skills criteria. Keep this simple and concrete:

Level 0: Insufficient knowledge
Level 1: Knowledgeable but no capability
Level 2: Can perform but needs review
Level 3: Can perform to standard
Level 4: Can teach to standard; improves the standard

Identify the key skills. But don't include everything. That's just distracting. Instead focus on skill constraints based on holes in team capability and where you have only 1 or 2 experts.
Assess the skills to fill in the matrix. I tend to just do this as a self-assessment and then peers tend to correct each other.
Adjust over time. As the skills in the team evolve, the matrix should evolve too.

Socialising, trust in the work context, and diversity

2011-12-12T10:40:00.000+11:00

Pretty much all organisation run social "team-building" activities, from informal drinks, team/office parties, to more formal off-site adventure course type events.

The idea is that this will develop social cohesion and allow personal trust and favours to smooth over bad or unclear work protocols.

I've always been somewhat sceptical of this.

Does trust transfer across context?

The fundamental assumption is that trust developed in the non-work-specific context will transfer to the work-specific context.

Is this actually true?

When I think of trust in a work context, I break it down into two aspects:

Competence: Do I trust that the person is capable of doing the work?
Expected behaviour: How do I trust the person will behave?

Will a non-work-specific social activity develop trust in work-specific competence? Does a person's behaviour in a non-work-specific social activity develop trust in their work-specific behaviour?

It seems reasonable that some aspects would transfer but surely not all of it would be relevant.

Does a focus on socialising discourage diversity?
Even if trust actually does transfer from social to work contexts, if we couple team membership to ability to socialise outside of work, does this act as a force towards team homogeneity?

Imagine that instead of focusing on socialising, we focus more on developing our trust in mutual competence (practicing together, actually working together) and developing our trust in expected behaviour (agreeing on team interaction protocols). So even if I hate the person, as long as I trust s/he is competent and we both have agreed to interact in a particular way, then we can work effectively together.

The consequence is that now we are not limited to only working with people we like socially.

What happens with the diversity of an organisation when we change the balance between personal trust and protocol trust?

Obviously large organisations don't like ideas...

2011-12-07T15:00:00.001+11:00

You work inside a large organisation. You have a great idea which you tell anyone who will listen but nothing happens. Obviously large organisations don't like ideas...

Or maybe not...

If nothing happens with your idea, perhaps you need to sell
And by selling I'm thinking of SPIN selling. For the people you need to influence to progress the idea:

What is their (as opposed to your) situation?
What are their (as opposed to your) problems?
What is the implication to them (as opposed to you)?
What do they (as opposed to you) need? And how does your idea align with this?

Is it surprising that people are typically not interested in ideas about problems that they don't believe is relevant to them? Is this really limited to large organisations?

Ideas have different sizes and types
Some ideas are easy to do and don't impact a lot of people. Other ideas are quite expensive, require a lot of coordination, and impact a lot of people. It seems reasonable that the way we deal with the idea should depend on where it is on the spectrum of difficulty and risk.

Perhaps the reason why the idea got stuck because it was routed incorrectly?

Or... the organisation's idea routing isn't reasonable and only has one route for all ideas...

There is always an existing system
There is always an existing way that ideas are handled within an organisation. It may not be explicit, it may not be altogether effective, it may not even be consistent, but it does exist.

With a smaller organisation, you should probably still notice problems with how ideas are handled even if it's not an explicit approach.

With a larger organisation, this is highly unlikely. Making the existing approach explicit and encouraging curiosity can help highlight the problems.

Lean and Kanban for IT Operations: Understand the flow of work and information

2011-12-05T09:02:00.001+11:00

Who is your customer?
If you are on a desktop support team, who is your customer?

It's not the team leader.

The customers would be the internal staff that need the new desktop setup, that need a password changed, etc. You may have people in between who make the requests on their behalf, that is, their manager, but it's probably most useful to consider the end user as the "customer".

If you are on a BAU (business-as-usual) change support team, who is your customer?

It's not the team leader.

The customers really depends on what kind of systems you are supporting. Some of them may be for internal staff while others may be for external customers.

If you are on a site operations team, who is your customer?

It's not the team leader.

Most of your customers are the external uses of the site / system. You will probably also have internal customers, for example, application development teams who need to deploy changes.

What are your work flows?
IT Ops teams have multiple work flows related to how many types of customers they have and how many types of work they have. However, it's not really necessary to map them all. The most common work flow, that is, the most common work type for the most common customer type, is a good place to start.

So how do you determine an actual work flow?

Look at the work item and follow it from creation to completion to the customer observing what happens to it, who works on it, how long it is worked on, delays that occur, rework that occurs, etc.

How are your work flows managed?
How is the "work on this next" signal sent?

For example, does the team leader triage and assign all the work? Is it all self-managed through the ticketing system? What about walk-ups?

What to Do (or really how I do this)
When I do this, it's more about looking around, talking to people, browsing logs, and poking around ticketing systems. I am trying to understand the flows but I have never actually drawn a map as it never seemed necessary to highlight a particular problem. The eventual creation of a Kanban board perhaps also reduces my desire to use a drawn map.

This is quite different in software development situations where I've always tended to draw the value stream. I wonder if this has to do with how overloaded the teams tend to be, the nature of the work, some accidentally developed preference, or something else.

So all I can really suggest at the moment is to focus on shared understanding and experiment with drawing or not to see if it makes things better or worse.

Thoughts on value stream mapping in IT / software development

2011-12-04T09:44:00.000+11:00

What is now commonly known as value stream mapping was originally called Material and Information Flow Analysis, that is, the idea was to understand how material moved through the system, what information was provided to support that movement, and how that information was provided. The act of creating this map, which requires observation and investigation, would expose opportunities for improvement.

Is value stream mapping a useful tool for the IT / software development world?

How might we answer that question?

Let's clarify the question.

Is it useful to understand and vlsualise, through observation and investigation, how IT / software development work (i.e., change requests, product features, etc.) flows as well as how and what information is provided to support and manage that work? Would it expose opportunities for improvement that would not otherwise be easily seen?

But isn't software development more like a network than a stream?
One advantage of the original phrase, Material and Information Flow Analysis, is that there is no implication of a single linear stream of activity. Using the phrase "value stream" or "value chain" does create this implication which is why the concept of "value network" comes up.

In object-oriented (OO) software development, novices may believe that object models are about modeling the world exactly. Experienced OO designers though, understand that what we are actually trying to do is represent the world in such a way that allows us to deal with our systems effectively.

So, if we want to judge a mapping approach, instead of asking:

"Is this a more exact map of what's happening?"

we might ask questions like:

"Does this highlight X type of problem more clearly than if we map this differently?"

"Does this map (with its realistic complexity) highlight problems better than a simpler map or even no map at all?"

There is more to see than just work and information flow
Understanding and visualising work and information flow is quite effective in highlighting problems with unnecessary delays and some forms of quality problems.

But there are more potential problems than that...

Do we have problems with skills and/or skills development?

What is the experience of all the stakeholders?

Self-organisation does not mean absentee leadership

2011-11-30T12:33:00.001+11:00

A team forms in order to complete a project. The "leader" doesn't really do anything to help define success criteria, identify the general approach they'll take, or contribute to resolving detailed issues. Eventually someone else on the team steps up and fills in the gap.

Was this an example of self-organisation? Yes. It's also an example of an incompetent, absentee leader that the team was able to compensate for by identifying an actual leader.

A team forms in order to complete a project. The leader independently defines the success criteria, independently identifies the general approach to be taken, and is involved in resolving every detailed issue. The "team" simply does what the leader tells them to do.

Was this an example of self-organisation? No. But it is an example of an incompetent, authoritarian leader.

So how can you tell the difference between someone developing the team to be more autonomous versus someone who is just incompetent?

If we remove the leader and there is no loss, that probably means the leader was useless. If we remove the leader and there is complete and utter collapse, that probably means the leader was incompetent. If we remove the leader, and there is loss but the team compensates and continues to improve, that probably means the leader was useful and competent.

What is Kanban?

2011-11-28T10:34:00.000+11:00

Kanban != kanban
I'm talking about Kanban, as in the method used in software development / IT circles, rather than kanban, as in the tool used at Toyota and in Lean. Having to say this is why I've always found it unfortunate that the same word was used.

However, Kanban invariably leads to kanban as a countermeasure so there is that...

The foundation of Kanban is incremental, evolutionary change
From The Principles of the Kanban Method,

There are 3 foundational principles:

Start with what you do now
Agree to pursue incremental, evolutionary change
Respect the current process, roles, responsibilities and titles

In other words, the Kanban Method follows the same change sparsity principle of solution-focused and positive deviance approaches:

Do not change faster or more than necessary

The reason for this is that smaller changes are less threatening, less disruptive, and more motivating and yet can still have highly leveraged effects.

What is the method of change?
From The Principles of the Kanban Method,

There are 5 core properties:

Visualise the workflow
Limit WIP (work-in-progress)
(Measure and) Manage flow
Make process policies explicit
Improve collaboratively (using models and the scientific method)

Here's how I prefer to express this:

Visualise for shared understanding (of work flow, information flow, and capability)
Limit WIP (work-in-process)
Measure performance (productivity, quality, cost, morale)
Make process policies explicit
Improve collaboratively and scientifically

Visualise for shared understanding (of work flow, information flow, and capability)

Visualise to make our implicit understanding explicit and thus allow any disagreements in understanding to be resolved.

Because in software development, the work itself is information, it is easy to confuse work flow and information flow. Information flow refers to work signaling, for example, "how do you know what to work on next?", while work flow refers to the movement of a work item (e.g. feature) from the start to end of our process.

It's not enough to understand the flow of work and information.

Visualise to share understanding of the flow of work items, the signals we send to manage those work items, AND the capabilities of the people working within the system.

Limit WIP (work-in-process)

I'm inclined to consider Limit WIP as not part of the change method so much as a very common, perhaps, fundamental solution that the Kanban community uses.

Limiting WIP is technically quite easy to do but can be very difficult psychologically and politically to do. So difficult in fact, that I'll suggest that if you are able to convince people to actually Limit WIP, and not just that it's a good idea, the rest is rather easy by comparison.

Measure performance (productivity, quality, cost, morale)

Measuring performance always starts with the question: "What does it mean to be good at this?"

My answer will be efficiently, and sustainably, delivering value that delights customers. Just being fast isn't enough. Just delighting customers isn't enough. Just being efficient isn't enough. Just being sustainable isn't enough.

Make process policies explicit
Similar to visualising, making process policies explicit exposes disagreement which allows us to resolve conflict. In general, making knowledge about how things work explicit is a democratising action. When only a few people really know how and why things are done, they make all the decisions on how to improve; when we all know how and why, we can all participate in the decisions.

Improve collaboratively and scientifically
Every other Kanban property is about exposing the situation and problems. The final property is the response. Improve collaboratively because involvement in change leads to commitment to change. Improve scientifically because otherwise we're more likely to just change and not actually learn and improve. Improving scientifically means actually making a prediction about the effect of an intervention and re-assessing our model of reality when the intervention results in worse or even better performance than predicted.

Kanban is not the common solutions that the community uses but it's useful to know what they are
Although Kanban is officially referring only to the The Kanban Method, it's useful to also consider the typical Kanban-ish solutions that the community uses:

kanban typically in the form of kanban boards (aka heijunka boards)
Some variant of MMF (Minimum Marketable Feature), BVI (Business Value Increment), MVP (Minimum Viable Product), etc.
Cumulative Flow Diagrams
Statistical Process Control charts, especially for cycle and lead time
Multiple cadences
Classes of service
Greatly simplified estimation
Etc.

How do we close the gap between teams with different ways of working?

2011-11-24T13:59:00.001+11:00

Especially in larger organisations, there tends to be a lot of separate teams:

Separate projects teams doing application development
Separate BAU teams
Separate operations teams
Etc.

Each of these separate teams will tend to have different ways of working. But given that work passes through and is coordinated amongst each of the teams, the difference in ways of working tends to cause friction and confusion.

So how do we deal with this?

Re-organise to service teams?
Organise teams around end-to-end products or services. These product / service teams would be responsible for app dev, BAU changes, and operations.

Would this work?

Given that one team is handling the lot, we shouldn't have problems with different approaches. But what about interactions between product / service teams?

More significantly, major re-structuring is always a rather crude intervention. It may technically work but is more likely to engender an incredible amount of change resistance.

In most situations, I prefer lighter touches first.

Encourage natural consistency
There are generally two approaches to consistency in ways of working:

Attempt to impose it via policy
Encourage it via exposure

Consistency encouraged via exposure is what I call natural consistency:

Have showcases between teams about how they do things and ideas they have
Rotate people between teams
Combine into one team

But natural consistency will not eliminate all variances in ways of working. For that matter, it should not eliminate all variability as we should expect that doing different things requires working differently.

So no matter how naturally consistent we are, we still need to work out how to work together despite our differences.

Agree clearly on how you will work together
When we're building services that need to communicate, to send messages to each other, we will be explicit about both the messages and the protocol.

That's pretty much what we can do with teams:

Agree clearly on how you will work together
Agree what is part of the protocol (decided between teams) and what is outside (decided within team)

Lean and Kanban for IT Operations: How well are you performing?

2011-11-23T15:18:00.000+11:00

"The first principle is that you must not fool yourself--and you are the easiest person to fool."

Richard Feynman, Cargo Cult Science

If we want to know what interventions to make as well as whether our interventions make any difference, we need to understand how well we are performing now.

I like to think of performance using 4 general categories:

Productivity: How much output do you get based on the effort you put in? How fast do you complete tasks? Examples:

Time-to-resolve
Server-to-Server Administrator ratio

Cost: How much does it cost to run your operations? Examples:

Asset costs
Labour costs

Quality: How good is the output from the perspective of your customers (internal and external)? Especially with internal customers, have you ever wondered how people thought of the service you provide them? Examples:

Net Promoter Score or a simpler customer satisfaction measure
Qualitative assessment (aka talk to people)

Morale: How do the team members feel? I always say that you can have situations where Productivity, Cost and Quality are fine but only because the team is engaging in heroic measures. Morale acts as a leading indicator of potential collapses in the other measures. Examples:

Niko niko calendar
Employee satisfaction / engagement
Qualitative assessment (aka talk to people)

When I've previously shared these categories, someone suggested that I should also include a general category for Scalability or perhaps Sustainability.

I'd be interested in what people think of this, especially if they have further suggestions.

Why aren't people interested in releasing incrementally?

2011-11-20T08:08:00.001+11:00

It seems very obvious to us in the Agile crowd that incremental release is superior:

You learn faster by exposing problems faster
You get better cash flow

And yet we very often encounter people in organisations that seem not to be interested in incremental release... why is that?

Lack of focus on cash flow. Especially with large corporations, there is a tendency for an implicit belief that "cash falls from the sky". Money comes from the budgeting process, not from delivering valuable products and/or services.

The increment will need to be reworked or thrown away. This is essentially loss aversion. Just because we've invested in something initially doesn't mean that the correct next step won't be to drop that initial investment. However, because humans are naturally more averse to loss, we will have a tendency to not want to put ourselves in that position.

Incremental releases will undermine the brand. When someone hears "incremental", they may be translating that to "half-ass" rather than "half the features". From a product/service marketing perspective, there are actually a lot of opportunities with incremental releases especially if you are able to target subsets of users:

reduced brand risk by not doing drastic changes all at once
ability to target market segments
ability to A/B test

I'd suspect that if you actually talk to product/service marketing people about what problems they have and what they want to do, you'll find that it lines up quite nicely.

The budget process does not support incremental releases. Try talking to someone in your finance department:

"We are thinking of moving to more incremental releases because [insert reasons] and we believe it will improve cash flow, but we're not sure how to model this financially or how to make it fit with budgeting. Would you be able to help?"

It can't technically be done. When you talk to the various IT stakeholders, remember one question:

"If were able to solve that problem, is there anything else that would stop us from releasing incrementally?"

When you gather all the problems, then it's just the simple though not easy matter of working through them all.

Other miscellaneous administrative reasons tend to follow the same pattern:

Talk to the stakeholders
See if they actually have a problem as they may not
If they do have problems, make sure you get all of them
Work the problems one-by-one

Lean and Kanban for IT Operations: What is the nature of demand?

2011-11-19T16:12:00.001+11:00

What are the different types of work?
If you look at all the types of things that IT Operations teams do, they generally fall under one of the following categories:

Tickets
Business-As-Usual (BAU) changes
Project work (this includes supporting development projects as well as internal improvement projects)
Incidents
Ad-hoc (aka the walk-up)

Your particular situation may be slightly different or you may prefer a different kind of breakdown but you should be able do a similar categorisation.

Is the work more predictable than you think?
At first glance, you might expect projects and BAU to be predictable and therefore able to be scheduled, while incidents and ad-hoc would be unpredictable and therefore unable to be scheduled. Tickets would be somewhere in between.

If you look more closely, however, I would suspect that a lot of the work is much more predictable and able to be scheduled than typically believed. A few examples:

Do you have tickets or incidents raised because some license or certificate is expiring soon? Given that the expiry dates are known, this work could have been scheduled for more convenient times.
Are you watching capacity trends in order to be able to schedule upgrades to memory, disk space, etc.?
Have you noticed that tickets, changes, incidents increase around project releases?

The reason why you should be interested in predictability is that you can use that to level the demand which makes coordination easier and generally makes work life more pleasant.

How much noise is in the ticketing system?

Having noise in your ticketing system refers to tickets that aren't really going to be done and therefore interfere with your ability to see how much work needs to be done. For example,

Tickets that should be scheduled in a calendar instead
Wishful thinking tickets. These are typically tickets that have been around for a very long time (over a year) with no resolution.
Work that needs to be done but is already handled by another team.

Even if you know they are noise, it's very difficult psychologically to ignore noisy tickets without actually removing them from the system.

What to do:

Identify all the different types of work that is done. You can probably get most of this from existing ticketing systems and project records but be careful about hidden demand that is not currently recorded. You can either directly observe yourself or ask the team.
What is the distribution of effort based on work type? That is, how much effort do we spend on tickets vs BAU vs projects, etc. Is it what we think it should be? Why or why not?
What is the distribution of scheduled vs unscheduled work? How much of the unscheduled work is actually predictable?

Possible interventions based only on information acquired by this point:

Single request queue: Everyone on the team should only have one priority queue to determine what to do next. In most places, this is primarily the removal of "walk-up" requests as a valid prioritisation mechanism. You might accept the request in a walk-up but unless it is an emergency incident, it doesn't automatically get prioritised.
Remove the noise: Begin reviewing and removing noisy tickets
Level predictable demand: Begin reviewing and scheduling predictable work

Clayton Christensen's 5 keys to improve the probability of successful innovation

2011-11-19T11:51:00.001+11:00

Disruption (aka The Innovator's Dilemma)
Compete against non-consumption
Supply chain disruption (i.e., disruption coming from your own suppliers)
Target the job, not the customer
Catch the tide of decommoditisation

Via his talk at the 2011 Gartner Symposium

Unfortunately he ran out of time in that talk so he doesn't actually describe the 5th key.

Tactical vs strategic prioritisation

2011-11-18T09:04:00.001+11:00

We can portray potential features in a 2x2 matrix of value vs effort:

It seems easy enough to say that the first things we do should be the low-effort, high-value features and we should not bother with the high-effort, low-value features. Then we make judgments on high-effort high-value features vs the low-effort low-value features on a case-by-case basis.

Seem reasonable?

On the other hand, will this feature-by-feature approach actually produce the best product result?

In practice, how much trust do we have in the value assessment? Will we systematically undervalue certain types of features due to biases for faster ROI? Or to phrase that more generally... Do humans have a tendency to systematically undervalue long-term investments due to biases for faster ROI?

What about features that have no or minimal value on their own but, when combined with other features, create a large aggregate value? After all, we are not creating a bag of features so much as an overall product/service experience.

(Fantasy)

"I like this product because it has more features than the others."

(Reality)

"I like this product because it's better than the others."

"What does 'better' mean?"

"Exactly."

I suspect feature-by-feature prioritisation is a good tactical prioritisation approach but is inadequate as a strategic prioritisation approach.

Instead of feature-by-feature, perhaps prioritise using aggregates of features where the aggregates are steps toward the True North (aka perfect) vision of the product. Within the aggregates, we do feature-by-feature prioritisation.

Note: By "feature", I mean a Minimum Marketable Feature, that is, something that is independently valuable and releasable. A Feature Aggregate is a collection of MMFs. I'm also assuming that each MMF is released so Feature Aggregate is not synonymous with Release.

Lean and Kanban for IT Operations: What are the nominal problems?

2011-11-17T10:34:00.001+11:00

What triggered you to even bother looking at Lean and Kanban for IT Operations? What are the problems that you're thinking of?

You should fully expect that your statement of the problem will change as you learn more about the situation but it's important to start from something if only to clarify why other people would be interested in participating.

I would say that it is not even necessary at the beginning to agree on what the specific problems are but rather only to agree that there are problems and it is worth investigating. It's also valuable to understand where everyone is coming from.

What to Do:
Answer the following questions:

What is the overall change / improvement / problem you want solved?

What is the purpose / business reason for change?
What specifically needs to be improved?

Productivity?
Cost?
Quality?
Morale?

What is the context?

Has anything been done before?
How does this relate to organisational structure and culture?
How does this align with organisation strategy?
What is your sphere of authority and sphere of influence?

Approach:
Two general approaches to get the answers:

Do it by yourself and walk around to get feedback, involvement, commitment
Do it in a group session

Which approach you take really depends on availability of people, local preferences, your preference, timeframe, etc.

Example: Sev 1s; Scaling
(Note that even though I'm answering the questions, I don't need to structure the answer that way. Also, you may not be able to answer all the questions, which is fine. You should expect the answers to change anyway as you learn more. This still helps you setup a starting / talking point.)

Owned by: Bob (Site Ops team lead)
Authorised by: Alice (Head of IT Ops)

Overall Theme: Improve reliability and scalability of our Site Operations team

Background:

Recent Sev 1 failures not managed well; incident levels have noticeably increased in the last few months
Staffing growth is linear to revenue growth; un-scaleable cost structure
The organisation plans to grow by 20% year-on-year
Improvement attempts started 30 days ago have had no impact and have decreased morale

Example: Conflict between teams; too much overtime; too many projects

(From http://itopskanban.wordpress.com/before/)

many teams (DBA, Networks, Sysadmins, Service Desk, Release team) often inadvertently working against each other.
All communication done via helpdesk software and emails, even when individuals sat next to each other resulting in very little collaboration and team work.
Very large overtime bill with many individuals regularly working a 70 hour week.
Over 60 projects in flight – prioritisation by “he who shouts the loudest”
Project Managers going head to head over shared resources and applying unfair pressure to delivery teams
Teams time-slicing between projects, departmentally struggling to manage many stakeholders and strike a healthy balance between projects, incidents, and BAU.
Regularly missed deadlines, wasted capacity – particularly around hand-offs, waiting time, and lot’s of partially done work.

Example: Difficult to focus

(Note that this can be very simple as a starting point)

We get a lot of emergent work which makes it difficult to focus on projects

Lean and Kanban for IT Operations Field Guide

2011-11-17T10:18:00.001+11:00

A short while ago, someone asked me whether there was a further expansion to what I described in my Lean Kanban Benelux presentation on Lean and Kanban for IT Operations... and I thought, that sounds like a good idea!

So I plan to write a series of blog posts to act as a kind of field guide to Lean and Kanban for IT Operations.

I'll use this post as a roadmap which I'll update it as the individual posts are done.

----

Understand the current situation

What are the nominal problems (aka triggers)?
How do things currently work?

What are the actual problems? Revisit the problem statement.

Quick and easy wins (If the situation is severe enough, do this before completing 1)
What is True North? (If you are not in a firefighting situation do this before 1 and 2). Revisit the problem statement (gap between current and future state as step toward ideal)
Optimise conditions for improvement

Expose information - kanban board, explicit policy
Limit WIP
Measure Performance
Improve collaboratively and scientifically

Typical solution patterns

Join us for Sydney Lean Coffee

2011-11-16T09:36:00.001+11:00

We've been running a Lean Coffee in Sydney since July and it would be great if we could get more participation.

We meet every Tuesday 8:00 - 9:00 at the patio area outside the Rouge Bar in Australia Square in the CBD. Feel free to drop by and look for the people with index cards on the table.

Take a look at the Sydney Lean Coffee blog for examples of what we have talked about.