When talking about motivation, many people will reference Drive with its three key factors:

• Autonomy
• Mastery
• Purpose

One of the main sources that Dan Pink used for Drive is self-determination theory, which also points to three key factors for human motivation:

• Autonomy
• Competence (which is perhaps not as trendy sounding as Mastery)
• Relatedness

Note the difference with the last factor.  Dan Pink used "Purpose" while self-determination theory has "Relatedness".
Imagine you're in a job.  You have very broad autonomy.  You are very good at the job and are constantly getting better at it.  The job contributes to a grand purpose to do good in the world.  However, you don't identify with anyone at work, you end up mostly working on your own because every interaction with others reminds you how disconnected and uncaring your workplace is.
Imagine you're in another job.  Again, you have very broad autonomy and you are very competent and getting better at the job.  This time, you feel very connected with your work colleagues and generally feel a strong sense of mutual caring.  However, if you really think about it, the purpose of your work is really nothing special.
Which job feels more motivating? Which job do we think will be more motivating for most people?

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.

----

1. Understand the current situation
1. What are the nominal problems (aka triggers)?
2. How do things currently work?
1. What is the nature of demand?
2. How well are we performing?
3. Flow of work and flow of information
4. What are our skills?
3. What are the actual problems? Revisit the problem statement.
2. Quick and easy wins (If the situation is severe enough, do this before completing 1)
3. 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)
4. Optimise conditions for improvement
1. Expose information - kanban board, explicit policy
2. Limit WIP
3. Measure Performance
4. Improve collaboratively and scientifically
5. Typical solution patterns

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

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

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.

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.

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.

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.

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

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

1. Why before How: philosophy is important. Focus on Why (philosophy, general guidance) before How (detailed practices, behaviours, techniques)
2. 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."
3. 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.
4. There is no doing without mistakes. What is the company's response? Forgive failure. "Reasonable failure should never be received with anger"
5. 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."
6. 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."
7. 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.
8. 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.

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

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.

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:

1. Competence: Do I trust that the person is capable of doing the work?
2. 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?

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.

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.

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?

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.

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:

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

Here's how I prefer to express this:

1. Visualise for shared understanding (of work flow, information flow, and capability)
2. Limit WIP (work-in-process)
3. Measure performance (productivity, quality, cost, morale)
4. Make process policies explicit
5. 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.

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)

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