Agile in Machine Building / PTC AgileWorx 3

[Finglas]

Hope I’m posting in the correct forum. If not feel free to move to something more suitable. I’m doing some research on integrating agile framework into machine building and have a few questions related to same.

I was reading an article from Scrum for Hardware Development that said the following:

"One of the most useful solutions that Scrum teams have found in working with hardware is adjusting the frequent release principle. Instead of delivering a functional, physical product to the customer at the end of each sprint, teams have opted to deliver virtual simulations of the result of the sprint. This provides a reasonable solution for many of the challenges of using Scrum for hardware."

Now I'm kinda familiar with how the design phase works for a machine build. After meeting with customer and noting requirements etc concept drawings are done and design reviews are held to ensure designs conform to customer requirements. Once final design review is signed off, drawings are sent out for tender or parts are made in-house and build can commence. That's obviously a very watered down description.

My Questions

Do many companies actually produce a simulated model for design reviews or are they mainly static in nature, preferring to use something like eDrawings or story books? Been a while since I used SolidWorks and back then it was very memory intensive to produce simulated designs even if they were small. Energy chain for example was a difficult thing to ‘move’ on screen. Usually the program crashed.

Now I just did a quick Google and came across a link to PTC’s New AgileWorx AgileWorx. Is there anybody using this and could they explain how it works?

Alternatively is there anyone using Scrum in machine design and build/mechanical product development that could give some info on how they integrate agile into the machine build.

Do you use the ‘frequent release principle’ and of so do you simulate the model to reproduce how it should (emphasis on should) work in the real world?

 

[drawoh]

Finglas,

When I design something in SolidWorks, I start drawings off immediately. Immediately, it makes document searches faster because I only look for drawings. If I see everything, there is too much to search through. As time goes by, I fill in important information like critical tolerances on fabrication drawings, dimensions and section views on arrangement drawings, exploded views on assembly drawings, and external dimension drawings for the customer. I can create PDFs of the drawings. I can create 3D[ ]PDFs of the models if they have not gotten too large. I can create Edrawings, and I can save these as executable files so that the other guy does not need any SolidWorks software. The Executable Edrawings work on my Linux box at home through Wine, as long a I have a decent video card. If SolidWorks itself is available, we can directly load my drawings and 3D[ ]models.

During any sort of design discussion, you ask me a question. I have all sorts of tools for answering it. We can discuss how the system must or will work. I can show you how I plan to fabricate the parts, and I can show I plan on the thing being assembled. You need this if we are going to do DFMA. Customer drawings show off things the customer needs to know, minus all sorts of IP[ ]stuff we would rather they did not know. There is no substitute for you paying attention, asking intelligent questions, and arguing with me.

I am not process driven. I am results driven. I am not familiar with your use of the word "Agile".

--
JHG

 

[3DDave]

"Agile" is a software development process.

In the typical development, there is a group that develops a spec, and then that spec is handed to developers who create software and turn that over to test. In mechanical development it's called 'throwing it over the wall.' In software development it's called 'waterfall' as nothing downstream comes back.

'Agile' compresses all the parts together, so that small parts of the overall task are developed simultaneaously on the theory one will always have a working, if imperfect, piece of software. The expectation is the buyer is a tightly integrated part of the development and testing team and that working deliverables come out on a short loop - 1 week if I recall correctly.

They also throw in terms like 'scrum' and 'sprint'

https://en.wikipedia.org/wiki/Scrum_(software_development)

It is based on the concept that no one knows ahead of time what they really want at the outset, so it is better to produce something and then decide what is not liked and fix that, rather than spend a lot of time polishing a spec.

Agile might be a great idea (and there are projects that use it and don't fail,) but it seems to me to hold near toxic levels of managespeak.

 

[drawoh]

3DDave,

So, it is like concurrent design.

It sounds suspiciously like someone has designed "agile" software, and that someone else is going to install and operate the software, and then call this process "agile".

--
JHG

 

[drawoh]

3DDave,

One more thought.

A lot of really bad mechanical design happens because someone adapts an existing mount or structure to some new application it was not designed for. This is perceived as a way to save design time and/or reduce the risk of failure. A horrible kludge results when people add brackets, and try to solve access problems without modifying the structure or the covers. Not having a well defined design specification is a good way to wind up there.

If software is written chaotically, the result may just be that it uses 500MB of RAM instead of 250MB. No one will notice. If my air-conditioned, IoT capable floor mop weighs 30lb, people will notice.

--
JHG

 

[Finglas]

Yes agile is taken from software development. I was just looking to see if there is anyone who apply the principles to the hardware side of things in a productive manner.

So to elaborate on my example of agile in mechanical hardware, I would see designing a station assembly and testing virtually as being agile, i.e. test it as early as possible, albeit virtually and see what it looks like/how it works kind of like what Kuka do with their robotics testing. I know this isn't foolproof and will never be the same as real world testing. It's the principles I'm interested in here. I'm more interested in finding out if any companies do much simulation testing within their CAD software itself, whether that be SolidWorks or whatever system they use.

@ 3DDave - you sum up Agile well in software. It's not going to be the same in hardware for the simple reason that stuff is hard and physical. Iterations might prove to be longer as stuff needs to be ordered and you have lead-times which you can't dictate. The Scrum concept is something that I don't see there being a problem with, again tweaked for hardware. Scrum to me is more about the team meetings and the communication more than about iterations but I am still a bit ignorant of Agile and it's methods (agile only being a framework and not a method) and getting my head around it.

Compass Automation are a US company who seem to use Agile principles and I was hoping there might be someone out there who might be working in a similar environment.

 

[hendersdc]

We have tried to adapt the agile process to mechanical design in past projects with mixed results. For one thing the duration of tasks that the project was broken up into had to change. Software likes to break things up into tasks that are meant to take an hour or two to complete, we found that many mechanical tasks couldn't be broken down to lower levels than a day or two and had to accept that.

In the spirit of "prototype early and often" we planed one project around a series of 2 wk long sprints with some sort of physical prototype at the end of each. It didn't have to be the full product, just a portion of a mechanism or something. What we found was that even with modern rapid prototyping methods by the time you had parts in hand the design had moved too far along and they were only of moderate use. We also found that trying to force your project into many prototypes was inefficient as you spent a lot of that 2 wk sprint trying to clean up a design so it could be prototyped, sending out and receiving the prototype quotes, ordering, lead time, and assembling. It just ended up being too much of a distraction. Prototypes and testing are great, but don't try and force it if the project isn't in a position to gain from it.

Simulation is a part of our design process, usually confined to FEA and CFD. Depending on the project this can be a major or minor part of the design process. The way it is used in your quote above it sounds more like reviewing a CAD model than reviewing the results of a simulation though. We included a brief customer review at the end of every sprint and found it useful, especially since the customer continually changed requirements and added features on us.

The daily scrum meetings were useful, even more so as the size of the team increased. It was good for everyone to have a high level view of what other people were working on day to day so they could keep in mind how what they were doing was affecting everyone else and vice versa.

This turned into quite the rambling reply, let me know if you have any specific questions I can answer.

 

[Finglas]

That's a really good answer above and exactly the kinda info I was looking for. I can see what you men there when you say when you had the parts in hand, things had already moved along. The thing with hardware is it takes time to get parts between quoting, ordering, tracking, building, testing. This requires lots of admin work also so I suppose you have to be careful in weighing up the benefits of all this, will it end up actually being more of a burden than a help. As you say, don't try and force it. Isolating certain things that don't require many parts, robot grippers for example might be area to focus on and get testing done early on.

As i get further along in the project I'll probably have more questions. Thanks for the reply.

 

[stick1]

Just to add to the comments, we also have tried using the AGILE process for hardware development. We found that 4-6 week sprint lengths allowed enough time to accomplish some significant work. The problem we encountered is that if a team member had their sprint interrupted with an unplanned support issue, the whole sprint timing went out the window. Also the time spent planning that sprint was lost as well. Therefore participants must either allot time in the sprint for unplanned activities, or else one member must be made the emergency worker so that unplanned work can be sent their way.
We did find that coming up with ways to deliver prototypes earlier was fruitful. Sometimes a clunky item was "good enough" to keep a software engineer going, or it could allow an electrical engineer to do some critical early testing.
Next, creating stories that align to major project delivery milestones is a must. That way progress (team velocity) can be used to judge if the team can meet the needs of the schedule. More resources, or schedule adjustments can be considered if the planner is aware of the team's progress.
Lastly, while tracking our velocity, we noticed that if teams can spend significant chunks of time on their tasks, their efficiency really climbs. If members could hit the 60% mark for time spent working on their tasks, there was good correlation with an large increase in velocity. This seems like an elementary observation, but when in the midst of an aggressive schedule, planners tend to over-commit members to meetings, discussions, and other peripheral tasks. This can break up the longer time windows that are needed to really gather momentum on design and development efforts.

 

[Finglas]

Thanks Stick1. From reading literature, longer sprint cycles seem to be the norm for hardware projects compared to software. What kind of prototypes did you deliver? Can you go into a bit more detail?

Also can you elaborate on stories? The company I had been working with had started creating storybooks for machines which gave an explanation of how each station in the overall machine worked and what the main components in it were. For example, one station might apply glue to a lens and the essential components were a gripper and some vision sensors (bare essentials there, designer would list more than that). The main problem was that the stories were being created by the people doing the design and hence they were intimately familiar with it. I guess they assumed too much in terms of other peoples understanding and people in other departments reading these user stories still did not fully understand them as there was information missing.

Came across a really good article on minimum viable product delivery. What are peoples thoughts?

 

[3DDave]

That piece is really straining to force a metaphor. His supporting examples are all of simplified versions of some final product, not incrementally developed unrelated items.

I think the bicycle predates the skateboard, the first car pre-dates the motorcycle, and the horse-drawn wagon was the actual lead in to the automobile, to the point that many people still refer to engines by horse-power. I think self-propelled machinery started in a big way with the railroad and that was definitely before cars, so a bus ticket wouldn't be right - it would be a horse-drawn coach or a steam train ticket.

It would have been a better presentation to look at the much better documented invention of the airplane by the Wright brothers. They built a small airplane that was nearly (about 1/4 to 1/2 size, or within an order of magnitude of their initial guess for the finished size) the size they expected to need. It failed their own expectations because they depended on others for critical data - so they iterated from a partially working but sub-useable platform to a workable one.

As an aside, it was the League of American Wheelmen that pushed for smooth, paved roads that cars now use.

http://bikeleague.org/content/mission-and-history

 

[drawoh]

Finglas,

Minimum viable product does not work for me at all as a concept. As 3DDave notes, cars were not developed that way. If someone asks you for something, you both are able to visualize it, which means that most if not all the design elements are well understood. For a car, you need a chassis, at least three wheels and an engine. You might not know which end the engine should go into. You know you need one.

The actual sequence would be that somebody learned around 4000BC that animals could pull stuff. At that point, axles and wheels are an obvious development. Then, somebody invents engines. Then, somebody wants a horseless carriage. Note how each stage in the development is functional.

--
JHG

 

[JNieman]

Metaphors are not literal. They are descriptive of ideas. The picture is not the thesis. The picture is just a tool.

I've applied MVP concepts to various scales of development and found much better success with those I rely on for either my paycheck or for partnered achievement.

 

[KENAT]

Hmm, while some of the stuff in Crips blog link is pretty good, I've seen too many people not even try and do a reasonable up front analysis - or setting of requirements as I think of it, with design 101 being know they requirements.

Failing fast because of technological barriers or difficult to capture use cases etc. is one thing. Failing fast because no one bothered to do even elemental tolerance analysis or check all the holes lined up etc. is just shoddy engineering.

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[3DDave]

An interesting blog from an interesting company, touching on Agile:

https://www.instrumental.ai/blog/20...chedules-look-nothing-like-software-schedules

The company is interesting because they are selling an interesting solution - inspecting all parts at multiple stages via photographic record. The secret they may have is how to get manufacturers to actually go along with it.

 

[Finglas]

Great link Dave. Really useful reference for me. Thanks.

 

[CWB1]

Just my opinion, but Agile is nothing more than a slight twist on Lean with different tools.

Regarding demos and modeling, I prepare demos in a similar fashion to how I would a trade show exhibit. I try to visually use as many images, models, simulations, and parts as possible, focusing on a different aspect of the product each demo and how that aspect relates to the overall product. The more visual and/or hands-on a display is the better, and thanks to large servers, clusters, and other electronics I can record videos of motion sims, FEA, CFD, etc to share. I've always invited a thoroughly cross-functional contingent of both technical and business folks, production, trades, and even dealer staff, typically I try to keep my comments and presentations to a level the entire crowd can understand. Often a fellow engineer sidetracks discussion into deeper technical matters but I try not to allow that too much, as a product owner feedback is the #1 goal, I'm not trying to educate so much as get various reactions from everyone up/down the various value streams in order to prioritize future development of important features.