I disagree, having taken part in agile embedded development.
Sure, it looked a bit different from pure-software, but the same underlying principle of short iterations applied. Our definition of "short" was a bit different, but still...
And yes, you may have some "very specific" requirements, but you may also have some "pretty loose" ones -- just like software.
> But... I think there are lots of ways to do quick experiments and tighten up the feedback look even with robotics or electronics. Breadboards and development kits can be used as initial electronics prototypes. 3d prints help test a mechanical concept
See, there you go.
The core idea behind Agile isn't to have sacrosanct two week sprints (or even to have sprints in the first place), it is to close as many feedback loops as you can as quickly as you can. Whatever that means in practice.
This has been good engineering practice for longer than software exists.
I read that the Mercury space project created their software in half-day "sprints". Back in the '60s, on punch-card machines (I guess).
No, not at all. Just maybe a little... narrow?
> observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint.
Quite quickly, yes.
The next sprint...maybe? Not necessarily.
Sure, you'll stick it in the backlog. But whether you'll start working on this improvement immediately is a separate matter. If that's the best course of action, sure, do it. But maybe you have more pressing matters, and the present implementation will do for now. Or... it's not possible to attack it in the next sprint, because a new board needs to be spun, and that takes preparation. Then it'll be slated for the appropriate time, by necessity. That doesn't mean you forego an agile approach -- it just looks different, because the landscape is different.
> Especially true when the project gets closer to start of mass production.
Sure. Which is why being able to make, and find, and correct your mistakes early, when it's not so dramatic yet, is the goal of that whole Agile song and dance.
As you're intimately familiar of course, surprises in engineering are usually the bad kind, and the later they come, the worse they catch you. So, have as much feedback as you can, as early as you can (and with as much fidelity as you can).
I don't think a single compile cycle per half day meets most people's definition of a sprint...
Hm... I read this quite differently than you do. Not compile cycles, but actual test-driven product iterations.
Do you have more solid sources than I do?
https://intenseminimalism.com/2012/a-brief-history-of-agile-...
1) "A brief history of agile methods" asserts:
1958 — Project Mercury (NASA) software development, ran with half-day iterations.
The only thing that looks like it could be intended as evidence for that assertion is the Larman and Basili article.
2) "Rockets before Rovers" asserts:
Project Mercury did half-day iterations with test first development!
The only thing that looks like it could be intended as evidence for that assertion is the Larman and Basili article.
3) So there only seems to be one source — Larman and Basili "Iterative and Incremental Development: A Brief History" — which asserts:
"Project Mercury ran with very short (half-day) iterations that were time boxed." page 2
[pdf] http://www.craiglarman.com/wiki/downloads/misc/history-of-it...
Where's the evidence for that assertion?
afaict the Larman and Basili article does not provide a source as evidence for that assertion?
So we're left with nothing.
Every phase of the project has iterations, but iterations stress different things (requirements in the beginning, construction and handover in the latter phases).
Now, most people who say they do Waterfall are quite mistaken. They don't, they do some sort of iterative method as you say. But they report as if they have distinct, linear phases with distinct linear steps, as if Waterfall were the reality and not an imagining. Which is itself problematic. This means that upper managemnet comes to believe that Waterfall works because they see it working, not realizing that the reports themselves are misleading.
Everytime one of the project managers tells me they're doing Waterfall I press until they admit it's "Modified Waterfall", by which they mean the V-model or Spiral or other models with explicit feedback loops/mechanisms. And it frustrates me to no end that they keep using the wrong terms rather than the precise ones, because now upper management has begun enshrining Waterfall again after two decades of improvements. Now we have to fight the same battles, to impress upon them that iterative methods are what we actually do, and that a strict linear flow is impossible.
It feels like the Bruce Lee idea of "take what is useful and leave the rest" but either the opposite or a bastardized version. Like, take what is easy and leave the nuance
I see, whatever this idea/principle would be called, all over.
Then like evolution, it's survival of the fittest with the entrenched old idea having the heavyweight advantage.
BTW, this is a great point you make! I hope my comment doesn't seem to discount it as your thought made my mind go to the experiences I have seen that led to this comment.
> Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle.
> Cargo cult programming is typically symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution
> The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position.
Why does Kanban help in some offices and do nothing or hurt in others?
Two reasons for success: Luck or understanding. Two reasons for failure: lack of understanding or lack of commitment.
What does Kanban assist with, what principles?
It assists in elaborating and clarifying the workflow or processes in the organization or unit. This can be done many ways, Kanban is just one. But without understanding the, often unwritten, processes you cannot effect meaningful change (at best you're stabbing in the dark).
It also emphasizes focus by setting limits on "work in progress" which improves overall flow/throughput. It turns out that this is, generally, a good idea.
The ones who succeed don't succeed because of Kanban. They succeed because of those two basic principles (and other related principles and concepts that I'm not elaborating on here). Kanban was a mechanism which led to success by drawing on these ideas.
The ones who fail don't fail because of Kanban. They fail because they don't control WIP, or failed to describe their process accurately, so it provided no, or perhaps even negative, value. Why don't they control WIP? Maybe they aren't aware of that element of Kanban, or they don't believe that it can bring value and ignore it. They're too busy fighting fires so they don't have time to focus. Why don't they have an accurate process description? Often, because the process is dictated rather than discovered (You are doing X, even though you actually do A, B, and C).
That's just one practice and two principles that it is related to (there are others). This is the problem with Big-M Methodologies like Big-S Scrum and Big-W Waterfall and Big-A Agile, the easy part is the visible practices. So they're imitated. The hard part is the invisible principles and hidden practices (all the work that went into identifying the workflow, for instance). Repeat this across all the practices in these methodologies and you'll end up with a mess that succeeds by luck, or at least doesn't harm you so badly that you fail, but certainly doesn't offer significant assistance.
With quick-turn fab houses, you can do two-week sprints in hardware. You can fix up the circuit with X-acto/bluewire changes, and roll the fixes into the next sprint. Or you can make individual subsystems per sprint.
And with firmware, most software methodologies work with minor changes.
Usually you can get something working in the first sprint, and iterate from there.
For a simple project all of that can be managed iteratively.
Not everything has to be changed, that's just a strawman.
But not every detail has to be nailed down at the beginning either.
The idea behind Agile is to reduce risk. If there is no risk of the bus system changing on you, there's no harm in fixing it right at the beginning.
But if there is a chance it might, you'd do well to have systems in place which enable you to react to changes with a minimum (though non-zero, of course) amount of pain.
It's impossible to foresee those all in advance—better to adopt a system that is structured to anticipate them. "Unknown unknowns" are a fact of life, no matter how disciplined we believe we are with our preparation.
"Ah, you have hardware version 2.3.1.3 - yes, it does sometimes emit sparks - we fixed that in the version that came out the month after."
Physical safety risks are an exceptional class of defects that in most jurisdictions has a legal requirement for the vendor to fix or replace the defective part(s) at their own cost (not to be borne by consumer).
Point: SPECTRE/MELTDOWN were not "physical safety risks". Yes you can argue they are security risks, but they didn't physically manifest as a physical safety risk which can lead to severe injury or loss of life.
Your commentary seemed to suggest you were not attaching an appropriate level of mental priority with regards to the severity and risk.
I was once in a meeting with some hardware people who were looking for help with the UX and complementary app for their product. They had already locked the hardware design, but had yet to decided what the buttons would actually do. Essentially, they were looking for help to come up with features for the buttons.
Thankfully I didn’t get the job.
This is unusual to my taste, but thinking about it, I half expect cheap appliance and toy vendors to work like this - decide on a microchip, and only then figure out what to do with it and how.
Modern software projects seem to just start with people typing and little upfront documentation. A long time ago there was documentation (flow charts, Booch diagrams). Now whether these are useful seems debatable, but I do not see any upfront analysis done with software.
You can still use some agile ideas when working in electronics, thought it might look quite differently than in software.
For example, if you are a startup and your plan is to create a super duper wireless speaker with bluetooth, wifi and AI, you could first build a wireless speaker with only bluetooth, and sell that. That way you build experience with producing speakers, sales channels, manufacturing, sourcing etc., and build a customer base.
Then you could ask your customer base if they'd prefer wifi or AI in the next model, and iterate accordingly.
This is not the same as doing one-week sprints in software, but it does iterate that you can start small, build and sell small, viable products, and work your way up to the intended product.
These quick loops are really the only difference, and are precisely where the advantage lies.
And having as short feedback loops as you can get away with has been sound engineering practice since before software was a thing.
The difference now is more bureaucracy under agile.
Building the actual bridge on which people will expect to drive or walk or whatever is probably better thought of as deploying a bridge (design), even if it inevitably also includes some ad-hoc on-the-spot development too.
But when developing a new bridge design, it seems extremely valuable to be able to iterate as quickly as possible.
They did do it. The MAX part of the 737 MAX was basically an agile iteration on top of the existing design.
>But when developing a new bridge design, it seems extremely valuable to be able to iterate as quickly as possible.
Seems like a new and innovative way to design things. Bridge 2.0. Bridge MAX.
You'd obviously want a new, experimental, or prototypical design to fail ASAP so you can fix whatever the problem(s) are sooner than later.
I'm pretty sure most bridge or airplane failures are either due to mistakes made during building or, probably even more often, failing to maintain (and monitor) its condition.
But the whole point of agile is to make, and release, smaller sets of changes at a time precisely so those changes can then be tested or validated more quickly than otherwise. That may – probably is – more difficult with airplanes and bridges versus software so the relevant tradeoffs are different, but the basic point about minimizing the duration of making changes so those changes can be tested sooner seems equally applicable.
Let's think about bridges. I'm sure most bridges use a standard design with standard materials – that part then has already been tested and validated. But even at the stage of evaluating a standard bridge design and whether and how it could be built in a specific location, I'd imagine an 'agile' methodology would be better than a 'waterfall' one in terms of testing or validating a tentative plan, i.e. you'd want to address the highest priority risks first, and 'fail fast'. You wouldn't want to create a final proposal if you knew up-front that there was no way to anchor a bridge of a certain design in the designated location.
https://hbr.org/2016/04/the-secret-history-of-agile-innovati...
On a different note, it is also interesting that stand-up meetings seem to be popular in many companies again, after going through a period where snippets tried to fill role of stand up meetings.
http://teche.ltc.mq.edu.au/human-science/getting-s-done-goog...
The Agile Manifesto was largely a reaction against the blind application of process developed for civil engineering to software development, and the features you point to are real reasons that civil engineering process is a bad fit for most software development.
But the Manifesto doesn't specify process, it proposed priorities and objectives that should be considered for process that (changing only the words “working software” to whatever it is you want to produce) are fairly broadly applicable.
Of course, most “Agile” shops aren't Agile at all, they are improved over what the Manifesto reacted against only in the small way that the process that they blindly impose without applying the considerations of the Manifesto is a Frankenstein’s monster combination of things other people designed for some other team (probably not all the same team) working on some other problems (probably not the same problems) in some other part (probably not all the same part) of the software industry.
I disagree; I think those priorities are appropriate because of the unique situation of software development. Prioritising individuals and interactions over processes and tools makes sense because it is easy to adapt and modify software tools, and because software allows abstracting out any form of repetition without needing to make it a process. Prioritising working software over documentation makes sense because source code is understandable in itself to a much greater extent than physical artifacts. Etc.
No, it makes sense because the processes and tools don't work if they don't work with the individuals and their interactions, and that's true in much wider domain than software development (it's true of any highly skilled, or even more generally labor-supply-constrained, work, where you can't easily replace the workers with ones that fit the preferred process; it may be applicable even more broadly, since sense of ownership of process can be a morale and productivity booster), so the process and tools must be subordinated to the team rather than vice versa.
> Prioritising working software over documentation makes sense because source code is understandable in itself to a much greater extent than physical artifacts.
No, prioritizing the production objective over supporting artifacts makes sense because of the fundamental nature of an objective. That's just as true when the production objective is not software (doing so will result in different levels of documentation and other supporting artifacts for different production objectives, sure, and software may often have lower documentation needs than many other tasks, but the prioritization isn't about do less documentation, it's about “do only, but still.all of, the documentation that has utility outweighing cost in support of the production objective of working software”.)
This is backwards. Software enshrines the repetitive business process and (hopefully) automates it as much as possible. This is happening regardless of whether that business process was defined before the software was implemented.
> Engineering systems requires an engineering process and discipline, and agile is just not up to the rigor.
Agile just means closing as many feedback feedback loops as you can as early as you can, and to preserve opportunities to course-correct for as long as you can. All this to keep the destructive effects of surprises (which are sure to catch you) as low as possible.
This is good engineering practice, plain and simple.
1 - Is it a domain where "user story" means something? 2 - Is it a domain where you can iterate fast?
Usually for UI these two conditions are met. From my experience, when talking about big infrastructure projects, they aren't
All else equal, smaller or shorter feedback loops are better. And often shortening a feedback loop is worth considerable tradeoffs elsewhere.
It's certainly the case that being able to iterate fast may not be currently possible, but being able to do so, or even just being able to iterate faster should probably always be a priority (even if not the top one).
This all applies even to physical real-world infrastructure. I remember a story about a city somewhere (South America?) where the mayor (?) was able to shorten the feedback loop whereby roads were built or repaired. That seems like a good, even great, thing, even at somewhat considerable cost.
What kind of big infrastructure projects were you thinking of specifically?
Maybe a bad example, but it's basically mandatory to include a manpage for a cli utility, but do you always include drag & drop for a file uploader?
We have an API that is used by external systems, those systems (and developers) are our "users".
It's vital to think of API consumers as users, because it avoids the "REST is CRUD" attitude by focussing on the business/system functions that are being expressed, which leads to focussing on the Nouns, not the verbs of the business.
There, fixed it for you.
News for you: Not all software has the tendency to become a giant mess.
Without discipline, I'd agree with beat - any process will produce code that becomes a giant mess.
However, I still think waterfall is the only approach when trying to design a hardware product. Electronics require pretty specific requirements up front before you design and order boards, obviously mechanical tooling can be even more expensive.
But... I think there are lots of ways to do quick experiments and tighten up the feedback look even with robotics or electronics. Breadboards and development kits can be used as initial electronics prototypes. 3d prints help test a mechanical concept. Within each phase of the design more experiments can be done. But ultimately the project is probably more waterfall than agile!