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

The visual design of cards on a wall

2012-05-24T19:13:00.000+10:00

Agile teams put cards on walls and boards.

I wonder though how many of those teams understand that the purpose of visual management is to make problems obvious.

How easy is it understand the board?
Can you read the cards from a distance?
Can you read the cards at all?

Mundane details like large and legible lettering, consistent colour coding, vertical positioning for importance, etc. are quite important.

The purpose of visual management is to make problems obvious. How well is the visual design of your Kanban board / card wall / task board fulfilling that purpose?

My current thoughts on organisational change / transformations

2012-05-24T07:21:00.004+10:00

I'm currently seeing transformations as exhibiting the same characteristics as introducing a new product to a market place.

So I'm thinking more about mindshare and what influences how people decide to "buy" an idea or behaviour. See New Lanchester Strategy and Stratified Systems Theory.

I prefer to emphasise the aspects of context to pay attention to (e.g., mindshare, what is already happening, business context, etc.) rather than a sequence of context-free change steps.

I've also always thought that there should be in general two change strategies in play simultaneously. One that is coordinated, centralised, targeting leveraged initiatives and one that is de-centralised, grassroots, opportunistic. The first strategy deals with faster, more significant payback and the second strategy deals with long-term engagement and innovation.

Very recently, I'm interested in the Learn Startup for Change approach that Deloitte LEAN and Yuval Yeret are experimenting with.

How to undermine dialogue with emotional hijack

2012-05-03T19:42:00.000+10:00

Emotional or amygdala hijack refers to what happens when stimulus bypasses the neocortex (thinking brain) and goes straight to the amygdala (fight or flight emotional response).

To trigger emotional hijack, you need to increase the level of perceived threat. For example,

raise your voice
appeal to strong emotions, especially using imagery
engage in personal attacks
interrupt and talk over people

All of this should undermine thoughtful dialogue and any semblance of desire to seek understanding and common interest.

For pretty good examples of this in action, I would suggest watching a few parliamentary debates.

Regression tests for organisational change

2012-05-02T20:43:00.000+10:00

You've spent a lot of active effort to initiate a change but if you don't leave something behind to reinforce the change, you'll see a back slide.

Such things could be role models, systems, policies, etc.

Another way to think of this is like having regression tests for organisational change. Other changes will inevitably occur as the organisation continues to evolve. What have you left behind to ensure your changes are not broken?

Management Improvement Blog Carnival #163

2012-04-10T08:00:00.000+10:00

Entry #163 of the Management Improvement Blog Carnival!

Perfect Pricing Part Deux - More money from fewer sales by Jarrod Drysdale - "If you begin a business by thinking about price, you have already lost. Customers do not buy because of price; they buy because of the value they receive. Without value, the equation is broken."
Enterprise OODA by Richard Veryard - "The limitations of the OODA model appear when there is too much emphasis on speed (especially response speed) and not enough appreciation of complexity."
Why Knowledge is Superstition by Dave Trott - "When you start believing, you stop thinking."
Yet More Musings on Muda by Jon Miller - "A good test of whether something is overproduction or overprocessing is to question the reason why the waste exists."
Are You Having Problems with Your Problem Solving? by Tracey Richardson - "As I teach problem-solving to companies, I find many common mistakes by people who are learning/using the process. It's easy when you are in the learning process to quickly develop bad habits, and important to recognize them and develop better ones. Here are questions to help you avoid some of the common mistakes people make."
Your stance towards learning by Ed Kraay - "We are natural explorers and scientists. So, what is keeping you from a positive attitude toward learning and exploration?"
Fall In Love With Your Business, Not Your Business Plan by Dharmesh Shah - "I don't think business plans are completely useless, just mostly so. And sometimes, they're even dangerous."

Defending against entrants as the established incumbent

2012-04-04T16:18:00.000+10:00

I've noticed that most material discussing an incumbent versus a plucky startup tends to take the perspective of the plucky startup.

So what if we took the side of the incumbent?

Let's imagine that we are the established market leader and we find ourselves under siege by a number of annoying little start-ups. How do we respond?

New Lanchester Strategy suggests that we need to pay attention to market share as there will be tipping points that cause noticeable changes in profitability. If we are the dominant market leader, we expect clever start-ups not to compete head-on but rather to attempt to re-segment the market, either using a niche that we aren't focusing on, or as a low-cost alternative.

The most dangerous approach for us is when they go low-cost because this is usually an indication of a disruptive innovation attempt. It's likely that we may initially see their product as under performing ("It doesn't even have Feature X") but they are probably targeting a less profitable segment that we are therefore more likely to retreat from and thus begin our market share slide.

To address this, we may consider setting up a separate unit that creates a low-cost variant of our product that might even cannibalise sales of our existing product. That's still better than ceding market share to someone else. The reason for separating the unit is that our current policies and incentives are based on different assumptions that will otherwise undermine the efforts.

Note that we should only bother doing this if we being thinking about retreating because "those customers aren't profitable anyway". That thinking would be a strong sign that we are being disrupted. If the startup is foolish enough to go after our profitable customers, then we can rely on our normal structures and systems to respond correctly.

The startups must focus on differentiating. We should focus on neutralisation, that is, just being good enough that any difference in performance is not worth our customers switching to them. We should also improve productivity to allow us to neutralise faster. This makes things fairly uncomfortable for a cash-strapped startup.

Neutralisation is about just enough and no more, as we want to preserve resources for our own differentiation innovation.

Designing a scalable IT work force

2012-04-02T19:16:00.003+10:00

The industry you work in is cyclical which means that you will have periods where you can afford to spend money enhancing systems and designing new products, and other periods where you need to focus on reducing costs and minimise activity.

A typical response to this type of situation might be to outsource or contract most, if not all, the IT work. Stop contracts during the weaker periods and simply re-hire people during the stronger periods.

Good times: outsource everything with a nominal internal management team
Bad times: stop work
Restoration of good times: ramp up again

Sound good?

Well, this is what is more likely to happen:

The managers lose familiarity with the IT systems (which includes strategic systems) so they are ineffective at managing any IT projects. All the domain expertise is with the outsourcing partner.
When you stop work to save costs, the partner re-assigns their experts in your domain or makes them redundant.
When you ramp up again, the domain expertise in your partner has degraded or is gone. No one knows how your IT systems (including strategic systems) work with all the related consequences (more mistakes, more costs, generally more problems)

So what to do instead?

Maintain a core team within your organisation and use partners only to scale up.

To maintain partner expertise, there are several options:

Use partners within the core team
Help the partner get work with other similar companies in the industry
Retain minimal project activity even during bad times but focus on capturing knowledge and cost optimisation

Is Agile too inefficient for start-ups?

2012-03-25T13:50:00.000+11:00

Is Agile too inefficient for cash-strapped start-ups?

To answer that, let's look at how an Agilist (with a strong Extreme Programming flavour) would think about preserving cash.

Fewer people means lower burn rate
Although the trendier terms are "T-shaped people" or "generalising specialists", the original discussions were more aggressive about having people who could do everything.

"A programmer should be able to find a bug, market an application, refactor a spike, lead a team, architect an application, hack a kernel, schedule a project, build a database, route a network, give a reference, implement UserStories, analyze UserStories, work in a team, work alone, use patterns, innovate, write documentation, have a RealLife, create a cool website, email efficiently, resign gracefully, AdmitIgnorance, and keep on learning. Specialization is for recruiters. "

Peter Merel, Specialization Is for Insects

I tend to use the following images when I do the introduction to Agile thing:

Fewer people means lower burn rate. Simple enough.

Do less

"Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters? … Listen, Test, Code, Refactor. That's all there is to software. Anyone who tells you different is selling something."

Kent Beck, from the original version of the Extreme Programming page on c2.com

Startups are too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters? Well, at the end of the day, a startup is a temporary institution whose purpose is to discover a repeatable process that:

Creates and defines something of value...
... that other people want or need...
... at a price they are willing to pay...
...in a way that satisfies the customer's needs and expectations...
...so that the business brings in enough profit to make it worthwhile for the owners to continue operation.

Anything else is wasting cash you don't have.

With acknowledgements to Josh Kaufmann.

Do less of what doesn't matter so you have cash to do more of what does matter. Simple enough.

Don't spend money on things you may not need

"Make it work, make it right, make it fast"

Kent Beck

The Agile approach to design has always been prioritised on whether the result worked, then whether the result was "right" (No duplication, expressive, minimal), and only then looking at performance considerations... and even then only to the extent that it was needed now.

You Ain't Gonna Need It was about creating a culture of simplicity (you must justify building more than you need to), which tends to preserve cash, versus a culture of anticipation (you must justify why you're not building something that handles every imaginable scenario), which tends to burn cash as if it magically falls from the heavens.

I'm not sure at what point building excessively scalable solutions to the wrong problem became associated with Agile engineering practice.

Don't spend money speculatively on things you may not need. Simple enough.

Release (aka go cash flow positive) early

The classic Agile model is to incrementally release subsets of an overall product / vision rather than all at once to dramatically reduce time-to-market and therefore time-to-profit. In essence, the strategy is to go cash flow positive early.

Release faster and make money faster. Simple enough.

You keep saying Agile but I don't think it means what you think it means...
Arguing that particular roles or rituals are required for Agile, which therefore makes Agile inefficient for startups, even though those roles or rituals don't align with what an Agile thought process would produce for a startup context, is reflective of both a watered down and cargo-cult understanding of Agile.

Questionable ways to preserve cash
But isn't Agile still bunk when it comes to start-ups?

After all, in start-ups in order to preserve cash you need to...

Work crazy hours... even though we know that it's less productive (aka produces less output given the same investment) within a relatively short period of time.

Just hack something rather than pair or test... since in the start-up world, typing has somehow become the constraint in programming, not thinking... and since start-ups are unlike every other software context where low internal quality slows things down much more quickly than most people realise.

Build it first and check with potential customers later... since in the start-up world, you can't afford the effort required to get concrete feedback on whether anyone wants what you're building.

What's interesting is that the same questionable ideas exist in the enterprise setting.

In the enterprise, it is reflective of lazy, undisciplined thinking and behaviour. In the enterprise, it is theatre to justify failure. And perhaps, in the enterprise, it is theatre to convince people with money to continue to fund a project.

But I'm sure that's not what is happening with start-ups.

But I really am cash-strapped...
But still, "cash-strapped" really means cash-strapped so even Agile tactics might not be enough. What else could you do?

Find alternative ways to get cash (aka "be scrappy"). This can be consulting or even selling cereal.

Sell the solution to the problem first, build something after (aka the Concierge MVP).

Find a way to have an interim offering that segments an existing market to pay for your new market, new product game changer OR when you have no money, stop trying to create an unproven market with unproven technology

Maturity level is not an Agile concept

2012-03-22T12:49:00.000+11:00

Via the Extreme Programming mailing list,

"Maturity level" is not an Agile concept. It is an SEI concept and the general usage of the term is not well aligned with what Agile and XP are about, in my opinion. (Ron Jeffries)

Do you really need to ask how long a project will take?

2012-03-19T20:37:00.000+11:00

As a program manager, project management office, or similar, is it actually necessary to ask how long a project will take?

If you have historical data on all past projects, and you determine what kind of project you're looking at, could you not forecast expected duration with expected range of variation without any additional estimation required?

If you can't have stable teams, why not stable study groups?

2012-03-17T11:43:00.000+11:00

In a consulting company, the needs for any particular engagement will vary. For example, one situation may require more development skills, another may require more skills related to business solution exploration and analysis, and yet another may require more testing related skills.

What this generally means is that consultants are hired out more like a collection of individuals than as a stable team. This creates problems since people are constantly re-forming teams. By the time you get comfortable with each other and start performing, it resets and starts all over again. Rotation and common approaches helps mitigate this phenomenon but it still isn't ideal.

To address the problem, we could adopt a model where teams were hired rather than individuals but this might be seen as a rather drastic change, especially by customers.

Instead of a stable team, why not have a stable study group? The study group would consist of people across multiple disciplines that meet regularly to cross-train and share experiences. If not entirely compensating for the overhead of repeated team formation, it should at least ensure exposure to cross-functional perspectives.

Now replace "consulting company" with "typical medium to large enterprise". Introducing stable teams into medium to large functionally-oriented enterprises is a non-trivial exercise. Would study groups be a useful transitionary alternative instead?

Charismatic leadership? Or deceptive leadership?

2012-03-17T10:46:00.000+11:00

Via Michael Balle at the Lean Edge,

"The test of any leader is not what he or she accomplishes. It is what happens when they leave the scene. It is the succession that is the test. If the enterprise collapses the moment these wonderful, charismatic leaders leave, that is not leadership. That is — very bluntly — deception." (Peter Drucker)

Emotionally inept parenting and leadership

2012-03-15T19:16:00.000+11:00

Emotional Intelligence describes the three most common emotionally inept parenting styles:

Ignoring feelings altogether
Being too laissez-faire
Being contemptuous, showing no respect for how the child feels

It occurs to me that these are also emotionally inept leadership styles.

If I were to improve the Agile Manifesto...

2012-03-11T15:15:00.000+11:00

Every so often, I get into a debate about why the Agile Manifesto should improve over time given that's what "We are uncovering better ways of developing software..." means.

I've done re-visitings before ("What is Agile?" -- June 2005, "Agility is not the point" -- May 2007) but I figure it's time to do another one.

So if I were to improve the Agile Manifesto...

I would add pictures and tell stories rather than just have text which are essentially bullet points.

I'd describe an ideal outcome or vision.

I'd use simpler language and structure.

I'd rank concepts in order of importance.

I'd emphasise more strongly the values of thinking for yourself, of continuous improvement, and of respecting people.

I'd have clear, ideally visual, examples of what IS and IS NOT Agile.

4 ways to be dysfunctional about diversity

2012-02-22T20:45:00.000+11:00

Convenient diversity - Diversity is seen only as a social good with no performance benefit which means it's dropped when financial pressures increase
Shallow diversity - Diversity is all about appearances which means you end up with a lot of different looking people who all think the same way
Fake diversity - You have people with a lot of diverse perspectives but really only one perspective is ever acknowledged in interactions
Alienating diversity - There is a lot of diversity but no common identity or values which means that many people don't have any sense of relatedness to others in the organisation

What would the ideal Kanban game look like?

2012-02-08T15:56:00.002+11:00

The GetKanban game is quite a popular way to introduce Kanban. However, I've found it takes quite a while to run (even the short version) and is possibly more complicated than necessary for an introduction.

So let's jump to the end... let's imagine that we've already created the ideal Kanban game. What would it look like?

The game requires minimal setup cost
The game can be completed within 1 hour
The experience of playing the game is enough for most teams to start using Kanban
There are more advanced versions of the game for when teams / organisations mature

Next up: What are the minimal things a Kanban game should teach?

Solution-focused goal-driven retrospectives

2012-02-08T14:51:00.000+11:00

When people think about what's not working, they tend to be in a more negative mood, which then tends to lead to a more narrow perspective... and frankly tends to just be depressing.

I first noticed this phenomenon when doing current state value stream analysis and I suspect the same effect is occurring to a lesser extent with the start of traditional retrospectives.

I've begun experimenting with a different style of retrospective inspired by solution-focus and previous experiments with goal-driven retrospectives:

Identify the Ideal State / True North / Future Perfect using the Miracle Question. "Imagine that a miracle occurred and all our problems have been solved. How could you tell? What would be different?" The idea here is that we want to make sure everyone is on the same page around where we want to go.

Each person works individually using sticky notes
Share and group results into Goals
Discuss and resolve differences in vision

Identify where we are now using the Scaling Question. "If 10 is the ideal and 0 is where nothing is working, where are we now?" The idea here is to remind people that we are not at 0.
Identify what we are already doing that works. "What are we already doing that works? That is, why are we [for example] 5 rather than 0?" The idea here is to identify existing resources, strengths, practices that we can leverage for improvement.

Each person works individually using sticky notes
Share and group results into Resources

Identify how to move toward the ideal. "Using the resources we have, what can we do to move one step closer to 10?" The idea here is to identify the next incremental step to move toward the ideal.

Identify Actions for each of the Goals.

----

So far, my first attempt at this style worked out quite well and maintained quite a positive mood throughout.

If you try this style of retrospective, I'd be interested in hearing about your experiences.

The six parts of every long-term business

2012-02-06T20:13:00.000+11:00

One of my favourite concepts from The Personal MBA is The Five Parts of Every Business:

Value Creation - discover what people need or want and create it
Marketing - attract attention and build demand for what you've created
Sales - turn prospective customers into paying customers
Value Delivery - give customers what you've promised and ensure that they're satisfied
Finance - bring in enough money to keep going and make your effort worthwhile

It occurred to me that for any business that survives long-term has to have another part:

Human Development - develop people to be better at the above

Misconceptions about daily stand-up meetings

2012-02-06T09:51:00.000+11:00

There's an article at the Wall Street Journal about daily stand-up meetings. It's mostly a collection of sound bites, and not really that informative in terms of why things are done or subtleties, but I'd attribute that more to WSJ editorial constraints and time constraints than the personal intent of the writer.

There's also an associated video.

What's great about the article comments are that they provide examples of numerous misconceptions about stand-ups that I've either forgotten over the last 10+ years or I'd never have thought anyone would actually have.

To help with education, I thought I'd take the opportunity to capture the misconception and then explain why it is incorrect:

Stand-up meetings are a fad. My first encounter with daily stand-ups was in 1998 when I was doing an internship with a Canadian defense contractor, before Agile (2001), and even before I encountered Extreme Programming in 1999. The article mentions standing meetings used by military leaders during WW1 but the current Agile-style format probably started with the development of Scrum, so let's say mid-to-late 90s.

That's 10 to 15 years.

It's a stretch to describe that as fleeting behaviour or a fad. It's more accurate to describe it as a trend which is entering the mainstream.

Stand-up meetings impose too much control. This probably refers to things like mandatory attendance, punishments for being late, having to stand up, the particular meeting format, etc. Here I would say that some people do actually impose too much control on their stand-up meetings. Specifically, I consider the use of punishments to generally reflect a poor understanding of human motivation. However, the key to avoiding imposing too much control is not about what particular stand-up mechanism is used but more about how it is introduced, essentially whether it is introduced in an autonomy-supportive way:

taking everyone's perspective into account (for example, checking the team's opinion on daily stand-ups)
offering (meaningful) choice between alternatives (for example, using an egg timer rather than standing up to keep the meeting short)
providing relevant information that people may not have had access to (for example, background info about how other people do stand-ups)
giving the rationale for suggested mechanisms (for example, we use a standard set of questions because it's easier to remember considering certain topics)
acknowledging everyone's feelings (for example, initially some people are uncomfortable talking to the team)
minimising the use of controlling language and attitudes (for example, modifications to the stand-up format are proposed and accepted by the whole team rather than just by the team leader)

Stand-up meetings are like the assembly line. Daily stand-ups are actually done at good factories. The idea is quite similar, review what needs to done for the day and problems to watch out for. But where does the assembly line comparison come in? Think about it. 15 minute meeting at the start of the day implies assembly line? Seems to be a rather large logical leap.

I suppose there may be some mental image of clocking-in for the day but this is really the general idea of checking in with the team. Is the idea really that talking about what you've done, talking about what you plan to do for the day... Is all that too much like an assembly line? Is it because assembly line workers typically stand therefore standing up in a meeting is too much like an assembly line?

As an aside, there are health benefits to standing at work.

Stand-up meetings are too short for thoughtful decision-making. Agile-style 10-15 minute stand-ups are not used for decision-making. The research by Bluedorn, Turban, Love suggests that standing decision-making meetings should be shorter (sit-down meetings were 34% longer) with no loss in decision-making quality. Note that it's 34% longer with sit-downs. There's no suggestion that decision-making standups will be only 10-15 minutes nor would be just standing in a circle. I'd expect decision-making to be more active than that.

Stand-up meetings are disruptive to individual productivity. Any scheduled event has the potential to disrupt an individual's flow, for example, a preset time for lunch. The issue here is that we should be more concerned about team / organisational productivity than any one individual. That is, coordinating the efforts is more important than having every individual "productive" in an uncoordinated fashion. Having said that, we can choose times that are less likely to be disruptive to most people. For example, if everyone arrives to work at around the same time, we can schedule the stand-up to be shortly after that giving time for people to settle, read e-mail, etc.

Stand-up meetings (and Agile) lead to low quality software development. This is more about Agile than stand-ups. I'd expect stand-ups to have minimal, if any impact on software quality. As for whether Agile leads to low quality, the short answer is "No, it doesn't". But this is based mainly on my own direct experiences which may not be convincing.

So here's something by Capers Jones and Oliver Bonsignour (The Economics of Software Quality):

The waterfall method has been troublesome for many years and correlates with high rates of creeping requirements and low levels of defect removal efficiency. Better methods include several flavors of Agile, the Rational Unified Process (RUP), and the Team Software Process (TSP).

Stand-up meetings are all about standing up. It's understandable that one might think that because it's called a stand-up meeting, that it's all about standing up, but it's not. Standing up is simply a useful tactic but not the only one available to achieve the desired outcomes.

Stand-up meetings are common sense. This is an example of the common sense fallacy. If stand-up meetings are common sense, then why are they not common? Besides, we should be more concerned about what works, not what is common.

Stand-up meeting tactics are unnecessary if everyone would just have basic courtesy and common sense. This is an example of fundamental attribution error. The only reason why people don't know what's going on is due to their defective personalities... despite not having any structural, practical mechanisms for people to learn about what's going on.

The Creating and Sustaining Positive Organizations blog has a nice post of the lazy use of personality as a scapegoat.

Relatedness and Purpose

2012-02-04T05:37:00.000+11:00

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?

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.