Mastering Embedded Systems

In the first session about root-cause analysis we have introduced the 5-Whys technique. It has its benefits, but also some severe disadvantages. As one of the most obvious ones the limitation on one root-cause can be highlighted.

In this episode the Ishikawa technique will be introduced. The Ishikawa-diagram could be assumed as the big brother of the small 5-Whys. The Ishikawa covers all the limitations of the 5-Whys and provides a great way to also handle multiple root-causes and more complicated effects. But it also has its disadvantages and pitfalls.

The Ishikawa-technique is a graphical approach combining both, Brainstorming and Mind-Mapping. It is a valuable technique for group sessions. You will be astonished how progressive and fast you achieve results using the Ishikawa-approach.

If you need to dig deeper in your root-cause finding, then you will sooner or later be confronted with Ishikawa. Take this episode as your personal guidance to get an instant understanding how the technique is done. Moreover take my experiences with Ishikawa to circumvent usual problems and overcome common obstacles.

This episode is about building, maintaining and distributing tools and operating system in large scale projects. With Robert Schiele an expert on all this kind of topics stays with me. He is senior specialist for developing OS-tools, providing toolchains and building operating systems.

Robert provides dedicated and verbose insights into the Linux Kernel and the Linux Operating System in particular. He’s one of the guys I know who is eagerly engaged into the OpenSource-community.

In his current role he maintains development tools and OpenSource components for a global mobile network supplier. His main task is to provide running build-systems, tool-chains, toolsets and root-filesystems.

He has seen and resolved a lot of problems when providing tools and operating systems. Especially for large scale systems and multiple hardware platforms in multi-site environments.

We’re talking about build-systems, root file systems, native and cross building.

All the day you might run into the situation to explain problems, defects, situations or environment. Very often your listener or the audience is not aware of the underlying technical details. Or they do not have the knowledge to understand the details at all.

This episode tells you 6 ways to struggle for sure with all of your explanations. But it also shows you an approved ways to convert even very complicated nerd details into an understandable manner.

Be sure that you struggle

If you want to ensure your failure follow these six behaviors:

If you follow at least half of them you can be assured that your description of the situation will not be understood by anybody outside of your knowledge. A perfect way to stay inside of your cage of expertise.

However, if you want to provide better descriptions, more understandable reports or you simply want to be understood if your run into problems, then have a look at the next paragraph.

People understand stories. People like stories. And people like comparisons. If you start to describe your situation with a picture, then that’s already a big step forward. A picture is worth a thousand words. But the problem might be to find the right picture. Or to strip down the picture to the very basics the audience gets the point of your problem.

A different approach, I reguarly prefer, is a metaphor. A metaphor is a comparison which does not emphasize the differences, but the similiarities. That means you pick and idea out of your experience. This idea should be common to your audience, too. Then you compose a story or the comparison around this idea to explain the much more complicated other situation or problem.

The essential point is that you have understood the pattern or the skeleton of your situation. You need to abstract this pattern and look for similiarities to find an appropriate metaphor.

Let’s assume you have drawn out this pattern. Then you can use the following anchor-points to find the story for your metaphor:

With every approach, with every tail, with every explanation, your audience will grasp a little bit more of the original topic. Thus any failing metaphor is also an indication that your audience gets more specific and closer to the subject.

You need to excercise a lot to tell metaphors quickly. It’s a lot about fantasy, but it’s also a lot about extracting the pattern of the situation. You need to lift yourself onto a meta-level of the situation’s description that you can use metaphor’s gracefully. Excercise a lot. Throw away metaphors as quickly as needed. Try another one. Your audience will be happy to see your effort and your eagerness to let them understand.

This is the vacation episode. Recorded on my way to the beach of Moliets-et-Maa.

Moliets-et-Maa is a small village in south-west of France. It’s situated close to the Atlantic sea. Roundabout 120 km south of Bordeaux and 50 kilometres north of Biarritz. It’s a surfer’s spot and offers a 9- and 18-hole golf course. We love it due to the great sea view, the wide beach and the lovely weather conditions.

It’s also my 10th episode and therefore time for a short celebration. Hoorray. Okay, that’s enough.

I wanted to give you a short insight how the episodes of this podcast are meanwhile produced. You will learn about planning an episode. The way it is recorded. And the details about post-processing and releasing. Finally I will add some details about promotion.

Enjoy!

Remember your last sickness. Caught a cold or a flew? Weren’t you only curing the symptoms? Usually nobody cares for the real reasons when getting ill with these small diseases. But there are lots of persons who are able to somehow avoid any disease. What’s the difference? Why were you felt sick?

It’s like weeding your garden. Very often only the symptoms are cured, but no real solution can be achieved. The weed gets back soon. Removing the root would do the job,

Within the business context regularly the management requests an immediate, complete, fast and reliable solution of problems. But is that possible without finding the real cause of a problem? Without fixing the real cause of a problem it might pop the same way again as the weed does.

That’s the ideas of root cause analysis. Dive deeper into a problem to find the real underlying cause of the problem. The diving should be that deep to find not only a cause, but the process which is failing or is insufficient

This episode is about the first and basic technique of finding the real root cause of a problem: the 5-Whys technique

The 5-Whys is a technique first time introduced by Toyota within the Toyota Production System (TPS). It is an iterative question-asking technique to explore the cause-and-effect relationship underlying a particular problem.

The technique belongs to repeating the question “Why?”. Each question forms the basics of the next question. The “5” in the name derives from an empirical observation on the number of iterations, which is typically required to find the real cause of a problem – the root cause.

The idea of 5-Whys is to dig deeper. But it’s even more. It not only stupidly asking Why, Why, Why again and again. It’s a change in the paradigm of evaluating the cause of a problem by not getting stucked with the symptoms. It’s like unveiling an onion. You work from one shell to the other until you come to the nucleus.

The 5-Whys technique has several benefits:

The 5-Whys is most useful for problems involving human factors and interactions, like handling, reactive, planning, or design problem. However complex problems might benefit from a more detailed approach. Hereby the 5-Whys can deliver useful insights.

The 5-Whys technique has several disadvantages and is under critique for:

Nevertheless “5-Whys” is a great tool to start with the root-cause analysis. It is fast, in an elaborated hand very effective and therefore efficient in an outstanding way.

To improve your understanding of how to do the 5-Whys I have these 3 steps to follow:

Start with a description of the problem by providing answers on these questions:

Best thing first is to invite for a meeting to start the 5-Whys questioning

First you should define a 5-Whys master or moderator. This should be an elaborated person who is able to work on a meta-level of the outstanding communication. It should not be one of the major stakeholders, if he have the tendency to fell blamed for what has happened.

Especially the last step is the most essential one. This changes your perspective from symptoms and easy causes towards a general view. This is the starting point of real improvement. Knowing the failed process is a cornerstone in becoming really better.

If you have digged out one or multiple root-causes for your problem, then summarize the results:

Please be aware that the 5-Whys are simple in concept but sometimes tricky in reality. The following 3 aspects are essential to keep an eye on:

5-Whys are living from experience and excercise. Don’t be impatient if the result is not that good in the first usage. Using it continuously will give you the expertise to do it quicker and more elegant. Don’t hesitate to improve!

Before you start running a task-force you will have a short moment or phase of planning and launching it. You should use this time carefully and wisely. Potential flaws during this phase might be a constant burden over the whole run-time of the task-force. I’ll show you the questions and the actions you need to successfully launch your task-force.

The launch or kick-off phase of a task-force is like the take-off of an airplane. Even it takes off the conditions might be not good and the overall journey might have started already under a bad star.

The following three actions shall support you in your intention to launch a task-force successfully.

You need to define the objectives and the needed resources for the task-force. Use the SMART-criteria to define the goals and targets of your task-force.

This is the major part of your preparation action for the task-force. There are three different parts you need to have an eye on:

Your task-force should be schedule on a rule of thumb once per day. Usually you do not need more. However if there are extraordinary circumstances or outcomes, then it might be needed to meet more often. For example testing unveiled totally different results of the situation. Or you have team-members in two time-zones that far apart they do not meet each others during regular working hours.

Over the years I collected some details which should be contained in an informative invitation. Follow my Meeting invitation template to provide a meaningful invitation. Please remember that your task-force members will be more willing and more supportive if they immediately understand the purpose and the situation.

During the launch phase you usually run into two different limitations:

For the first my preferred way of working is to decide. If it is not possible from your perspective to fulfill the work without the person you need, decline the task-force. If you do not get the needed expert, but you see a chance to achieve the goal, then accept. But request to get access to the expert on demand. Or accept a substitute which has direct access to the expert. With both approaches I have made good results.

For the second and if it is totally out of mind, decline the task-force also. An unrealistic approach needs to be highlighted in such situations. However if it is realistic, then accept with restrictions. Outline crystal clear what you can achieve with the limitations. To provide such statement reliably you need to have a deep insight view of the problem.

Marcus and me joined the IoT-TechDay in Frankfurt end of June. The IoT-TechDay was a one day conference organized by WindRiver, Intel, SalesForce, SAP, Accenture and Microsoft. The intention of meeting was “Moving from talk to transformation” creating business opportunities around IoT.

Marcus is a wholehearted engineer and Product Design Director at SAP in Walldorf, Germany. He’s responsible for evaluating the potential of IoT and finding product ideas and opportunities for SAP. On the other side he was and is an engaged engineer within Embedded Systems. This combination made me curious and we have had a good talk already at the IoT-TechDay and later on by mail. Our opinions about IoT and it’s potential, risks and challenges are not always the same. But that makes this talk even more exciting. Enjoy the episode.

The term came into extensive use originally by the United States Navy around the beginning of 1941, as a way to increase operational flexibility. The fleet itself was divided into division and squadrons. A task force can be assembled using ships from different divisions and squadrons, without requiring a formal and permanent fleet reorganization, and can be easily dissolved following completion of the operational task

Nowadays task-force is something different, no longer using the military speech:

Task-forces are regularly established in project management when:

Task-forces stumble mainly due to three different reasons:

In all the different approaches to do work with teams, the task-forces are the strongest way to proceed. You have great chances for rapid progress, you have best heads in the team, and good chance for successful outcome. However you also have to face the disadvantages that task-forces distract from regular work, consumes a lot of (company) energy, and it’s working across hierarchies might be taken as anarchic way of action

Especially as in some organizations task-forces are established too often, their effectiveness gets lost quite soon as they become regular.

The previously mentioned task-force charter should contain the following topics and need to be agreed by everybody engaged into the task-force:

My list of 5 tips to make your task-force successful:

Give you task-force a unique name that it is distinguishable from other ongoing activities. And stick with this name until the end. There’s nothing more worse than renaming the activities without real need.

Less is beautiful. Take as less persons as possible into the task-force, however as much as needed.

Give clear structure to your task-force members. These guys needs to concentrate on resolving the issues. A good structure gives them a solid harness they can concentrate on the essentials.

It’s essential that agreed rules are also checked and enforced it they are not followed. Make this point clear in the agreement session. Therefore as less rules as better.

Laugh and have fun with the guys without loosing your focus on the goals of the task-force. This kind of relaxing and cheerful talk and appearance might decide whether your task-force sustains or gets lost in all day trouble.

The next episodes within this mini-series about Task-Force‘ing

If you already have your preferred solution how to prevent being trapped in such projects – let me know. I do appreciate all of your contributions.

[saf feature=”email” cta=”Let me know your way”]

There are a lot of reasons why a project might run into trouble and most project problems are indicated by specific symptoms. Problems of projects are often caused by changes in leadership, company organization or the company itself. All of them create FUD – Fear, Uncertainty, Doubt. As a result we see inappropriate planning, schedule, staffing, and tons of other issues.

The reasons for project trouble might be impacted by you or not. From the outside key signs are very often rather clear. But very often they cannot be detected from the inside. Within daily work-load, unaware of changes in environment or the company, with lots of rookies in place, critical symptoms are not recognized or misinterpreted. There are always warning signs – the flashing yellow light indicating that a red light will follow.

This episode is about the key-symptoms I have detected during my career indicating that a project is in trouble. They do not mean that the project will fail, but they indicate that there’s something going wrong definitely. And they highlight that additional attention is needed – either to fix them or to escape them. This episode is about this very first step – the symptoms.

I followed a variation of the Ishikawa-method to categorize the different symptoms. This gives us the opportunity to see the bigger picture. But it does not mean that the different symptoms could not be summarized under a different category.

I want to follow up these questions in one of the following episodes. Stay tuned.

[saf feature=”email” cta=”Let me know your way”]

I’d love to hear from you about what’s your detection and experience with project failing symptoms. Please comment here in the show notes and let me know what you think.

Zero-faults strategy means that there are no faults accepted in the delivered product. Or at least only a very minimum amount of failures with low priority. Regular for medical devices, avionics, spaceflight. But is it really necessary for other industries? The zero fault phase might start anytime before the near customer delivery.

You can take the following actions in a short-run:

And these are my proposed actions for the long-run:

To mitigate or handle the effects of zero-fault targets you may take the following actions: