agile methodology for hardware projects - Page 1
Forum section: electronics / projects

author: Morgoroth
author_rank: Regular Contributor
timestamp: August 31, 2016, 01:35:26 am
content: Someone have any experience with agile methodology for hardware projects ?, I'm involved on a project surrounded by software guys, without any experience on hardware development, preaching over the advantage of agile methodology for hardware... now, I like to keep my mind open and try to see how that methodology could improve my development, but I can't stop thinking that on a computer you always can fix a problem, but with hardware is different, is more complex since the software (OSs, drivers, etc...) are only a part of the project.The problem that I have is probably this methodology could bring more problems than benefits given the other areas of the company measure future developments given a system of points and suppose to resume a future effort on that... I just don´t get it, probably my mind is too obstinate.Any experience and/or comments welcome.JP

author: singapol
author_rank: Frequent Contributor
timestamp: August 31, 2016, 04:56:49 am
content: I'm just a hobbyist not a pro but your thoughts are normal.So I looked up what is Agile..whatever, it originatesfrom software development. Theory is just theory, while some report success in applying agile to hardware development there are cons to it also. It's easy to apply a list of metrics to measure performance provided it's based on real life. I sympathise with you ..haha as a hardware man.Talk is easy as you say about doing it on a computer by simulation? hardware costs money and time so the thinking part is critical ( trying to get it right the first time) but sadly in real life it's not the case. Take a piece of wisdom from the engineer who designed the mars rover, he said " It does not it to be perfect but just GOOD ENOUGH" to do the job.http://www.design-reuse.com/articles/32442/are-we-too-hard-for-agile.htmlhttp://blog.grabcad.com/blog/2014/05/14/pros-cons-agile-hardware-product-development/

author: Dago
author_rank: Frequent Contributor
timestamp: August 31, 2016, 05:45:43 am
content: First you would need to define what "agile methodology" is. Most software shops do NOT follow the original agile method specified in the agile manifesto but some sort of weird bastardized version of it (usually bypassing any kind of benefits you could actually get from following the method).Usual version of "agile" seems to be some variation of "have a quick meeting everyday and try to do shit quickly" (quick meeting meaning anything from 15 min to two hours) which is not that much related to actual agile...As a whole I'm rather skeptical of the benefit of these methods for HW development because as you said you just cannot be so quick/flexible with things when ordering new round of prototypes can take a month and so forth.

author: cat87
author_rank: Regular Contributor
timestamp: August 31, 2016, 05:48:21 am
content: We've tried to implement the "agile" method in our SW test team, with some success. Unfortunately, I can tell you that the methods described are just for software develoment.Everything is based on a direct communication path between the SW test team and SW development team, so that feedback can be given very fast and bugs ironed out on the fly.I doubt the same can be dome with HW...I mean, OK, sure, it can, but if you have to actually spin a board before you find out there's a glitch somewhere, that will eat up a lot of time and resources. Not much point to thatJust go with the ordinary development cycle.

author: ivaylo
author_rank: Frequent Contributor
timestamp: August 31, 2016, 07:05:01 am
content: I always found hardware more susceptible to (what they call) Agile than software. In hardware you just naturally iterate over your prototype. Not to mention that some methodologies considered Agile today came entirely from hardware development -https://en.m.wikipedia.org/wiki/Kanban. Now, I wouldn't try and do Skrum and all that nonsense with HW. So yes, perfectly acceptable, existing for a long time, but probably under different names. Wonder what exactly were the software people saying you could be doing differently (in actuality they could probably learn something from you)?

author: 2N3055
author_rank: Super Contributor
timestamp: August 31, 2016, 07:55:56 am
content: Agile is just fluff from marketing and management types...In the end team adopts to a sort of internal workflow that does what needs to be done to make it work, and all the interruptions to satisfy management....Classic waterfall process works because you need to freeze requirements. Requirements changes can have butterfly effects in the rest of the project.So, in reality you cannot move the target and hit it.....I know of one big public project that is being done with sort of agile development methodology... and it was a disaster... and still is.. F35 fighter jet..Adding a feature to an almost finished product sometimes require redesign from the scratch.. All else is wishful thinking from people that don't do actual work..

author: tggzzz
author_rank: Super Contributor
timestamp: August 31, 2016, 09:53:18 am
content: Agile is a very ill-defined jumble of many concepts, many of which came from other engineering disciplines.There is remarkably little difference between hardware and software. It can be a fun game over a glass of beer to try to get a newbie to define the difference between them - and then to point out examples where their defininition fails. Of course hardware and software do have some different characteristics - but exactly the same is true of just software technologies. Think of RDBMS, functional/procedural/logic/OOP/spreadsheet/constraint based languages, and the old joke "you can write FORTRAN in any language".Arguably there is more difference between analogue or RF and digital electronics, than there is between digital electronics and software - particularly embedded / real-time software, and with distributed software systems.And the problems that arise in projects are common to all projects, whatever the technology.So yes, agile can be applied to hardware. And, just as with software, it can also be misapplied.

author: MosherIV
author_rank: Super Contributor
timestamp: August 31, 2016, 12:08:38 pm
content: HiIt looks like most here do not embrace 'agile'.QuoteYes, I have worked closely with my hardware colleagues.QuoteAs someone said "Most software shops do NOT follow the original agile method" - so what are the key concept to adopt and that work?Think of Agile as lots of mini waterfall iterations or sprints.Within each iteration - define a key development or a goal to achieve and concentrate to deliver that.Have a rough plan of the whole project - order in which to tackle things.It is tricky for hardware/electronics if the whole system is one BIG thing but even the biggest design had sub systems.So set the 'sprint' (iteration period) to match typical period for delivering a sub-system.Do not get distracted - only work on what is in each sprint.At the end of each sprint - evaluate and refine how you work ie adjust the working practices in the next sprint to get better results.Re-plan after each sprint.This also allows for any change in requirements and any unforeseen problems that arise.It can work for hardware, it does require a change in mind set though. Do not think of 1 long project - think of lots of little projects which deliver lots of little part of the whole system.Hope this helps.

author: dferyance
author_rank: Regular Contributor
timestamp: August 31, 2016, 12:51:56 pm
content: Unfortunately Agile has just become a buzzword. There are good ideas and merits behind it but they have all be overshadowed by nonsense. In the software world, "agile" has come to mean "scrum" which has come to mean having lots of status report meetings. It also is an excuse for doing no planning whatsoever and having lack of direction on a project. This isn't the intent behind agile or the problems it was meant to solve. It is just what it has become once project managers and people who like gantt charts and metrics take over. Something intended to give engineers more control over a project has become the tool for others to take it away.Having worked at both a hardware company that understood that engineering changes take time and a bunch of software companies where the attitude was, "I don't know or care what the feature is, but you better get it out the door by the end of the week", software desperately needs to slow down and plan a lot. At least in hardware, you have a somewhat tangible product so people tend to be more understanding that engineering takes time ("tend" being completely relative, not absolute or universal).So stay away from agile. Nothing wrong with the original ideas but now-days it is just an excuse for poor project management.

author: ajb
author_rank: Super Contributor
timestamp: August 31, 2016, 12:55:51 pm
content: The first problem is that iterating hardware is expensive, so any methodology that requires many rapid iterations of hardware is going to have a much higher cost floor. If the hardware is high complexity and has a niche application, even *one* board respin may be intolerable (think of some of the teardowns of (what used to be) ridiculously expensive kit with bodge wires all over the place, because it was cheaper to bodge the hundred or so boards they needed than to redesign the PCB). It's really only financially feasible to repeatedly iterate hardware if it's some combination of simple and high volume. But if it's simple, then why would you need so many iterations?The first-and-a-half problem is that iterating hardware takes time. So you finish a new 'sprint', order hardware, and then what? Twiddle your thumbs for a few days while you wait for boards etc? Have everyone on the team switch to another project, forcing a major mental context-switch that will have to be reversed in a few days? Plow ahead on the next 'sprint' of this project, so that by the time you have this iteration in hand for testing your current design documents no longer reflect it?The second problem is that it's almost impossible to implement a new hardware feature without affecting many other aspects of the design. You're not talking about writing a handful of new functions and clicking "Compile", you're talking about re-evaluating your power budget, finding or making enough contiguous free space on the board to place new components, hopefully not breaking other functions as you shuffle things around to make room, running new signals, possibly changing connectors to add new signals in/out of the board (which may require changing other PCBs), possibly revising your mechanical design to accommodate new connectors and/or a larger PCB. It's much easier to do all of that in CAD + design review meetings BEFORE you order PCBs or start fabricating enclosures.I guess you could do something agile-ish in the schematic design stage with strict hierarchical schematic capture, but even then the tools don't necessarily lend themselves to propagating changes through interfaces between sheets in a well-controlled way, as far as I know, so you still need to have a well-defined structure from the beginning before you divvy up the work.In short, each 'waterfall' in hardware is unavoidably expensive, so any methodology that requires more of them is going to be a tough sell. Even if the waterfalls are smaller from a design point of view, the nature of hardware requires a large minimum amount of effort to implement it, based on the amount of effort required to spin the PCB or enclosure or whatever. As a cost proposition it makes more sense to front-load all of the design so you get as much as possible out of the first prototype, do as much modification/bodging of the prototype as you can to verify any necessary hardware revisions, then do another, hopefully final, design.Of course if when you said "hardware" you were including firmware/HDL, then okay, sprint away, but that's not really the same thing ashardware.

author: tggzzz
author_rank: Super Contributor
timestamp: August 31, 2016, 01:51:44 pm
content: Quote from: dferyance on August 31, 2016, 12:51:56 pmMore accurately, different poor management.I've seen agile improve company's products, but the danger is that religious zealots push the doctrine too far.

author: tggzzz
author_rank: Super Contributor
timestamp: August 31, 2016, 02:04:10 pm
content: Quote from: ajb on August 31, 2016, 12:55:51 pmOnly for some forms of hardware: consider FPGAs, for example.QuoteOnly for some forms of hardware: consider FPGAs, for example. There's nothing in agile that dictates the length of a sprint.QuoteOnly religious zealots would argue/assume that agile removes the need for planning.QuoteSoftware is exactly the same, if not worse: start by considering why COBOLlers are still in demand, and why IBM mainframes are still essential.QuoteYou need the same for software.QuoteJust so. The harder you look, the smaller the differences between hardware and software. That isn't a new phenomenon: I first noticed it in the 70s, and it has become more valid since then.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 31, 2016, 04:02:08 pm
content: Words like "agile" are problematic, because they are completely meaningless buzzwords. Anyone can and will use words like this for any purpose they like or don't like.You should try to talk with them on a less abstract level. You could ask them what they actually want from the hardware development flow. It should be a bidirectional flow of ideas where you educate them about practical hardware design issues, and they give their out-of-the-box insight how it could be changed. Mostly, you would find their ideas completely unusable and ridiculous in a bad way, but every now and then there might be something important, exactly because theydon'tknow anything about HW design.

author: Nuzzler
author_rank: Contributor
timestamp: August 31, 2016, 04:05:38 pm
content: QuoteGood summary and how most software development shops, that I've worked with, implement the agile methodology. From the software side of things...one thing we try to do is reword RFE's and bug's summary statements in the form of "As a user, I should be able to do x". Once we have chosen the features/bugs we're tackling for a given sprint we try to keep focus on those as to avoid scope creep, etc...As others have already noted, this may or may not translate well to hardware development depending on the type and maturity of the project.- Nuzz

author: Tomorokoshi
author_rank: Super Contributor
timestamp: August 31, 2016, 04:17:09 pm
content: I agree with the overall sentiment here.Think about these situations for an Agile hardware project and how to deal with them using the Agile paradigm:1. The product goes to the EMC lab and fails.2. The product goes to an approval agency and fails.3. The product goes to field test and fails.4. A component goes EOL just after a PCB revision.

author: filssavi
author_rank: Frequent Contributor
timestamp: August 31, 2016, 04:18:17 pm
content: Quote from: tggzzz on August 31, 2016, 02:04:10 pmWell to be honest FPGA's are the only kind of hardware design where the agile (as in iterate quickly as many times as you can) is feasible, since FPGA developement is turning getting closer and closer to the CS side, devices are getting more and more powerfull and there will be less and less need to wirry about resources ( and on top of that High level synthesis is getting better and better, not I'm not saying you will be a great FPGA guy if you have no electronics background, but you don't need an EE major to use One for shure) that is because the build phase is generally very quick (generally seconda to few hours) and free,But the majority of Electronics doesn't consist in programmino/configuring FPGA's most of the times (even when there an FPGA involved) there is a board to responsabile to iterate, and redoing a while board for all but the simplest stuff is inconvenient and expensive at best and downright impossible at worst think for example cellulare base station kind of design you will have a Digital board with fine pitch High pin count devices for the Digital baseband processing side and than you'll have rf sections with thightly controller impedances stackups etc, the manifacturing alone of a board that complex takes time it can't be done in 2 daysAnd that is the Easy stuff, if we take a look to IC design (even on a old node where the Mask set is not crazy expensive) the tapeout is a pretty log and convoluted process (for example mosis required thas some aspects of the design such as what devices are used and metal layer count is decised 11 weeks from scheduled manifacturing date. Now once the design has been sent to the fab you have to twiddle your thumbs (or work on another design), since the manifacturing processo will take another 8-9 weeks (not to mention the whole process will have cost you 15-20 k$ for a very cheap/simple devices)As for the make a lot of small independent-ish subsystems that is not a silver bullet, it will be possible, but only in certain kind of design/markets, an industrial PLC/control system is a very good example of such a design, a modern smartphone on the other hand will definitely not be the case (try explaning to designers/marketing that their phones must be 2mm thicker to accomodate the board to board Interconnects) there are also High vibrations environements, where connectors will greatly decrease reliabiliy (aerospace or mining industry)

author: Ice-Tea
author_rank: Super Contributor
timestamp: August 31, 2016, 05:11:02 pm
content: Some guy said something along these lines: "hardware is exactly the same as software. Except that for every time you push "compile", 25k goes down the drain". Sums it up, I guess.Yes, FPGA code is different but is VHDL coding really hardware? More like something in between...

author: rstofer
author_rank: Super Contributor
timestamp: August 31, 2016, 05:28:17 pm
content: Quote from: Siwastaja on August 31, 2016, 04:02:08 pmExactly right! I hate the words 'paradigm shift'. I have no idea what they mean in some particular context and neither does the person who uttered them. They picked up the words at a management seminar and are trying to use them with engineers. We tend to think in terms of 'step-wise refinement' (Niklaus Wirth) and not in terms of paradigms - whatever they are...Disrupters can be helpful. We get in a rut of doing things in a particular way using well established guidelines. It is sometimes a good idea to throw out the rules and start from scratch. That doesn't mean throw out F=ma, some rules are laws!I have been in a lot of meetings where non-engineers were trying to 'help' me do my job with the best of intentions. They were smarter than me, just ask them, and they just wanted to pass on their vast experience. It was hard to keep from laughing...

author: PChi
author_rank: Frequent Contributor
timestamp: August 31, 2016, 05:52:45 pm
content: I thought that "agile" was lets not bother to write a specification. Then wonder why it's taking so long. If you don't have a plan how can you estimate how long it's going to take? It's like setting off on a car journey with no clear idea of your destination.

author: tggzzz
author_rank: Super Contributor
timestamp: August 31, 2016, 05:53:14 pm
content: Quote from: filssavi on August 31, 2016, 04:18:17 pmIt isn't always that clear cut in the software world!I have seen a software product where an incremental change from a customer took6 monthsto get in the field. There was absolutely nojustifyablereason for that duration; the reason was aridiculouslyconvoluted codebase and the customer/development/QA in separate silos.

author: tggzzz
author_rank: Super Contributor
timestamp: August 31, 2016, 05:55:44 pm
content: Quote from: PChi on August 31, 2016, 05:52:45 pmOnly if you are stupid (and there are plenty of idiots around).Anyprocess or methodology is doomed to fail if it applied inappropriately. Yes, some people believe that following a process issufficientto guarantee a good result; they are usually disappointed.

author: tggzzz
author_rank: Super Contributor
timestamp: August 31, 2016, 06:06:09 pm
content: Quote from: Tomorokoshi on August 31, 2016, 04:17:09 pmThere are direct analogies for software, particularly distributed systems combining components from multiple other companies.

author: filssavi
author_rank: Frequent Contributor
timestamp: August 31, 2016, 09:18:56 pm
content: Quote from: tggzzz on August 31, 2016, 05:53:14 pmI can understand that updates and changes can take a long time also in software, but there is a massive difference between the two worlds, in your case the delay was bacause of (granted indirect) a human error in the developer-QA-customer relationship and a horrible codebase (which we can also trace to a mix of errors from management who let that code slide out of hand and previous developers having written said code, had not these errors been committed the update would have been much fasterin the IC production case what i described is the best case scenario where the design is perfect (no bugs errors and such) there are no delays the Fab-management/engineering dept comunication is perfect the times are basically driven from the process length, the mask set has to be checked, produced and verified, one that is done the true manifacturing process can begin, here the times will vary with the design complexity (the finer the features the more steps it take, more metal layer more steps etc...) for a single metal layer digital only 0.35 um ,which is an unrealystically simple (for example only 1 metal layer no high/low Vth transistors etc) digital only process takes more than 50 different steps, and a lot of the steps require baking the wafer in ovens ( ok i'm oversimplifing but oxidations and diffusions in particular) and that is inherently slow (ramp up/down times) you get the idea...So in hardware frequent respins are not possible because the process is just too long, there would be also a lot to say about the feasibility of just the engineering part of a theoretical ic agile developement methodology in fact for every change (however stupid and easy it might be) before manifacturing the whole design must be simulated and verified to work (no one likes to flush 10-20 k$ to few millions down the drain) and for complex designs (like say a leading edge microprocessor, be it arm intel amd etc) it might take months just for that

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: August 31, 2016, 10:47:45 pm
content: As I work a bit with rapid prototyping I'd say that to be agile in the hardware world you need to be able todesign for changes. This means maybe laying out more footprints than is needed (for alternate parts) using a lot of 0R jumpers so you can test blocks in isolation, be generous with test points (also easy to solder on hookup wires to those) and the list continues.Agile is hard to define and indeed it's grown to something that it was not intended to be.http://agilemanifesto.org/Like most production runs I find that agility is the one true way for finding the right spec. When the spec is good - waterfall is the way to go because you can branch off and do things in parallel. I.e the firmware can be tuned while the molds are made, the DFM can start while procurement starts.Things like an in-house PnP and a 3d printer are investments that helps with the agility for new ideas and prototypes. Agility in the face of going from a prototype to a production unit is, in my mind, a fallacy. For software though, I'm a strong believer in being agile at all times.My 0b10

author: tggzzz
author_rank: Super Contributor
timestamp: August 31, 2016, 11:06:21 pm
content: Quote from: filssavi on August 31, 2016, 09:18:56 pmI'm not going to argue your points because they are valid. But it rarely as bad as the example I gave, and there are many valid cases where software changes are very difficult and time consuming.Consider anything where safety is important.Consider anything where service interruptions/downtime are very expensive. (Think telecom systems, the airline reservation systems)Consider anything where mistakes can be devastatingly expensive. (Think automated trading systems)If you read comp.risks (and if not, why not?) you will become all too familiar with the effects.

author: IanB
author_rank: Super Contributor
timestamp: August 31, 2016, 11:23:38 pm
content: Quote from: Morgoroth on August 31, 2016, 01:35:26 amIn the spirit of keeping an open mind, have a look into what "Agile" is all about by locating original sources and reading what those authors have to say. Don't only listen to what random people (including me) say about it who may be far removed from the original proponents.Some principles of Agile include:Fail fastGet early feedbackAdapt to changing requirementsIf you think about it, those principles are going to be just as valid with hardware as with software. Can you imagine designing a hardware product, investing in a manufacturing capability, paying for a marketing campaign, and then finding it flops because customers don't like it? No. You would do market research, you would build prototypes, you would conduct customer clinics, you would adapt the design according to what you learn before you commit to making millions of them. That's all Agile thinking. Agile is about getting things right and not wasting money.

author: hendorog
author_rank: Super Contributor
timestamp: August 31, 2016, 11:29:01 pm
content: Quote from: filssavi on August 31, 2016, 09:18:56 pmThe code doesn't need to be bad for changes to take a long time to reach production. I've seen processes that are so bad that they can take months on their own - even ignoring the design/development/testing effort. Ask yourself how long it would take to get a single line change of code into production without using any sneaky fast tracking/emergency change processes (which only exist because the normal process is crap). In a significant corporate environment I'd be very impressed if the answer was less than 1 month.For me this quote perfectly describes how project (and change management) bureaucracy grows:Code:…if a project managed by a defined process fails,people then assume that the project failed because thedefined approach was not adhered to rigorouslyenough. They conclude that all they need…isincreased control and project definition.Ken SchwaberQuoteYou wouldn't respin the hardware just to satisfy agile, that wouldn't make sense. If the project can only afford one production run then that is just a constraint the project needs to work around. There are also expensive constraints in the software world - Servers, storage, licenses etc are not free.Instead think of other approaches to get everyone involved early. Perhaps the entire team would iterate on a low cost prototype, or a simulation - which would at least give the software guys (mentioned by the OP) a chance to get up to speed and start to contribute.Compare with the traditional Waterfall approach, which would not hand the hardware over to the software team until your money has already been spent. Any serious problems uncovered by the software team at that point are terminal. Of course your PM would have had a formal sign-off from the software team manager and others (process centric approach) but at the time the software team were not fully engaged and so the sign-off is worthless.So IMHO the idea would be to get everyone involved, onboard and engaged earlier rather than later (people centric approach) so problems are uncovered earlier when they can be resolved cheaply. It would be up to the people involved to figure out how that would be done in reality. As mentioned, pull ideas from established methodologies, but avoid zealotry.

author: filssavi
author_rank: Frequent Contributor
timestamp: September 01, 2016, 07:34:52 am
content: Look we are probably saying the same thing in 2 different ways, so I'll try to explaina bit my views...I'm not advocating for a full blown traditional waterfall developement cycle, obviously close hardware/software collaboration is fondamentale, so hardware should be given to software peoples as early as possible for example, if there is a need to respin a board (and there is time/Money) it should be done etc so in a sense some agile principles (which are more common sense principles if you ask me) could be applied to hardwareBut there is also no denying that the whole agile principles and manifesto is tailored to the software industry, and there i quote from the agile manifesto principles youcan find on the official siteQuoteNow I'll do what i hate, a point by point rebuttal1) continuous delivery of a lot of hardware prototypes is really really costly and time consuming so it makes Little to know sense (doing 2/3 prototypes doesn't count as continuous delivery)2) this is just madness if applied to hardware (see F35 example) because software (good engineered software anyway) is higly modular in it's design, so swapping out a library for another One with more features will be time consuming/difficult but it will not required redesign/retest of almost all the products features, that is because in software global state is kept at minimum, in a board you have some things that are global state by default (Power/ground both in terms of ammount of deliverable power and of conducted EMI air being another one, for cooling and radiated EMI, and so on)3) you can not design prototype test and deliver anything other than the simplest stuff in a weeks time frame, and even a couple of months will be rightNow even in software case as you and many other suggest there are fields (big distributed systems and safey critical stuff) where agile developement is not possible often for the same reason it is not possible to apply it to hardware (namely inherently long cycle times and expensive testing required)I'll challenge you to go and do agile software developement in a seventies style multiple users time shared Unix mainframe with punchcards and tell me how it goes...

author: hendorog
author_rank: Super Contributor
timestamp: September 01, 2016, 09:17:38 am
content: Yep I agree with most of what you are saying. Note Continuous delivery is notoriously difficult even for pure software projects - I mean this in a traditional environment not a web startup. 6 monthly releases are not uncommon despite the dev's working in an 'Agile' model.And of course you are right, (as I understand) Agile appeared in response to big software projects failing, and the knee jerk increases in bureaucracy were effectively solving the problem by preventing anything at all from happeningYou don't need to build something from scratch in one iteration - depending on the project you could stagger production of the various components so that one appears every few weeks. That keeps the downstream software guys busy without swamping the hardware guys. There is no standard way, it's just a case of working out amongst yourselves what is going to work.Here is an example of a hardware project I worked on which could have benefitted from a more agile approach:I was working with hardware guys in the past (as the software guy) on a project and they decided on building one large PCB board with everything on it - because it was cheaper. This completely bottlenecked the project until that board eventually was finished.In fact it would have been more efficient for them to break the big board down into smaller boards and delivered them one at a time. Initially we could have been testing using bench supplies and COTS hardware etc in a prototype. When all the boards were ready we would have had something to sell in less time - albeit at a lower margin.The cost would have been higher per product, but lower for the project as a whole. If the volume ramped up then we would have been able to produce the cheaper large board relatively quickly as we had a working model.Agile isn't a silver bullet - these guys of course will say it is - but they are using the F35 as an example of waterfall - I have no idea myself and we can't afford jet fighters in NZ anymorehttps://www.scruminc.com/wp-content/uploads/2014/11/Patterns1.pdf

author: filssavi
author_rank: Frequent Contributor
timestamp: September 01, 2016, 01:44:20 pm
content: Quote from: hendorog on September 01, 2016, 09:17:38 amTherein lies the problem, going from a multitude of modules to a single board is not as easy as you think (it is to be done well of course) it is not just the case of copy pasting the different modules layout in a single big board, and connecting the hanging traces, there are a lot of hidden traps:1) With a change that radical to the layout any EMI emission/suscettibility test useless and must be redone (and it's not at all guaranteed that it will be passed the first time)2) Power supply and grounding must be thoroughly checked since different sections (power/digital/analog) might disturb each other3) the circuit itself might need to be tweaked, buffers will be used in high speed signaling when leaving the pcb due to cable capacitance/inductance without cable they will be superfluousthese problems will be especially hard to solve if the system is a mixed signal (analog/digital one) since most often because digital and analog will be pun on separate boards, and combining them in a single board in a way that doesn't degrade analog performances will be hardit is just like taking 2 different softwared with different codebases and merging them together, shure you might just remove the UI and duct tape them together with some IPC and call the job done, but is it a job well done? I don't think sowhat is the best approach to solve the problem you describe (apart from having more than just one project at different completion stages) is to use dev boards, simulators and emulators as much as possible, so the software team can do the grunt of the work of getting the system up (HAL drivers that suit the project needs for example) so that when the hardware is ready only the highest level businnes logic must be implemented, if the firmware is so low level that it needs hardware to do anything you can also do black box emulation of the physical system it cam be done both at hardware level(you can use a multichannel DAC for example either on a small custom board or there are NI/Keisight/anyone else products that can do that) or in software (if an external adc is used you can just use an FPGA/PLD to feed data from a PC) and again there are commercial products to do that as wellin the end it is the same problem we have when for example we have to build a car's ECU, we can't ask our boss to buy us an engine Test bench, an engine, and the spare parts for when it will inevitably break/explode because we need the complete real system before we start working

author: ondreji
author_rank: Contributor
timestamp: September 01, 2016, 02:27:14 pm
content: Have a look at Kanban. It makes sense for HW because it tracks work in progress and it's completely customisable. Each sub-system can have own board with a different set of columns (basic set of columns: "backlog", "doing", "done").Each column should have a limit (WIP limits - maximum number of tasks in a column (this can be per team or entire board)) which is set by the project constrains, such as number of engineers, workbenches, ... When limit is exceeded then the whole team should take responsibility and figure out why this happened.Columns should have entry or exit criteria (not both), such as "Design review done"Tasks are sticky notes with brief description. Persons are assigned to the task by attaching another sticky note (or avatar) with name. In some teams task gets a new date sticker with the current date. In this case (compared to writing date on the note) is easy to see progress on the task.

author: hendorog
author_rank: Super Contributor
timestamp: September 01, 2016, 08:12:36 pm
content: Quote from: filssavi on September 01, 2016, 01:44:20 pmQuite - and you know far more about those constraints than me - however compare with the other approach in which would have no working model to use at all, no software to use for testing against and the rest of the team off doing other projects as they are all waiting on you.I know which situation I would rather be inQuoteI'd have no problem if the internals are stunningly ugly as long as there is a replacement or improvements planned and it is 'componentized' in some way - meaning it is wrapped in some interface which allows something better to be plugged in. I'm older and more pragmatic than most though.Making the internals of software perfect before making the software actually work is something that software people often go overboard on IMHO. Again this depends on the personnel.QuoteYep that all makes a lot of sense - the project and the team dictate how you solve problems like that, not the methodology.The methodology just gives you some principles, the team gets to exercise their grey matter to work out the best way to operate. Out of the box lateral thinking is quite valuable.In my example the lack of spend on an iterative hardware approach was a false economy (in hindsight!) as we spent way more in time and lost opportunities. It was just an example and probably not typical of projects you will see.Other projects will have different constraints and we all have to work within those.

author: Miles Teg
author_rank: Regular Contributor
timestamp: November 16, 2016, 02:05:28 pm
content: My company is going on the open innovation train.We are sourcing lot of products, but making few real HW and SW design.And as HW engineer I'm now ask to focus on provide support for functionalities research.Exagerated example: somebody got an idea of putting Wifi and a new user interface technic on a coffee maker. or a camera.And when I ask "what are the rough specifications for the camera" "don't know, could you help to set the specs?".So i'm no more involved in designing electronic for mass production. Now I'm more on prototype and demonstrator. Prove that putting 3D gesture radar on a toaster handled with an android is finally a good idea or not.And so I'm following my software colleagues (Smartphone and embedded) in there sprints.First sprint I provided Raspberry pi with camera and wifi dongle, to let them code asap.And I was fast going in a "one sprint in advance" to build the next iteration of HW.Currently on Cortex A System on Module small enough to fit on my PCB that could be integrated in the target product.Every month, at the sprint review, "customer" come to see the result and adjust requirements. Help him to realize which HW could make such performances, same validation for embedded SW perfs and smartphone app UI.At our "project" end we have a proof of concept with a rough possible cost, validating the idea or not and much more precise ideas to write real specifications for a dedicated PCB and product factory (with a real planning).Doing modular?I will bend on the modular side to reuse my functions modules to output functional monsters as fast as possible. Assemble a dev kit for SW team and get some time to gather my schematics blocks on a better integrated PCB (without EMC or certification concern).And build modules for new technologies or component feel less risky, don’t need to throw away a whole PCB because I didn’t know already how a component could really work. This makes me more ambitious to test new things.We work like this since few months only (and only 1 sprint completed following closely Agile manifesto/scrum). I feel it could be good to “sprout” new product ideas on prototype.But I feel already also the dephasing between HW and SW development time (that’s globally longer than my PCB generation). And other times I have to wait 1-2 weeks bare PCB and components deliveries.But anyway for our designs, SW dev is the bottleneck. And “stories” are mainly defined by them.So I follow as HW service provider.I feel there is a real benefit to prototype to build real good specifications for “new different” products.Here was my first impression to apply agile for our specific needs.