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

Highlights from Lean Kanban North America 2013: Day 2

2013-05-22T08:29:00.001+10:00

Highlights from Day 2 of my trip to Lean Kanban North America in Chicago 2013

Day 2: Tuesday, 30 April

Designing Adaptive, Innovative and Engaging Organisations Using Sense and Respond 3.0 Adaptive Lean Principles: Stephen Parry

Service climate is the combined perception of customers, employees, managers, and leaders

I'm wondering where organisations like Toyota, Semco, etc. fit on the Climetrics organisational landscapes.

Prioritising Safety: An Unexpected Pathway to Excellence: Joshua Kereivsky

Focus on 1 value, not 2, 3, 4, or 5. Joshua suggests that this 1 value might be Technical Safety, similar to how Alcoa chose Safety.

Focusing on safety creates a habit of mindfulness which generates multiple other benefits beyond saftey.

Interesting idea about explicitly showing in your editor how code is connected to production exceptions and test failure frequency to highlight which code is not safe.

Referenced Michael Feather's thoughts about churn vs complexity.

The Lean Mindset: The Far Side of Paradox: Mary Poppendieck

"It's much harder to be experts together than to be an expert alone."

"Whether-Or-Not" or "Either-or" are examples of teenage decision making

Large companies struggle with aspirational goals; startups struggle with safety-focused goals.

Approach Avoidance: Heuristics for Modeling Systems with Kanban: Jabe Bloom

Work != Working != Worker

"Social capital explains how people do better because they are somehow better connected with other people."

Too much communication in an organisation means that you end up in stasis

"People strongly connected are likely to provide redundant information." Ronald Burt

This talk reminded me of Anathem and Bowling Alone.

Limited WIP Society Gathering

Talked to Janice Linden-Reed and Juan Barberis essentially about the items I posted here.

Highlights from Lean Kanban North America 2013: Day 1

2013-05-21T19:18:00.001+10:00

Highlights from Day 1 of my trip to Lean Kanban North America in Chicago 2013

Day 1: Monday, 29 April

Lean Coffee

"Respect for People" means "Respect human nature" as in "respect the laws of physics".

Everything You Know is Wrong: Bob Lewis

"We should call ourselves process automation [rather than IT]."

"Never name the project after the software; name them after the business outcome."

"IT spending doesn't matter; total cost of operations matter."

"The right level of IT spending is based on the amount of change the organisation can absorb."

"Before you can be strategic, you first have to be competent."

One thing I disagreed with in Bob Lewis' talk was the idea that effective IT Operations should be invisible. I would say that effective IT Operations should be visible by enabling improved capability.

Innovation Games: Software Powered Innovation Through Collaborative Play: Luke Hohmann

"If we're so focused on value, where are our collaborating customers?"

Scaling Agile at Spotify: Anders Ivarsson and Joakim Sunden

Spotify moved away from synchronising Sprints across teams. I interpreted this as they removed the need to synchronise releases across teams.

Ignite Talks

Rodrigo Yoshima suggested that instead of technical debt, we should focus on visualising failure demand which would then encourage improvement.

I presented My Customers Won't Accept Smaller Releases.

How Lean Health Care Can Save Your Life (While Also Saving You Money): Mark Graban

Commenting on the practice of getting doctors to wear buttons that say "Ask me if I've washed my hands": "Hospital CEOs don't walk around wearing buttons saying "Ask me why we're understaffed""

"Lean = no tradeoffs" I would say that the trade-off is changing the way you work.

The concept behind the andon cord is that you get help when you ask for it.

If your managers say things like "My people are very careful", this is an indication that you have a systemic quality problem.

"The ultimate arrogance is to change the way people work without changing the way we manage them." Kim Barnas of ThedaCare

Mark mentioned problems with people attempting to implement Lean without understanding what they are doing.

I still find it odd how many people don't understand what 5S is about.

5S in software development is closer to why we have standards for coding styles to make mistakes more obvious. If you're not making a relevant problem visible, you're not doing 5S correctly.

The Spice Must Flow...: Ramon Tramontini and Marcelo Walter

I actually ended up in this session accidentally as I was intending to go to the Kanban Patterns session. It turns out it was a fortunate accident as this was actually quite interesting and entertaining.

I didn't take much notes though and the best thing would be to link the slides... if they are eventually posted...

Kanban, Leadership, and Alignment at Jimdo: Fridjof Detzner and Dr. Arne Roock

Jimdo spends a lot of effort on culture in the sense of creating opportunities to increase a sense of relatedness. I see culture as not just things that encourage relatedness but also the things that influence behaviour and decision-making.

Teamverlötung means "team hacking" which seems to be like a 45-60 minute operations review.

In order to determine goals, ask the Spice Girls question: "Tell me what you want, what you really, really want"

Jimdo is experimenting with an open prioritisation session which I think is working because it allows transparency of rationale and is therefore autonomy-supportive.

Jimdo founders' blog here.

Open Space

Spent the entire time talking about doctrine with Simon Marcus, Richard Hensley, Juan Barberis, and a few others whom unfortunately I can't remember.

What I think works for running a user group

2013-05-13T20:56:00.000+10:00

A few thoughts on what I think works for running a user group:

Circa 2013, if you want to organise a user group, just use Meetup:

It provides cross marketing to similar groups for you;
It makes it easier to coordinate with other groups by showing events occurring on any particular day;
It pretty much takes care of everything except for discussions / mailing list which are frankly woeful

In general, predictability helps. The more regular you make it, the easier it is for people to plan to attend.

Run events on a regular cadence. So, for example, an event roughly the same time every month. I tend not to be too strict about this but I know other groups will pre-schedule the events in advance. I'll usually schedule at most a month in advance.

Try to use a regular location. This can sometimes be difficult, especially if you vary the types of events, but it makes it easier for regular attendees to know where to go.

Avoid using boring offices, pubs and similar are more socially conducive... however, if you want to run activities, offices tend to be better.

Activities are good, lectures are boring. This is more my preference for groups I facilitate.

Provide food... that's not pizza. Again, this is more my own preference. Pizza is a very cost effective meal option but it gets boring when every user group serves pizza. I prefer to mix it up with alternatives. I use Menulog and I assume there are similar services outside of Australia.

Beginner sessions will always attract more people (there are always more novices than experts) but be careful...

Beginners show up to interact with more experienced practitioners. Experienced practitioners will tend to leave if all you have are boring introductory presentations.

Perhaps an obvious point... famous visitors tend to attract a lot more people... so pay attention to who's visiting and just ask them if they'd like to drop by.

Thoughts from Lean Startup Machine Sydney April 2013

2013-05-11T16:11:00.000+10:00

I participated in Lean Startup Machine in Sydney in April 2013. Here are a few things I noticed and thoughts I had...

Three customers

Sebastien Eckersley Maslin, CEO of BlueChilli, talked about his 3 customers concept:

Target Customer: Who has the direct problem you're solving?
Scale Customer: Who deals with your Target Customers in bulk?
Strategic Customer: Who can derive more value from your assets than you can?

This was from the perspective of exit strategy which I generally don't care for. However, this concept is still interesting if you see this as a way to understand the bigger picture of what happens when a product / service is introduced in a market place.

What's your larger mission?

Jodie Fox, co-founder of Shoes of Prey, pointed out the importance of having a larger mission, even a potentially impossible mission, but one that provides a consistent direction. For example, for Shoes of Prey this is "Every woman deserves a perfect shoe". This was in response to a few teams that had "pivoted" to perhaps not as interesting concepts.

This reminded me of The Toyota Way and the importance of having a Long-Term Philosophy.

Teach a way of thinking or find another successful startup?

Is the purpose of events like Lean Startup Machine to teach a way of thinking? Or is it to find another successful startup? I believe it really should be the former.

Structuring as a competition does not reflect that purpose.

Instead of a competition, the event would focus on teaching concepts, basic assumptions, principles, and tactics like Magic Tests, Concierge MVPs, selling approaches, etc.

Teams would be encouraged to identify problems that could be explored within the context of the event (i.e., on a weekend) AND/OR the event would be scheduled to allow different types of problems to be relevant.

Teams would be smaller so that participants would actually have to attempt all the skills themselves rather than rely on another team member. Perhaps they would be 1-person teams to ensure that everyone has a direct understanding of what skills you actually need in the real situation, and therefore who you'd want on your team. People would be exposed explicitly to what their strengths and weaknesses are.

Validation Board or Business Model Canvas?

Lean Startup Machine uses a Validation Board to structure our hypotheses and tests. The focus is on testing problem-solution fit. I like the focus of the board, but I miss the bigger picture aspects of the overall business model that you can see with the Business Model Canvas or even the Lean Canvas. I think I'd rather use either of those to capture the overall business hypothesis and switch to a Validation Board like structure after the riskiest assumption was identified.

What do you mean when you say "Agile"?

2013-03-27T19:52:00.000+11:00

UPDATE: Added "Agile" as a set of target outcomes. Suggested by Dale Emery.

"I'm glad we all agree what 'Agile' means"

The word “Agile” can trick us into believing that we are talking about the same thing when we are actually not.

Here are a few interpretations that I’ve encountered:

“Agile” as a synonym for good. Instead of “that would be better”, you’d say “that would be more Agile”. Please don’t do this. This dilutes what is specifically distinct about Agile and discourages thinking. It also leads to tendencies to believe that everything that is not “Agile” (aka good) must therefore be bad.

“Agile” as a particular workflow. Specifically, backlog -> iteration planning -> in progress -> showcase. In practice there is more variation such as pipelining / “scouting ahead”, more explicit management of specialisation, iteration-less approaches for continuous work situations, etc.

I’ll suggest the essence of an Agile workflow has two basic aspects:

Iterative, meaning revisiting and improving based on learning
Incremental, meaning large work is broken up into smaller pieces that are delivered independently

“Agile” as a set of practices. Pair programming, visual workspaces, retrospectives, co-location, involving customers, stand-up meetings, coding standards, showcases, continuous integration, collective code ownership, release and iteration planning, test-driven development, refactoring, evolutionary design, spike solutions, etc. This has the advantage of being concrete… and the disadvantage of implying that every practice is applicable to every context.

“Agile” as an ideal. Any feature, in any order, one at a time. This requires addressing both fundamental technical and policy constraints and may be incredibly difficult … but provides a clear direction for improvement.

"Agile" as a set of target outcomes. This is similar to "Agile" as an ideal but using achievable, observable outcomes. As an example, Elisabeth Hendrickson proposes "Deliver a continuous stream of potentially shippable product increments, at a sustainable pace, while adapting to the changing needs and priorities of their organization".

The potential problem with seeing "Agile" as an ideal or a set of target outcomes is that it does not provide much guidance on approach or method. That is, the problem of "I'm Agile therefore I should see these outcomes... even though I'm not changing any existing behaviour".

Currently, I prefer the following interpretation:

“Agile” as doctrine. By doctrine, I mean a set of fundamental principles that guide actions in support of objectives. These principles are authoritative but require judgment in application.

My interpretation of Agile as doctrine is:

Reduce the distance between problems and problem-solvers
Validate every step
Take smaller steps
Clean up as you go

What is Agile doctrine?

2013-03-03T11:08:00.001+11:00

Strategy and plans are not enough

Mark Bonchek and Chris Fussell write about why strategy and plans are not enough:

Strategy doesn't give employees enough guidance to know how to take action, and plans are too rigid to adapt to changing circumstances. In rapidly changing environments, you need fog lights to get closer to the ground.

...where "fog lights" is doctrine.

Doctrine creates the common framework of understanding inside of which individuals can make rapid decisions that are right for their circumstances... If strategy defines objectives, and plans prescribe behavior, then doctrine guides decisions.

In other words, doctrine allows us to safely decentralise decision-making by establishing consistent decision logic.

NATO defines doctrine as...

Fundamental principles by which the military forces guide their actions in support of objectives. It is authoritative but requires judgement in application

So I wonder...

What might Agile doctrine be?

What are the fundamental principles by which Agile practitioners should guide their actions in support of objectives, that are authoritative but require judgement in application?

Is it just the Agile Manifesto?

The most obvious candidate for Agile doctrine is the Agile Manifesto.

I have problems with this for the following reasons:

It was not really the intention of the Agile Manifesto to act as doctrine... despite that many new Agilists treat it as such
The Agile Manifesto was the result of compromise, the lowest common denominator set of values and principles that a group of people could agree upon.
The Agile Manifesto hasn't been updated since 2001 (i.e., as of this writing 12 years). To borrow a phrase from John Boyd: Don't treat the Agile Manifesto as doctrine because an awful lot has happened in 12 years.
12 principles is a lot to keep in working memory... and I'd prefer a doctrine that most people will remember without having to look it up... at least for the base version.

What about Extreme Programming?

Instead, I'd prefer to look at a concrete Agile method. Because of my own history, my preference would be Extreme Programming:

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

Listen, Test, Code, Refactor seems too programming-centric to be suitable for general Agile doctrine so let's pull it up a bit...

A proposed Agile doctrine

1. Reduce the distance between problems and problem-solvers

I first heard a version of this from John Sullivan, but he described it as reducing the distance between customers and developers.

There are two types of distance that I'm referring to here:

Physical distance
Conceptual distance, that is, how conceptually accessible the problem is to the problem-solvers. This leads to things like making the problems visible, better techniques to model the problem, etc.

2. Validate every step

What is the desired outcome?
Why are you taking this step? Does it move you toward the desired outcome?
How would you know the step was done and successful?

In other words, in the words of every effective Agile practitioner:

Do you have a test for that?

3. Take smaller steps

…many of the most important improvements in product development, such as concurrent engineering, rapid prototyping, and agile software methods, are recognizable as batch size reductions.

Don Reinertsen in The Principles of Product Development Flow

Smaller work packages, smaller releases, etc. all follow from this.

Because avoiding transaction cost is typically the main reason why larger steps are taken, reducing transaction costs is a big part of this as well.

4. Clean up as you go

Leave this world a little better than you found it.

Robert Baden-Powell

"Clean up as you go" is more than just awareness of and dealing with technical debt, but also generally leaving things a little bit better than you found it to incrementally address entropy. Technical systems degrade over time without maintenance but so do human systems.

So what?

Is doctrine a useful concept?

Is this the right doctrine?

Compared to other sets of principles, will this doctrine be easier to establish, easier to maintain, and be more effective in supporting appropriate decision making that is recognisably Agile?

What does "industry standard" actually mean?

2013-01-27T21:40:00.001+11:00

Many times I encounter decisions that imply people have what I'll call the naive understanding of "industry standard":

"industry standard" means that this is best practice across the industry and doing this will ensure that we have the best chance of achieving our outcomes.

"industry standard" doesn't even mean that it will work. Many industry standards are decided by a committee, what is known as a de jure standard. Actual practice in the field tends to at most influence the standard; it's not usually a straight copy. In other words, until it's been around for a while, a standard approach is not necessarily a proven approach.

"industry standard" doesn't mean all the significant players in the industry were involved. For various reasons (political, technical disagreement, whatever), not everyone will want to play in standardisation efforts. It is entirely possibly that a significant player will ignore or compete with the standard, which means it's quite possible that the standard ends up going nowhere.

The "industry standard" is almost always not the best technical solution... it's the one that could be agreed on... so unless the standard is about some kind of interoperability that you actually have to care about, don't bother.

What are we actually trying to do?

In priority order, we're trying to design and build something that:

works
acknowledges the likely direction of change in the industry to avoid unnecessary change later

An "industry standard" presumably gives us guidance on industry direction. However, until we are confident that a design actually works, I wouldn't worry too much about industry direction. It's a reasonable assumption that things that don't work are highly unlikely to be the eventual direction of an industry.

Flip the Agile classroom

2013-01-27T14:27:00.001+11:00

You have a large organisation with a few thousand people and you want to train them on basic Agile concepts.

What are your options?

Typically this means a lot of instructor-led training. Let's call that $1600 / person for 2 days.

And what do you typically get? From experience, I'll describe it as pretty hit and miss.

Here's an alternative.

Well-designed online training and assessment. Let's call that at most $50 - $100 / person and this is not considering any enterprise licensing.

Tack on facilitator-led practices to validate understanding of concepts. That still might be $1600 / person but it's more likely to produce a useful result.

So why hasn't anyone does this yet?

Are you sure we have conflicting goals?

2013-01-26T16:11:00.000+11:00

What initially looks like conflicting goals might not be...

What is actually your position? Maybe I just don't understand.

What specifically do I disagree with? Is it every aspect of your position? Or only really a specific subset? Let's not worry about what we are already okay with and focus on what we need to resolve. Maybe the aspects of our positions that conflict are not actually that important and we can just adjust them.

Why do you have this position? What are your interests? What outcomes does your position provide you that you want? Are there alternative ways to satisfy both your and my interests? Maybe we just need to be more creative with our solutions.

The most popular topic is not necessarily the most important topic

2013-01-26T15:27:00.003+11:00

The most common approach for prioritising topics in retrospectives is some form of popular vote with an underlying, implicit assumption that what is most popular is what should be discussed.

Is this assumption trustworthy?

Would I not vote for something because I find the topic uninteresting?
Would I not vote for something because I find the topic uncomfortable?
What I be more likely to vote for something because it had happened to me recently?

The question should not be "What do you want to discuss?" but rather "What are the most important things to discuss given our agreed target outcomes?"

This means being clear on what those target outcomes are. See Goal Driven Retrospectives.

This also means that we need collect data before the retrospectives, not just during.

I've started to suggest that teams have check sheets to record issues with a running tally each time the issue occurs. By the time the retrospective occurs, you can look at what has occurred the most often versus what has just happened to have occurred right before the retrospective.

We agree... but...

2013-01-13T14:11:00.001+11:00

We agree... but only because we don't understand each other.

We "agree" but only because we don't understand each other. By making our understanding explicit, we can highlight our disagreements and come to a resolution and real agreement.

This type of problem doesn't just exist with product development. The same issue exists with organisational policies. With implicit policies, we "agree" but it may be only because we don't understand each other. Making policies explicit means that we can detect disagreement, come to a resolution, and real agreement.

We "agree"... but actually I don't.

With policies, we also have another phenomena. "I agree" (but actually I don't and it's too much hassle to change policies so I'll engage in work arounds).

We agree on who makes the decision... but not on the decision logic

Most organisations act as if the most important agreement on decision making is about who makes the decision. I see that as agreeing on the boundaries of a "decision box".

We agree on the decision logic... but not on who makes the decision

In reality, the more important agreement is about the logic around how to make the decision. In other words, agreeing on how to fill the "decision box". If we agree on how decisions should be made, it becomes much less important on who makes them. This approach seems more sensible to me than suggesting that if we agree on who gets to make decisions, we don't have to agree on how decisions are made.

Instead of As A - I Want - So That ...

2013-01-07T20:37:00.000+11:00

Instead of "As a [role], I want [requirement] so that [reason]", I'd rather see an icon or picture representing the relevant user persona, a simple title or sketch, and verification and validation criteria on the back of the card.

I'd also like to see an estimation of Cost of Delay and Size (assuming that the stories are not all similarly sized)

Problems I have with SAF-style WSJF

2012-12-26T13:27:00.001+11:00

I suspect that there are now a lot more people in the Agile community who are aware of Weighted Shortest Job First (WSJF) (originally from Don Reinertsen's The Principles of Product Development Flow) because of Dean Leffingwell's Agile Software Requirements and the Scaled Agile Framework (SAF).

The Reinertsen version:

WSJF = Cost of Delay (CoD) / Duration.

The SAF version:

WSJF = (User/Business Value + Time Value + Risk Reduction (RR) / Opportunity Enablement (OE) Value) / Job Size.

I think it's a good thing that SAF has meant WSJF is more widely known, specifically the following concepts:

Consideration of duration (proxied by job size) when scheduling work
Consideration of cost of delay

However, I find some aspects of the SAF version of WSJF problematic...

The purpose of quantifying Cost of Delay is to create a decision rule to support trade-off decisions between "improvements" and cycle time.

"We simply have no business trading money for cycle time if we do not know the economic value of cycle time."

Don Reinertsen

For example, let's say you are thinking of adding a new feature to the scope of the project which is estimated to be worth an additional $100k but will delay release by 1 month. If you already know that the cost of delay was $200k / month, the decision is pretty straight forward.

Reinertsen suggests that team member intuition of cost of delay will typically vary by 50 to 1 so having an explicit agreed value (e.g., $200k / month) has a significant impact on how decisions are made.

In SAF-style WSJF, "cost of delay" is the sum of a set of relative size estimates. As an example, if User/Business Value was 1, Time Value was 3, and Risk Reduction / Opportunity Enablement was 5, the SAF "cost of delay" is 9. Again, you are thinking of adding a new feature worth $100k but delays the project by 1 month. Your cost of delay is 9... Is the decision straight forward?

SAF-style Cost of Delay is no longer useful as a decision rule for trade-off decisions.

Cost of Delay already accounts for overall value.

"The total profit of a high ROI project may be less sensitive to a schedule delay than that of a low ROI."

Don Reinertsen

Project A provides $1M of value and its cost of delay is $100k / month. Project B provides $500k of value and its cost of delay is $250k / month. If we want to maximise life-cycle profits, the logical choice is to do Project B first and Project A after. That Project A is worth twice that of Project B is actually irrelevant.

The only thing we need to know is cost of delay.

In SAF-style WSJF, "cost of delay" is the sum of three values:

User / Business Value: "relative value in the eyes of the customer/business"
Time Value: "how the user value decays (or CoD will increase) over time"
Risk Reduction / Opportunity Enablement Value: an aggregated proxy for eliminating risks early, value of information, and unlocking new business opportunities

Project A provides $750k of user / business value, $250k of risk reduction / opportunity enablement value, and its cost of delay is $100k / month. Project B provides $250k of user / business value, $250k of risk reduction / opportunity enablement value, and its cost of delay is $250k / month. If we want to maximise life-cycle profits, the logical choice is to do Project B first and Project A after.

Just as before, the only thing we need to know is cost of delay.

So what is the point of adding User / Business Value and Risk Reduction / Opportunity Enablement Value to the equation?

SAF-style WSJF misses the fundamental point that we do not need to know overall project value for prioritisation if we know cost of delay.

WSJF done with a relative scale still produces a reasonable result.

SAF-style WSJF uses a relative scale for all parameters which is probably a reasonable approximation, especially as some organisations actually don't have business cases, or at least none that are any good AND/OR they are not willing to do economic modelling for whatever reason. Even the use of a relative scale is likely to produce a better result.

But, instead of scaling and summing 3 parameters, it seems a lot simpler, and closer to the original concept to just relatively scale the Cost of Delay.

For example:

Absolute numbers: $100k / month

Relative scale: 3

Job duration: 5 months

Job size relative scale: 5

WSJF score = 100k / 5 = 20k

Relative scale WSJF = 3 / 5 = 0.6

WSJF can be done with relative scaling but there's no need to add additional parameters as in SAF-style WSJF.

For prioritising similar sized Stories, use High Delay Cost First (HDCF).

"When job durations are homogenous, do the high cost-of-delay job first."

Don Reinertsen

For prioritising Stories, SAF suggests a simpler formula since Time Value and Job Size are equal:

Priority = User / Business Value + Risk Reduction / Opportunity Enablement Value

This directly contradicts the fundamental insight that prioritisation should be based on how value degrades.

For example (using absolute numbers to make the point more clear),

Story A: value is $10k, cost of delay is $1k / week
Story B: value is $5k, cost of delay is $2.5k / week

With the SAF formula, we will do Story A first... while if we understand Cost of Delay, we will do Story B first.

Instead, in situations where job durations are homogenous (i.e., Stories of approximately the same size), Reinertsen suggests High Delay Cost First which simply means:

Priority = Cost of Delay

SAF-style story-level prioritisation contradicts prioritising by cost of delay.

What I'd like to see in SAF WSJF

When it comes down to it, there are two basic adjustments I'd like to see in SAF WSJF:

Use economic modelling at the product / service / capability level to provide decision logic that can support distributed decision making
Simplify the parameters to only estimate cost of delay, not the current sum of user / business, time, risk reduction / opportunity enablement

Make the process easier without taking over the process

2012-12-02T13:35:00.001+11:00

Some random "Agile coach" shows up and starts talking about abstract concepts and "culture". A lot of hand-waving but no specifics because s/he says you're supposed to "self-organise". So what are you thinking? This coach is obviously just another clueless waste of money who's apparently good at suckering managers.

Alternatively, some random "Agile coach" shows up and starts changing everything. S/he declares that everything you've done previously is wrong (and stupid) and here are a new set of things that you should do and think instead. If you ask for rationale, s/he tells you that you should just try it first because you have to learn by doing. So what are you thinking? This coach is obviously just another clueless waste of money who's apparently good at suckering managers.

If the coach is too abstract, s/he comes off as useless and incompetent; if the coach is too prescriptive, s/he undermines autonomy.

Instead, coaches are the most valuable if they make the process easier without taking over the process.

To do this, I can think of a few options:

Propose a straw man target state that the team modifies to their context. A good straw man demonstrates the coach's insight into the situation. Getting the team to modify allows them to take ownership. The coach is not useless, the team maintains autonomy.
Ask insightful questions. Asking good questions demonstrates the coach's insight into the situation. That the team still has to come up with the answers means the eventual insight is still theirs. The coach is not useless, the team maintains autonomy.
Do both.

Next questions:

What's a good straw man? How would you determine a good straw man?
What are insightful questions? How would you determine insightful questions?

A summary of Protocol Analysis: Verbal Reports as Data

2012-10-21T19:21:00.000+11:00

A while ago I read Protocol Analysis which is a summary of the research about using verbal reports as data. This should be relevant for running user tests and in general understanding what happens when people try to tell you what they're thinking.

Giving verbal reports affects the subject's cognitive processes, that is, talking about something can change how we think about it.

In order to give a verbal report, the subject must:

Understand what you are asking
Turn this understanding into retrieval cues
Use those retrieval cues to select the relevant information from long-term memory
Put the retrieved information into a sequential form, so that s/he can...
Generate a coherent series of verbalisations

When thinking aloud, ask people to only verbalise the information they attend to, not describe or explain what they are doing. For example, "4 times 6", "24", etc. not "I am trying to multiply 24 by 36".

If you also ask people to explain what they are doing, you will change the sequence of their thoughts.

There are several design tactics to improve the quality of verbal reports:

Make it clear that social interaction is not intended by sitting behind the subject or otherwise being invisible
Explicitly warn the subject against explanation and description
Provide practise problems to practise concurrent verbalisation and just verbalising without explaining or describing
Minimise social interaction. Say "Keep talking", not "Tell me what you are thinking".
Always tell the subject to focus on completing the task with thinking aloud as a secondary instruction. Only if the subject is completely focused on the task can we expect the verbalisation to reflect the same thought process as the silent condition.

Concurrent verbalisation, unlike normal social interaction, often lacks coherence and is disjointed without explicit relationships. You have to resist the urge to therefore ask for explanation and description. Instead, we need to work out how to infer underlying cognitive processes by encoding and analysing the verbal sequences.

For tasks of very short duration (that is, less than a few seconds) or with severe real-time constraints (e.g., juggling) retrospective verbal reports may be preferred. Whenever appropriate, collect both concurrent and retrospective reports.

There are several design tactics to improve the quality of retrospective verbal reports:

Start with "I first thought of..." This helps subjects focus on the task of recalling distinct thought episodes rather than elaborating, rationalising, and justifying.
Do warm-up tasks by retrospectively reporting on relatively fast processes (less than 2 seconds) (e.g., single and two digit addition, judge whether two letters are in alphabetical order)
Instruct and remind subjects to remain focused on the task and retrieve info for the retrospective report only after completion.

Teaching aloud, for example, being asked to instruct an unseen partner, or being asked to explain reasoning, tends to improve performance. So even if teaching aloud and describing reasoning is not as useful for user testing, it's actually quite useful for instruction and improving performance. See Think Like an Expert.

How I'd approach Startup Weekend if I did it again

2012-08-25T16:27:00.001+10:00

I've participated in a few startup events: Sydney Startup Weekend, Social Startup 48, and Melbourne Startup Weekend. Each time, I've changed how I've approached it to try to improve my experience. At the moment, this is how I'd approach it if I were to do it again:

Pitch: If you're going to attend a startup event, you might as well be a founder. The events are way more interesting if you're working on your own ideas and own initiative. Having said this, you may decide to join someone else's more interesting idea, especially if you find yourself on your own

Go to where the customers are: Get out of the building and talk to potential customers. Everyone on the team should do this and at a minimum the founders should.

Model the customer more explicitly: Use empathy maps, user personae, customer journey maps, etc. to guide your understanding of your customers.

Build prototypes earlier: I've tended to have a reluctance to build much until we've validated with interviews and things like magic tests but now I'm thinking using multiple prototypes of many forms to learn both what customers want as well as just to allow more technical engagement.

Collective learning over throughput: Involve everyone in the learning process so we all learn about what we should build together. This might end up being slower but it rubs me the wrong way otherwise.

Focus on insight and creativity, not on how to impress potential investors: Learning and experiencing how to identify and solve a valuable problem in a very short period of time is the point of the exercise. The fact that there is a structure around competition and judging might mislead you into thinking it's about something else.

Mind share strategy for organisational change

2012-08-19T11:57:00.000+10:00

It occurred to me that New Lanchester Strategy, being originally a military strategy about force concentration applied to market share in sales and marketing, might also be applied to organisational change.

Should we expect that there would be different effective strategies for organisational change depending on whether we are in a position of strength vs weakness?

Strength in New Lanchester Strategy refers to numerical strength. In our case, instead of troop numbers or market share, I propose that strength in the organisational change context is about mind share, that is, how many people desire the new idea and/or behaviour you are trying to introduce.

Note that mind share does not mean that the individuals are skilled in executing the idea or behaviour, just as desiring and buying a product or service does not mean that you are skilled at using it. So I'm also proposing that we distinguish acquisition of mind share from development of capability.

You are in a position of strength when your mind share is dominant, that is, 3 times greater in mind share in a one-on-one situation, and √3 greater in mind share when there are multiple competing ideas. You are in a position of weakness when your mind share is not dominant.

As with New Lanchester Strategy market share targets, the maximum target mind share is ~70%, the leading idea only requires ~40% (assuming 3 or more competing ideas), and at least ~25% is required to maintain a stable presence in the organisation.

In New Lanchester Strategy, there is a principle about prioritising attacks on the weak and on weak points. This refers to building market share by taking it from weaker competitors and by attacking the weak aspects of stronger competitors. With organisational change, you can similarly build mind share by absorbing supporters of weaker ideas and emphasising the weak aspects of the dominant idea.

The weaker idea should never engage in open, wide-ranging confrontation with the stronger idea. Instead, the weak should focus on local battles and close combat.

Local battles for organisational change are about identifying and targeting isolatable and winnable segments within the organisation that can be defended. For example, some possibilities might be a single person, a single team, a single function, a single business unit, etc. as long as they generally have authority to independently decide on their own approaches.

Close combat for organisational change is about staying close to your allies and using a personal touch. If you have a sponsor, focus first on his / her direct sphere of authority and influence. Win there before expanding elsewhere. Focus primarily on engaging people directly face-to-face and personally over potentially sterile, official communication channels.

Beyond New Lanchester Strategy, we should also consider concepts from diffusion of innovations. When in a position of weakness, target Innovators and Early Adopters as the first defendable segments and exploit opinion leadership and mind share to convert the majority / mainstream. To be clear, when in a position of weakness, don't start by trying to directly convince the mainstream or laggards.

The strategy changes when you get into a position of strength. The stronger idea should engage in the open, go after the mainstream, and publicise widely. That is, when in a position of strength, you want to exploit all the official communication channels, modify official policies and structures, provide official training, change official incentives, etc.

I want to end this on an important point.

Mind share strategy is about competing ideas within people's heads; it is not about competing people. Someone who doesn't currently support your idea or target behaviour is not the enemy / competitor, the alternate idea or behaviour is.

PERMA for human motivation

2012-08-13T19:44:00.000+10:00

In Flourish, Martin Seligman describes aspects of well-being represented by the acronym PERMA:

Positive emotion: Happiness and life satisfaction
Engagement: Flow state
Relationships: Other people
Meaning: Belonging to and serving something greater than yourself
Accomplishment: Success, winning, achievement, mastery

I'm wondering if this is a more complete way to think about human motivation over Dan Pink's Autonomy, Master, Purpose or even self-determination theory's Autonomy, Competence, Relatedness.

New Lanchester Strategy Volume 3: Sales and Marketing Strategy for the Strong

2012-08-12T21:27:00.000+10:00

My notes from from New Lanchester Strategy: Sales and Marketing Strategy for the Strong...

The strategy of the weak focuses on offense while the strategy of the strong focuses on defense. Defending as the stronger opponent means preventing the weaker opponent from attacking, that is, preventing the weak from using the strategy of the weak.

Matching Operations
The main strategy of the weak is differentiation, therefore the strong can negate the strategy by matching.

Matching operations must be quick to prevent the opponent from gaining confidence and momentum. Repeated matching sends a message to the weaker competitors that you are not vulnerable to attack.

Detect attempts at differentiation by setting up a information gathering system
Neutralise differentiation by matching

See also "neutralisation innovation" from Escape Velocity

Engage in Wide-Area Battles

The weak prefer to fight local battles therefore the strong should force them to expand their campaign.

Fight in open territory, that is, large markets with weak boundaries
Go after the mainstream, that is, customers that tend to follow the crowd
Use general purpose products, that is, try to undermine the ability to segment the customer base

Engage in Stochastic Battles
The strong should avoid one-on-one competition and instead use numerical strength to overpower others.

The strong should prefer markets where there are many competitors:

consumers in these markets will tend to choose based on name recognition
weaker competitors will weaken themselves fighting each other

Engage in Remote Battles

To counter the close-combat strategy of the weak, the strong should prefer fighting from a distance to allow them to exploit their numerical strength, that is, remote battles.

Emphasise advertising and publicity

New Lanchester Strategy suggests that Pull is a strategy of the weak and the strong should instead Push products and services. From a Lean perspective, this seems misguided.

Engage in Comprehensive Battles
The weak will focus on one area. The strong should counter with everything they have available.

Defend AND counterattack at the same time. When a weaker rival launches an attack, both respond to the attack and launch your own attack against another region at the same time. This forces the weak to split their resources.
Improve product strength, service, and sales strength. Continuously improve the quality of all your "weapons", product strength, service, and sales strength.

Inducement Operations

Inducement operations are about luring opponents into situations where you have the upper hand.

The weak will use diversionary operations to prevent the strong from detecting their true objectives. To counter this, the strong should make the first move to force the weak to respond, distracting them from launching their own offensives.

The essence of a learning organisation

2012-08-09T14:39:00.003+10:00

See what you don't know
When you don't know something, solve for it in a disciplined fashion so you do know
When you discover something, tell a friend
If you're responsible for other people, teach them to do those things

Steven Spear, Achieving the High Velocity Edge in System Design, Deployment, and Operations

New Lanchester Strategy: Volume 2 - Sales and Marketing Strategy for the Weak

2012-07-29T16:38:00.002+10:00

My notes from New Lanchester Strategy: Sales and Marketing Strategy for the Weak...

If the weak do the same as the strong, the gap between them will never narrow
The weak must differentiate themselves from the strong as using the same strategies can only maintain the gap but never decrease it.

New Lanchester Strategy suggests using 3 or more differentiation types. For example:

Product performance and quality
Branding and packaging
Customer service
Quantity and quality of sales calls
Type and number of distribution channels

See also strategy canvas, disruptive innovation, etc.

Engage in local battles
The weak cannot afford to disperse their forces when competing against the strong. Therefore they should focus on finding or engineering a "local battle" situation, that is, an isolated market segment.

New Lanchester Strategy segments by:

geography
size
pricing
use or purpose
scale
industry
gender
age
income

The upcoming Lean Entrepreneur describes all of these segmentation approaches as proxies for segmenting by problem.

Engage in single combat
The strong have the least amount of advantage over the weak in one-on-one combat. This is for a couple reasons:

It's easier to differentiate with only one competitor
Stronger opponents tend to become presumptuous, thus having dissatisfied customers that can be won over

If it is not possible to engage in single combat, target areas with few competitors.

Engage in close combat
The closer you get to a strong opponent, the harder it is for the opponent to exploit a strong position.

"Close combat" means staying close to customers:

Direct rather than indirect sales
Start at your home territory
Use personal touch

The track record of the weak are not as good as that of the strong so they need to forge personal relationships to develop fans and build trust.

One-point concentration
The weak must concentrate on a single point for any chance of winning.

There are different ways to select a region to concentrate on where you are more likely to win:

You are already number 1 in the region and the gap between you and number 2 is large
The region is where the competitor has a blind spot

Distant from home base
Small or niche markets

Diversionary operations
Diversionary operations are designed to confuse the competitor in order to:

Upset the competitor's morale
Disperse the competitor's strength

Strategies are not visible but tactics are... and strategies can be inferred by tactics.

Example diversionary operations:

To trigger an emotional response, go after the competitor's home base:

attack blind spots
temporarily concentrate sales force
hold an expo near their home office
go after major clients
pretend to launch a head-on attack

Don't limit events to target regions or customer segments. This will give the impression that you are engaging in wide-ranging battle rather than a concentrated attack.

Next: New Lanchester Strategy for the Strong

Identity is more than just shared purpose

2012-07-29T10:50:00.000+10:00

When talking about shared identity, it is easy to believe that this is equivalent to shared purpose or meaning. I believe that this is partly reinforced by the popularity of Dan Pink's Drive.

As I've mentioned before, Drive re-interpreted self-determination theory which talks about "relatedness", not "purpose".

Relatedness is about feeling connected to a group, to care and to feel cared for. It occurs when we develop closer relationships with others.

I will submit that when we talk about shared identity, we are really trying to talk about relatedness. And if we are talking about relatedness, it is not enough to find shared purpose.

We can have shared purpose and still not feel connected. We can have shared purpose and still not feel cared for. Those are just alliances of convenience.

New Lanchester Strategy: Volume 1

2012-07-08T16:57:00.000+10:00

I originally learned of New Lanchester Strategy from Steve Blank in The Four Steps to the Epiphany. In order to learn more, I recently read the 3 volume set from Shinichi Yano on New Lanchester Strategy (in manga form!). The first volume is an overview, the second focuses on the "strategy for the weak", and the third focuses on the "strategy for the strong".

Here are my notes from the first volume...

New Lanchester Strategy is the application of Frederick Lanchester's Power Laws (relative strength of military forces) to sales and marketing strategy.

Lanchester's First Law - The Law of Single Combat

M_o - M = E (N_o - N)

where

M_o is the initial numerical strength of group M
M is the final numerical strength of group M after combat
N_o is the initial numerical strength of group N
N is the final numerical strength of group N after combat
E is exchange rate efficiency which is determined by weapon performance and individual skills

In ancient combat, large-scale warfare was essentially an aggregate of one-on-one engagements. To win, one can either:

Increase numbers
Increase exchange rate efficiency (i.e., better weapons, tactics, training)

This concept also applies to one-on-one market competition, where numeric strength is market share.

Lanchester's Second Law - The Law of Stochastic Warfare

M_o² - M² = E (N_o² - N²)

In modern combat, large-scale warfare is a messier affair with weapons that engage multiple people. To win, one can either:

Increase numbers
Increase exchange rate efficiency (in proportion to the square of the strength ratio)

In other words, numeric superiority becomes more advantageous with stochastic combat. The primary way to win with inferior numbers is to disperse the opponent's forces.

This concept also applies to many-to-many market competition.

Market share targets

Maximum Target = 73.9%, also known as "monopoly share" of market. At market share greater than 73.9%:

it is difficult to stimulate additional demand;
you get into direct competition with speciality niches;
the correlation between market share and profitability disappears.

Equlibrium or Stable Target = 41.7%, assuming 3 or more competitors. The key point is that 50+% market share is not required to become the industry leader. The gap in profitability between the leader and rivals widen when the leader as 41.7% or more market share.
Minimum Target = 26.1%. 26.1% is the boundary for unstable and stable market leadership. Any less than 26.1% and there is significant danger of leadership reversal. Profitability also changes at this point.

Shooting range theory and market share
In a local battle between two companies, if one company's "war potential" (i.e., market share, effectiveness) exceeds the other by more than a factor of √8, it is undefeatable. In a wide-ranging, comprehensive battle between many companies, this factor is reduced to √3.

This also applies to competitions over individual customers or market regions, and in competitions for market positions (e.g., 2nd vs 3rd place).

The No. 1 principle
Only the leader (aka No. 1) has absolute advantage in a battle, therefore segment the market and become No. 1 in as many ways as possible.

No. 1 strategy for the strong
#1 product -> #1 product line -> #1 in customer base (industry, channel, profession) -> #1 with client -> #1 in region

Focus on one or a few products and create #1s and then keep adding to get a #1 product line

No. 1 strategy for the weak
#1 with client -> #1 in customer base -> #1 in region or district -> #1 product

Focus on a region and create #1 with specific clients and then keep adding to get #1 in a customer base for the region and then until #1 in the region and then get more regions

Prioritise attacks on the weak and on weak points
Your competitive target is a stronger rival you are attempting to reverse. Your offensive target is a weaker rival that you are attempting to take market share from.

Attacking weaker rivals to grow market share is known as the principle of "bullying the weak". This is done to prepare for stronger rivals.

For stronger rivals, you should attack blind spots and weak points and avoid direct confrontation.

Combined the principle is "prioritise attacks on the weak and on weak points"

Principle of One-Point Concentration
If you have fewer resources than your rival, you cannot win unless you concentrate them.

What you concentrate on depends on whether you are strong or weak. See No. 1 strategies for the strong and for the weak.

How much you concentrate depends on the level of investment by the rival.

----
Next: New Lanchester Strategy for the Weak

Are the Kanban practices in the right order?

2012-07-01T10:40:00.000+10:00

Hakan Forss blogged about a session he hosted at the 2012 Kanban Leadership Retreat about the order of Kanban practices.

David Anderson has written about a set of core practices for Kanban adoption that go from shallow to deep:

Visualise the work and work flow
Limit WIP
Manage flow
Make management policies explicit
(NEW) Implement feedback mechanisms
Improve collaboratively using models and the scientific method

Based on his experiences, Hakan proposes a new ordering:

Visualise the work and work flow
Make management policies explicit
Manage flow
Limit WIP
Implement feedback mechanisms
Improve collaboratively using models and the scientific method

The difference is the ordering of "make management policies explicit", "manage flow" and "limit WIP".

Hakan's proposal matches my own intuition and experience.

I typically describe the point of visualisation and making things explicit as both falling under an overall umbrella of creating a shared understanding of the current situation. This is beyond just work, work flow, and policies, I will almost always also look at how to visualise the current capabilities within the team.

I would actually simplify this even further though by borrowing from Steven Spear, we need to setup an environment that allows us to...

See our work, work flow, policies, and capability
Learn in a disciplined fashion (i.e., science)
Share our learning

Culture Change and Cool Runnings

2012-06-30T19:32:00.000+10:00

"All I'm saying, mon, is if we walk Jamaican, talk Jamaican, and *is* Jamaican, then we sure as hell better bobsled Jamaican."

The quote above comes from a scene in the 1993 comedy Cool Runnings about the first Jamaican bobsled team in the 1998 Winter Olympics. The character, Sanka, is advising the leader of the team that if they want to be successful, they have to be true to who they are, rather than just copying the Swiss.

I'm reminded of this scene when I hear people talk about how Agile requires culture change... typically with the implied conclusion that therefore all (or at least most) of the previous beliefs are wrong and useless.

When I hear someone say something like "If they want to go Agile, they need to fundamentally change their culture", another voice responds in my head:

"All I'm saying, mon, is if they walk Jamaican, talk Jamaican, and *is* Jamaican, then they sure as hell better Agile Jamaican."