Lukas Timm’s Post

Being a safety critical industry and hungry for innovation and adaptation for new technology. Communication is the way to resolve conflict and update the standards to achieve the objective behind.

Will ASPICE remain the bottlneck ? can it get leaner ? 2025 might be the year we need to re-think how to properly engineer software deliverables to guarantee quality, coverage, testing and short time to market.

I could definitely “like and subscribe” to this Toyota Production System - old idea made new by Allen Holub. But the biggest waste (and source of jobs) is one-off custom software development for individual customers, or the projects that never make it to market. No matter what an established software development company (the kind that sells the same product to many many customers) does with their teams, almost no matter what level of “waste”, they have an incredible economy of scale such that this “waste” is a non-issue. There’s no ‘production’ in the sense that TPS is about production. So imho this change in perspectives is the first and biggest step to reduce waste, and this is mainly to people who run businesses or departments that are involved in making multiple customers features/tickets for others (clients, other departments, etc): 1. Stop making what you do a production line such as was envisioned for producing defective free cars. 2. Start making a single product that multiple customers would “like and subscribe” to. (i.e. be the designer and producer of the production line, not the production line itself) 3. 4. 5. …. 10. Profit!!! Incidentally - the early stage of development I refered to as waste is the part AI currently competes with. Crafting a product (or a production line), with the aid of computers and other people, is very much still a human-centered activity which strongly resists too much process. i.e. it is more ‘design the production line’ than ‘be the production line’, more agile than scrum, more human than robotic.

The Toyota Production System (TPS, usually called "Lean" in the West) defines three sorts of difficulties, all of which apply to software development: Muri, Mura, and Muda. They're all worth thinking about. Muri is long-term overburdening of the entire production system (e.g., too much work for the people at hand). That's not waste so much as creating a system incapapable of doing the work. To my mind, Muri also encompasses inappropriate organizational architectures, where the management structure is fighting against working in effective ways—all too common in larger corporations, but you see it everywhere. Mura is variation in the work to do. The biggest cause is usually random show-stopper bugs in the drop-everything-and-fix-this category. Variation can also happen at a macro level, for example, tax-related software that's used only once a year, so all the bugs surface over a couple of weeks rather than continuously throughout the year. In general, the more variation you have, the more buffering and slack time you need in your schedule to absorb it. In the Muda category, TPS defines eight categories of waste (all of which apply to software). I use the acronym DOWNTIME to remember them: * Defects (of all sorts, including bugs and technical debt). * Overproduction (is related to Inventory. Producing software we can't sell—often because we're not validating products before we build them) *Waiting (all sorts of dependencies cause waiting, as do processes that mandate lots of meetings and the like). * unused taleNt (punishing people as "unproductive" instead of training them is a big one here.) * Transportation (when the work needs to move from one place to another—from product to dev or dev to test, for example—you have delays). * Inventory (work done that has not been released to customers. Money spent without a balancing revenue.) * Motion (too much process. too many meetings. Lots of motion, but no progress). * Extra Processing (building more software than you need. futureproofing). Of course, all this is just the tip of the waste iceberg, but it's a good start.

Toyota's Production System: A Software Development Lens Intriguing read on applying manufacturing principles to coding. 'Muri', 'Mura', and 'Muda' concepts offer fresh insights into dev inefficiencies. Curious how these ideas resonate with your experiences? #SoftwareEfficiency #DevOps #LeanDevelopment #ContinuousImprovement #TechInnovation #SoftwareEngineering #AgileMethodology

With 20 years in manufacturing, ignoring maintenance was something I'd often see. Companies not wanting to lose production time inorder to perform maintenance would often lose even more time when something breaks. Knowing the time it takes to perform certain maintenance duties can be very beneficial. You can often "squeeze in" maintenance during times of change over, or when shipping out of the product. These are naturally occuring down times during the production cycle that a good maintenance program can take advantage of.

🚗 𝐍𝐚𝐯𝐢𝐠𝐚𝐭𝐢𝐧𝐠 𝐂𝐡𝐚𝐥𝐥𝐞𝐧𝐠𝐞𝐬 𝐢𝐧 𝐀𝐮𝐭𝐨𝐦𝐨𝐭𝐢𝐯𝐞 𝐒𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭 🛠️ In today's fast-paced automotive industry, software development is more critical than ever. As we steer towards a future of highly automated driving and advanced safety systems, several challenges continue to shape our journey. Here are some key hurdles we face and how we can overcome them: 𝟏. 𝐂𝐨𝐦𝐩𝐥𝐞𝐱𝐢𝐭𝐲 𝐢𝐧 𝐑𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭𝐬 𝐌𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭: Ensuring a seamless requirements management process is vital for a successful market introduction. This involves meticulous monitoring and ensuring complete requirements traceability, guaranteeing a transparent and organized process. 𝟐. 𝐀𝐝𝐡𝐞𝐫𝐞𝐧𝐜𝐞 𝐭𝐨 𝐈𝐧𝐝𝐮𝐬𝐭𝐫𝐲 𝐒𝐭𝐚𝐧𝐝𝐚𝐫𝐝𝐬: Meeting industry standards such as ASPICE and functional safety norms is crucial. This ensures not only product liability but also the highest levels of safety and reliability, particularly in ASIL D projects. 𝟑. 𝐓𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐅𝐞𝐚𝐬𝐢𝐛𝐢𝐥𝐢𝐭𝐲 & 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭 𝐇𝐚𝐫𝐦𝐨𝐧𝐢𝐳𝐚𝐭𝐢𝐨𝐧: Aligning technical feasibility and development efforts between clients and suppliers is key. Striking the right balance ensures both customer satisfaction and project success. 𝟒. 𝐈𝐧𝐧𝐨𝐯𝐚𝐭𝐢𝐯𝐞 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐚𝐥 𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧𝐬: A well-structured architecture serves as the cornerstone for effectively defining a product’s functionality. Using cutting-edge UML and SysML diagrams, we bridge the gap between the problem space and the solution space. 𝟓. 𝐀𝐠𝐢𝐥𝐞 𝐌𝐞𝐭𝐡𝐨𝐝𝐨𝐥𝐨𝐠𝐢𝐞𝐬: Incorporating agile methodologies allows for flexibility and responsiveness in the development process. It empowers teams to adapt to changes and deliver high-quality results efficiently. Having recently worked on technical project management for car access and authorization systems at Huf Hülsbeck & Fürst, and managing ASIL D software development projects at Continental Automotive Technologies, we understand these challenges firsthand. Our experience in these areas has reinforced the importance of a structured and collaborative approach to overcome these hurdles. Let's connect and discuss how we can navigate these challenges together, driving innovation and success in your projects! 🚀 #Automotive #SoftwareDevelopment #RequirementsManagement #FunctionalSafety #ASPICE #AgileMethodologies #Innovation #ProjectManagement

At Tricise, we believe that transparency and collaboration are key to innovation. Today, we're taking you behind the scenes to show how we contribute to the support and enhancement of Automic and how valuable customer feedback directly influences its evolution and roadmap. ✅ Development Driven by Innovation: Automic is crafted by a dedicated team of developers, engineers, and product managers at Broadcom, who bring a diverse set of skills and perspectives to the table. The development process combines cutting-edge technology with agile methodologies, ensuring that Automic remains at the forefront of automation solutions. Our role at Tricise is to support these efforts by facilitating brainstorming sessions, hackathons, and continuous learning programs, all designed to push the boundaries of what Automic can do. ✅ Customer Feedback The Heart of Our Support: Our clients are active participants in the ongoing enhancement of Automic. Through a variety of channels such as user forums, feedback surveys, and direct interactions, we gather insights that are crucial in influencing the product’s features and functionalities. ✅ User Forums and Surveys: These platforms allow us to collect broad feedback on user experience, pain points, and desired features directly from those who use Automic. ✅ Customer Advisory Boards: We collaborate with a group of key customers who provide in-depth insights and validate the direction of our support and enhancement efforts. ✅ Beta Testing Groups: Before new features are launched by Broadcom, we engage with select clients who test these functionalities in real-world scenarios and provide feedback that fine-tunes final releases. ✅ Impact of Customer Feedback: One notable instance where customer input led to significant product enhancements was the development of a new, intuitive user interface by Broadcom. Feedback indicated that users needed a more streamlined experience, leading to a redesign that has since improved user satisfaction and efficiency. ✅ Continuous Improvement and Future Plans: Broadcom's roadmap for Automic includes several exciting features inspired by user feedback, such as enhanced analytics capabilities, deeper integrations with leading cloud platforms, and advanced security features to meet the latest compliance standards. ✅ Our Commitment: At Tricise, we are committed to maintaining an open dialogue with our clients because we believe that the best way to serve you is by listening and responding to your needs. Your insights not only influence immediate improvements but also guide our long-term strategies. Join us on this journey of continuous improvement and innovation. Your feedback is not just valued — it's essential. We're Listening: Have thoughts on what you'd love to see next in Automic? Let’s hear it! Your feedback might just be the spark for the next big feature. #Automic #BehindTheScenes #CustomerDriven #InnovationInAction #Tricise #Broadcom

🔍 The journey from paper-based to digital work instructions marks a pivotal shift in manufacturing. Here's why this evolution matters: Real-Time Updates: Digital instructions offer immediate revisions, ensuring the latest protocols are always in use. Precision and Clarity: Enhanced guidance reduces errors and streamlines operations. Adaptability: Digital formats allow for swift adjustments to meet evolving production needs. This change heralds a new era of efficiency and innovation. Interested in diving deeper into the benefits? 👉 Read our blog post to explore how digital transformation is reshaping manufacturing. https://lnkd.in/gNhvE3J2

VW Software Issues: "It never was a tech problem, it was a culture problem" If I were to break it down, here's how I would explain it: Moving expertise into a common SW organization: All the brands in the VW group have been doing at least some amount of SW in-house. And by in house what I mean is to actually develop it and test it internally instead of relying on a supplier to do it. By moving all this expertise into another organization, what actually happened is a lot of that expertise got lost. There were no concerted efforts to bring in the learnings because the approach was more looking ahead to build a common solution for multiple brands. The main argument being we can save a lot of cost by developing things once and deploying it across product lines and brands. As written below, was that really a valid argument? €12bn and still counting. > Since launching Cariad four years ago, VW has poured almost €12bn into building in-house car software to retain control over everything from parking assistance and navigation to battery management systems and cars’ interaction with other devices and apps. (https://lnkd.in/dpD4gJNx) Management culture needed for SW: The SW engineering aspect of organizations are getting more and more drowned due to all the bureaucracy that creeps into large organizations. Having executives that have gone through large SW projects will probably have learned a thing or two on how to run these endeavors.  > “It was never a tech problem; it is a culture problem,” said another former Cariad employee. This I think is in the heart of the problem. Repeatedly VW has tried to do both high level approaches: try to do it on its own(CARIAD) OR ask someone else to do it(XPENG, RIVIAN). > A former employee of the software unit said that although “you have some really high-quality engineers at Cariad . . . decisions have never been made by them”. They added many senior software specialists at the unit had grown frustrated by a perceived lack of understanding of software development from VW’s top management. Read today's full report for free: https://lnkd.in/dSD5ucGZ