A software project is a creative, unique and therefore unpredictable endeavor. We are not building the same thing over and over again, but solve new problems, address increasing demands and use perpetually changing technologies. Under these conditions, people – smart, creative and productive – are the most important factor of success . Software development process can only support and compliment these people, but it cannot guarantee success alone and make the factor of people negligible.

But, business wants predictable, reliable and successful results. I bet they don’t want to be at mercy how cards are shuffled in their talented development team. The answer is in establishing a process that increases chances of success and aligned with present nature of software development (unpredictable, empirical and heavily dependent on people).

The Toyota Way can be a great example that worth to learn. Toyota evolved from a small looming equipment shop to the largest car manufacturing company. The main foundation of successful growth is the system of few core principles that enables best quality, high productivity, lowest cost, shortest time and long-term success.

Agile and Lean Software Development adopted some practices from Toyota. Lean Software Development: An Agile Toolkit  (by Mary Poppendieck, Tom Poppendieck) is an excellent book that review Lean practices and principles in details. This post focuses more on philosophy and the system of practices as a whole that can turn software development team into a smart reliable machine.

1. Value

Why customer will pay money for your product? How does your company creates value?

All we are doing is looking at the time line from the moment the customer give us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value-added wastes.

– Taiichi Ohno, founder of TPS

The only thing that adds value in software development is transformation of information and code into what customer wants. It is very important for software team to know how does it create value for customers. Or simply, decrypt the formula:
Customer (needs) -> Cash (delivered software)

Software Development Value Stream
Problems, needs and ideas are translated into units of development – functionality, user experience (interface, interactions, usability) and system qualities (performance, reliability, security, etc). A software development team transforms these pieces of requirements into a computer system using value-added and many not-so-value-added actions.

The ultimate goal of Toyota Way is to eliminate non-value-added activities while keeping the best quality of the product.

2. Flow

What is the process of creating value in your company?

Properties of the optimal flow for software development:

• cut back to zero the amount of time that any unit of work is sitting idle or waiting for somebody to work on it
• move design, code and information fast, link processes and people together that problems surface right away

One-piece flow
The most effective flow is one-piece flow – a customer need is immediately converted into a delivered software solution. In the same time this is the most demanding flow: a customer, designers, developers, testers and system administrators should be dedicated to the project, immediately available and work as one team together until the need is implemented in a live system.

One-piece flow has significant benefits (if it is implemented right):

• Quality – defects detected quickly; close proximity and connections ensure that necessary information is available immediately and important details are not missing; problems are solved quickly
• Flexibility – flexibility to respond and do what customer really wants in real time
• Productivity – the team engaged in high value added continuous work
• Morale – immediate results of work bring sense of accomplishment and job satisfaction
• Cost – lean production with minimal waste

However, in reality one-piece flow is difficult to achieve in many projects:

• a customer is not engaged all the time
• complex business domain requires analysis and preparation before development can start
• project activities involve people with different skills that are not available immediately
• deployment of mission-critical systems demands intensive testing and scheduling

• management, marketing, end-user expect specific time-lines, features and support

• and so on

Toyota uses two additional principles to overcome challenges of one-piece flow: pull systems and leveling out the workload.
However, Toyota Way says: “Flow where you can, pull where you must“. The big challenging goal is to turn eventually all the processes into one-piece flow.

Pull system (Kanban)
Kanban is a signaling system to trigger action. It adds to flow small buffers pulled by customer demand. Kanban allows optimal use of people and natural breaks in processes.

Agile iterations and Scrum sprints are close to Kanban ideas. A team pulls new user stories every time-boxed iteration from the backlog to design, implement, test and deploy within the same iteration.

However, it is not classical Kanban. An original idea would be to pull small batches of user stories for development after a team has finished a current batch (not at the end of fixed time iteration). In parallel, QA pulls implemented user stories for testing and so on. A customer can continue preparing next batches of work based on their priority of needs.

Main ideas

• provide dependent down stream teams with what they want, when they want and in amount they want
• just-in-time – started by high priority needs
• minimize work-in-progress and untested code
• frequently push what a customer can use right away
• be responsive to day-by-day shifts in demand instead of relaying on long-term schedules

Kanban is effective way to synchronize people and teams work without bringing them into continuous flow, where they should be always ready for the next unit of work.

Level Out the Workload (Heijunka)
The main idea of Heijunka is to level production by volume and activities mix.

• it is not built around actual flow of customer orders
• workload is leveled for the period considering previous history and scheduled projects

In software development workload could be leveled and scheduled when people could make reliable guess for what is expected. It is different from Kanban that works as just-in-time system adapting to the current workload.

Good candidates for Heijunka are

• standard procedures (automated testing, performance testing, deployment)
• recurring events (meetings, planning, demo, code reviews)

• scheduled tasks for people with limited availability (external consultants, customers, management)

• tasks with high confidence in estimation, usually done many times before (initial requirement exploration, design mockups, security audit, training new team members, reusing components and solutions)

Benefits:

• predictability and active planning

• balanced use of people, ability to schedule their involvement

• smoother demand on customers, shared resources and contractors

Toyota Way is focused on eliminating waste of non-value added work (Muda). Heijunka eliminates two additional types of waste:

• unevenness in project schedule (Mura)
• overburden of people and systems (Muri)

Building your own flow

These three approaches can help you to build most optimal flow. Consider cons and pros:

One-piece flow (push)
pros: minimal waste, fast implementation, low cost, quick problems resolution
cons: uneven workload, requires full availability and high level of engagement
when to use: for one collocated team work that is dedicated to one project

Kanban (pull)
pros: dynamic adaptation to load; synchronization of different teams and disconnected processes
cons: low predictability for completion; buffers hide waste
when to use: disconnected or involved in the multiple projects teams; activities that need people with limited availability

Heijunka (level)
pros: good predictability, ability to plan, balanced use of people: avoid overburden and uneven workload
cons: non-adaptive, inefficient for tasks with unpredictable effort (a lot in traditional software development)
when to use: activities that are standardized, highly predictable or have to be scheduled

You cannot build reliable and optimal flow from the scratch based on a theory only. The best process for your projects will emerge as result of evolution, problem solving and eliminating waste. This is a topic of the next post.

If some problem occurs in one-piece flow manufacturing then the whole production line stops. In this sense it is a very bad system of manufacturing. But when production stops everyone is forced to solve the problem immediately. So team members have to think, and through thinking team members grow and become better team members and people.

– Teruyuki Minoura

References:
The Toyota Way by Jeffrey Liker
Lean Software Development: An Agile Toolkit  by Mary Poppendieck, Tom Poppendieck

Posted by Andriy Solovey | Permalink | Trackback