The manager slams a door and tells us that we are in a big trouble. Our old customers complain about many bugs and bad performance, new customers complain about delays and lack of dedication. And, top management considers our department financially unsustainable and wants to deeply cut expenses.
The manager tells that we are brilliant programmers, work very hard and create cool software solutions. But there is something wrong and we cannot work this way anymore.

Anxiety started to penetrate our souls. We know what is wrong: our team is short of people, we have too many commitments, our code is becoming a big mess, new technology and our new software version makes something bad with servers. A snowball of different problems makes us stressed, distracted and incapable of productive work.

What could our manager do next?

1. Distrust. Become a dictator, make own decisions including hiring external consultants to recommend what to do or even replace us. However,
   • we are good programmers and know our business well – the problem is not in lack of skill and knowledge
   • external people will take a lot of time to understand the system and they will have different motivation and won’t care about the long-term success
   • people will be demotivated and the manager cannot make effective decisions without active team involvement
2. Faith. Give to team the full power to fix a problems and make own decisions in hope that smart people, motivation and technical expertise will do magic. However,
   • fresh outlook and thinking out of box are hard when a team immersed for a long time into difficult situation
   • a team possibly doesn’t have understanding and control over external forces – management, customers, finances
   • changing of reality is tough (especially in people heads) and requires more than technical experience

There is a third way. Place improvement practices in the core of development process. Make self-improvement inevitable and required for any activity. Do it every day.

Toyota Way is the best example of large-scale reliable self-improvement process. It focuses on eliminating waste, solving problems at root cause and making right decisions. Toyota Way reduces problems, increases internal efficiency and makes a company successful. This is the best receipt for coming out of crisis.

Targets:

• Problems – emergencies, fires that require immediate fix: bugs, server crushes, deadline slips

• Waste – inefficient and non-value adding activities: waiting, misinformation, stress

• Challenges – adaptation to external forces (market, competitors, customers, society): new trends and technologies, changes in users expectations for user interface and functionality

Practices to see waste and stop to fix problems

1. Seeing waste

The team and managers should learn to see targets – real problems and waste. Otherwise improvements will be wild shots in the dark.

There are many targets in software development:

• stressed people – reduced energy, less productivity, more mistakes
• waiting – delays, tools / system problems and downtime, capacity bottlenecks (waiting for results of other people work)
• over-engineering – producing features and complicate design without real need
• unfinished work – functionality not used in a live system, probably still in design or under development or simply discarded (but not removed)
• defects – complete waste of time and money
• unused creativity – loosing time, ideas, skills, improvements and learning by not engaging or listening to your employees
• inadequate information – unclear, misleading or simply wrong information that causes useless activity and leads to rework at the end

• over-processing – taking unneeded steps to build software because of poor process and system design, overhead, bureaucracy, compliance, cumbersome tools
• motion – how much effort to get necessary information, access systems or use tools
• multi-tasking – losing time to switch between projects, tasks or different activities

2. Jidoka – stop to fix the problem to get quality right the first time

It is not enough to see your targets. The Team should carry commandment to shoot targets immediately. Otherwise the best intentions will be buried under growing avalanche of problems.

How to stop:

• quality for the customer drives all the processes – prevents temporary patches and bad for quality decisions
• low tolerance for quality problems and immediate detection are core work principle
• use Andon – a system to signal for help, notify about a problem and stop the process

• build in tools and process capabilities of detecting problems and stopping itself
• use all modern QA methods available
• managers encourage stops to fix problems and support implementation of counter measures

Making Decisions

“Make decisions slowly by consensus and thoroughly considering all options, implement rapidly.“ – Toyota Way

Even knowing problems and committed to solve them, the Team should make right decisions how to do it.

Make decisions slowly

1. Go and See (Genchi Genbutsu)
2. Understand underlying causes (Kaizen)
3. Broadly consider alternative solutions and develop a detailed rationale for preferred solution delaying certain decision as long as possible (Set-Based concurrent engineering)
4. Build consensus within a team and partners where group decision is preferred (while management can step in if consensus is not achieved)
5. Use very efficient communication devices – preferably one side of one sheet of paper

Implement rapidly

1. Put in place solutions and counter measures.
2. Evaluate the results
3. Standardize if solution is effective.

Practices to Eliminate Waste and Solve Problems

3. Genchi Genbutsu – go and see for yourself to thoroughly understand situation

How often do we jump to conclusion based on partial information, vague assumptions and what other people say? Information creates reality in your mind. This reality is a base for your decisions. So, you and the Team should get right information to make right decisions:

• observe situation with blank mind
• avoid assumptions and preconceptions
• use personally verified information

In short, base decisions on what really is going on

4. Kaizen (5 why’s) -continuous learning and improvement

“We view errors as opportunities for learning” – Toyota Way
The Team should find the root causes of the problems. Kaizen helps to find the root cause by repeatedly asking why the problem occurs.

Example of Kaizen
Problem: there are persistent javascript errors on a live site

1. Why? A developer didn’t build correct logic for complex web UI components interaction
2. Why? A developer built own solution without guidance and enough experience in this area
3. Why? A team expert didn’t tell about existing proven solutions, didn’t help and didn’t share knowledge
4. Why? The team is under stress, over-committed and don’t have time to communicate
5. Why? Managers accept too much work without consulting with development team
6. Why? you can continue…

Kaizen forces us to overcome desire to find a first convenient explanation and patch problems without fixing root causes. By ruthlessly applying this practice, we get deeper insight into reality and better learn our product, processes, people, environment and tools. Kaizen is a core practice to see waste, solve problems and improve process.

To avoid forgetting learning from Kaizen, it is important to standardize the improved process and make it a base for further improvements.

Practices to Support Flow

5. Standards – best you know today which is to be improved tomorrow

Standardized work is easier, cheaper and faster – stable repeatable methods can maintain predictability, high productivity and support quality.
Effective standards are not coming from theories, they come from

• best practices
• accumulated learnings and individual experience
• lessons from applying existing standards

The Team should try to use standards in many areas: project phases and activities; development practices; architecture and design approaches; code conventions; tools; programming techniques; libraries and third-party code; reuse of components and solutions; testing and so on.
Standardization in software development is a controversial topic – some theorists want to bring programming closer to standard-dominated engineering, practitioners are keen to reduce standardization to minimum promoting creativity and self-organization. In the rigid interpretation, standards are “must to follow” rules for any situation, in other interpretation standards are well defined steps and guidelines highly recommended for specific context. I support the latter definition. A productive team should have standards in place to focus on customer needs instead of fighting with the same puzzles and problems over and over again.

The system of standards shouldn’t be a heavy bureaucratic conduit, but a light and fluid book of knowledge. The book that contains most helpful and important rules and checklists. Standards will be effective if they are minimal, reviewed often (Kaizen) and followed by every team member.

6. Reliable thoroughly tested technology

The Team should be conservative with new technologies. Software development and IT thrive on change and innovation. However, Toyota Way suggests to be conservative in adapting technology and considers stability and reliability of operations as much more important goal than keeping on the cutting edge of technology.

Considerations for using technology

• primary goal is to improve flow and support people, process and values.
• process is driven by business, not technology concerns; software and tools do not eliminate themselves waste
• technology is visual and intuitive – people can use it correctly and effectively

• process manually before adapting technology to support the process – understand what problems it solves and how technology could help
• important: people / processes are easy to Kaizen, machines are difficult

Adopting new technology:

• new technology is unreliable and difficult to standardize, therefore it endangers flow
• proven process takes precedence over new and untested technology
• conduct actual tests before adapting new technology
• reject technology if it conflicts with culture or might disrupt stability, reliability and predictability

In the same time encourage people to consider new technologies while looking into new approaches. If technology improves process and flow – quickly implement after thorough testing.

7. Visual Controls

The Team should have clear status of information. Visual controls can convey complex information in fast and efficient for our brains way. We can use controls as a user story board; status of projects, servers or code build; burn down charts and others.
Simple visual indicators help people determine immediately whether they are deviating from the standards, provide quick gist of situation and direction for solving problems.

• use simple and most important indicators

• than provide clear picture for decisions and what to do next
• reduce reports to one screen / piece of paper even for the most important decisions

People, leaders and teams

8. People

People who build software are the people who should improve the process. They are directly involved and have first-hand experience of problems and waste.

Toyota Way expects that each team member is a problem solver and values job experience more than theoretical knowledge. The Team will beat any external consultants and find better way to work if people are open about problems and eager to find good solutions.

9. Leaders

The Team desperately needs strong leaders to build great products to overcome problems. Toyota grows leaders within who thoroughly understand the work, live the philosophy and must understand the daily work in great details

Chief Engineer is a key person in Toyota projects.:

• blessed by top management
• has control over project
• exceptional engineer
• critical link: between engineers and customer satisfaction
• coach for other engineers
• focus on concepts first, technicalities later

Chief Engineer concept is an excellent example for software technical leadership. A software team leader often lacks authority or makes too technical decisions without good understanding of customer needs.

10. Teams

The Team should be diverse and capable of solving wide range of problems. Toyota builds cross functional product teams, which

• use integrative decision making
• fast and accurate in implementation
• enhance process and flow by solving difficult technological problems

Software developers and their leaders are foundation of success in any project. Management, process and technology can only support them. And anyway, the process is as good as people follow it. Therefore, it is important to make software teams a key player in process improvements – they know problems, they understand work and they are capable to find good solutions.

Using Toyota Way

Can The Team revert a situation and win? Can it build the optimal process and expertise for fast development of high quality and low cost solutions?

This post shows the most effective option – build continuously improving process into the heart of development. The process that focuses on quality, eliminates waste and fixes problems at root cause. I believe this approach is a foundation of long term success. Your managers and company would love it!

Posted by Andriy Solovey | Permalink | Trackback