Tag Archives: tps

Roots of Lean – day one

Posted on by

I am currently on a visit to Japan to meet Toyota and representatives from Japan’s industry to learn about their challenges. Already on day one, things got really interesting.

We met today with the CEO of a Fujitsu subsidiary, specialized in software. The company is applying TPS to improve their practices. It was interesting to see that:

  • The CEO was puts improving engineering and kaizen practices on top of his agenda. He is committed and actively involved, driving improvements. In his world improvements comes first, operations second.
  • A sign of the ambition is the fact that the company employs a mathematical expert to help out with analysis. When would that happen in a western company ūüôā
  • They are experimenting a lot with estimation techniques! The technique currently favored is "Function Scale" –  a simplified version of Function Points. The technique is based on user interface design and is fast, only takes 1-2 minute compared to what a skilled function point analysis would take 30 min or more to do.

Some reflections:

  • Culture and local experiences affects solutions looked at. Turning to TPS, Kaizen and statistical process techniques for improving software products is therefore logical
  • But – using best practices based on other’s success, without thinking (what problem it was intended to solve, how this would help our situation) – is dangerous. Not only can this stop you from solving the right problem (you might be in another situation!) it can also dilute your competitiveness no longer staying ahead. Something to think about when we apply Scrum, Lean or any practice.

Anyway, a really interesting week up ahead! Tomorrow, first visit at Toyota plant, later in week , meeting the former Lexus cheif engineer Kataymy-san and the former IT manager of Toyota.

Planning ahead in Scrum

Posted on by

In Toyota Production System (TPS) action takes place through the Plan-Do-Check-Act-Cycle

Plan-Do-Check-Act

If we relate this to Scrum we see a lot of emphasis on the Do, Check, Act part. But not as much on the plan part. Planning is usually explained as a an activity that takes place on sprint planning day where both team and product owner are participating.

However, how do we deal with situations like:

  • stories that require a multi team effort
  • interfaces to third party systems

..and given a definition of  done "running in production" are we answering questions like:

  • are we implementing the right solution to our problem?
  • is our delivery useful to our recipients?
  • have we got access to necessary resources?
  • can we test? can we deploy?

Basically we need continuously run a thought process in the sprint before we do the implementation. Typically a development team spend around 20% of their time planning for their implementation (Mary Poppendieck).

Thinking ahead
The deliverable for the thought process is "story has business value and is estimatable"
So how do we go about?

Option 1: Use scrum master as an analyst
Appoint the Scrum master as the responsible person for dealing with forward thinking.

Pro’s:

  • SM is already a contact point
  • He does not suffer as much from interupt control as other team members

Con’s

  • Not always the correct technical person for solutions
  • Team can feel overrun

Option 2: Use an external analyst
Get a dedicated analyst in the team that always looks forward.

Pro’s:

  • Releaves team from communication stress

Con’s

  • Adds an extra handover step (waste)
  • Needs to be a superb communicator with team.
  • Analysts tend to lean over to business focus
  • Communication issues remain hidden

Option 3: Assign a "look ahead" story for each sprint
Insert a story which makes next sprint stories estimatable.
Team can pick tasks from this story in same way as on normal stories.

Pro’s:

  • Team can choose among the stories in normal scrum way
  • Communication issues are surfaced
  • Bonding to outside parties is preserved in team

Con’s

  • Product owner needs to have a forward vision
  • Team members might need training in communication skills
  • Implementation might suffer if extensive travel is required

My personal preference is with the option #3. But I have also seen option #1working in Scrum teams. The bottom line is that you need to think this through or you might end up building software that does not deliver intended business value.