Mastering Embedded Systems

The man with the "Leadership Mind" - Bernd Geropp - MES054

Day 2 of the Embedded World - MES053

Day 1 of the Embedded World - MES052

Year's-End Wrap-Up 2016 - MES051

The ESE-Kongress in Sindelfingen. More than 1.300 participants! 100 presentations! 3 days with 4 streams in parallel! Amazing! The German Embedded Software Engineering Kongress is the second largest gathering of Embedded specialists in Europe. I gave my debut presentation with "No belly-flops with virtual teams". But there are about 100 other presentations in 4 parallel streams on three days. From 29th, November until 1st, December people belonging to the Embedded realm has their gathering in Sindelfingen. It's a great happening with interesting persons presenting stunning talks, new topics and detailed insights.

You were misunderstood. Although you have spent a lot of effort to be precise and clear. But nevertheless somehow your counterpart has horribly misunderstood you. And now you're in big trouble. Perhaps your spouse interpreted your "Nice" for the new dress as inadequate. Or there was this tone of desinterest in your voice. Or you just run into this ugly problem at work and your mind is still in the office. You all remember what happens after such situation. Something has gone wrong. How can we avoid such kind of situation? Everything we say OR not say, everything we do OR not do, transfers a message. We cannot decide whether we communicate or do not communicate. We always communicate. Communication happens verbally and non-verbally, explicitely and implicitely. We should be aware that a risen eyebrow, a turn-away face, a dismissive look transfers information to the receiver. You guys should listen to this episode if you want to understand why communicating could sometimes be that complicated, erroneous or misleading. If you want to improve your skills herein you're exactly right in this session. If you want to get the tips in written form, feel free to use the link below to get your personal copy of the tips-list.

It's a pity. That most of us find their best time in staying in their Comfort Zone. In this hammock of our regular habits. Full of cosy feelings, thoughts and emotions. Of course, we all have our regular habits, the routins. In the morning in the bathroom or in the evening going to bed. We also follow our inner boosters telling us to be perfect, punctual, or push ourselves and hurry up. But it's really sad, that we regularly get stuck in this zone. Our Comfort Zone is supposed to keep our life safe. But what it really does is keep our life small. Outside of our comfort zone there seems to be lot of interesting amazing things. Possibilities without end. But it's outside. And before we can get in touch with these endless possibilities, we have to tackle the wall of pain. Lots of pain are waiting: denial, uncertainty, helplessness or fear. There's a way to overcome this wall. But first you need to understand the paradoxon of pain. In this episode I wanted to share with you a tool I have detected some time ago. The Tool "Reversal of Desire" was introduced by Phil Stutz and Barry Michels. And it is their gift to all of us who want to lift ourselves to the next level. A tool to propell you out of your comfort zone. That you get in touch with your possibilities overcoming the pain.

This is the first episode of my mini-series "Improve Yourself". This series is based on the results of my last survey on my podcast listeners. We'll start today with the episode of Time-Management. Is it really possible to manage time? To do Time-Management? I do not think so. Because time is something we cannot impact or manipulate. The only thing we can do is to change our way to experience time passing by. And this change of perspective drops away all these usual Time-Management tools, books, courses, hints and tricks. But you get confronted with yourself. Everybody of us lives in the same time. But some of us seem to have sufficient time. Others seem to always exceed their amount and do not succeed in time. The question is: why is it like that? And what can we do as individuals to get the best out of our time? This episode will support you here. Detect your next steps to realize things which are really important to you. And then start. Stay tuned and be inspired.

Do you have ever thought about the aftermath for your root cause analysis? What should be done if you have found real cause of your problem? What do you regularly do after you have made your correction? By the way - do you know whether your correction really corrects the problem? That it only corrects the problem? And does not introduce a ton of new problems? In this episode it's all about what's coming after the problem's analysis.

Sometimes people ask me: "What's that about project troubleshooting? What does it mean? What are you guys doing? Who does anybody need this kind of stuff? And what's the benefit at the end?" I want to provide some answers on these question. I have invited a friend of mine, who has done this kind of work for roughly ten years. Maik Pfingsten is an elaborated engineer, a versatile project leader and he has saved a lot of projects under rough conditions. He meanwhile works as mentor, speaker, author and coach for specific topics round about projects in trouble. He tells us a lot about his very personal way of coping with projects in trouble. About the regular steps he has used and the experiences he has gathered during his long journey. This episode will support you in understanding the different steps how derailed projects might find their way out of trouble. What kind of essentials you have to take into account. And perhaps also whether this approach is the right one for you, your project or your company.

Right before my holiday I have made a bad experience. Some meetings with a vendor have gone sub-optimal to say the least. There were several road blocks and nit-picking details which brought the meetings close to waste of time. However it was a good opportunity to observe what could be done much more better when talking with vendors for technical problems. I have run a lot of such talks and I wanted to take this bad situation as trigger to collect my 5 hacks to get the most out of vendor discussions.

Tech Chat: What QRAcorp can do for your requirements? - MES043

In episode #38 I have already had the pleasure to welcome Joachim Reinke. Joachim is an expert in requirements engineering. In episode 38 he explained the reasons why we definitely need requirements engineering. And today I'm happy that we managed to continue our talk. We're discussing the big pain points in Requirements Engineering. And how it is possible to relief this pain. But we also needed to back up a little bit to grab the bigger picture. First we identified the main points in Requirements Engineering. In a second step we jumped into the details how to select an appropriate tool to support you in maintaining requirements. It's not that easy to find the right tool. Because there a several aspects you need to consider. For example you will regularly not establish such a tool on the greenfield. There will be environmental conditions, limitations and constraints which might bother you. And here's Joachim's list of 9 important bullets when selecting a RE-tool will become very helpful.

And here we are with the third and last part of how to survive Death March Projects. In episode #37 we have talked about how to define and detect Death March projects. And about your decision whether to leave or stay. In episode #39 we have tackled the kind of actions you will face if you want to bring such a project to a good end. We have talked about politics and negotiations. About rational negotiations and negotiation games you should know. And how to identify accetable trade-offs or what to do if all negotiations fail. Episode #40 was about people. How to hire for Death March projects. How to achieve loyalty, commitment and accountability. And the major aspects of communication and team-building. Finally in this episode I'll present you some very important processes you should know if you find yourself in a Death March project. And I wanted to highlight tools and technologies which might become handsome for the success of your Death March project, too.

In the last episode I have mentioned how important negotiations become in maintaining a Death March project. Today we're focussing on another aspect: How to gather the right people in your project? Especially in Death March projects your surrounding team mates might become the only persons you see for a very long time. Insist on having the right persons in your team. Expect overtime hours, but remember always that you've a long way to go. And at the very end you should have enough power to sprint for the last 100 meters. Taking care for people is an essential part to be successful in running projects. For Death March projects however it is an absolute must to do it. Besides all technical knowledge, besides all negotiations, you need to have loyal, cohesive, and cooperative team with you. In this episode I will highlight some essentials when working with people in critical projects.

Hopefully you guys remember Episode 37 Hopefully you guys remember episode 37. We talked about Death March projects. How to identify them. What their characteristics are. The reasons they happen. And about your decision to stay for them. Episode 37 was the introduction. This new episode starts to emphasize the four major aspects how to survive a Death March project. In this context surviving more means to stay psychologially unharmed than physically shattered. Regularly these four aspects appear in certain combinations. That's the reason you need to know all four of them to get the whole picture. Today I will present you the first of these aspects. We're talking about negotiations in Death March projects. There are not only rational negotiations - the one you might know from your daily life. But there are also negotiation games and special trade-offs to put your free. In a first I will give you some additional support to make your decision whether to stay or leave a Death March project at all.

"We do not need specificiation because our product is its own specification!" You know such kind of statements? You suffer from such kind of attitudes? Then you're exactly right in this tech-chat with Joachim Reinke. Joachim is an elaborated specialist for such kind of hassle. He is an engineer who specialized in the area of Requirements Engineering. He's a crack in this area of the development and production process. We both got acquainted at the systems camp 2016 in Berlin. Requirements engineering refers to defining, documenting and maintaining requirements to the sub-fields of systems engineering and software engineering. But the major question is - why does it seem that neglected in real development life. We're discussing a lot about these aspects. The benefits you get out of well done requirements engineering are tremendous. But it's also a quite long way to go. However also the longest way starts with the first step. In this episode we're giving you the path to do the first steps and continue successfully. Stay with me and enjoy the chat.

Already at the very beginning of this podcast, in episode 5 I have talked about projects in problems. In this former episode I have talked about the warning signs if your project runs into trouble. Everybody of us has some kind of understanding the term "Death March". It's from the military indicating a task you have a good chance to not stay alive. And the same could be, if you take projects in civil life in which the project members are working 13-14 hours each day, 6-7 days per week, for months. There is a good chance to lose people. But there's also a good chance to fail the project itself. I wanted to explain how exactly a "Death March" project looks like. How you can identify it. And what general decision you have to make if you face a Death March project. Due to the bare amount of information I have to split this topic into two episodes. In the second one you will finally get a general guidance how to tackle "Death March" projects.

You know such kind of story - everybody is talking about security, but not really everybody knows what it effectively means. Especially security in Embedded Systems has become a valid topic in the last years. My today's guest has an intimate knowledge about all kind of aspects of security for Embedded Devices. I wanted to welcome Andrey Nikishin from Kaspersky Labs. Many of you will remember Kaspersky Labs as one of the main competitors in providing anti-virus software. However they have become much more. Andrey describes himself as evangelist of new technologies and new business directions. As an expert for cyber security he is working very closely with Kaspersky OS - an operating system designed for security from scratch. I got in touch with Andrey at the Embedded World in Nuremberg. I've seen their booth and initially thought: "What does the manufacturer of anti-virus software do at such exhibition?" I was so wrong! The threats towards security and integrity of embedded devices has grown heavily over the last decade. But that's only one aspect. The other side of the medal are the ubiquitously available small embedded devices connected via the Internet. The bare amount of embedded systems in all parts of our life has dramatically increased during the last years. And they will still grow for the next decades. Stay with me and enjoy the chat.

Taking minutes can be some real awkward story. But using Mind-Maps it gets more natural, more fluent, and more precise. But, doing it that way, I detected during running consecutive task-force meetings, that the Mind-Map approach is not that stringent. It needed some tweaks to get its real harmony and fluency. And this episode is about the five major tricks I have found during the last months when using Mind-Maps for taking meeting minutes.

Today we're talking about Virtualization in Embedded Systems. This is particularly different from host-based virtualization. For that reason I wanted to welcome major experts in this special area: Baurzhan Ismagulov and Alexander Smirnov from Ilbers - Technology for better life. Ilbers provides Mango - a bare-metal Type 1 hypervisor. If you do not understand a word what this means - jump back to the previous episode #33 of the MES-podcast Combining the Uncombinable and fill up your missing knowledge. Mango was nominated for the Embedded Award 2015 at the Embedded World exhibition in Nuremberg. They have created a great piece of software which will provide a lot of benefit into embedded projects.

Today's episode is an introduction episode. It's introducing into the topic of the next episode. We've tackling the big topic of Virtualization. Virtualizing is in. Everybody, everythings seems to be in some way virtualized. But what does it really mean? At least in the context of IT it definitely means something different as in day-by-day usage. In this episode I'll give you the big overview and dive a little bit into some details. Details you should know when talking about virtualization on computer-systems.

Today I wanted to talk about deadline pressure. Everybody of us might have some experience with these special working conditions. There's a deadline - and you have to achieve it.

Today it's up to Jeronimo Castrillon-Mazo. We got acquainted at the Embedded World 2016 in Nuremberg. He is co-founder and adviser at Silexica. They have won the Embedded Award 2015 in the Tools-category for SLX MultiCore Toolsuite. That drives me to visit their booth. Having an amazing talk I asked Jeronimo to appear in this podcast. Let's have some tech-chat, widen the topic and enlarge the audience for this interesting topic. Jeronimo has studied Electrical Engineering in Colombia, achieved his Master-degree at ALaRI-institute in Lugano, Switzerland. He has made his Ph.D. 2013 at the well known RWTH Aachen. In 2014 Jeronimo joined the department of computer science of the TU Dresden as professor for compiler construction. He has a proven track record of multi- and many-core programming. Moreover he is known as specialist within the realm of automatic code generation. Nowadays we have tons of single-core based legacy code. In parallel multicore hardware platforms have overtaken. Usually software for multicore needs to be designed manually. What might happen if the amount of cores still increases in future? How shall we handle existing code bases? Migrate all of them manually? Or might there be automatica ways to move towards multicore structures? And how can we improve software design for multicore deployment? For all of that the SLX MultiCore Toolsuite's solutions will support. We're discussing the benefits a tool has instead of redesigning code manually for multicore systems. We dive into the models and operations necessary to paralellize existing code. We identify user-stories and we mention tricky pitfalls. Jeronimo unveils details of automatic code-analysis and problems solved to provide a tool like SLX MultiCore. Stay with me and enjoy the chat.

A short review about my visit to the Embedded World 2016 last week in Nuremberg. This episode is for all of you who haven’t had the chance to visit the Embedded World. I wanted to introduce you for a virtual walk. Join with me some interesting booths and see the big players

In the first two sessions about root-cause-analysis I have introduced the 5-Whys and the Ishikawa techniques. Both have their pros and cons. For a long time I was looking for a better way to provide root cause analysis. More sophisticated than the 5-Whys, but not that compilicated and elaborate as the Ishikawa. And hereby I come across with an enhanced version of the regular Cause-Effect approach. It's again a graphical approach which combines simplicity and logic. It's especially useful for situations in which multiple goals are affected. The way to evaluate root-causes using the enhanced cause-effect is my preferred way. And that's due to two reasons. First, it's rather progressive and can be driven alone or in groups. You achieve quick results without spending too much effort into nasty categorizations or simplifications. Second, in it's final stage provided as a diagram, it can be quickly and fully understood. You do not need verbose explanations how to read it or why some things have been dropped. Stay tuned and be inspired.

Embedded Systems without logging is a pain. But with logging it's very often a desaster, too. I wanted to present you my thoughts how to improve logging. It's not for the super experts knowing everything and every detail of your system by heart. But it's for all the regular engineers out there who are facing a failing system. A system providing either nothing or an awful lot of superfluous information. What if you would introduce an indicator describing the system's healthiness. Something what would highlight an immediate status of the system: healthy or unhealthy. Stable or unstable. Reliable or doomed. The system-healthiness indicator needs much effort before you can use it. But it will be a walk in the park afterwards. No longer fears of uncommon errors. No longer daylong investigation to find the failing parts in your system. Stay tuned and be inspired.

Today I'm happy to introduce you another presenter of the Embedded Testing conference in Munich. I got acquainted with Oleg Nenashev already in the first minutes of the conference. We're sitting aside of each other. He was working for his Jenkins presentation. Oleg is a 27 year old engineer from St. Petersburg in Russia. Although he has started as a hardware-engineer he's mainly engaged on the software side. With his presentation Integrating Jenkins with verification flows of Embedded Systems he has introduced himself as Jenkins specialist. He's currently working for CloudBees in Neufchâtel in Switzerland. Although I was in touch with Hudson and later on with Jenkins, I never get that deep inside of it. In contrary Oleg has become responsible for testing hardware in an automatized way already in 2008. He get in touch with Jenkins from the very beginning. Later he provided several plugins before he gots elected as core-developer. Meanwhile Jenkins has more than 1000 plugins. And it has undergone a redefinition from a pure Continuous-Integration tool towards a more general, more framework like automation server. The time we recorded this interview Oleg stayed in St. Petersburg. He has just finished his PhD-thesis and was in a quite relaxed mood. In our discussion we're highlighting the way of Jenkins development. We stress the chances and challenges. Why someone should use it. And the struggles you might run into. We also talk about the newest changes in its self-understanding. And Oleg provides an outview what we can expect from the next major release. Jenkins 2.0 will cover mainly architectural needs, especially from User-Interface-perspective, which have been recognized and accumulated during the last years. Stay with me and enjoy the interview.

Hi fellows, I wanted to welcome you in 2016. Hopefully you have survived all the holiday stress, the good food, the sometimes stressful family gatherings. And perhaps you have also taken your New Year's resolutions into mind and into heart. I have done my homework - not fully, but most part of it. 25 episodes done; half of a year. Time for making a review. What has gone fine? What has gone wrong? Where is the direction? What was the feedback? Am I still on course? These questions came into my mind during the last two weeks. Today's episode is about all that. And about the next steps of this podcast. About its future and the direction. About details and then big picture. Stay with me and see what's in for you.

It's an ever lasting story in Embedded Systems: Integrate hardware and software. You need to combine a new piece of hardware together with new software. That's the time you need engineers like my today's guest - Jürgen Salm. Jürgen has a proven track of experience as SW-developer. He's running his own zoo of Unix- and Linux-machines at his home-place. At work however he's engaged as SW-tester and mainly HW- and SW-integrator. Jürgen is working for one of the big mobile equipment manufacturers in Germany. Jürgen is a constant source of ideas about improvement and he has tons of experience you can participate from. As a former SW-developer Jürgen instantly provides the feedback the author of software will understand. More over he does regularly not only provide feedback about the failure, but also directly points to the failing component. Very often I have experienced by myself that he's already pointing to the wrong algorithm directly. We're highlighting the daily problems when integrating immature hardware with even more immature software. The challenges when working together with multi-sited SW-development teams. And of course the mother of all questions: How to improve collaboration between developers and integrators. Stay with me and enjoy the interview.

I have recorded this episode twice. Not by intention - far away from that. But I was neither convinced nor satisfied with the first recording. Also the subject was not really impressive and I decided to do it again from scratch. Thus I got a first hand impression what waste of time and effort is. However one detail in the first record was amazing. It was about waste in SW-development. You remember episode 4? Already there I have mentioned waste due to over-processing and over-engineering. Both are part of the 7 forms of regular waste in any kind of system. The Toyota Production System (TPS) has introduced to a broader audience the classification of waste forms. In this episode I wanted to connect traditional manufacturing based Kaizen and Muda, Mura, and Muri with Software-development. Is it possible? Do we have parallels? Or is the TPS not adaptable to nowadays IT-based technology? Stay with me and enjoy the show.

I have mentioned the Embedded Testing conference in Munich in episode 20. One of the presentation was about "Applying DevOps Principles to Software-Hardware Integration Test". Vassilis Rizopoulus, naming himself as DevOp and Tester, explained further details, their tooling, automated testing and the mandatory environment. I was excited and we have had an extraordinary talk after his contribution. Some days later I asked him for an interview. I am sure that Vassilis' ideas and thoughts will be helpful for a lot of engineers out there. Especially engineers who wanted to try something knew, but who might need some trigger to change their way of thinking and habit. Vassilis works as an engineer at Zühlke in Germany since 2001. He has tons of experience and knowledge. According his own statement on his company blog he has "... helped build software for devices as small as a cookie to as large as a 60-ton locomotive". Moreover he was co-organiser of the European Ruby Conference in Athens in 2013. You see, Vassilis is an outstanding personality and I am very happy to present you this talk. We're discussing about DevOp-priniciples. His will to automatize everything. The infrastructure you need for day-by-day development. And of course the mother of all questions: what are the differences between SW-tester and SW-developer.

In episode 20 I have described the main differences between traditional conferences and the idea of BarCamps. In this session I wanted to give you my 15 for your BarCamp visit. I have meanwhile joined several BarCamps. And I have made a lot of things wrong. Mainly because I was not aware of. Sometimes also I thought it is better done in another way. But there are a some main phases you are confronted with. And for all of them you can do things well and you do things much more better. Starting into a BarCamp well prepared lets you enjoy the atmosphere even more intensively. You get much more quicker into connection with the other BarCamp-members. And you finally get more out of the time you're staying at the event. All BarCamps can be separated in three different phases: BEFORE, DURING and AFTER the BarCamp. Even the AFTER phase is as much important as the other phases. If you do not care for the AFTER-phase you loose a lot of momentum you have gained during your time before. Please take these 15 tips into account. Let your first or next BarCamp-visit become an even more thrilling success.

Holy moly, seems I'm getting old. Two times in the last two weeks I was confronted with the PDP-11. Things which are part of my experience are nostalgic for others. They have never seen or touched them. Never experienced in real life. What has happened? One day I saw an update in LinkedIn highlighting DEC's PDP-11 as an old system. That's nothing extraordinary. It is old. But one of my colleagues mentioned it as nostalgic. Bumm, right in the face. Second, I got a mail by another colleague. In his signature he mentioned that this mail was written from his PDP-11. I doubted this, but he showed me a picture showing him from the backside (hopefully it is him) and a PDP-11 aside. That picture must be old. I do not consider that he really has a PDP-11 in his cellar. But both moments let me think back into that time 30, 40 years ago. Computer Systems were different. Computer Science was slightly different. And of course the systems you own or you could directly touch were dramitically different. Compared with the systems available nowadays the are more like flintstones than real lighters. And these thoughts created this episode. I wanted to go back with you showing some highlights in my computer-life. Not for nostalgic reasons, but to make you aware that things were really different at that time. And that it is of some benefit to know a little bit about it, to understand the situation we're currently in.

You know conferences. For sure you do. You might be a fan of them. Or even not. You might be even disappointed, as I am after visiting the Embedded Testing 2015 in Munich last week. Although I was invented as presenter, I was not convinced. I mean the topic was really good - no other conference or meeting available covering exactly this specific part in the Embedded Systems realm. But the conference got stuck as a sponsor-driven event which highlights products over general knowledge, marketing over sharing of experience. One could have made a lot more out of this conference. So the participants have finally had only their others to get acquainted with each other, hear the problems, discuss and finally detect the old rule, that the best of conferences are the pauses. Free time which can be used for connecting and sharing. In this episode I wanted to highlight the approach of traditional conferences in comparison to BarCamps. A BarCamp is an un-conference born from the desire for people to share and learn in an open environment. It is the direct response on all attendees who wanted to create and design their own agenda of content. For me BarCamps, the un-conferences are by far the better conferences. Listen to this episode and create understanding about this popular approach to confer.

Talking about bug-hunting has become a regular topic in this podcast. However there are tons of different persons out there using their own approach to handle bugs. All of them might have different attitudes, different approaches and different experiences. And it might be of interest to get more familiar with them and the details they can tell us. Within today's episode we have Bero Brekalo as a guest for interview. Bero is one of my very first listeners not directly related to me. We got acquainted after release of Episode 2. We have had a long mail-discussion about debugging, our different and common understanding. Especially Bero's very interesting debugging tools made me curious. As more as we discussed and as more as I got familiar with Bero, I more and more get the impression, that he's Mr. Bug-Hunting in person. Today I have the pleasure to present you Bero Brekalo. We're talking about many details of debugging. You get further details about his approach and his understanding of debugging. And you get acquainted with a very experienced engineer, who has gone through a lot of storms and bad weather. Let's stay with me and enjoy the interview.

Everybody has his limit in handling emails. For one 10 per day are too much, another handles 150 without any problems. But sooner or later, everybody of us have to declare: it's too much. I have had a time in my life in which I have had to handle 750 mails per day in average. Nobody can say that this is possible to do. But that was the time I started a very strict and consequent filtering and categorization. However it still was too much. The combination of importance and urgency was back-breaking. In the first part of this episode I will show you some of the most successful approaches how to handle the flood of emails daily arriving in your inbox. There are different concepts, sometimes even contradicting systems, but give them a try and find the most acceptable way for you. But if you're in the same situation as I was, even the most sophisticated approaches to handle the flood, weren't succeeding, then you might be interested in the 2nd part of this episode. This summer I stumbled over the book of Rory Vaden "Procrastinate on Purpose: 5 Permissions to Multiply Your Time"". Rory was welcome as guest in the Art of Charm Podcast His book was an eye-opener. I do not agree with everything Rory has written, however the major part, the introduction of a 3rd dimension, was essential. If importance and urgency are the first two dimensions, significance becomes the 3rd dimension.

Do you have ever heard about Soft-Errors? No, I do not mean Software-Errors. That's something completely different. I mean Soft in difference to Hard. I first time get into contact with Soft-Errors in late 2011 as we have observed a spontaneous reset within a customer's appliance. There was no indication for a reset-request, the system simply resetted. Within some industries this is no case to be worried about. But in that time, in that type of industry, with this particular customer it was a challenge to find the root-cause of this spontaneous reset. And it was even more complicated to approve this root-cause. In this episode it is Michal Lewczyk joining us. Michal is one of the very seldom specialists available for Soft-Errors. Michal was one of my colleagues in 2011 and the years after. He was the main investigator for all Soft-Error issues we suspected. Michal has a deep knowledge in bare metal SW-programming. He's mainly engaged into developing software for Digital Signal Processors; thus he's not only an elaborated and experienced software-engineer, but also a great investigator and marvelous bug-hunter. Let's enjoy the engineer's talk with Michal Lewczyk about one of the most quirky phenomenon in Embedded Systems.

In this episode I will give you further details and helpful hints how you can do all the aftermath in running and working with task-forces. You get a lot of details about how to provide meaningful and reliable meeting minutes. I provide you my experiences in doing minutes both, during and after the task-force meetings. Additionally you will also get my minutes template available for free at Google Docs. And last not least I will drop you my ideas about the retrospective you should have for each of your task-forces.

In this episode I will give you my thoughts and considerations about the Volkswagen Diesel scandal. I wanted to highlight some of the obvious technical problems as some of the not that visible intrinsic issues. Where do we have seen this kind of cheating before? What could the customer expect? How will Volkswagen deal with the situation? A big amount of questions let me consider about some potential answers or thoughts how this could have happened, why it has happened and whether it is not that simple to resolve the problems.

This episode is the 2nd part of the root-cause mini-series. It has started with episode #9 and the 5-Whys technique. This time we get introduced into the Ishikawa-technique. It is a much more versatile approach which handles even more complicated problems with more than one root-cause. In detail the Ishikawa-technique is a simple as the 5-Whys. However it also has some problems and obstacles which you should know to use it on its best. This episode provides you an introduction in this graphical cause evaluation method.

In this episode you will learn a lot about building, maintaining and distributing tools and operating systems in large scale projects. With Robert Schiele a senior expert on all this kind of topics stays with me. We're talking about build-systems, root file systems, native and cross building. We tackle observable problems with distributed environments. We discuss about struggles with multiple hardware platforms. And we give you a close look into the way how well prepared tools-provisioning saves you time and prevents waste.

Complicated technical problems, defects, situations or environments often need some abstraction to be understood by outsiders. This episode give you 6 ways to fail with your explanation. But it also gives you six great ways how to become a 1st class insider providing exceptional explanations.

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.

Finding the real cause of a problem is like weeding your garden. Treating only the weed is useless effort if the root is not eradicated. The 5-Whys technique provides you a way to dig deeper, find the root cause of a problem. Although the technique is quite simple in its process, it has its tweaks and caveats which needs to be known. This episode gives you a first entry how to do the 5-Whys best. It give you an overview of the benefits, but also mentions the drawbacks. A step-by-step guide introduces the way how to do it in practice.

Each task-force follows three different phases: launching, running and aftermath. This episode handles the first phase. Get 3 basic actions to succeed.

Marcus Behrens is a wholehearted engineer and Product Design Director at SAP in Walldorf, Germany. We came into discussion at the IoT-TechDay in Frankfurt. He's not only one of the masterminds at SAP for IoT, but also an engaged engineer within Embedded Systems. This interesting combination triggered this talk. We're chatting about our experiences and impressions from the IoT-TechDay, the chances and risks we see in IoT and our future outlook for IoT in our daily environment.

This episode is the starting episode of a mini-series about how to establish and run a successful task-force. This episode gives you the overview about the advantages and disadvantages, the risks and chances of running task-forces. Get 5 tips how your task-force becomes successful.

Rescuing a failing project seems to be something regular nowadays. Whether your project starts tilting is something you should detect beforehand. This episode gives you the major indications for a failing project. Take them seriously and hold your personal vigilant attitude to ensure that you do not miss the point for rescue or escape.

In this episode I will show you how zero-fault targets jeopardize the goal they try to achieve. I will show you some of their major problems. And I will give you some ways to escape or at least to handle them.

This episode is about my biggest mistake when starting to lead a Virtual Team. It is most likely a very common mistake. But if you're not familiar with it, you might get trapped for sure. I will give you some thoughts and tools you will be able to prevent your failing when working with Virtual Teams.