Cover image of Mastering Embedded Systems
(4)
Business
Management

Mastering Embedded Systems

Updated 3 days ago

Business
Management
Read more

Out of practice into practice. The podcast for engineers in the Embedded Systems realm.

Read more

Out of practice into practice. The podcast for engineers in the Embedded Systems realm.

iTunes Ratings

4 Ratings
Average Ratings
3
0
1
0
0

Excellent stuff about Embedded Systems!

By krish2nasa - Jul 04 2016
Read more
Excellent stuff about Embedded Systems!

GREAT JOB!

By MattMcWilliams - Jul 14 2015
Read more
WOW…Mastering Embedded Systems Podcast is flat out awesome. Good production quality. Easy to listen. Very impressed Georg. Keep bringing it.

iTunes Ratings

4 Ratings
Average Ratings
3
0
1
0
0

Excellent stuff about Embedded Systems!

By krish2nasa - Jul 04 2016
Read more
Excellent stuff about Embedded Systems!

GREAT JOB!

By MattMcWilliams - Jul 14 2015
Read more
WOW…Mastering Embedded Systems Podcast is flat out awesome. Good production quality. Easy to listen. Very impressed Georg. Keep bringing it.
Cover image of Mastering Embedded Systems

Mastering Embedded Systems

Latest release on Jun 20, 2017

The Best Episodes Ranked Using User Listens

Updated by OwlTail 3 days ago

Rank #1: Find root causes with the Enhanced Cause-Effect approach - MES029

Podcast cover
Read more

Find root causes with the Enhanced Cause-Effect approach

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 came 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.

Essential Answers Provided In This Episode For:

  • What are the major drawbacks of 5-Whys and the Ishikawa?
  • When to use the Cause-Effect approach?
  • How to do the Enhanced Cause-Effect RCA?
  • What are the goals of the affected situation or item?
  • How to determine the causes which impact the goals?
  • Why is it essential accumulate all causes and not only the preferred ones?
  • Where to use the AND clause for combined causes?
  • Why do even nitpicking details need to be mentioned?
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Find root causes with the Enhanced Cause-Effect approach – MES029 appeared first on Embedded Success.

Feb 16 2016

Play

Rank #2: 9 surprisingly simple tips to improve your communcation - MES049

Podcast cover
Read more

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?

Paul Watzlawick once said “We cannot not communicate”.

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.

But there are ways to improve communcation and decrease misunderstanding. In this episode I will introduce the Four Sides Model for communcation. Friedemann Schulz von Thun has invented this abstraction to let us understand communication ways better. This model gives you a strong background to improve your communcation. In detail I will share with you nine surprisingly simple tips to improve your communication.

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.

Stay tuned and be inspired.

Essential Answers Provided In This Episode For:

  • Why do we sometimes communicate that weird?
  • What does communicating mean at all?
  • How does the Four Side Model work?
  • What can go wrong in communication?
  • What does good communication mean?
  • Why listening is essential for good communication?
  • Why pictures or stories support you?
  • How can body talk impact the meaning of messages?
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post 9 surprisingly simple tips to improve your communcation – MES049 appeared first on Embedded Success.

Nov 22 2016

Play

Rank #3: Avoid managing your time - MES047

Podcast cover
Read more

Avoid managing your time – MES047

This is the first episode of my new 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-Mangement 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.

Essential Answers Provided In This Episode For:

  • Why time management tipps and tools do not work
  • What are the inner benefits for self-made time problems?
  • If we cannot manage time, what else can we do?
  • Which 3 things have changed my life belonging time?
  • How does the Zegarnik-effect prevent you from being free in your time?
  • Why the Five-Minute-Journal might be the best things to start?
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Avoid managing your time – MES047 appeared first on Embedded Success.

Oct 25 2016

Play

Rank #4: It's a shame that you do not make the best out of your root cause analysis - MES046

Podcast cover
Read more

Do you have ever thought about the aftermath for your root cause analysis? What should be done if you have found the 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.

I have given you 3 examples of how to find the root cause of your problem: 5-Whys, Ishikawa and Enhanced Cause-Effect. But finding the root cause is not the end, but the beginning of the whole story. There is so much more in it.

You should listen to this episode if you have to analyse problems with a significant depth. And if you want to know what you can do after you have done the root cause analysis? What are the next steps?

This episode will support you in improving the outcome of your root cause analysis. You will get an idea how to achieve consistent, substantial, and reliable ways to proceed with your analysis.

I have composed a checklist you are free to use to improve your root cause analysis. It will provide you several questions to enlarge your perspective of the problem situation, your correction and your next steps. Feel free to download the checklist here.

Stay tuned and be inspired.

Essential Answers Provided In This Episode For:

  • How to get one step ahead of regular root cause-analysis?
  • What do we miss after regular root cause analysis?
  • What’s this Kaizen and Yokoten about?
  • Do you really improve? Or do you only pretend to improve?
  • Why you should not stop directly after the root cause analysis
  • What kind of questions should you raise to enhance your understanding of the situation?
  • How to establish or improve your process?
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post It’s a shame that you do not make the best out of your root cause analysis – MES046 appeared first on Embedded Success.

Oct 11 2016

Play

Rank #5: Tech-Chat: How to maintain derailed projects with Maik Pfingsten - MES045

Podcast cover
Read more

Sometimes people ask me: “What’s that about project troubleshooting? What does it mean? Who does anybody need this kind of stuff? What are you guys doing? 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 worked as project troubleshooter for a decade. 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.

You should listen to this episode if your project is in trouble and you have already thought about some external support. Or you want to know details how such kind of external consulting might look like. And it will become especially worthwhile if you consider to work yourself as project troubleshooter, but you do not yet exactly know whether it is the right way. But, of course, you also can listen only if you’re simply interested in the topic

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.

Stay with me and enjoy the chat.

Essential Answers Provided In This Episode For:

  • How to become a project troubleshooter?
  • What kind of skill do you have to work successfully as a troubleshooter?
  • Why does Maik follow a specific plan to cope with derailed projects?
  • How does the system footprint supports different perspectives?
  • Why Maik protects the project team first?
  • Why stepping out is that essential for the troubleshooter.
  • Highlight for the ESE-Kongress 2016 in Sindelfingen
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Tech-Chat: How to maintain derailed projects with Maik Pfingsten – MES045 appeared first on Embedded Success.

Sep 27 2016

Play

Rank #6: 5 hacks to succeed in discussions with your vendor - MES044

Podcast cover
Read more

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.

You should listen to this episode if you will sooner or later found yourself confronted with your boss’ request: “Hey man, let’s discuss with vendor #XYZ. They should support us here.” And with “let us” he of course means you. Or you’ve already talked with your vendor (or vendors) and you again and again observe some counterproductive situations, but you do not exactly know how to improve them.

This episode enhances you to finish vendor discussions better as average. Or if you’re the vendor, you know exactly whether your customer is well prepared and honest with you in his request for explicit support.

Stay with me and enjoy the chat.

Essential Answers Provided In This Episode For:

  • Why do we need to talk with the vendor?
  • Why becomes the meeting invitation that essential?
  • When you should cancel the meeting directly?
  • How can you prepare for the meeting with your vendor?
  • What kind of additional communication channels should you maintain during the meeting?
  • When will superiors in the meeting become counterproductive?
  • Why writing of minutes is the key-point in control?
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post 5 hacks to succeed in discussions with your vendor – MES044 appeared first on Embedded Success.

Sep 13 2016

Play

Rank #7: Tech Chat: Security in Embedded Systems - MES036

Podcast cover
Read more

Tech Chat: Security in Embedded Systems with Andrey Nikishin

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.

Andrey thankfully provided me some documents and white-papers about the mentioned topics. Have a look at them in the links-section below.

Stay with me and enjoy the chat.

Essential Answers Provided In This Episode For:

  • What has changed in the industry belonging security in the last two decades?
  • Why Andrey’s dog is not (yet) connected?
  • What actual security threats do we see for Embedded Devices?
  • Security, safety, and functionality! How shall devices be built from the very beginning?
  • What are the main drawbacks of traditional OSs belonging security?
  • Why do we need a different way of thinking in SW-development?
  • What should be considered by everybody when dealing with security?
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Tech Chat: Security in Embedded Systems – MES036 appeared first on Embedded Success.

May 24 2016

Play

Rank #8: Tech Chat: Virtualization in Embedded Systems - MES034

Podcast cover
Read more

Baurzhan Ismagulov

Tech Chat: Virtualization in Embedded Systems with Baurzhan Ismagulov and Alexander Smirnov

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.

Alexander Smirnov

Already at the Embedded World I have had an amazing talk at their booth. But how much more deeper do we get into our todays tech-chat. We’re tackling the main use cases for using virtualization: combination and isolation. We’re discussing the main feature of Mango, as there are: static partitioning, bounded latency, no scheduler and a marvellous small footprint. And we come up with the general pros and cons of virtualization in embedded systems. For the latter have a look at Alexander’s talk at the Embedded Conference Scandinavia last year.

For all the ones out there who believe in doing things by themselves. Here’s the deal: Ilbers provides a Mango-demonstrator for the BananaPI. Just study their Getting Started Manual and give it a try.

But first, stay with me and enjoy the chat.

Essential Answers Provided In This Episode For:

  • What are typical use-cases for Mango?
  • What kind of hardware is supported by Mango?
  • How does Mango intercept the performance of the guest operating system?
  • What’s the interdependency between Mango and the processor’s caches?
  • What are the benefits of using Mango?
  • What are the differences to other virtualization solutions?
  • How can I get as BananaPi-based demonstrator?
  • What are the pros and cons of virtualization in Embedded Systems?
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Tech Chat: Virtualization in Embedded Systems – MES034 appeared first on Embedded Success.

Apr 26 2016

Play

Rank #9: Tech Chat: From SingleCore to MultiCore with Jeronimo Castrillon-Mazo - MES031

Podcast cover
Read more

Tech Chat: From SingleCore to MultiCore with Jeronimo Castrillon-Mazo

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.

Essential Answers Provided In This Episode For:

  • What stands the SLX Multicore Toolsuite stands for?
  • When does the attempt to parallelize do not make much sense?
  • What kind of applications and languages are supported by SLX?
  • Who are the 3 different kind of users?
  • What different models are in use to support our migration from single- to multi-core?
  • How do we handle and prevent race-conditions?
  • How does Silexica prevent resource bottlenecks created by parallelism?
  • What are the general benefits of using a tool like SLX?
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Tech Chat: From SingleCore to MultiCore with Jeronimo Castrillon-Mazo – MES031 appeared first on Embedded Success.

Mar 15 2016

Play

Rank #10: Muda, Mura and Muri - Waste in SW-development - MES024

Podcast cover
Read more

Muda, Mura and Muri

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.

Essential Answers Provided In This Episode For:

What is Kaizen?

Kaizen is Japanese and means Improvement. It is regularly used in conjunction with Continuous Improvement. However that’s not the original intention. Kaizen stands for the understanding and the wish that everything can be improved.

Why are there different kind of wastes?

The classification of wastes for manufacturing and assembly purpose is one of the key-concepts in the Toyota Production System (TPS) as one of the three types of deviation from optimal allocation of resources (muda, mura, muri).[2]. Waste reduction is an effective way to increase profitability.

What does Muda stand for?

Lean and TPS knows the key step to distinguish between manufacturing steps which add value and which don’t. The classification of all processes involved into these two categories let one improve the one and eliminate the other. That means Muda is any activity or process which does not add value. Thus it is a physical waste of time, effort, resources and finally money.

Which forms of waste does Muda indicate?

  • Transport; the movement of product between operations, and locations.
  • Inventory; the work in progress (WIP) and stocks of finished goods and raw materials that a company holds.
  • Motion; the physical movement of a person or machine whilst conducting an operation.
  • Waiting; the act of waiting for a machine to finish, for product to arrive, or any other cause.
  • Over-Production; Over producing product beyond what the customer has ordered.
  • Over-Processing; conducting operations beyond those that customer requires.
  • Defects; product rejects and rework within your processes.

Which forms of waste cannot be adapted to SW-development?

In principle can all forms of waste in Muda be used for SW-development, too. However some of them are quite seldom and do not effectively match always, like Transport or Motion. However others, like Over-Production, Over-Processing and of course Defects seem like exclusively made for SW-development.

What does Mura and Muri stand for?

Mura and Muri define some more abstract ways how waste can be finally created in Muda-categories. Mura and Muri drive Muda.

Mura stands for the waste of unevenness. If the available men, material and equipment are used in a non-balanced way, this finally will result in waste. For example, four weeks ahead of an upcoming milestone the previous measured way of working is changed into a more hectic, confuse and challenging action. The probability of waste, especially defects, will increase. This can be prevented by steering the utilization of all resources in a balanced way.

Muri stands for the waste of overburden. If there is unnecessary stress given on employees and processes this will cause Mura and then Muda. Permanent overburden will cause absences of employees, increase of sickness-rate and finally a higher attrition rate.

Selected Links and Resources From This Episode

[saf feature="email" cta="Send me feedback"][saf feature="twitter" cta="Reply on Twitter"]

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Muda, Mura and Muri – Waste in SW-development – MES024 appeared first on Embedded Success.

Dec 15 2015

Play

Rank #11: Engineers' Talk - DevOp and Tester Vassilis Rizopoulos - MES023

Podcast cover
Read more

Engineers’ Talk: DevOp and Tester Vassilis Rizopoulos

You remember episode 20 where I mentioned the Embedded Testing conference in Munich. One of the presentation was about Applying DevOps Principles to Software-Hardware Integration Test. Vassilis Rizopoulus explained details about DevOps, 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 has been dabbling in software engineering close to two decades by now. In this time what started as a hobby of a would-be electrical engineer became full time occupation. He specializes in software productivity engineering, a catch all term for the role that integrates the development environment, test automation, continuous integration and deployment, devops and general behind the scenes tooling that enables software teams to concentrate on actually producing useful software.

His language of choice is Ruby and has been for the past dozen of years, but he also has several C and C++ embedded projects under his belt as well as a few C# .NET projects. Most of his professional career has been spent working for large industry firms doing really close to the metal stuff, from devices smaller than an Oreo cookie to as large as 60-ton locomotives. He is one of the co-founders and organizers of thessaloniki.rb the Thessaloniki Ruby Users group and also had the luck to be part of the organizing committee for EuRuKo 2013 that took place in Athens. Whatever free time remains between deadlines and family life goes into open source projects mainly in the Ruby community with the lion’s share reserved for rutema and gaudi.

In the Engineers’ 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.

Stay with me and enjoy the interview.

Essential Answers Provided In This Episode For:

  • What are the DevOps-principles?
  • How does typical tooling for DevOps look like?
  • Why does Vassilis describe himself as Testing hardliner?
  • Where does the classic SW-developer distinguish from a DevOp-Tester
  • Why is it essential to treat your environment as code?
  • What are the 3 most important skills a good and successful tester should have?
  • And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Engineers’ Talk – DevOp and Tester Vassilis Rizopoulos – MES023 appeared first on Embedded Success.

Dec 08 2015

Play

Rank #12: How everything started - My way to the PDP-11 - MES021

Podcast cover
Read more

How everything started – My way to the PDP-11

Holy moly, seems I’m getting old. Two times in the last two weeks I was confronted with this fact. Things which are part of my experience are nostalgic for others. They have never seen or touched them.

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.

Please pay special attention on this video showing the startup phase of the PDP-11.

Essential Answers Provided In This Episode For:

Why was the TI-59 hand calculator that desirable?

Together with its printer and its magnetic card it was – more or less – a fully equiped computer system. The price was horrible. But it still was only a fraction of a real computer system.

What should you take care for if you carry punching cards?

As each punching card is representing one line of your batch-job, you should take care that the order is not corrupted. Stumbling or shuffling has to be prevented at any price.

Why could the mounting of storage be embarrassing?

Mounting of devices at that time really meant that someone, the operator, physically lifted the storage into a storage-equipment. If you liked to mount some storage you do not have privileges for, the operator might come personally to your working place offending you as stupid moron.

How could the Atari ST have such a great success?

The Atari ST was the first fully graphical desktop system. With its GEM Operating System it opened a whole new world. Out of the familiar character based limitation into the freedom of fully flexible presentation.

What was the most weirdest action you have to do with the PDP-11?

The PDP-11 has had to be started by using the front-panel in-line keys. These keys were set representing the address and the octal data to setup the boot-code.

Why should you know Assembler languages?

If you like to deal with computers on a more technical level you should know their very basic language. And assembler is mnemonized object-code. If you know assembler you are directly in touch with the bare metal. Mandatory if you need to know for sure what’s going on.

And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post How everything started – My way to the PDP-11 – MES021 appeared first on Embedded Success.

Nov 24 2015

Play

Rank #13: Was your last conference poor? - MES020

Podcast cover
Read more

Was your last conference poor?

You know conferences. For sure you do. You might be a fan of them. Or not. You might be disappointed. As I was 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.

Essential Answers Provided In This Episode For:

What do participants expect from traditional conferences? And what do they really get?

Attendees regularly expect sharing of information, knowledge experience. They very often expect ideas and impulses for their own problems. They regularly focus on problem solving. Instead they get sponsors’ driven events only highlighting their own products and particular approaches.

What is most missing from traditional conferences?

The opportunity to make an impact on the sessions, their schedule or the selection of presentations. Very often there are only one or two presentations you’re really interested in.

Why is the quintessence of traditional conferences that poor?

As many of the conferences are sponsored the companies behind try to monetize their presentation for their own purposes. That often results in pure product presentation and selling event. This again thwarts the expectations of the audience.

What are BarCamps?

BarCamps are un-conferences not following the traditional approach of given schedule and predefined structure of speakers. People share and learn in an open environment not preferring the presenter over the audience.

Do these kind of un-conferences have rules? And if so, what kind of rules?

There are several pre-defined as also inofficial rulse. Listen into the episode to get some of them in detail. The general rules could be also find at BarCamp-rules.

When should you prefer BarCamps instead of traditional conferences?

If you want to experience know-how and get acquainted with interesting characters out of your environment or industry. You should join BarCamps if you’re interested more in sharing of expertise and problem-solving experience than in particular products.

What is expected from you if you join a BarCamp?

There are no spectators, but only participants. It is expected that you do not only consume, but actively engage yourself into the sessions, the discussion and share your knowledge.

And much much more.

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Was your last conference poor? – MES020 appeared first on Embedded Success.

Nov 17 2015

Play

Rank #14: Finding root-causes with Ishikawa - MES014

Podcast cover
Read more

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.

Root-causes and the Ishikawa technique

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.

Essential Know-How Provided In This Episode:

  • What helpful tools can be used to create an Ishikawa-diagram?
  • Are there templates for the Ishikawa?
  • When should Ishikawa be used preferrably?
  • Which predefined categories of causes could you use in your Ishikawa?
  • What’s the difference between sufficient and necessary?
  • How mind-mapping can assist you with Ishikawa?
  • And much much more

Possible categories of causes

  • Traditional: Man, Machine, Milieu, Material, Method, Measurement
  • 4 P’s of Marketing: Product, Place, Price, Promotion
  • 7 P’s of Marketing: Product, Place, Price, Promotion, People/Personel, Process, Physical Evidence
  • 5 M’s of Manufacturing: Machine (technology), Method (process), Material (includes Raw Material, Consumables, but also Information)
  • 5 S’s in Services: Surroundings, Suppliers, Systems, Skills, Safety
  • 7 S’s of McKinsey: Strategy, Structure, Systems, Share Values, Skills, Style, Staff
  • My favorite: Measurement (inspection), Milieu (environment), Equipment, Material (Information), Methods (Processes), People, Management

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Finding root-causes with Ishikawa – MES014 appeared first on Embedded Success.

Oct 06 2015

Play

Rank #15: Engineers' talk: Tools and Building with Robert Schiele - MES013

Podcast cover
Read more

Tools and Building

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.
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.

Essential Know-How Provided In This Episode:

  • What are the main challenges when building large scale systems?
  • How can a good building system support you or waste your time dramatically?
  • When to prefer individual build-system over stock products?
  • How to handle circular dependencies?
  • Why is it a very bad idea to put timestamps into your code?
  • What are the benefits of supporting a hardware platform you’re not even using?
  • And much much more

Selected Links and Resources From This Episode

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Engineers’ talk: Tools and Building with Robert Schiele – MES013 appeared first on Embedded Success.

Sep 29 2015

Play

Rank #16: Finding root causes with 5-Whys - MES009

Podcast cover
Read more

Root cause? What’s that?

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,
but that costs additional effort, back-pain and time.

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

5-Whys to find the root cause

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.

Benefits of 5-Whys

The 5-Whys technique has several benefits:

  • It helps to identify the real cause of a problem
  • It uses small incremental steps to improve the situation
  • It is one of the simplest tools; it’s easy to complete without any statistical analysis
  • It also determins the relationship between different root causes of a problem

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.

Criticism of 5-Whys

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

  • its tendency for investigators to stop at symptoms rather than going on to lower-level root causes.
  • its inability to go beyond the investigator’s current knowledge. You will not find causes that you do not already know.
  • its lack of support to help investigators for asking the right “Why” questions.
  • its possibility to provide different results for the same analysis. Results are not repeatable. Different people using 5-Whys come up with different causes for the same problem.
  • its tendency to isolate a single root cause, whereas each question could elicit many differenr root causes.
  • its lack of supporting multiple reasons for a problem. You will have to decide to follow one path only.

How to 5-Whys

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 the 5-Whys

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

  • What has happened?
  • Who was engaged?
  • When does it have happened?
  • Who has detected the problem?
  • What impact does the problem have?

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

Do the 5-Whys

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.

  1. Start with the first “Why” question
  2. Note the answer and validate it by reversing the statement and validating the statement. Example:
    Q: Why do I have forgotten my keys today morning?
    A: I have forgotten my keys because I was in a great hurry
    Reversed:
    If I would have been not in a hurry today morning I would have not forgotten my keys? Right or False?
    That’s not a clear conclusion! That’s not the cause of having forgotten the keys.
  3. Check for additional causes. Eventually us a parallel path of investigation.
  4. Ask “Why again”
  5. After some iterations and you got the impression to be done change the question to “Why does our process have failed?”

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.

Report the results of 5-Whys

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

  • Provide the historical data
  • Highlight the priorities of the different problems (perhaps by using a Pareto-chart or similar)
  • Show the results of the 5-Whys
  • Provide first ideas of corrective actions and their verification

Pay attention

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:

  1. Many times teams will stop once a reason for a defect has been identified. These conclusions often do not get to the root cause. A disciplined 5-why approach will push teams to think outside the box and reach a root cause where the team can actually make a postive difference in the problem, instead of treating symptoms.
  2. Avoid intentional or unintentional bias while answering! Find the right person who can answer the 5Why’s! Use other RCA Tools if you’re getting misleading answers.
  3. Do not ask your coworkers again and again for the Why. Do not upset them.

Summary

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!

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Finding root causes with 5-Whys – MES009 appeared first on Embedded Success.

Sep 01 2015

Play

Rank #17: 3 mandatory actions to successfully launch a task-force - MES008

Podcast cover
Read more

Launching a task-force successfully

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.

Why do we need a successful launch phase?

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.

Key indicators of a successful launch phase

  • What has to be done? The objectives!
  • What has to be considered? The constraints!
  • Who and what do we need? The members! the environment!
  • When and where? The schedule!

3 mandatory actions for a successful launch

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

1st Action: Define

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.
Pay attention to also clarify the knowledge and actions which are needed for your task-force.
Objectives and resources are needed for the next action.

2nd Action: Organize

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:

Participants should be selected …

  • by their knowledge of the problem, the system, the technology or the methodology;
  • whether they are affected by the problem or the objectives;
  • whether they are involved into the creation or invention of the problem;
  • whether they are involved into evaluating, finding or testing the situation the problem has been observed;
  • whether they could provide a strong push and/or support to your task-force.

The schedule

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.
But in general keep in mind: as long as needed, as short as possible.

The invitation

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.

3rd Action: Handle limitations

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

  1. You do not get the persons
  2. You do not get the time, environment or the budget

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.

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post 3 mandatory actions to successfully launch a task-force – MES008 appeared first on Embedded Success.

Aug 25 2015

Play

Rank #18: Engineers' talk: Internet of Things with Marcus Behrens - MES007

Podcast cover
Read more

Talk with Marcus Behrens about IoT

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.

We’re talking about:

  • Our experiences and impression of the IoT-TechDay
  • What IoT really means for us
  • Chances and opportunities of IoT
  • The technical challenges of IoT
  • Potential security problems and legal restrictions
  • Outlook on IoT

Show Notes

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Engineers’ talk: Internet of Things with Marcus Behrens – MES007 appeared first on Embedded Success.

Aug 18 2015

Play

Rank #19: 5 tips that your task-force gets successful - MES006

Podcast cover
Read more

What is a task-force?

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:

  • Small group of 4-12 persons
  • With a specific set of skills
  • Accomplished for a short term task
  • Exits only for specific, time-limited purpose (few day until one year)
  • Members often come from different parts of an organization
  • A task-forces enhances enhances the project’s chance for success

When to use a task-force?

Task-forces are regularly established in project management when:

  • Project confronted with complex or thorny issues
  • Solutions require organizational change
  • Involving different perspectives often greases the organizational wheels
  • Task-forces are especially valuable if their outcome impacts people deeply or emotionally. Or impacts a large part of the organization.

Why do task-forces stumble?

Task-forces stumble mainly due to three different reasons:

  1. There is no task-force charter given and agreed
  2. Task-force members are not made to do the work
  3. Task-forces are too often established and therefore loose their crispiness and dedicated flavor

Task-forces are the strongest kind of team

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 task-force charter

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

  • Purpose and objectives of the task-force
  • Roles and responsibilities of the task-force
  • Others involved into the task-force (project manages, top management, consultants, etc.)
  • A list of tasks and expected work products
  • Overall task-force timeline
  • Resources which will be made available

How-To successful task-force?

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

Tip #1 Stand Out

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.

Tip #2 Start small

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

Tip #3 Do operations on a schedule

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.

Tip #4 Create and enforce rules

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.

Tip #5 Be a cheerful leader

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.

Outlook

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

  1. Launching a task-force
  2. Running a task-force
  3. Doing the aftermath of a task-force

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”]

Now I’d love to hear from you:

  • What’s your experience with projects running into trouble?
  • Do you have a warning sign that I didn’t listed here?
  • Or do you wanna agree or disagree with me about these symptoms?

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post 5 tips that your task-force gets successful – MES006 appeared first on Embedded Success.

Aug 11 2015

Play

Rank #20: Have you these symptoms of project problems? - MES005

Podcast cover
Read more

Why does a project run into trouble?

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.

What are the warning signs that your project is in trouble?

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.

Process & Definitions

  • Missing or shaky project direction
    Detectable by: Micro-management; Contradicting statements and direction advises; No direction at all – Silence
    Results in: Missing of scope and waste
  • Company statements conflict with project goals
    Detectable by: Less attention by company leaders; Statements about withdrawal of the project; Denial of continuity in support
    Results in: Loss of reliability by customer; Drop down of credibility
  • Absence of standards and methodology
    Detectable by: Different process actions for same situations; Constant introduction, withdrawal and re-introduction of tools, processes and methods
    Results in: Invention of processes and standards on-the-fly; Disturbance, frustration and intolerance; Decline of effectivity and efficiency

Communication

  • Bad communication within team
    Detectable by: Personal issues; Hidden conflicts; Unwillingness to speak with everybody
    Results in: Bad productivity; Frustration; Waste
  • Ignoring expert’s voices
    Detected by: Expertness requested but not followed; Over simplification of problems
    Results in: Wrong way of realization; Wrong destination; Waste of effort due to inability to realize the wishful thinking
  • Client becomes unresponsive
    Detectable by: Requests for information are not responded; There is no “No news is good news”; Critical decisions are made without client attention
    Results in: Sailing in foggy conditions; Silent drop by client; Withdrawal behind the scenes

People

  • The “vision guy” leaves
    Detectable by: No further technical lead guidance; Lack of response in general design questions
    Results in: Headless chicken mode; Management mess – who will be the successor; Re-planning/-building/-organizing, “Re-“whatsoever
  • Everybody is the visionary person
    Detectable by: Everybody is barking a different tree; Changes are requested you have already requested long time ago; Team members fight about specs; Project is accounted by corrected faults, not by completed features
    Results in: Arbitrariness; Bewilderment; Inactivity
  • No visionary guy at all
    Detectable by: Nobody cares for the project’s progress; Nobody is in charge; No report; No manager/leader; Project does not really matter – to anyone – besides you.
    Results in: Arbitrariness of project and result; Stopping of project the moment management gets aware of the situation

Management

  • Project goals less important than company politics
    Detected by: Management is fiddling into the project’s leaders/managers work; Micro-Management by company-leaders; Thwarted project goals by conflicting company goals; Zero-fault targets (see also Episode #4); Dislikes by Executives; Boss’s statements like: “I know best what the customer wants”
    Results in: Project members become puppets; Project goals are ignored or silently withdrawn; Nobody takes any risk; Communication with client will drop down
  • Your project’s success is not defined
    Detected by: Senior management cannot describe the meaning and intention of your project; Stakeholders have different measurements for success; Client’s perspective not requested; Project targets are taken to a minimum level
    Results in: Wrong project outcome – customer frustration; Waste of effort for arbitrary goals; Frustration and demotivation

Environment

  • Too much overtime
    Detectable by: Constant overtime covering bad planning and bad scheduling; Weekend work becomes the regular working mode
    Results in: Bad morale; Bad mood; Attrition rate increases; Decline of productivity
  • Shortage in money
    Detectable by: Travel bans; Mandatory investment is not made; Project schedule stretched; Reorganization of company ongoing
    Results in: Window-to-market missed; Investment failed; The end of the project

Outlook

  • How could you prevent to be trapped in such a project?
  • How to overcome such projects?
  • Why do you find yourself in such projects again and again?

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

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”]

Now I’d love to hear from you:

  • What’s your experience with projects running into trouble?
  • Do you have a warning sign that I didn’t listed here?
  • Or do you wanna agree or disagree with me about these symptoms?

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.

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com

The post Have you these symptoms of project problems? – MES005 appeared first on Embedded Success.

Aug 04 2015

Play