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

Lean Software and Systems Conference 2012 Day Two

2012-05-31T09:22:00.000+10:00

I recently attended the 2012 edition of the Lean Software and Systems Conference. Here's my summary of the second day.

Gregory Howell - Lessons Learned in Lean Construction
Very similar to previous work I've seen from Hal Macomber and Mary Poppendieck but it's good to hear from the original.

Triggered by this talk, I finally got around to getting Building Trust but I have to admit that I was somewhat disappointed...

Benjamin Mitchell - What Comes After Visualising the Work? Conversations for Double Loop Changes in Mindset

Thoughts triggered by this talk:

I try to assume a reasonable, humane person as a default rather than assume nothing about intent. In other words, ask the humanising question: "Why would a reasonable, rational, and decent person do that?" See Crucial Conversations Skills.
I suspect flawed memories and assuming most behaviour is cognitive is what leads to two apparent theories of action
I wonder if the reason why people don't share rationale is because they assume other people are unreasonable or incompetent. Therefore to encourage sharing of rationale, we need to address how one attributes cause. See Six Sources of Influence.

Jeff Patton - Lean & Kanban Myths, Misconceptions and Forgotten Principles

"No I am not Adam Savage."

What Jeff Patton knows about Kanban:

Every package of sticky notes comes with two shapes: a square and a diamond."
Your backlog contains "bets" (aka aspirational value)

The Underpants Gnomes model for business:

Jeff described a variant of Tim Brown's definition of Design Thinking:

Ignite & Lightning Talks
Tip if you want to do an Ignite talk: Effective presenting in the Ignite style is not about perfect timing but more design focus and adaptation

Someone from BTI360 gave a very interesting talk about implementing Lean Thinking in an auto shop.

Claudio Perrone - A3 Thinking and Kaizen

Things improved sharply once we began celebrating the completion of each story

Kaizen memo to capture improvement experiments:

Mary Poppendieck - Continuous Feedback: Process Control for Developing Software-Intensive Systems

I just caught the tail end of this which ended up being an interesting question about the relationship between Success Assured, Set-Based Design vs MVP, A/B Testing.

There are a few things that come to mind:

Set-based Design and MVPs are both about exploring the solution space
Set-based Design is about exploring the solution space independent of any particular problem space
Typical MVP approaches are like point-based iterations but it can be a set of parallel MVPs. A recent HBR article talks about this: http://blogs.hbr.org/cs/2012/05/dont_let_the_minimum_win_over.html

Lean Startup for Change

Yuval Yeret, Jeff Anderson and few other people I don't remember got together for an ad-hoc session using Lean Coffee format to discussion Lean Startup for Change (#ls4chg).

Yuval has a good summary here: http://yuvalyeret.com/2012/05/16/so-what-is-lean-startup-for-change-ls4chg/

Next up: Day 3

Lean Software and Systems Conference 2012 Day One

2012-05-27T11:00:00.002+10:00

I recently attended the 2012 edition of the Lean Software and Systems Conference. Here's my summary of the first day.

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

Essentially discussing themes from his book The High-Velocity Edge.

Without the opportunity to be surprised, there is no opportunity to learn
The only way to learn is to raise your hand and say "I don't know"
Use the language of the domain - don't bring arcane Toyota language [which I'd generalise as "Use what's there - don't drag in your own baggage"]

3 point summary of his talk:

See what you don't know (and create environments that allow you to do this)
Learn in a disciplined fashion (i.e., science)
Tell a friend

Brant Cooper - Are you a Visionary? How Lean Startup is Helping to Create an Innovation Economy

I expect these were themes that will make it into the Lean Entrepreneur.

"Visionary" is a media myth
What's worse than building a product that no one wants is writing a business plan to build a product that no one wants
Stages of customer action: curious -> intrigued -> trusting -> convinced -> eager -> satisfied -> passionate
It's easy to build something no one wants... just build what's between your ears
To create a startup culture in a large enterprise, buy the leaders copies of The Lean Startup

I asked a question about how to migrate products / services from something like a corporate Lean Startup lab to main business units. There's no clear answer here. I wonder how Intuit and 3M do it.

J. Leighton Reed - Total Engagement and the Reinvention of Work Using Games

I expect these were themes from Total Engagement.

As you can tell from the title of this blog, I'm also an avid gamer (PC primarily) so I was interested in this from more than one perspective.

Being able to customise your avatar is important for self-representation. [This suggests that we should encourage custom card wall avatars rather than just using photos]
People accept transparency in reward systems when the the reward system is perceived as fair. [So if people are reluctant to expose performance measures, salaries, etc., you should be asking whether this is more a reflection of the fairness of the system]
We need to give feedback in the time cycles that are relevant to humans
Without an epic story, badges, ranks, and levels aren't engaging enough to matter

He also described a system using a currency called Serios to create an attention economy. I'm not sure about this part but it's interesting...

Lightning / Ignite Talks

A new addition to LSSC were lightning and Ignite talks. Some were good, some not so much. I'd suggest the kind of presentation shepherding that Ignite Sydney does. I'd also suggest just Ignite format.

Learned about Change Camp from Gerry Kirk... neat!

Jim Sutton - President's Address

The main thing I remember...

Jim says: "We're all about community. We're all communal."
Someone in the audience says: "Isn't that communists?"

Jeff Andersen - Enabling Enterprise Kanban Transformation through Lean Startup Techniques

Although I have some issues with some execution choices, I found the overall concept quite interesting as I've begun experimenting with framing organisations as market places into which we are trying to launch ideas. My starting point has been New Lanchester Strategy via The Four Steps to the Epiphany (aka Customer Development) while Jeff and the people at Deloitte LEAN have focused primarily on the concept of Minimum Viable Changes.

I also began wondering about what a Change Model Canvas modelled after Business Model Canvas might look like.

Brant Cooper wondered on Twitter whether we could create a weekend "changeathon" akin to a hackathon.

This led to an ad-hoc session scheduled via Twitter which I'll summarise for Day 2.

Steven Denning - Making the Entire Organisation Lean

I did not know that Steven Denning was Australian...

I expect these were themes from The Leader's Guide to Radical Management:

Not balanced scorecards but one goal: delighting customers

Everything else he said essentially supported that one point.

Michael Kennedy - Set-Based Decision Making: Taming System Complexity to Ensure Project Success

These were themes from his books and beyond:

I attended the Lean Kanban Benelux version of this talk but I popped in to catch the end of this version.

How do we systematically learn as people and as an organisation in software product development for the current and all subsequent products?

This is what's called an interesting question.

Next up: Day 2

Lean Software and Systems Conference 2012 Day 0 - Lean Camp and Lean Action Kitchen

2012-05-26T17:46:00.001+10:00

I recently attended the 2012 edition of the Lean Software and Systems Conference. Here's my summary of the pre-conference Lean Camp and Lean Action Kitchen.

Lean Camp
Jim Benson opened the Lean Camp Open Space session which I thought was a good addition to the main conference.

I proposed two sessions:

Think Like a Lean Person (The LSSC version of Think Like an Agilist)
New Lanchester Strategy for organisational change

The first session I attended was with Jim Benson who happened to propose a similar session about learning the Lean mindset. I mentioned a model that I learned from Think Like a Commander:

The classroom teaches you basic facts
Full-on simulation allows you to exercise strengths
Deliberate practice allows you to expose and address weaknesses

All three aspects are required to learn.

I also mentioned Derek Muller's (aka Veritasium) PhD thesis about the need to start with misconceptions to avoid people tuning out because they believe they already know the answer and how this will feel uncomfortable. Learning feels worse than not learning anything.

Session two was a preview run of Russell Healy's Kanban System Design game:

An interesting behaviour that occurred was even though we were able to determine that the larger project was better economically, we were wary enough about unanticipated risks that we avoided starting it until the end. This behaviour seemed to hold for other players of the game.

Session three was Think Like a Lean Person:

Two concepts that seemed difficult for attendees to understand (which suggests they're the ones I need to focus on):

The difference between setting up an environment that learns (i.e., reflective practice) and deliberate practice outside the normal working environment. The key issue that I wanted to emphasise was the strong tendency to exploit strengths and work-arounds in full simulation or real environments which doesn't allow for much focus on exposing and addressing weaknesses.
The difference between the basic facts of Lean, Kanban, Agile versus the cognitive behaviour themes that allows one to adapt effectively to different contexts.

Session four was New Lanchester Strategy for Organisational Change:

I have some blog entries in progress to describe the concept in more detail but the gist of it is to adjust your organisational change tactics based on an assessment of mindshare.

When you are in a position of weaknesses (low mindshare):

Segment the market - focus on a subset of the organisation or a subset of your overall change
Stay close to allies
Engage in "local battles"
Bleed the strong - undermine and exploit the weak points of the dominant idea
Bully the weak - replace other alternate ideas that are weaker

When you are in a position of strength (high mindshare):

Go broad - role models, systems, symbols
Neutralise and overwhelm competing ideas

What is the organisational change equivalent of superior weapon efficiency that helps overcome numerical mindshare weakness? That is, what's the equivalent to an "idea bomb"? We figured that this might be a very successful, high impact pilot project.

A key question with this strategy is how do we know what situation we are in? How do we know if we're in a position of weakness or strength?

Potential answers:

Sample
Survey
Run brown bags or similar events to see how many people show up

Lean Action Kitchen
Jim Benson and Torianne Demaria Berry prepared a series of dishes and linked them to Lean concepts. Allow me to attempt to communicate the experience through a series of pictures...

I remember having a conversation with someone about how our memories of an experience are more important than what we actually experienced but forget. Therefore, things like photographs and souvenirs can be useful to deliberately shape how much we enjoy the memory of our experiences. Amusingly, I have forgotten her name but she's the one sitting with her back to the camera in the second picture.

The only adjustment I would suggest is to replace the wine pairing with high quality tea pairing.

Overall, Day 0 of LSSC 2012 was quite interesting and memorable. Worth attending on its own.

Next up: Day 1

Tiered Daily Meetings

2012-05-26T13:37:00.000+10:00

From Creating a Lean Culture,

Tier 1: Start of shift, led by production team leader with production team
Tier 2: Led by supervisor with production team leaders and any dedicated support group representatives
Tier 3: Led by value stream manager or equivalent with supervisors and support group representatives or staff members.
Tier 4: Led by plant manager with production and support staff members. Focused on "run-the-business" as well as "improve-the-business" activities.

Characteristics of all meetings:

Brief - rarely longer than 15 minutes
Standing up
Located immediately adjacent to and not physically separated from production floor
Agenda and content defined by a visual display board

---

This all sounds very familiar doesn't it...

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