Michael Balle has a very interesting post on "making people before making products":
When I first studied how Toyota engineers implemented TPS at a supplier, they always knew what the next step was, and so I assumed (as did the supplier’s engineers) that had a roadmap of how they wanted to make the cell progress. I kept badgering them to show me this map, thinking that they didn’t want to share this for proprietary reasons. The Toyota guys always refused, explaining that they didn’t have a roadmap. All they were doing was focusing on problems as they appeared and then working hard at solving them. One day, exasperated with my annoying questions, the lead engineer said to me” “WE DON’T HAVE A ROADMAP. But—we do have kind of a golden rule: making people before making parts.” I’ve tried to puzzle this out ever since.He has a quote from a CEO that I like:
“I don’t want people who will do the job right. I can find those any time. I want people determined that the next time they’ll do the same job, they’ll do it better. Those are the people I need."

"There are two ways to extend a business. Take inventory of what you're good at and extend out from your skills. Or determine what your customers need and work backward, even if it requires learning new skills." Jeff Bezos

Tried out a job crafting exercise and this was the result:

This is the presentation I gave at Ignite Sydney July 2010.
Stop Starting and Start Finishing
View more presentations from Jason Yip.

Let's take a look at a simple cash flow curve:
The initial dip is the investment.  Cash flow changes direction at some point, around when the product starts selling. For simplicity, let's assume that this roughly happens at the point of release so the change in direction can be considered time-to-market.  At some point, we recover our initial investment and start getting into positive cash flow.  That point is time-to-profit.

So what are our options to improve time-to-profit?

Option 1: Reduce Costs
If we don't have to spend as much in investment, it will take less time to recover to positive cash flow even if we are not any faster in time-to-market.  This assumes that there is no change to the product uptake.

A variant of this would also incrementally improve time-to-market, assuming much of the cost has to do with non-value added activity which also takes up unnecessary time.

Option 2: Improve Uptake
If the rate of uptake is faster, then the rate of cash recovery is faster and therefore the point at which we switch to positive cash flow is reached sooner.  This option is about designing a higher quality, more usable, more appealing product.

A variant of this would dip lower during the initial investment to pay for additional activities to learn how to design the better product.  The greater initial investment is a trade-off against potentially faster and longer uptake after release.

Option 3: Minimum Viable Product
This is the classic Agile model.  If we are able to incrementally release subsets of the product rather than all at once, we can dramatically reduce time-to-market and therefore time-to-profit.  There is ongoing investment for multiple releases but you're playing in positive cash flow territory at that point.

Option 4: Combine all previous options

This is essentially the problem we're dealing with.  You want to tell me what we're trying to build and I'm trying to understand but that communication channel is prone to misinterpretation.  If we make our communication more rigorous, we can prevent misinterpretation, however, we will also make communication more onerous and therefore less frequent.  There is a reason why we converse in natural language.

Natural language is good for conversation, but bad for misinterpretation.  Structured communication is good for avoiding misinterpretation, but bad for conversation.

Way back in 2001, Ron Jeffries came up with the 3 Cs of User Stories:

• Card - A physical token used for planning.  This is about work management.
• Conversation - A dialogue between customers and programmers.  This should be done in natural language but can be supported by diagrams, prototypes, and other supporting techniques.
• Confirmation - Acceptance criteria in the form of concrete, testable examples to clearly communicate to all involved what is necessary for the User Story to be done.  These will not include all the test cases that will be required but enough that we can validate common understanding.  Preferably, these examples are structured language descriptions of scenarios, each combined with data-driven tables to describe expectations for different variants.

This is a more visual way to describe this:

As one of the first steps to trying Agile, organisations often attempt one or more pilot projects.

Recognise that when you are running a pilot project, what you are doing is running an experiment.  Given a set of inputs, we are interested in what happens to a set of outputs.

What are the inputs to an Agile pilot project?

• The people involved
• The problem being addressed, in other words, the project context
• The solution space constraints, including both technology and organisational constraints

What are the outputs we should be interested in?

• Project performance, that is, the effect of introducing the change
• Process performance, that is, the success in actually introducing the change

Remember, the objective is to see if the change is effective in improving performance.  It's obviously foolish to say "X didn't work" when we weren't actually successful in introducing X.
Here's a more visual way of describing this:

As a follow up to my previous post, I've created another Meetup group for the Sydney meetups.  Initially we'll just be cloning the same events as Melbourne but please post ideas to the group for future meetups.

YOW Nights! Sydney is coming again on 6 July featuring the dazzling Pamela Fox (Google) talking about the wide range of Google APIs and the more stern-looking Erik Doernenburg (ThoughtWorks) talking about turning good builds into great builds.

http://yownightsydneyjuly.eventbrite.com/

Drinks and food included as well as door prizes, including a free ticket to the full YOW! conference.

David Joyce has setup a Meetup group for the Limited WIP Society in Australia with the first meetup planned for Melbourne on the 27 July:
The first meet up will be presented by David Joyce - An overview of kanban and how it was applied at the BBC. It will take place in Melbourne and if there is enough interest it will also run in Sydney.Over the next few months we will be running a series of meetups which will include:

• The GetKanban game - Russell Healy
• An overview of Systems Thinking theory
• The Red Bead Experiment

I'm looking for volunteers to run sessions in addition to the above, please get in touch if you would be interested in this djoyce@gmail.comNon-Melbournians feel free to join as well.  Will likely coordinate David to do this in Sydney as well and I don't see why we can't have events in other cities if there is enough interest.

"Every day I remind myself that my inner and outer life are based on the labors of other men, living and dead, and that I must exert myself in order to give in the same measure as I have received and am still receiving."

Albert Einstein

A while back someone asked me the question about how they could get Agile to work in an environment of deception.

My immediate thought was that no approach leads to high performance in an environment of deception.  High performing, (internally) deceptive organisations don't really exist.

So really the question should be not be about how to get Agile to work in that context but rather about how to change that context.

Visibility helps.  Getting and supporting allies help.  Changing policies help.  Building reputation helps.  Delivering helps.  Agile helps.

Despite the best maintenance efforts, it's generally accepted that physical machines eventually fail and this is part of planning.  I have not usually encountered software architects / designers who explicitly acknowledge the expected life span of systems they design (and that includes me).  There seems to be an implicit suggestion that because it's software, it can last and be modified forever.  Even if it's just a gut check, how many systems have you seen would reasonably survive (useful, able to cope with existing context) past 5 years? 10? 20? 50? 100?  Should we not plan for replacement effort, rather than plan to standby with duct tape and hope we can keep the thing going as long as possible?

When physical machinery is not maintained, it is obvious to some extent.  Even an unskilled observer knows something is wrong when smoke starts to emit from the machine.  A software system that is failing apart is not so easily detectable.

While physical machines degrade over time due to wear and tear, software degrades over time due to being constantly adjusted over years, evolving integration environments,  and evolving platforms.  So software degradation is more about designs being pushed beyond original intent until they finally fail.

I've recently been looking at Total Productive Maintenance:

Preventative maintenance - Actions occurring at a regular interval which are intended to prevent future breakdown.  For example, I remember regularly walking around a boat engine room wiping oil off machinery.  This is the category I place typical refactoring in, with the regular interval being on the order of minutes.

Predictive maintenance - Actions in response to indicators that equipment is deteriorating.  In other words, maintenance when an alarm, signal or diagnostic tool indicates that something has or is about to go wrong.  This is the kind of thing that visualising internal quality metrics tries to address.

The reason why I'm exploring this is because I'm trying to show that someone saying "let's skip refactoring" is like saying "let's skip preventative maintenance".  Not paying attention to internal quality diagnostics is like asking everyone not to pay attention to the blue smoke spewing out of the machine.

Maintenance is necessary to ensure the ongoing performance of your software production system and should not be considered optional.

Via Eric Ries,
Team vision and discipline over individuals and interactions (or processes and tools)Validated learning over working software (or comprehensive documentation)Customer discovery over customer collaboration (or contract negotiation)Initiating change over responding to change (or following a plan)

The common response to intellectual criticism - categorise it and then dismiss it out of hand - is one of the great sources of weakness in economics, and indeed much political debate.Steve Keen in Debunking Economics

Recently read Total Quality Control by Armand V. Feigenbaum.  Here are the key points I liked:

"Quality is a customer determination, not an engineer's determination, not a marketing determination or a general management determination. It is based upon the customer's actual experience with the product or service, measured against his or her requirements -- stated or unstated, conscious or merely sensed, technically operational or entirely subjective -- and always representing a moving target in a competitive market."

"Quality must be designed and built into a product; it can not be exhorted or inspected into it."

"Carried beyond a certain point, the theory of division of effort begins to create more problems than it solves, because it promotes narrowness of perspective, duplication of effort, and fuzziness of communication."

Cost of quality control = prevention costs + appraisal costs

Cost of failure of quality control = internal failure costs + external failure costs

I also mentioned his use of usual vs unusual causes of variation previously.

The Need for Enterprise Agility & Vision, a Case Study: Alan Shalloway and the Vanguard case study by someone I forgot the name of...
I really only jotted down a couple quotes and a thought for Alan's short bit here.

"Theory by itself teaches nothing. Application by itself teaches nothing. Learning is the result of dynamic interplay between the two." (Peter Scholtes)

"sometimes chaos is creative but usually it's just madness"

And my thought was that we can't really assume any particular shape of return vs time.

I didn't capture anything about the Kanban case study from Vanguard except for their "when to use" table:

"Agile" and by "Agile" they really meant Scrum

• 1 big thing
• team swarm
• commitment
• MMF -> Stories -> Tasks

Kanban

• many small things
• 1 person projects
• priorities change daily
• work is already small

Keynote: Bob CharetteBob Charette comes from a risk management background so this was an interesting and different perspective.
"Risk, Lean Development & Profit"
When Toyota people visited Ford, mass production was considered the best approach in the world.  Toyota did not assume that there's nothing better than Mass Production.  I think we must also not assume that there's nothing better than Agile / Lean.
"Assumptions are risks that we have accepted"
Bob referenced an old paper "A Strategy for Comparing Alternative Software Development Life Cycle Models".
Profit = Provider's Risk - Consumer's Risk
All exchanges of goods and services are exchanges of risk and opportunity.
3 root causes of risk:

• Information
• Control
• Time

The goal is to increase information, increase control, reduce time.
Principle: Lean Development is about taking the right automation decisions and profiting from them
Bob referenced Rockwell-Collins and their Real-Win-Worth model:

1. Is it Real?
2. Can we Win?
3. Is it Worthwhile (aka profitable)?

Principle: Lean is critical to create a risk entrepreneurial culture
saru mo ki kara ochiru - Even monkeys fall from trees
Bob was using this to relate to the current Toyota problems.
Risks of being good at Lean:

• Complacency and hubris
• Competing futures
• Self as Customer
• Admiration of Lean
• Organisational hypocrisy

"The most important discoveries, the greatest art, the best management decisions come from taking a fresh look at what people take for granted or cannot see precisely because it is too obvious." (Richard Forson)
BeamTeam Case Study: Dennis StevensVery interesting talk that included a description of a Strategy Execution Kanban board.

1. Strategy articulation: SWOT
2. Capability model
3. Initiative A3s which lead to identification of deliverables
4. Strategy execution Kanban board

This reminded me a lot of how Ian Robinson describes how to begin an SOA initiative.
PDCA: Beyond Simple Inspect and Adapt: Ryan MartensRyan referenced an equation he heard from Esther Derby by Kurt Lewin:
B = f (P * E)
B - behaviourP - peopleE - environment

Update: This is known as Lewin's Equation

1. Pilot using A3s - the art of of problem solving
2. Pilot PDCA and True North
3. Examine cultural assumptions
4. Learning organisation

Shewart:

• Chance-cause: Implies that the variation is random and is inherent to the design of the system.  However this is internal variation that is controllable by modifying policy and/or changing process.
• Assignable-cause: Implies that there is an easy cause-and-effect relationship between an external event and the variation.  Cannot be controlled by local management.

Alpert / Deming

• Common-cause: Implies that the variation is common to all similarly designed systems so it's nothing special.  Probabilistically predictable but otherwise noise within the system.
• Special-cause: Signals that something happened that was a surprise (i.e., new knowledge or an event that is different to how the system normally works).  Unpredictable.

Feigenbaum

• Usual: The amount of variation that you've learned to expect of the system.
• Unusual: Any variation that is greater than what you'd expect.

I kind of like the simplicity of Feigenbaum's naming but it's useful to know about all the variants to have a better understanding of what they're all trying to convey.

Feeding the Agile Beast: Dennis Stevens


This session was a more detailed description of the approach described in the BeamTeam Case Study on Day 2.

Business value:

• increase or protect revenue
• reduce cost
• align with product strategy

1. Specify Value

This is based on Silos, Politics and Turf Wars.

Thematic Goal (e.g., make a great product) -> Defining Objectives (e.g., build CRM) -> Standard Operating Objectives (e.g., protect brand, usable)

2. Identify Capabilities

• Determine high level feature groups
• List features for each group
• Categories: Controlling, Value Added, Supporting
• See the end user value stream (aka consumption value stream)
• Create a Capability Relationship Diagram

3. Determine Business Value of Capabilities

• Aligned with product strategy?
• Key to brand?
• Provides competitive differentiation?

Alternative approaches could be Blitz QFD, business value game, real options, etc.
Border of the capability card: red = important, green = okay
4. Determine the current performance of capability
The middle of the card

• How is this performing today?
• Do we understand the level of performance expected?
• Do we know how to improve?

5. Determine risk
Dot in the corner of the card

• compliance or business risk?
• design, development or delivery risk?
• closely tied to other features?
• cost of delay is high?
• executive mandate?

Can also use a star to mark consumer priorities
Kanban GameThe rest of the day I hung out at the Open Space where I played the Kanban game that Russell Healy created.