Scrum/Agile/Lean/whatever in mechanical engineering - looking for case studies!

[Leonhard Grugl]

Hi,

 

I'm working as a scrum master on CNC machine development projects. It looks as though everyone is confident that the share of software as part of this development is growing bigger and bigger, but still I couldn't find any success- or fail-stories about using scrum in this kind of development. The process consists of a large variety of disciplines: design, mechanics, mechatronics, electronics and software (PLC, HMI, ...). We were already successful in applying scrum in parts of the software development, but we would really like spread the agile values all over the place!

 

This is why I'm looking for case studies. I've used the search feature of the group, google and even asked a consultant (one with noticeable reputation, of course), but couldn't get the kind of information I was looking for. There are a couple of stories about projects far off software engineering or engineering at all, but they don't seem to answer my questions. Here are some, which I'd like to have an answer for:

• Is scrum the way to go for us, or is there probably something else we should use, or combine with? I'm thinking of Kanban, Lean or the like...
• The mechanics and hardware developers have to deal with long delays in single tasks, since they often need to wait for test equipment or prototypes. How could we deal with this, while we would like to have tasks finished within less than 2 days (or at least within a 4-weeks sprint...)?
• I haven't yet verified this for myself, but mechanical engineering seems to be highly dependent on the individuals' expert knowledge, in contrast to software developers being more "versatile". I'm afraid this will easily lead to know-how-resource conflicts when we vertically slice through all the development disciplines. How is this dealt with?
• It's hard to build machine components to easily accept changes. Or at least, when something needs to be changed, there again is a delay until parts or prototypes become available. What can we do?
• I know a little about XP and also know the agile developer skills. But how about extreme design or "agile mechanical engineers'" skills?
• How is CI practiced in this kind of projects?
• How are test strategies applied?
• etc.

I'd really appreciate any link to case studies (the more comprehensive, the better), as well as event or book recommendations. If there are none, I'll maybe sooner or later be first to publish... ;-)

 

Thanks,

Leonhard

[Leonhard Grugl]

I forgot to mention one important question:

What were the expectations and how (well) were they met?

 

Thanks,

Leonhard

[Markus Gärtner]

Let me start with the basics: Why would you like to do/be Scrum/Agile...?

best Markus

--

Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

[Leonhard Grugl]

Well, Markus,

in some areas, or let's say projects, we've already gotten well beyond the basics, in others not. Our company has long been successfully applying "classic" MPM methodology. Now, products are getting more and more complicated and projects are getting more complex (talking about several years in duration and dozens of engineers of all professions). Also, our company is very successfully running a Lean-based production process. So, someone thought about how we could possibly get the benefits we see in production also in development, with respect to the complex nature of the projects with their ever changing requirements and little aches and pains ("transparency" was the buzzword). So much for the reasons (i.e. quality, transparency, efficiency, flexibility/manouverability). Now, the closer we get to "pure" software engineering, the more successful we are with scrum (for 2+ years now) and the closer we get to production, the more successfull we are with our Lean-based process.

But, while I do appreciate your reply and your will to help us, the question I asked was not really aimed at getting answers to the detail questions I posted right here, but rather to find sources of information, how others have been successful or unsuccessful trying to achieve the benefits I was talking about above. Of course, it would be nice if I could get conclusive answers right away, but I'm afraid I don't yet have enough information to imagine all important questions - that's why I'm looking for people who have already asked and answered these questions.

Or maybe there's someone in the same situation as we are who would like to share?

Thanks,

Leonhard

--
You received this message because you are subscribed to a topic in the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scrumalliance/gAYsCdCQNoM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alan Dayley]

My first adventures into Agile and Scrum were with teams developing physical data products for harsh environments. This involved software engineers creating firmware (of which I was one), FPGA designers, electrical engineers and mechanical design. We started similarly to you by attempting Scrum with software engineers first. This led to pulling in the FPGA people and then finally also the hardware designers. It was not easy. To be honest we didn't really get to Agile with the mechanical and electrical design people, though they participated in our daily meetings and planning.

One thing that we learned early was the need for getting to prototype and adaptable hardware as soon as possible. This meant using and leveraging vendor development kits. It also meant using "brassboards," (http://en.wikipedia.org/wiki/Brassboard) designs that we knew would not be the final version but permitted experimentation and development on hardware that was close to what the final would look like.

The mechanical people created a tight relationship with a local machine shop and other local vendors. This enabled them to get one-off parts and experiment with designs and materials. Promising designs could then go for small production runs and get into full testing quickly.

All of this took money and a change in thinking by the organization. We found that spending money on these things increased the design budget but allowed faster progress on learning and saved money by discovering wrong directions before a full production run. For example, making 10 cases that can't survive vibration testing is cheaper than scrapping 500 cases that we were "sure" would pass vibration testing.

All of this is about validated learning. That is what iterative and incremental development is about, getting to validated results sooner. Striving to get validated learning more often in your mechanical design work will lead you to Agile practices and give you motivation to be creative.

The realm of physical engineering (PCB layout, circuit design, mechanical design, etc.) does not have a lot of Agile literature. Physical is less malleable than software, of course. 3D printing, talented machinists, good tools and organizational support can help bring agility to these practices. Get creative!

Alan

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

[Leonhard Grugl]

Thanks a lot, Alan,

 

that's exactly the kind of shared experience I was looking for!

 

When you say that you didn't really get to Agile with mechanical and electrical design people, this resembles one of my mayor doubts about the whole thing, more for mechanical than electrical. In software, it has become almost natural to build for change and to refactor or throw away things, most of the time "loosing" only a couple of hours or days programming effort. But this is a different story for example for a machine body made of tons of steel, costing a little fortune to be prototyped and taking some time to be made. Of course, being creative, I can imagine that many things could be made faster and cheaper using simulations. I'll need to check this with the professionals.

 

Getting back to the comment, that still mechanics and electrics do not really practice agile, it would be very interesting to hear, if anyone else has made the same experience, or if there is a secret key to even manage this.

 

I like the brassboard idea and will keep it in mind, because I currently have no ready idea how to implement that for our needs. Of course, we do use experimental setups, which provide only parts of the machine needed to test and develop other parts. This might be something similar.

 

Luckily, we also have that tight relationship to our suppliers and prototyping resources. How much did you involve the people from your vendors into the project? Did you get them "co-located" or let them participate in ceremonies, or the like?

 

I'm not sure, if I correctly understood your example: "making 10 cases that can't survive vibration testing is cheaper than scrapping 500 cases that we were "sure" would pass vibration testing." Can you probably try to explain, how it's meant? Do you mean, that it's better to spend the money on relatively cheap prototypes/simulations to cut the number of iterations needed for the real thing, instead of over and over trying to score a direct hit - which is totally unpredictable? That would make sense to me. The change in thinking is progressing here and management is aware that it will cost money. At least I hope so...

 

It would be so interesting to hear more stories like your's, Alan. Be they successful in the end, or not. For so long, I'll try to stay creative. And of course, as a next step, I'll try to better understand the mechanical and electronics/electric engineering processes and try to find out, how much they match with software engineering, which I understand better.

 

Thanks,

Leonhard

[Philip Prendeville]

Hi Leonhard,

Just wondering if you came across anymore info on Agile in hardware? I'm doing a dissertation on Tailoring Agile for Machine Building and I have come across some useful stuff like Wikispeed and some journal articles (Thorsten P Klein wrote some really good stuff) but literature is not as widespread as it is for software and there are no real concrete examples in the field I'm researching. I have come across 2 companies in the US who seem to apply agile principles to agile design/automation but I haven't been able to get in touch with them. 

If you have anything I'd love to hear from you.

Thanks,

Phil. 

[Stefan Magnusson]

Hi all!

 

Im glad to find nice people to share experiences with

 

I started 5 years ago with developing methods to make agile work in embedded systems

 

My experience is in embedded projects with close collaboration between software and hardware and with unclear requirements, but also including mechanical integration (but with experts outside the core team). I was from the start challenging the common "knowledge" that hardware cant be built within one sprint. Now I know it can be done, but you need to be inventive and have some patience when you test out different methods

 

The one key things is to get HW engineers to deliver something that they feel is not "done". By challenging this you force them to find ways to break down their work into blocks that can be done within four weeks

 

Another other key was to go to 2x3 week sprints (should do a picture of this, hard to explain in words). First 3 weeks for HW is design only and the decision taken is to start building prototypes or not. The next 3 weeks is to release and order stuff, manufacture, assemble and integrate HW/SW. 

NOTE: You CAN design and build HW in 4 weeks, but then you need some parallelization so you start the updated design before the old one is tested. SW runs 3 week sprints with the normal Scrum setup but within the same core team and a common backlog. This gives a good trade-off to meets the slightly longer lead-times for HW and still be able to change direction fast enough

 

The last big thing is to inspire the core team to understand (and in many cases learn!) the other members competences. I have the SW engineer that do simple enclosures in the 3D-printer, the mech engineer write Arduino code for very simple automated tests. Several SW engineers understand a schematic and several HW engineers writes the code for pin-setup and automated electrical tests

 

The teams and I have found many tools to achieve this and I should do a write-up of some of them. To inspire you to not give up implementing Agile in embedded products this is what I now know can be achieve in 6 weeks for a subset of functions in one cross-functional team

• Design and manufacture PCB:s
  
• Design and manufacture a few rapid prototype mechanics
  
• Run automated electrical tests (test cases and needle bed are ready the day of PCB manufacturing)
  
• Integrate mechanic, electronics and SW to a working, demo:able prototype
  
• Test prototype deep enough to decide direction for the next 6 weeks
  
• Still maintain a good-enough (but not optimal) architecture
  

[mj4s...@gmail.com]

Stefan, I was not the original poster, but I enjoyed reading this.  I have clients facing similar challenges.  Thanks for the experience report.

—mj

(Michael)

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.

Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.