AgileFall does sound like an unholy mess, taking the worst aspects of both Agile and Waterfall!
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!
> 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.
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).
Maybe I am wrong in my understanding, but for agile to work, observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint. For the hardware where the validation can be quite lengthy, this is feedback loop is much, much longer. Especially true when the project gets closer to start of mass production.
> 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).
There's a talk well worth watching by Kevlin Henney called 'Old Is the New New' [1], where he points out that waterfall was initially conceived with design iteration in mind and yet that part was just essentially forgotten and replaced by something overly-simplified in common understanding.
Every phase of the project has iterations, but iterations stress different things (requirements in the beginning, construction and handover in the latter phases).
Tragicaly, it's not a strawman, it's an enshrined project management method the DoD created from a misunderstanding of Royce, which escaped into the wild.
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.
Some anecdotal evidence that waterfall is not a straw man: at least 10 years ago, waterfall was taught as waterfall without iterations at some German universities. This was the starting point, and many derived models, like the V-Model, where also taught, but iterations we’re nowhere in sight.
What's a word or phrase to describe this idea/principle?
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.
From what I have seen it's probably more "keep doing the old things + add the name of and a part of some new thing."
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.
I think you nailed it! From the Wiki on 'Cargo cult programming' but I think 'programming' can be subbed out for anything.
> 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.
Ha! $NEW_JOB instituted "daily scrums" alias "standups" like my second week here where 10 of us sit down in a meeting room for anywhere from 15 to 45 minutes every damned morning to talk about what we did the day before and what we're doing that day. Maybe what we do is ScrumFail? We had no process at all before other than what apparently is not actual waterfall but fits the literal description of a waterfall in that requirements pour down upon us from a tall precipice.
That is a great example of the problem. This is also why I keep trying to get people in my office away from specific practices and big-M Methodologies and focused more on the principles at play.
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.
Your absolutely right, and with a modular system design it can make it easier to plug in iterations of individual components. But at some point early in the design you need to lay out how the modules will work together, i.e. do we use CAN? 24V power or 48V? All that can be changed as well but at some point it gets complicated!
For a simple project all of that can be managed iteratively.
> All that can be changed as well but at some point it gets complicated!
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.
All the more reason to use an agile approach! The only reason you would be making those major changes is in the face of new information: a change in requirements, an unforeseen challenge, etc.
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.
Wrong. There are hardware bugs that do not manifest as physical safety risks.
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.
I have no real experience designing hardware, but I do have a story about extreme waterfall in hardware design.
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.
I think it could be. E.g. when making a low-cost consumer appliance. They must have had some idea of what they were building, enough to say that the upper bound on the number of buttons they need is N. This just creates a design constraint - they now have to figure out how to do something useful and ergonomic using no more than N buttons. The exact shape, form and placement of those buttons is orthogonal to the electronics and software part, so they didn't limit themselves there.
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.
Looking at almost any car, even in recent years, you will see blanks for features that may or may not be present, that need buttons if they are there. They may be more obvious on some cars than others, but even luxury cars have them.
I've done both hardware and software projects. My hardware projects began with an analysis phase where feasibility studies were done to answer questions like, can we build it at the desired frequency with current technology? No actual work on the project would be done at this point, since it was at risk of being thrown away.
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.
With hardware you can check your designs against the laws of physics. With software there usually aren't any such laws. Being a guy who has actually written a 1300 page requirements document in my career as well as large books full of designs, my experience has been that the only thing you can test them against is code. Usually you are wrong :-). It's much better to start off with tiny pieces and make sure to write a lot of code along the way. Exactly how much upfront analysis you need before you start writing code is a judgement call, but I would say that it's almost always safer to err on the side of writing code too soon.
> However, I still think waterfall is the only approach when trying to design a hardware product.
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.
This is different. Agile and waterfall seem to be defined over the lifetime of a product. Iterating the concept over several products while doing waterfall on each design sounds like a combination of waterfall and agile. I'll be clever and call this transmogrification "agilefall"
I think agile could work just fine even for airplanes and bridges, and I imagine people are already doing it.
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.
Well, yes, and un-ironically – during the development of a new airplane or bridge design.
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.
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.
Agile exists for the particular constraints of software development, where requirements are unknown, change is relatively cheap, and feedback loops are very tight. I wouldn't expect it to be appropriate to other domains.
> Agile exists for the particular constraints of software development, where requirements are unknown, change is relatively cheap, and feedback loops are very tight.
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.
> 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.
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.
> 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.
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”.)
> ... software allows abstracting out any form of repetition without needing to make it a process.
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.
I would go futher and say that Agile exists for the particular constraints of UI software development. User stories, Product Owners and Agility break down if you're building core infrastructure
Amen! When your product requires true engineering, agile just causes you to keep chasing your tail. Engineering systems requires an engineering process and discipline, and agile is just not up to the rigor.
> 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.
Agree with you and parent. "Agile", in it's current form, is managements holy grail pursuit of commoditizing software development. It's the latest management fad to circumvent the law of fast, good and cheap. Quality software is engineered and is expensive to develop.
Doesn't infrastructure have users too? Why wouldn't 'user story' mean something to them?
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?
UI specifications are inherently incomplete and often require feedback from stakeholders. You're developing software for consumption by regular humans with feelings and emotions instead of for another computer or developer. Then there's the "implied" specifications which could be anything from current design fads, to legacy support, accessibility, usability, and plain old opinion.
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.
It seems every time I read an article where some Agile consultant extols the evils of waterfall the author commits a Just In Case Fallacy or the lede is buried. This article is no different:
Teams only checked in – wait for it – every three months in a formal schedule review. I listened as Henrich mentioned that the teams complained about the volume of paperwork he makes them fill out for these quarterly reviews. And he was unhappy with the quality of the reports because he felt most teams wrote the reports the night before the review.
That's not a problem with AgileFall or ScrumFall, that's ineffective management irrespective of how the sausage is made. But nobody has to wear the Scarlet Letter of Project Failure if we assign blame to the process!
I've also never found that pure (like the wind-driven snow capital-A) Agile matches reality. After spending more than a decade wrestling with it - I still haven't figured out how quality assurance and test fits into the same iteration in Agile. Most teams I inherit have non-technical QA resources. Most projects I inherit have complex business logic and integration needs that aren't easily testable until some state of development "done" has been achieved. And time and time again I find myself staggering their effort slightly behind development so that test and development resources aren't taking turns sitting on their asses waiting for the other side.
I've written about this before as was even been publicly admonished by an Agile Manifesto signatory (hallowed be their names) that I was doing it WRONG WRONG WRONG! But I was never able to figure out how to contort reality to satisfy their criticism. Believing in iterations and backlogs and prioritization and shortened feedback loops wasn't enough. Thinking QA - any QA! - occurred AFTER any development was done was altogether impure. And despite asking repeatedly for concrete examples of how its done the "right" way, the only responses I received were vague platitudes and consultant sales blurbs that I guess I wasn't smart enough to understand.
In the end, I don't think there's any escaping that work has to be done in a sequence: identify a need, identify a solution, implement the solution, validate the solution. And so every software project has at least a little bit of waterfall mixed in.
> I've also never found that pure (like the wind-driven snow capital-A) Agile matches reality.
Pure Agile (the Manifesto and Principles) are all about adapting to reality.
Canned process sold as “Agile” probably won't work without adaptation to your concrete circumstances, but that problem that invariably comes with using canned process rather than team-owned process adapted to the team and their concrete circumstances is exactly the problem that motivated Agile.
That some of the signatories of the Manifesto are now on the dark side peddling canned, one-size-fits-all (but none very well!) process is annoying, sure.
> I still haven't figured out how quality assurance and test fits into the same iteration in Agile
Sometimes it won't. From your description, the concrete composition of your team with regard to those functions sounds problematic for that. In the long term you might be able to evolve your team to alleviate that, and maybe that is desirable, but in the near term, well, “people and interactions over processes and tools”. Forget what any guru tells you about the right way to do Agile if it doesn't work for your team dealing with the problems you face, and especially if they are just telling you your way is wrong without even proposing a testable alternative.
Agile isn't canned process, it's the rejection of canned process in favor of empowering the people actually doing the work.
Very few people have that flexibility of mind, in my experience. It is in the manifesto "while there is value in the items on the right, we value the items on the left more". I (may) be able to point out you failed here. Agile doesn't reject anything, including process. It just states that it values some things more than others.
Process is often vital. I used to write avionics software for the military. As you might guess "move fast and break things" was not our mode of operation. Retrofitting a helicopter requires massive amounts of process and waterfall. You can't not follow a plan. You have to decide where you are putting the electronics, and the specs on rack sizes, power, etc. Then you design the electronics to that. Then it needs to be manufactured, and so on. You can't decide at the flight readiness review that you want a screen on your radio that displays the weather.
This is really old stuff. I was taught this (agile way of thinking) in college in 1983 by an electronics professor. He stratified it differently, talking about goals, strategies, and tactics. People get hung up on tactics - "all code must use lower snake_case variables", or "stand up can't be a status report", or, .... But those are all tactics, in service of a goal. You need to remain flexible he lectured (and I agree), and recognize when the goals have changed, and/or when tactics and strategies conflict or make things non-optimal. That's all pretty much what the agile manifesto says, except they impose a weighting on values that I don't think fits all cases. As in my example above, sometimes process is more important, despite the many costs that kind of thing incurs. Cause, you know, we don't want people to die when they fly the helicopter.
And in that helicopter retrofit, the SW lead (Hi Paul!) had a saying "design a little, code a little, test a little". It was never waterfall, even back then, though you were in a waterfall process necessitated by the reality of complex projects. It was all about responding flexibly where you can, and being rigid when you can't. You don't push a sw patch 2 days before the flight readiness review. You don't decide to add components to a radio if it exceeds the designed power specs of the power network in the airframe. And so on. You may be able to change a screen element on a flight computer if the pilot suggests something is confusing or sub-optimal, but even that has high costs (revise all the training materials and documentation, simulators, etc, run all pilots through the training, it can run into millions). Always think flexibly about why you are making these decisions, why you are doing this, why you, say, empower people vs canned process, as you stated.
Without that, you are just back to unthinking process, claiming to be agile while you are anything but.
Back to how I started - I have yet to come across anyone running around extolling a specific methodology, including agile, that was anything but unthinking, inflexible, and unable to answer real world questions. It's just particularly ironic given the name 'agile'.
Edit: I left something unsaid, and it's important. The Agile manifesto is at the level of 'strategy', not goal. It is not ever our goal to "respond to change", as it states. That's a strategy. Our goal may or mat not make that strategy possible or desirable. I don't want to kill people, so if I'm making a helicopter change has to be planned out very carefully. Agile is mostly a set of strategies aimed to get working software into the hands of clients as soon as possible because things like specifying what you want, pricing out development costs, and so on are so hard. That often just doesn't hold. While I can't disagree with what is written given the states objectives, I think it is just another somewhat inflexible way of thinking about systems. It works for a lot of bay area type development, but goes off the rails in many other domains if you don't recognize the values listed, and the relative weightings, are based on a number of assumptions about what your real goals are.
I agree with the vast majority of what you say, the responses below are not disagreement so much as clarification or elaboration of related points.
> Agile doesn't reject anything, including process.
I said Agile rejects canned process on favor of empowering the people doing work, not that it rejects process. By canned process, I mean externally-imposed process not owned by and adapted to the needs of the team.
> Process is often vital.
Process is always vital; Agile (the Manifesto/Principles) is very much about how you get the right process for the team and moment.
> Back to how I started - I have yet to come across anyone running around extolling a specific methodology, including agile, that was anything but unthinking, inflexible, and unable to answer real world questions
Agile is not a specific methodology; it's a loose philosophy about parameters for a meta-methodology that enables you to continuously optimize methodology.
People selling a concrete methodology and calling it Agile are either missing the point of Agile or hoping their customers miss it.
The in-house coach pushed back mightily against hiring an engineer with a QA background with pretty much the exact same reasoning. The testing would be done in the sprint by the team, so there was no reason to proceed with the hire. The reality of the production code clearly showed a different reality, but the attempts at persuasion were made anyway.
I observed one of the Manifesto signatories for the first time last night. Superb presentation skills, I'll give them that.
I'm more of a Taoist than a Confucian (and a sysadmin to boot) in this sense: The system which can be defined is not the true system.
I wonder how much we've lost as end-users dealing with completely broken software due to Agile cargo-culting and the increasingly diminished (now gone) role of dedicated QA?
> The system which can be defined is not the true system.
My Grand Unifying Theory of Explaining Agile Proselytizers™ is "if it's not working, you're doing it wrong". True Agile always works.
Oh, and it has more-frequent check-ins/iterations than Waterfall (which is the defining aspect of Waterfall: fewer check-ins/iterations than Agile). The actual frequency is undefined, it exists only in comparison to Waterfall.
---
The problem is that that kind of stance does nothing but fluff up agile consultant's resumes. It doesn't actually lead to improvements that last, or even discussion that might lead to improvements. Agile is perfect because it's Agile.
> My Grand Unifying Theory of Explaining Agile Proselytizers™ is "if it's not working, you're doing it wrong".
If it's not working, but you keep trying to do it the same way (whether because management tells you to or because a book or consultant does), you are doing it wrong. Because Agile is very little except the team continuously adapting process based on observation of what does and doesn't work for them.
(Waterfall can be Agile, but only if it is waterfall adopted because the team views it as the best way to deliver working software in their particular circumstance and is continuously open to reevaluating that conclusion based on evidence. Agile isn't opposed to waterfall but to the way Waterfall was imposed. Which is also the way Scrum and variants are now frequently imposed, producing the same kinds of problems of process/problem fit.)
I suspect one of the key things missing in most people's understanding is that agile is part of the "continuous process improvement" camp. It is a set of principles, values, and practices which should be examined, in addition to the work being produced, and improved over time.
Sterman's book Business Dynamics has a great diagram that I think is relevant (I saw it there, but it's probably in other books on system dynamics and related fields). I'll attempt to ascii art it here:
Mental model -> Strategy/Structure/Decision Rules
|
v
Decisions
^ \
/ \
/ v
Information <----- Real World
Feedback
That is most people's and organization's view of the world. They have a model, they develop strategies (practices, methods), then they implement them. Feedback from the real world informs their next decision, but they don't go back and reevaluate the initial model and strategy.
A learning organization, continuous improvement, agile, whatever you want adds an additional loop. The information feedback gets pushed back into the mental model:
Mental model -> Strategy/Structure/Decision Rules
^ |
| v
| Decisions
| ^ \
| / \
| / v
Information <------ Real World
Feedback
The Agile Manifesto, in the twelfth principle, emphasizes this aspect:
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
This is not unique to agile, it is just emphasized in it. This is not a superfluous detail, this is actually critical, and commonly missed.
This makes me smile so much. As I have commented before no one can actually agree what Agile is. someone always says it doesn't work for them. Someone always replies with "your doing it wrong" with absolutely no indication of how to do it right.
Thankfully the agile trend seems to be left out of interview questions these days.
"Do you do Agile?"
- "What do you define as Agile?"
-"Does anyone NOT do agile?"
-"Do you think it actually makes a difference?"
would be the responses that cam to mind. Apparently I didn't get a job based on a variation of the last one. They thought I would be difficult to work with.
As far as I am concerned, everything you need to know about agile is on this page: https://agilemanifesto.org/
So looking at this:
> After spending more than a decade wrestling with it - I still haven't figured out how quality assurance and test fits into the same iteration in Agile. Most teams I inherit have non-technical QA resources. Most projects I inherit have complex business logic and integration needs that aren't easily testable until some state of development "done" has been achieved. And time and time again I find myself staggering their effort slightly behind development so that test and development resources aren't taking turns sitting on their asses waiting for the other side.
That sounds like you're following "Individuals and interactions over processes and tools" and "Responding to change over following a plan" quite well. The "QA while you develop" process wasn't working for the skillset of the individuals on your team, and so you prioritized the individuals over the process, and responded to the change of understanding instead of following the plan you now knew was bad.
So, public admonishment of Agile Manifesto signatories be damned, you were doing agile, and anyone (including Agile Manifesto signatories) who tells you otherwise can be told to go read the Agile Manifesto as many times as they need to in order to reach enlightenment.
The problem is, money ruins everything.
Once you sign your name to the Agile Manifesto and the Agile Manifesto becomes famous, the tendency is to try to capitalize on that. And the ways you capitalize on it is by pretending you hold some special knowledge that you can teach in a workshop or give a certificate in it.
However, the Agile Manifesto isn't some special knowledge. It's admirable because it articulated an important set of ideals succinctly and clearly, but it's really not anything that a moderately intelligent developer doesn't intuit with enough experience, even if they can't so clearly articulate it. And you can't really teach it in a workshop or give a certificate in it, because the application is different for every team. The way you apply agile is by getting intimately familiar with the individuals involved in the team and slowly adapting the process to fit their needs: you can't choose individuals and interactions over processes and tools if you don't know what the individuals and interactions are. The agile manifesto may be about individuals and interactions over processes and tools, but processes and tools are a lot easier to sell.
This means that even if you came across the Agile Manifesto and really grokked it, and maybe even signed your name to it, you've got a powerful incentive to then go forget everything you've learned.
In a broader sense, this is why ideas have to be evaluated on their own, irrespective of who those ideas came from. Ideas can be perfect--humans can't.
Great point. Agile is what is in the manifesto, including the agile principles. Everything else is people interpreting to match their agenda. i.e. Sell consulting services, stay in the top of the food chain, etc.
The truth is - to be agile you embrace Waterfall if that's the best approach for the project/team/client. Agile is about being flexible and adaptable in your approach in order to get the job done.
Anyone who tells you it's anything specific is trying to sell you something.
The last full system I delivered was created using a sort of waterfall/agile hybrid. We worked from a backlog, in short-ish sprints, but nothing was put into production until a certain milestone was reached, after multiple sprints.
We were replacing an existing, legacy system, and even though we switched over "piece by piece", each module of the old system was at least 10-12 sprints. And the end-users couldn't do a meaningful test of their normal tasks until most of each module was implemented.
How to teams who manage to work more "agile" do this sort of thing?
This seams a pretty reasonable approach to solve this problem. The only improvement I could think of is to "mirror" the data or API calls to the new system so it gets battle-tested earlier, but that only works for backend systems.
That only works with similar architectures. I've been involved with converting mainframe batch systems to service-oriented architectures on distributed systems, and that sort of mirroring does not work at all.
It's fine for prying microservices loose from monoliths for relatively modern REST api systems, tho. Big problems I see there are that the problem often isn't the code, but rather the api itself that's a mess, and evolving the api breaks client code which you may or may not control.
The problem is that you're building a new system to completely replace an existing system, and the existing system is tightly integrated in a way that makes piecemeal change difficult to impossible. And the new system isn't just a refactoring for bad code - it's a redesign in the name of new functionality.
In this particular case, it was a banking system that worked largely by nightly batch jobs. Data queued up during the day was processed at night. Job A triggers Job B, which Triggers Job C; etc. What we wanted was to change those batched transactions into individual transactions that could be processed in synchronous quasi-realtime.
With reconciliation happening near the end of the batch processing, how do you do that?
And mind you, this system moved more money every day than the GDP of many countries. Failure was NOT an option. Not if you don't want to roast the entire US economy. So the consequences of error were truly terrifying.
We did that for parts of the system, but that mirroring also needed to be implemented and tested. So most modules we straight out replaced once the new versions were done.
Consider what it was like when web browsers used to be rolled out every 6 months or so. When Google (I believe) started to rollout virtually weekly (or even daily sometimes) updates, there was a bit of a riot from enterprise users. "How will we verify that we can roll out the new browser when you update it so frequently", they said. And then Mozilla followed suit. Eventually people realised that if you roll out an update nearly every day, each update only has a tiny modification in it. You almost never need to validate it. Even if it goes wrong, as long as you can roll back to yesterday's build, you are OK.
Having said that, I still think there are projects for which it is best to do it the way you say. I've certainly had a lot of success with that approach as well. As others have said, if it ain't broke, don't fix it.
> Even if it goes wrong, as long as you can roll back to yesterday's build, you are OK.
Except that when the versions are coming out too quickly, you don't know to which version you should roll back, because it took longer to encounter the problem (let alone pinpoint its origin) than the time between releases and several or even many occurred meanwhile.
Why were you migrating the system? What kind of impact were you trying to deliver? Was there a way of giving that impact incrementally, rather than delivering it all at the end? When whoever’s paying for the project asks how it’s going, what do they care about, and how can you measure progress towards those things?
There’s no silver bullet. Small a agile is really a way of thinking as a team. Unfortunately, the big guys often sell it as Big A Agile with a list of processes you need to follow so you can avoid that thinking.
It’s never easy :)
In this case though I would try to explore ways to deliver meaningful work to the customer more quickly. Without that quick feedback loop the entire premise of “agile” is meaningless (at that point it's basically just a way to organize your todo list).
>Teams only checked in – wait for it – every three months in a formal schedule review. I listened as Henrich mentioned that the teams complained about the volume of paperwork he makes them fill out for these quarterly reviews.
In my experience, embracing agile is an organizational change, not just an IT team change. Product owners and subject matter experts need to be more engaged with their development teams. Not all business folks want to do this: they have their own day-jobs to get to. So when the IT team starts iterating faster, but the appropriate business / project stakeholders do not change their workflow, you get this "AgileFall" combo that just does not really work.
That’s exactly how agile got introduced at my company. The scrum training was attended by most devs, only a few higher ranked architects, exactly one level 1 manager. Nobody from marketing, project management or upper management attended and now years later they still don’t understand how Agile is supposed to work. For them it’s something engineers do. So in the end nothing really changed other than words.
Buzzwords like agile and agilefall and waterfall don't really mean anything.
One persons anecdotal experience about agilefall doesn't mean it doesn't work. Don't fall for the trap of using analogies and anecdotal experiences as evidence. To top it off this guy didn't even measure the outcome of agilefall, all he did was declare that it violates some made up philosophical principles and demand change.
I've seen a project manager literally catch himself from doing something waterfall like it was the plague. Do people not realize that waterfall is the only technique used to build airplanes and bridges? I would not get on a plane built/being built using agile.
Note that I'm not criticizing agile. Agile works, waterfall works and no logic or evidence provided by that article says that combining what works for both is not good.
Of course "anecdotal experiences" are evidence. Yes, they're messy, and may not be applicable to other circumstances, but they're certainly informative.
I'm pretty sure airplanes and bridges aren't designed using 'waterfall'. I'm sure they're built, i.e. 'deployed', using a well-defined process. But, ideally, the well-defined process by which they're built should itself probably be designed or developed with 'short' iterations.
You're right. It is evidence. This is an obvious fact that I mis-represented on accident. Let me rephrase for clarity:
"This persons anecdotal evidence is not good enough or unbiased enough to qualify as evidence to be used to arrive at a conclusion"
>I'm pretty sure airplanes and bridges aren't designed using 'waterfall'. I'm sure they're built, i.e. 'deployed', using a well-defined process.
Ok let me rephrase for more clarity in case people don't have the ability to know that by "designing" a bridge I can mean "build" and "deploy" as well.
"Airplanes and bridges are designed and built using waterfall."
>But, ideally, the well-defined process by which they're built should itself probably be designed or developed with 'short' iterations.
This was how the MAX part of the 737 MAX was designed. Using a short iteration on top of an existing design. It leads to shorter turn around and cheaper costs. With the small expense of 1 or 2 plane crashes.
If you can afford a plane crash go agile, if you want to build something correctly go waterfall.
> This was how the MAX part of the 737 MAX was designed. Using a short iteration on top of an existing design.
A lot of software (that's often written about) can be tested 'in production' with fairly minor consequences in the event of 'failures'. That's an obvious difference between developing or maintaining software versus something like airplanes.
But testing or validating the changes made in short iterations is important regardless. Agile stresses the utility of short iterations precisely so the changes in each iteration can be tested and validated ASAP. Whereas in a waterfall methodology, a larger set of changes, i.e. changes that would in agile be split among a number of iterations, is tested or validated together. And the more changes that end up being tested together, the larger the risk is that those changes, and more of them, will need to be scrapped or redone.
The problem with the "MAX" changes of the 737 MAX seems more due to those changes not being tested or validated with the relevant users, i.e. pilots, at all before being 'released'.
Yes, the flawed (or incorrect) reasoning was that the changes were relatively minor and thus didn't warrant the regulatory requirements for 'significant' changes. But that doesn't seem to have anything to do with how the changes were developed, whether their methodology was agile or waterfall (or anywhere in between).
Obviously you're more likely 'to have a bad time' if you don't respond to, let alone seek, feedback from users about the changes you're making.
> agilefall and waterfall don't really mean anything
That's the problem, though - they should. (And, actually, they do, but they've been twisted around and used incorrectly so often that they've come to mean nothing).
“Agile” and “Waterfall” aren't opposed, or even necessarily incompatible; “Agile” is opposed to “Process not dynamically adapted to the needs of the particular team in developing working software”.
I'd bet that these days it's a lot more common for a process imposed in the way Agile is a reaction against to be some variant of Scrum with which management is enamored, rather than waterfall.
I am currently leading a dev team on a project that I would describe as waterfagile/agilefall. It's a highly regulated industry and the product is for a state level client that has rigorous specifications. We operate iteratively, but there is a discrete golive and many specifications of the project were defined contractually before we pushed a single line of code.
For this kind of project it doesn't make sense to operate in a pure agile fashion, but we also have broad license to operate how we please in some aspects of the project (i.e. the UI), and those more closely resemble an agile method project.
this applies to many other instances of systems being adopted and appearing to succeed even though what's really behind the success is something else, but because we don't have the control we associate the system with the success, like how when it's reported that a successful person eats chocolate or wears red; they were successful and they happened to wear red and it was only coincidence. Humans are always looking for causes and will associate spurious things together by default. I bet you if Agile were removed from all teams tomorrow they'd still deliver.
If it's creating more overhead, it's not agile. It may wear the label, but it's not the real thing.
If the existing process was already the optimal one, the agile thing to do is to not change it. If the "agile" changes are adding overhead, the actually agile thing to do is to go back to the previous process.
Agile is "adjust your process". Your process is one of the variables, not something handed down from on high. If you aren't adjusting your process, you aren't doing agile.
Many places say "We will be agile according to this rigidly defined process". The contradiction is obvious.
"Whatever works man, whatever works." lacks deliberateness, and that's one of the key differences between it and agile (little-a to keep separation from the Big-A Agile sold by consultants).
Look at the difference between the principles of Theory of Constraints, and what most organizations do. Most organizations want to remove constraints, they know they're a problem (since, well, they're constraints). The difference between ToC and what most people do is that ToC emphasizes a deliberate focus on the singular constraint in the process. I've seen teams and offices optimize the hell out of areas that aren't the bottleneck. Meanwhile, they still spend 3 months at the end of their projects running their massive, manual test suite. Do the tests bring value? Yes, immense. Do they bring value at the right time? No, because they take 3 months to run so they're delayed until the end of the project, so the project schedule leaves 3-6 months of buffer after that testing to conduct rework. A deliberate focus, then, should be brought to the testing activities and identifying how they can be conducted more rapidly, ideally automatically, and feedback brought in at an earlier stage.
Agile, as described in the manifesto, brings in a set of values that are intended to provide focus on what's important for both the team and the customer. To a large extent, it means "whatever works", but with focus on the values you share with your team and customers, and the tradeoffs that will be incurred based on the choices made.
More touches, yes. But the incrementalism-centric approach of the daily standup (which should be kept quite short) should lessen a lot of overhead/BS from filling out reports (or the like) post-fact; cards are kept up-to-date and problems (FUDs) discussed early and often. No one is making up what they did 3 weeks ago because they can't remember, and it is very clear when something is stuck or making progress.
Here's an example of why I still can't take writing about Agile seriously. I'm not saying there aren't a lot of process improvements under the banner of Agile (and plenty more that Agile is retroactively claiming credit for), but writing like this turns me off:
>Henrich still had a process where success was measured by reports, not outcomes. It was the same reporting process used to measure projects that used linear, step-by-step Waterfall.
What are reports, if not documentation of outcomes? What are outcomes without evidence that those outcomes happened?
I can see what he's saying, but the more accurate description of the problem "the reports included unnecessary and distracting information." But that doesn't make as good of a blog post as casting it as "paperwork vs understanding outcomes."
The whole thing feels like it needs to invent a "paperwork = evil" boogieman just to allow a process change that throws away useless paperwork and allow a team to focus on the paperwork that you just don't call paperwork anymore.
Email is paperwork. Version control is paperwork. Change management is paperwork. It doesn't matter if it's software updating a database instead of a secretary updating 3-ring binders. Most of development is paperwork. In fact, online databases mean we do way more paperwork. If we were bottlenecked by that sea of file cabinets in the basement containing all our the legacy projects, we would have way less paperwork just out of necessity.
Standups are paperwork that just happen to not use paper.
IME the most common cause for waterfall sneaking back into agile is when agile experiences some kind of failure - like the project delivered late and over budget. The response to this is often to revert to waterfall methods and means. This frequently makes things worse.
There's a common misperception in the industry that agile is 'fast' but waterfall is better at handling risky situations.
"True agile" can't be past deadline and over budget, because the project should be viable, delivered, and to scope at each sprint. It's just that you start with a tiny scope and expand from there.
Where it goes wrong is inflexible scopes. The business obviously wants - needs - to tie down all three parts of the triangle, and the fact that this rarely works isn't going to stop them.
That's ironic, because in many cases the reverse is true. Agile can be slower when you are exploring the solution space. It's safer though in that scenario since you are more likely to identify and fix issues as you enter them.
There's this thing I say a lot... in large organizations, it's more important do appear safe (even if it's risky) than to appear risky (even if it's safe).
The speed in agile should be your speed to fail - to prove an idea does not work while still cheap enough to change tact.
The time to build the whole might be no faster or even slower - but then again you might find out that after delivering only half the 'required features' that you have done enough to meet the customer need, and stop there. Big projects rarely want to stop though until the shopping list is complete.
>> [perception that] waterfall is better at handling risky situations.
Subtle difference I think: Waterfall is perceived as being more predictable, which is why it would seem desirable when stability is needed.
Fully agreed that while Agile is meant to deal with change better, it's perceived as being a silver bullet to "Speed things up". I have yet to meet a enterprise manager who uses the word correctly :(
I once wrote a blog article ranting about how we shouldn't use the word "sprint", because it focuses on speed. Rather, we should say "iteration", which focuses on change.
Pushing agile as faster rather than better is the biggest problem agile ever had.
Majority of my managers have heard the word somewhere, tried to infer its meaning from dictionary definition, and started using it arbitrarily. Most frequent phrase is "We need to be more AGILE!", which 98.72% of the time simply means "We need to whip the workers more and have them work harder, faster, longer.... somehow".
This article conflates the reporting and engineering aspects of the two processes, then it goes on to focus purely on the reporting. There was also no discussion of engineering discipline and how that fits into their process, despite the waterfall graphics showing requirements and design.
At Cisco there was a big organizational push to become "an Agile organization". What we ended up with was waterfall with Scrum. But regardless of people's complaints, and the lack of integration throughout the org, we still got products out the door when we said we would, worked on solutions iteratively, added value, etc. If all you focus on is the name of your process, rather than just getting work done, you're not gonna get far. I find a lack of a vision, strategy, roadmap, etc to be way worse than just doing something in a less-than-Agile way.
Agreed. Vision and strategy set the table for why and how the work moves towards an intended outcome. Every company I've worked with that does scrumfall tends to value outputs over outcomes of the outputs.
The process name doesn't matter, the results of the process should be the focus of every product company.
Been in agile team for about a year now, the only good thing I feel is the stand-up meetings, that reminds everyone to stay on track, and update the status each morning(also press you ahead, can not be too lazy due to this daily update thing, especially for old lazy engineers like me), also, a quick exchange of ideas in the standup can make a day more productive once a while. This is the major if not the only thing I'm going to keep for the future.
I have seen managers thinking the best thing about "agile" is enforcing staff discipline and maximal productivity ("stay on track", "press you ahead", "can not be too lazy"). It usually leads to a process that it really is still waterfall, but with, like, total surveillance and constant stress and developers being treated as interchangeable widgets.
It is sad to me to see a non-manager saying this is somehow the part they _like_.
The best experience I've had with agile processes was also one of the least stressful and most relaxing workplaces I've been in. I knew what I had to work on, I could trust that it was the _right_ thing to work on that wouldn't be a waste of time, and I had no pressure to "push myself", what could get done in work hours was what could get done in work hours, and sometimes you had to schedule some R&D/exploration time too. (The analogy of "sprint" is actually alarming when you think about how it's used -- you can only "sprint" for a short distance, you can't do back-to-back springs for 20 miles, the human body doesn't work that way!)
I think that may actually be one of the fundamental divides in "agile", whether someone is trying to use it as a productivity tool to "press ahead" developers who would otherwise be "lazy", to squeeze out the maximum possible work out of them, being unconcerned if you burn them out cause you can just replace them with another commoditized developer slotted into the "scrum".
I would agree the word "sprint" can conjure up a bad picture, but the agile manifesto clearly states the team should work at a sustainable pace. Nowhere in the Scrum Guide does it say you must work at a breakneck speed.
Inputs for sprint planning include the relevant empirical data (velocity, burn down/up etc.) to help with planning. In my experience, these data points are used to measure productivity, which is dangerous. Companies end up measuring success by outputs, rather than outcomes.
Business units need to stop weaponizing Agile and realize they too need to change in order to inspect and adapt towards building things people want.
I agree that it is not inherent to Agile. (I'm more suspicious of "scrum", but I'll believe you that it's not either).
Like I said, I've had GREAT experiences with agile practices, my _favorite_ workplaces have been using agile practices. Also terrible ones. Knowing that the terrible ones were "doing agile wrong" didn't make them less terrible.
I even said very explicitly "It turns into a process that is more like waterfall, but..." So I'm a bit perturbed by your response insisting that this is not inherent to agile. When I was pretty explicit in saying that too.
LOTS of companies _saying_ their doing agile result in misery, even worse than before they pretended to do agile. On the other hand, doing agile well can be wonderful. In order to figure out how to make more of the wonderful than the terrible, we have to get _beyond_ just pointing out that "the agile manifesto clearly states". Cause it's clearly stated that already, and it hasn't stopped the terrible.
In classic waterfall type process, big requirements/design docs were often not updated after initial creation, so were often wrong/misleading if you read them as a newcomer. Good doc seems to me more about values/competence of the team vs. which process they use.
Fascinating. The worst thing about agile I feel is the stand-up meeting. It encourages people just to say stuff and posture as being busy. I feel it encourages the worst part about agile -- that input (work) is more important than results (a working product).
If the team isn't relaying how their work is progressing towards the sprint goal, the daily scrum ends up turning into a status meaning, negating its intended purpose.
The daily scrum is a planning meeting. It's meant to help the team understand the big picture scoped to 1 sprint while helping each other achieve a shared commitment.
I've been on a variety of teams that do this differently. I once blew up when multiple people said that they were in [the scrum] meetings the day before; this is an example of saying things to account for your time, not to ensure the team is on the same page!
I personally try to correct from this problem by asking questions whenever work may relate to me, and being very familiar with the backlog to know how things will coordinate.
But also, I rant when people tell me about meetings without any conclusions for the team.
> I once blew up when multiple people said that they were in [the scrum] meetings the day before; this is an example of saying things to account for your time
Have you considered the possibility that your temperament or personality might be the reason that multiple people on your team feel they have to pre-emptively justify themselves to avoid angry criticism? A meeting where people have to stand in front of their peers and potentially admit their failings can be quite anxiety-inducing if team members can't be trusted to respond in a professional manner.
"blew up" and "rant" implied more than intended; The team reacted really positively to the feedback and adjusted accordingly; The team became really healthy at preemptively pairing and parallelizing work, but - to your point adding personalized fun to the standup.
We're struggling, IMHO, with adopting agile in a highly regulated environment where there are a multitude of tollgates to get to production. Roughly 20 different stakeholders that need to be accommodated while leveraging many internal services that do not support automation.
Slipping back into waterfall can happen because many of these issues have sequential dependencies and are one time request driven processes. It's a bit of a nightmare.
Waterfall isn't an engineering methodology, it's an investment methodology. Engineering will mirror the interests of the capital. And sometimes capital wants to build the same thing again for a "safe" return, rather than building something new for a transformative return.
IMHO it's not actually a safe investment strategy, but I understand where it comes from.
Obviously not every detail is included here but I did find it odd that, although he mentions a focus on outcomes, the change he talks about is entirely about shifting from one process to another, both of which by themselves might be pretty arbitrary.
> reviews would be about frequent delivery, incremental development and how leadership could remove obstacle
I would think that in a Lean process that outcomes and therefore reports would be focused on performance of North Star Metrics, KPIs, comparing those against goals, analytics/research to help understand that performance, and hypotheses/strategies for how to improve.
I'm a big fan of Lean/BML approach and I'm assuming this is what is happening but the article doesn't really send that message. Because of that omission, after reading but before seeing the author my first thought was this was consultant blather.
Yeah, we did Waterscrumban. We're in our third sprint. The first sprint, we moved "requirements" from backlog to doing. Second spring, we moved "requirements" to done, and moved "design" to doing. Third sprint, we moved "design" to done, and "implementation" to doing. Verification and maintenance are still in the backlog.
It works great! Just three more iterations, and we'll be done with maintenance!
Coming from the other side we have Scaled Agile Framework (SAFe) [0]. Which introduces some waterfall to Agile instead of the other way around. 3 month planning events, commitments, etc. Not bad perse if you work in an environment where not everybody is agile or every process can be agile.
I've never seen an Agile implementation in the wild that wasn't a game of Mornington Crescent, whose stated goal was closer adherence to Agile principles but whose actual goal was to reinforce existing power structures and undermine developer autonomy.
"Sneaks"? There are projects where the agile coaches, scrum masters, and consultants proudly declare regularly that the project embraces the best of both agile and waterfall. Nothing resembling sneakiness.
Maybe for certain projects where failure is high risk waterfall is better. Or at least more up front planning is a “good thing” when fail fast = lives lost
An up-front design is sometimes necessary and valuable, in both agile or waterfall projects, but it always carries a risk of including mistakes or mistaken assumptions that result in dangerous flaws.
When such a flaw is discovered, especially late in the project, it is often very expensive and difficult to fix, because it has become foundational to the solution. This is true regardless of whether an waterfall or agile process has been adopted, and there will often be significant pressure to implement a hacky fix, instead of the truly correct one.
Where agile differs from waterfall is that it does, at least, philosophically accept that nothing is set in stone, even at a late stage. Discussions regarding how to address a flaw can then proceed on a basis of cost vs. risk vs. difficulty, and a hopefully rational choice can be made.
In contrast, the rigidity of the waterfall process is frequently used as a bureaucratic weapon to prevent these discussions from even happening. Decisions made in the project's initial stages are held to be settled and unalterable, and those seeking to overturn them usually have to fight a horrendous, uphill battle to do so, even when they're in the right.
I would liken the difference between design in agile and waterfall to that of scientific theory vs religious dogma. Neither necessarily has a monopoly on truth: A theory might be mistaken while dogma, by chance, might be correct. And challenging well-established scientific theory can, in practice, be almost as difficult and painful as disputing dogma. But science at least accepts the possibility of change, however hard it may be.
> In contrast, the rigidity of the waterfall process is frequently used as a bureaucratic weapon to prevent these discussions from even happening. Decisions made in the project's initial stages are held to be settled and unalterable, and those seeking to overturn them usually have to fight a horrendous, uphill battle to do so, even when they're in the right.
So much this. I can't count how many times I had a client tell me "We want the delivery on the proposed time, on budget, I don't care" even when analysing the client's design it shows obvious flaws and won't work as intended. Most of them usually gets fired from doing this, months later, but even so they just get another same-level job on another company, and the cycle goes on.
There's no development methology that will ever work on irrational business demands, and that happens all the time. Sometimes I think HN's users are just too entrenched at product-driven companies, or B2C ones, and never get to experience the amount of BS and CYA that happens on B2B, large-business deals.
I think upfront planning is almost always a good thing. The problem starts when people think that the plan doesn’t need to be revisited. You need to be willing to change the plan as new facts develop.
In the end no matter what you do software and hardware development is unpredictable. No methodology will ever change that.
“Over-planning can lead to a lot of rigidity in the process if it tries to plan too far ahead.”
Or they try to compensate for technical problems by doing endless replanning meetings instead of spending the time on solving the problem.
But a good long term road map is really helpful when you have to make a decision to go one way or the other. Just accept that it’s a rough guideline and not an exact plan that’s set in stone.
Agreed. I think a lot of agile proponents think that in waterfall, the project plan is created on day 1 and as reality drifts from the plan, the project manager shouts louder and louder at developers to try get reality back to matching the plan.
This a false straw man argument. One the project plan is created, it should be updated regularly (daily/weekly depending on the size of the project) as tasks are completed and new information comes to light. The plan is to give a prediction for the likely end date and cost of the project, but must be update as new information is known.
“as reality drifts from the plan, the project manager shouts louder and louder at developers to try get reality back to matching the plan”
Welcome to my world :). Just a few weeks ago I had a conversation with a project manager explaining that no amount of additional planning meetings, motivational speeches or free pizza can change reality.
> I think upfront planning is almost always a good thing.
Agreed. I think some people think agile means no plan, whereas I think it means frequent scheduled review of the plan as work is completed and more is learned.
"Fail Fast" doesn't have to mean crash airplanes. Quality and agility are orthogonal things. Agility is about understanding your requirements by producing prototypes and talking to stalkholders using those prototypes. Once you do the QA work necessary for safety critical software, misunderstandings about requirements or wrong requirements are the major source of failures.
In my mind, and agile approach would involve a series of 'tiny' incremental migrations from the existing system to the new one. I'd actually expect that to work much better than attempting to switch over everyone all at once, after years of development. That either doesn't work or works very badly in my experience.
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!