Andrew Walker just told me that he started a blog about his team trying Kanban, partly inspired by the talk I gave at Agile Sydney.

Check out Kanban Chronicle: Insights Into Our Kanban Journey.

This is the Agile Sydney version of my Kanban into presentation.(Agile Sydney version) Stop Starting and Start Finishing: An Introduction to KanbanView more presentations from Jason Yip.

I'm speaking at Agile Australia 2010 and they gave me a discounted registration rate code for my network which is good for $600 to attend (vs $900 normal rate).

Go to the registration page and enter 15160910 as the promotional code.

Via Sketchnote Army,

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)