The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Well I think the problem is Software want the hardware to change to meet there demands. At times we have had ARM9 used in place of a PIC for controlling some LED's... I mean come on that is plain overkill!
This is plain wrong. It is *possible* for software, but it does not make it *fine*.
Agility does not mean you can handle changes until last minute (There is no time machine sold with the Agile manifesto package). Agility means that your organization is capable of optimally cope with changes - refusing a change that comes too late for a deadline is also a perfectly *good* way to handle a change.
Oh boy. Trying to fit a square peg into a round hole. Either the square peg need to be shaped to round or the round hole need to cut into square. I understand your dilemma. The hardware is a square and you want to be catchy round process. Don't fight it mate. Keep them separate.
If you find one, please let me know. I work for a hardware company, managed by hardware engineers.
"By God, those flaky software monkeys will learn how to manage their projects just like hardware! There will be processes, appropriate documentation (and we decide what's appropriate), and they will write Engineering Change Orders (ECO's) for every single update. No more of this seat-of-the-pants willy-nilly updating!"
The key question in all these techniques is "What is the key constraint, or freedom, that stops / allows work to proceed?". It's all about the [theory of] constraints, e.g. Eli Goldratt, 'The Goal'
In agile it is the realisation that the manufacture cost (running the compiler) is almost zero, so one can concentrate on the other problem - do we know what we want, i.e. continuously ask the customer if the product is what was expected.
For the Circuit board design, the layout of the board is a time constraint, along with knowing if the customer has their external circuitry stabilised (there it's about the interface(s)). So concentrate on getting the time killer (and or cost / quality killer) right.
All in all, the best development strategy is to engage the brain, learn from others, and avoid blindly copying the many misunderstood fanboy techniques. There are no silver bullets (see “The Balle-Argentee Method.”).
1. Use your head.
2. Look at the original agile principles (not the myriad of implementations).
3. Look at the underlying principles in Kanban and waterfall.
4. Consider an underlying strategy that made NASA's moon landing project and the US Navy's Nuclear Power Program so successful - value engineering.
5. Once you understand the principles of various methods, come up with a strategy for managing and development of projects that fits the needs (as opposed to trying to change the need to fit some process). What works for hardware does not have to work for software. Adapt and overcome.