Tag Archives: lean

The Toyota Way: The need for doing it right the first time

Posted on by
Reply

After WWII Toyota started developing its Toyota Production System (TPS); which was identified as ‘Lean’ in the 1990s. Taiichi Ohno, Shigeo Shingo and Eiji Toyoda developed the system between 1948 and 1975. In the myth surrounding the system it was not inspired by the American automotive industry, but from a visit to American supermarkets, Ohno saw the supermarket as model for what he was trying to accomplish in the factor and perfect the Just-in-Time (JIT) production system. While accomplishing this low inventory levels were a key outcome of the TPS, and an important element of the philosophy behind its system is to work intelligently and eliminate waste so that only minimal inventory is needed.

As TPS and Lean have their own principles as outlined by Toyota:

  • Long-term Philosophy
  • Right process will produce the right results
  • Value to organization by developing people
  • Solving root problems drives organizational learning

As these principles were summed up and published by Toyota in 2001, by naming it “The Toyota Way 2001”. It consists the above named principles in two key areas: Continuous Improvement, and Respect for People.

the-toyota-way

The principles for a continuous improvement include establishing a long-term vision, working on challenges, continual innovation, and going to the source of the issue or problem. The principles relating to respect for people include ways of building respect and teamwork. When looking at the ALM all these principles come together in the ‘first time right’ approach already mentioned. And from Toyota’s view they were outlined as followed:

  • The right process will produce the right results
    • Create continuous process flow to bring problems to the surface.
    • Use the ‘pull’ system to avoid overproduction (kanban)
    • Level out the workload (heijunka).
    • Build a culture of stopping to fix problems, to get quality right from the first (jidoka)
  • Continuously solving root problems drives organizational learning
    • Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu);
    • Make decisions slowly by consensus, thoroughly considering all options (nemawashi); implement decisions rapidly;
    • Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen).

Let’s do it right now!

As the economy is changing and IT is more common sense throughout ore everyday life the need for good quality software products has never been this high. Software issues create bigger and bigger issues in our lives. Think about trains that cannot ride due to software issues, bank clients that have no access to their bank accounts, and people oversleeping because their alarm app didn’t work on their iPhone. As Capers Jones [Jones, 2011] states in his 2011 study that “software is blamed for more major business problems than any other man-made product” and that “poor quality has become one of the most expensive topics in human history”. The improvement of software quality is a key topic for all industries.

 Right the first time vs jidoka

In both TPS and Lean autonomation or jidoka are used. Autonomation can be described as ‘intelligent autonomation’, it means that when an abnormal situation arises the ‘machine’ stops and fix the abnormality. Autonomation prevents the production of defective products, eliminates overproduction, and focuses attention on understanding the problem and ensuring that it never recurs; a quality control process that applies the following four principles:

  • Detect the abnormality.
  • Stop.
  • Fix or correct the immediate condition.
  • Investigate the root cause and install a countermeasure.

Find defects as early as possible

In other words autonomation helps to get quality right the first time perfectly. With IT projects being different from the Toyota car production line, ‘perfectly’ may be a bit too much, but the process around quality assurance should be the same:

  • Find the defect.
  • Stop.
  • Fix or correct the error.
  • Investigate the root cause and take countermeasures.

The defect should be found as early as possible to be fixed as early as possible. And as with Lean and TPS the reason behind this is to make it possible to address the identification and correction of defects immediately in the process.

Business Quality with PointZERO; A next step in QA & Testing

Posted on by
1

Do you know what Insanity means? As Einstein once said it’s “Doing the same thing over and over again and expecting different results”.  I already said this in an earlier post, but it also fits here perfectly. And we’re being insane in IT quality today. Every year, money is thrown away by implementing bad software. It’s either lacks quality or the quality use is not practiced to get the highest quality against the least costs and still be flexible enough.

Sounds familiar isn’t it? Are you also struggling with the right balance in cost and quality?

Quality IT supports the Business in achieving business goals. Aspects in realizing shorter lead times, more flexibility, higher quality and lower cost are crucial. Quality Assurance and structured testing have been contributing to determining quality for years. Now we can increase this value and move to ‘Business Quality’.

PointZERO

With a new process around Business Quality to see three major movements in quality. By using technological opportunities, like TMap and TPI and Lean thinking we can industrialize quality activities.

When trying to start the quality process before the project even has started the business case is the driver of the IT project. All activities are evaluated against the business case, because by paying attention to quality as early as possible the greatest savings are achieved.

Integrating (future) SMART innovations into the whole process will help being quality driven from the very beginning of the project; once the business case is made, quality is part of the solution!

This all helps the Business to determine to what extent the described process is complete and accurate and effective solution to an identified business need; Business Quality is created, with PointZERO!

With this we van stop the insanity and proving Murphy wrong!

If you have any other ideas or the answer just let me know…

Lean MTP… (part 2)

Posted on by
2

This post is a continuation of my first post about a lean MTP. Last week I had my second two days in filling in the test strategy and finalising my MTP. But first the response I got of my project leader about the first concept I send him. He most of all missed the DSDM principle in there. When I read the document last week I realised he was right. I didn’t look enough at the DSDM products I had to produce instead of the normal test products. I realised I had it all in the document, but not in DSDM terms (I did have iterations stated in the testplan, but I don’t which yet).

Test products that are different from ‘normal’ are:

  • Business and Technical Testing Strategy part of the mastertestplan;
  • Test cases, scripts and charters are for the business process are part of the Business Testing Suite;
  • Test cases, scripts and charters are for the technical flow are part of the Technical Testing Suite, and
  • Test manager is a Technical Coordinator QA (not a product, but sits better here).

When I adjusted this in the document I had some interview sessions with users, functional service management, an analyst, the project leader ICT and Content and application management. I had to hold separate interviews because of the time challenge and not coinciding agendas of these persons. I asked everybody to think negative about where they think the application could fail (where they saw risks). On each answer I asked them what could go wrong (the risk of failure) and how bad this was. And what parts of the application of process should be tested and why (stating test goals).

The users, f and project leader Content were most interested in the process within and the performance of the application. They were also interested that the application shows the correct content in the application. The performance part was weird, because it wasn’t stated in the requirements. IT (project leader) and analyst had the greatest risks with the type of viewer that was to be integrated with the software. One viewer created higher risks for the program because nobody could work with it yet (it was new technology to them). Application Management didn’t have that many risks. Their main priority was to have a normal development cycle on the different environments (Development, Test, Acceptance and Production).

As of now I haven’t had much time to integrate the vision of the development team. Their team leader’s agenda hasn’t allowed us to talk, let alone summarise the risks.

After these interviews I tried to sort them out into a product risks analyses (PRA). I did:

  • At first I stated the test goals (including priority and quality characteristics for the test goals) and I matched them with everybody.

  • Then I sorted the results into the different processes and object parts of the product (they were stated in the documentation).

  • After this I matched the test goals with the different processes and their characteristics;

  • Next was the match between object parts and characteristics;

  • Per characteristic I assessed the damage for the processes;

  • Per characteristic I assessed the risk of failure for the object parts;

  • At last I integrated these last two to pick the risk classes.

Normally I have a workshop to do this PRA and we all take these steps in the workshop as a group. It’s easier this way to get a consensus, but due lack of time I had to improvise this option. After I processed the PRA I mailed it to everybody involved with a manual on how to read it. Some reacted on it and I needed to re-asses some values.

With this I could create my test strategy! And finalise my ‘lean mastertestplan’!