17 ms·

Even with Agile and Scrum waterfall will sneak in

197 points by KingOfCoders 5y ago

imbnwa 5y ago
It strikes me as impossible that no one realized that projects needed to adjust to unforseen events before a bunch of consultants decided to write a manifesto while skiing in Aspen.
sklargh 5y ago
Agile, MBA for, "I would like it immediately regardless of consequences for others."
Flankk 5y ago
Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity.
- moritonal 5y ago
  Agile (if the culture incentivises honestly) does have the benefit of feedback. Rather than a black-box which "could" be done in a month, you can instead see that the team on-average under-estimates by 10 days, has x stories left, so it'll likely be done in 2-3 months at this rate. The downsides are that it opens up the team to feature-creep, introduced a pile of weird buzzwords, and can be massively wasteful if the team doesn't want it and it's forced on them.
  - lelanthran 5y ago
    > Agile (if the culture incentivises honestly) does have the benefit of feedback. Doesn't Waterfall incorporate feedback? In my memory and experience, it does. My memory of learning Waterfall back in the early 90s is a bit hazy, but I distinctly remember that one of the advantages touted was that mistakes earlier in the process of developing software are cheaper to fix than mistakes later in the process (no matter what the process is). Finding an error when drawing up the requirements is orders of magnitudes cheaper to fix than finding an error after piloting at the client. As I remember it, Waterfall was taught (to me) as a way to avoid developing the wrong product, or a product that does not meet the requirements of the end-user (sound familiar?) My SDLC textbooks from back then were filled with different ways to elicit requirements, because fixing broken requirements after the product was developed was (and probably still is) bloody expensive. In the same way, fixing bugs during a test phase is a lot cheaper than after a deployment phase (hence various types of testing were introduced by the textbook). Fixing bugs during a pilot phase is a lot cheaper than after a full deployment, hence piloting was in the textbook as well. Agile aims to deliver features one sprint at a time. Waterfall aims to deliver the specified system as a whole or not at all. Which one works better is probably contextual, but I cannot see either one being unconditionally better than the other.
    - DnDGrognard 5y ago
      Exactly each waterfall phase has its own iteration loop
    - db48x 5y ago
      Yes, though as originally documented the Waterfall process didn’t have much to say about iteration. It was simply left to the reader to realize that they would be releasing version 2.0 of their software a year or two later, and that they could incorporate feedback from the users of version 1.0. Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too.
      - lelanthran 5y ago
        > Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Well that makes sense with my belief that WF aims to "deliver the system as a whole or not at all". There's no point in delivering an MVP G2A missile system that is not complete. > Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too. To be sure, CI/CD pipelines make the fixing of bugs in the code cheap enough to simply deploy when you can. However, bugs in the specification aren't going to be cheaply fixed after deployment, and these are much more common[1] and hard to get correct than any other type of bug. [1] I.e. the code does exactly what the programmer intended it to, but what the programmer intended it to do is different to what was needed.
- mytailorisrich 5y ago
  I don't think it's any issue of individual raw productivity. It's about not wasting that work by focussing on building exactly what the customer wants as fast as possible. With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. This means a longer lead time to working software and to any sort of feedback, and usually a waste of time in the docs/specs phase. Even trying to write a whole perfect spec before doing any coding prevents you from benefiting from the practical feedback that comes from actually doing. For some types of software this works mostly fine, but others not so much. Hence why most methodologies since then have feedback loops and try to make then small. IMHO sprints are not to pressure (though the name may not be well chosen in that respect) but to enforce small-ish iterations rather than spending 6 months developing something in isolation.
  - lelanthran 5y ago
    > With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. (see my reply above, for some context and why I might be wrong :-). My recollection of Waterfall is that there is always an "acceptance" phase at the end of every "fall"[1] - IOW, there is a sign-off by the stakeholders that what's in the phase is correct. So your requirements are engraved in stone, your test protocol is engraved in stone, and your UAT is engraved in stone, and your "pilot performance acceptance" is engraved in stone. If it turns out there is an error in any one of the phases above then that error, and that error alone, is signed off on and goes through all the phases (or "falls"?) again. Since this is more expensive the further in the falls the error is, there is pressure to get as much sign-off as possible for any issue before that issue proceeds to the next phase. [1] I like the word "fall" to describe each phase of waterfall :-) I'm going to start using it more often and see if it catches on.
- mr_toad 5y ago
  > Waterfall was never that bad anyway. If you’ve never seen a project that wasted its entire time in the scoping and planning phase (and not produce anything), then you’ve never seen how bad waterfall can get.
  - avian 5y ago
    Just to make a counter point, if you never spent your days in planning poker meetings, endlessly discussing hundreds of tiny scraps of yellow paper stuck to a white board (and never produce anything), you've never seen how bad Scrum can get.
- drran 5y ago
  Water is a good, predictable process. It's just result bad. If the result is not important, then use waterfall.
  - jollybean 5y ago
    "Water is a good, predictable process" No, Waterfall is bad precisely because of the inherent unpredictability of a given project. Never in all of history was a large software project speced out and built on time. Software lives in a dynamic environment, so the process has to be mutable. Maybe the answer is not 'Agile', but it's definitely 'agility'. If we set longer term term, rounded goals, but with smaller iterations, then there's a possibility, but not a big Waterfall.
    - drran 5y ago
      SCRUM is just a bunch of small Waterfalls. In SCRUM, we have 2-week sprints. It's not important when one of the sprints will fail, because we will adjust following one. Moreover, we plan for first 2 sprints to fail anyway. Why we should use something else, more complex, instead of Waterfall, for a single sprint? Waterfall is good enough and predictable enough for a 2-week sprint. Yes, the result of a single waterfall will be bad, we plan for that, but accumulation of knowledge will lead us to success.
- cube00 5y ago
  > As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity. This is why I hate agile, it's incredibly stressful. Daily stand ups to justify your last 24 hours, affirmations in said stand ups which must begin with "Yesterday I committed to... and did/did not achieve this because..." followed by "By this time tomorrow I commit to delivering....". JIRA burn down charts dropped in our group chat to "remind us" to keep following the planned burn down line, looking for stories we can close out to try and sneak the chart to match the line and somehow try and catch up after they're closed. It's horrible.
  - detaro 5y ago
    None of that is a requirement for agile processes. (Indeed I would argue that unless you have decided that's the best tool for your team, you're probably not being very agile. And no, when management of a big-co dictates how you work, they can call it "agile" as often as they want, it's not. Of course still extremely common, sadly)
  - iamflimflam1 5y ago
    That is not agile it is SCRUM.
  - littlecranky67 5y ago
    All you say is agile not implemented correctly (which is very common). I am a contractor and switch projects and development environments very often. I've seen agile working really well when it is properly implemented, and really poorly when it is wrongly implemented. The biggest problem I see that people never really get educated in agile. I see PMs/POs/Developers etc. that never had any formal training in agile/Scrumm (books, courses, experience) but rather learn-by-observation, i.e. "do what others do". And I have seen scrum master with zero expierience as a developer, just blindly trying to follow written guidelines in the books (scrum manual etc.) without being able to adopt those to a real development process. Take for example your metion of standups: They are really valuable, and are not meant to "justify" your last 24h - but some managers think that this is the case, i.e. make sure your developers are not slacking and surfing on hacker news all day. Instead, one of the purposes is to detect blockages in any way. I mean if a dev takes very long for a task without it being justified (i.e. no other developer would understand why it would take so long), it might just be due to lack of skill and the dev might need some more training or senior assistance. It could also be that the task is more difficult than originally anticipated, in which case the team should possible act on it and change the scope etc. Sometimes it could also be a very eager junior dev, who just doesn't want to admit struggling with something out of pride or even fear etc. As a developer I can totally say, it actually takes quite some guts to come out in a group of devs and freely admit: "Hey, I struggle with that task, I don't know what I am supposed to do, or am not familiar enough to debug that code, can somebody help me on this?" - but admitting that you are not perfect is something lot of people struggle, especially juniors as they think they must be capable of doing everything.
- littlecranky67 5y ago
  > Agile doesn't magically make people more productive AFAIK not only was that never a claim/scope of agile, but rather the opposite is deliberately accepted with agile: You accept quite some overhead during development, plan for constant refactors, shift of scope etc. The justification is, that while waterfall in theory is the most efficient and productive, in practice you very often end up with a product that doesn't fit your customers/users need. So working 2years on a product that is thrown away in the end and started over is less efficient and more expensive than working 3years on it in an agile way and getting (mostly) what you want in the end. Note that is the one of the reasonings of agile, I am not claiming that these statements and premises have actually proven true in the real world.
rdxm 5y ago
Agile fails not because of the engineering side of the house but because the business can't "get it", and just ignores it...seen this too many times to count across many different biz domains.
zogomoox 5y ago
A version of this is Scaled Agile (SAFe) which somehow manages to combine the worst of both worlds. If you see your organization preparing to go SAFe, run!
- otagekki 5y ago
  A major French bank where I'm currently working at has implemented this method for its development teams... While we do have deadlines there is so few pressure compared to the other teams I had worked with before, that we actually have the luxury to build our features and being actually satisfied with what we're delivering
- RealityVoid 5y ago
  Even the name is hillarous. It's like one of those cryptocurrencies that try to be sellable by a pump&dumpy name, like SafeMoon, haha.
- chewyfruitloop 5y ago
  SAFe seems to be a pyramid scheme to get you to pay for the latest SAFe badge its overly complex and seems to be there to make management feel better about itself
- sgt101 5y ago
  I misread your comment and thought you wrote "best of both worlds" and embarked on a rebuttal! One of the places I am working at is now ditching SAFe, because they have recognised the issues. The process as implemented there both burns vast amounts of time and is widely ignored. OUTSTANDING!
- drran 5y ago
  SAFe works just fine when Agile is perfected, i.e. about 5 years after every day practicing of Agile. If you have no Agile to begin with, then you cannot scale it.
- allo37 5y ago
  Last place I worked tried to do SAFe (I think? They kept repeating it and had all the branding on the presentations). To me it seemed like the idea was to replace a dedicated project manager (or team of them) with a week-long meetingfest every 8 weeks where all the different teams tried to self-organize based on what the business' objectives were. Apart from the colossal waste of time of those week-long "PI-planning" meetings, it was OK I guess...
buro9 5y ago
The extremes were bad, not the essence of the idea. Stay lightweight and you can have the best of everything. When anything is non-trivial to implement, i.e. it has dependencies, then it benefits from _some_ waterfall planning. Meaning to think before the work begins about the approach being taken, all of those dependencies, and who you need to engage and when... tada, you've made a GANTT chart in your head and are now waterfall because you put some thought into the dependencies and the order of execution. Within that, each epic / task can be SCRUM or agile or whatever... all you really need here is an idea of a "definition of done", to prioritise the work so that you hyper-focus on just doing what needs to be done to get you to done. You probably want to continuously remind yourself of those priorities... tada, you've created an agile process. The names are irrelevant, understand the essence of project / program management and do the least you can do execute on that. It's when the processes become formal, tooled up, etc... this is when the worst creeps in. The status meetings for middle management, the reporting of time to project management tools. But no-one has to do this, lightweight project management can work without any of this stuff.
- mytailorisrich 5y ago
  > then it benefits from _some_ waterfall planning. Meaning to think before the work begins about the approach being taken, all of those dependencies, and who you need to engage and when... tada, you've made a GANTT chart in your head and are now waterfall because you put some thought into the dependencies and the order of execution. Agile does not mean that you should forego all of this and code first, think later. What you describe does not oppose Agile and Waterfall.
  - buro9 5y ago
    I know :) But people did take agile to an extreme and they did forego the essence of other processes. I feel that the line "everything in moderation" applies well to project management. Moderation being the key part.
- HelloNurse 5y ago
  The "extremes" are good in their appropriate extreme niche: spacecraft flight control software is definitely engineering and it has to be perfect the first time (no exploration or iteration), while the only prudent and efficient way to publish a website with a day's notice requires a rushed MVP and then as many small edits and additions as fit in the available time. In the middle of the spectrum there are varied tasks, for which an excess of waterfall can force the creation of low-value documents (e.g. hundreds of pages of up-to-date screenshots of complex forms instead of describing in detail only interesting data and interesting workflow and honestly stating that UI layout will be arbitrarily reorganized according to stakeholder feedback after every demo until they are happy) and an excess of agility can be an obstacle to correct design (e.g. publishing a mock incomplete version of some service without taking a couple of days to determine whether the data needed to actually implement it is going to be available).
xondono 5y ago
To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. The whole thing is about processes, and tools (jira)… the complete opposite. The reason everyone ends up doing waterfall is that it’s not the devs who you need to convince when selling agility, is the chain of command. Being agile means having no long term plan. If the C-suite can’t handle that, you’ll never be agile.
- cube00 5y ago
  The C-suite only hear "fast delivery" and ignore the other parts while also demanding the waterfall parts that suit the ways they need to work such as committing devs to deadlines one financial year out when funding bids have to be submitted. There is something ironic about being ordered to estimate a 12 month work order while also being told make sure "it's agile" and delivered on time and on budget by ++currrentYear.
  - clairity 5y ago
    yes, non-agile organizations try to bolt on agile at the 'bottom' of the hierarchy, and that's a sure recipe for failure because of the significant impedance mismatch that causes. the c-suite wants to hand down directives, and the agile teams want to listen to the customer first, leading to conflicting interests. an organization has to be receptive to turning the marketing function upside down (product being one of the 4 P's of marketing) to be really successful at agile. that's why consulting firms tend to be more successful than ordinary product/service firms at it, because they're already inverting the marketing function (to lead with what the customer wants and then trying to execute on that). executives don't tend to want successfully implemented agile, as it undermines their control of (customer/market) information, and the organizational power derived from that.
    - imbnwa 5y ago
      In my mind, this sorta proves that most companies should not have in-house engineering divisions and instead most of us should be working for software engineering firms much like actual architects. This would likely also solve the career development/engineering pedagogy problem that is so lamented since firms would have better control over time internally.
boffinAudio 5y ago
I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated/verified with a Qualification step, and then it gets released to the end user/product owner, who sign off on it. This is a natural flow of steps, and it always appears to me that the new-fangled developer cults are always trying to 'prove' that these aren't natural steps, by either cramming every step into one phase (we only do "Analysis" and call it Scrum) or by throwing away steps (Qualification? What's that?) and then wondering why things are crap. Too many times, projects I've seen fail could've been saved if they'd just gotten rid of the cult-think. Its nice, therefore, to see someone else making the observation that Waterfall is a natural process and all the other -isms are just sugar/crap-coating what is a natural consequence of organizing computing around the OSI model - something that has been effective for decades now, and doesn't need improvement-from-the-youth antics.
- jason-phillips 5y ago
  > I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor... Because layers of management who need to continually justify their existence can never, ever keep themselves from putting their big fat thumb in the pie and fucking everything up.
- littlecranky67 5y ago
  The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. Additionally it is really hard for project management to get metrics/early warnings if something is not going properly (no project - waterfall or agile - is without problems during its lifetime). How would you asses the quality/progress of a project based on a couple of a specification or requirements documents 1-2years into the project with no (immediately usable) code being available? How would you asses if the approach taken after 3years in a project will be accepted by your endusers? Waterfall is just a big black box to management and stakeholders with the hope that after 5years something usable will come out of it.
OneTimePetes 5y ago
Waterfall is just a mapping of the dependency graph back into work-packages. As all things are hierarchical in some way, large changes and additions, always lead to a larger change allover the graph, making it necessary to go all the steps back. Change something large enough, and the process forces you back to the architecture drawing board.
pydry 5y ago
I noticed this as well. No matter how dedicated the team is to not doing waterfall, waterfall nearly always creeps its way back when anything that even smells like a deadline rears its head. Waterfall planning tends to get ramped up for four really common reasons: * Managers who simply cannot conceieve of non waterfall planning. * As a response to failure (ironic coz it tends to increase failure rate) * Because it's basically the job of most middle management to do waterfall planning. * Because if your managers manager wants deadlines, tough shit it's deadlines all the way down. * Because ultimately, upper mamagement tends to prioritize control over profit even if that control is somewhat illusory. Waterfall planning is kind of infectious, too - if the team does it in one area it spreads to others. I would say that 90% of teams experience this kind of "waterfall whiplash". I worked on a couple of teams where upper management didnt set deadlines or create roadmaps or anything. These rare occasions were the only time when I was entitely free of waterfall and we were way way more productive because of it. Like night and day. However, 90% of companies can't even envision this, let alone do it. Most people dont even believe its possible - developers included. I suspect this is one component of the secret sauce of high performing startups that defeat wealthier, more established incumbents.
- jollybean 5y ago
  Waterfall creeps in because it's the most rational and linear way to do anything and we do it in all activities is our life without even thinking about it. When you build a deck, you 'Waterfall' it. Iterative development is slightly counter intuitive, until you write software for long enough, then it's definitely the intuitive approach. I suggest the simplest, easiest, best way to combat the urge to overplan is to break the waterfall down into iterations, do those iterations, assign maybe risk to different iterations given unknowns and to expect change.
  - pydry 5y ago
    I actually started to notice after being a developer for a decade that a lot of people run face first into a metaphorical wall applying waterfall to their personal life where it didnt really work as well. It's definitely "natural" though. I wonder if it's a cultural hangover from our agricultural past where lack of waterfall planning = dead.
sgt101 5y ago
I find that waterfall comes with technical certainty. Waterfall is disastrous with erroneous technical certainty, if the customer is convinced that the solution is technically clear and yet there is still uncertainty then what will happen is that a number of good components will be developed and delivered all of which are useless. If you can communicate (you must) the uncertainty and the potential branch points in your project then one of two things happens: - it stops (often) because the client does not have any appetite for risk. This is painful, but it is better than the car crash of a failed waterfall (which is what is going to happen). The opportunity cost for the team and you is very high here - kill it now and get something viable. - you go to agile and make it stick. As soon as you are certain about the solution the design is frozen and you can plan effectively for delivery. This is now waterfall and everyone is happy.
m4r35n357 5y ago
Waterfall == Engineering Agile == Wild West There you go . . . you're welcome!
moksly 5y ago
Most project models are sort of useless in the modern office environment. Waterfall is useless because nobody ever follows it. I agree that it’s sort of the “default” mode, but show me a project that didn’t go back and change something from a previous step. Agile stops working the moment you need to sign any form of contract with anyone, because nobody is going to sign a contract that doesn’t tell them what they are going to get for X amount of money. Its processes are sort of fine on the smaller scale because it breaks project tasks into neat to-do-lists, but it’s utterly useless for actual project management because estimates are a lie and delivering on time is what is required to drive a project successfully. Then there is everything in between from the various stage-gate models to UP and what not, and they are all equally useless because nobody ever really follows them and because they can’t really apply to every type or project which is what organisations tend to want. I haven’t worked in a FANG or whatever you call the big American tech companies, but I have worked in the European Public sector and it’s affiliated private sector companies for years, and nobody has a magic project model in my experience. In many ways the most successful companies tend to be the ones who simply use some sort of Kanban board and refrain from giving estimates in intervals lower than weeks. I fully understand why organisations waste resources on this area of course, I’ve been in the trap myself many, many times and I’ll likely end up in it again, but the simply truth is that every project manager or business process person that you have is one less developer, and these helper functions don’t really add anything to your value chain the moment they start making up work for the sake of having the “right” processes in place. The best way to handle project management is to hire good developers who know how to deliver projects that are build safely and maintainable. That’s not easy, but no amount of project management is going to make up for the lack of them. And I’m not saying you shouldn’t need project managers or have an organisational strategy, but if you’re hiring more support staff for your developers than you would for the tradesmen you’d hire to build your house then I think that you’re doing management wrong. We build an entire city hall, a process that took almost a thousand different employees from very, very, differently ones of work and we did it with 1 project manager, 1 architect and 10 lead engineers. We did it on time and under budget, and that is how we build our IT projects as well. It’s sort of waterfall, because it’s what we default to like the author gets into, but maybe that’s because it works?
- cowl 5y ago
Guid_NewGuid 5y ago
I'm just wrapping up an Agile project, truly agile, and it was actually quite fun. At the start they tried to get us to use Scrum and 2 week sprints and I pushed back. We had basically no fixed meetings except a weekly sync and a couple of weekly meetings with stakeholders. In the first 2 weeks we were producing analysis of whether we should do the project at all and my week has been pretty much 20% meetings with product since then and it has been fantastic. We used JIRA but only as a log of tasks, sometimes we were asked to report up some more detailed estimates so we made a rought Gantt chart type plan, but otherwise we've been left alone. We've done the project in a way that truly matches the agile manifesto. And we're only a week or so past the original estimate in a 3 month project, so pretty on-track. It just reinforces for me that Business Agile is a load of crap[0]. [0]: https://d22qefpbdavdoz.cloudfront.net/#agile-is-hell https://d22qefpbdavdoz.cloudfront.net/#agile-is-hell
sornaensis 5y ago
In my few years working as a dev, I am absolutely convinced that scrum and agile are the worst possible development practices you can have from the perspective of a developer, even though they are sold as 'developer centric' or that seems to be the impression a lot of people have at least. It makes no sense at all to me to constantly have work interrupted with customer meetings that produce NO concrete specifications because everything is expected to be done just-in-time, on a whim essentially. It seems to nearly universally lead to dev whiplash, poor product architecture and large amounts of technical debt. Many companies also seem to end up employing tens of people who don't actually have any role at the company-- they just show up an 'moderate' these 'ritual' meetings. I'm sorry, what exactly is the value add for having a person with no understanding of either development or product, running meetings that center around product development??? It just seems like a scam to create jobs for people with otherwise useless business degrees. I'll take however many weeks of blistering specification followed by diligently developing against hard deadlines to the insanity of rolling technical debt and borderline abusive micromanagement that agile methods all but enforce. /rant
- simonbarker87 5y ago
  Ahhhh, I couldn’t have put this better myself. Agile is forcing devs to change how they work to solve a problem caused by poor product and business management and all the problems it creates are swept under the rug as “technical debt”
- lbriner 5y ago
  It makes a lot of sense, which is why a lot of people follow it. Your comment is implying that somehow 1000s of people around the world don't realise they are doing something stupid. You are portraying a poorly run implementation of agile as the only way and then destroying it. We call it a straw-man. * My development team are rarely interuppted with customer meetings * The meetings we have will always have outcomes, even if those are high-level "would this be possible?" * Everything is not expected to be done "just-in-time" "on a whim", it is simply a case of allowing the highest priorities to be looked into in much shorter cycles. * "Dev whiplash". Nope, not here. Poor architecture and tech debt? I haven't seen any more in the agile projects I have worked on compared to old waterfall projects. * Tens of people who don't have any role. Nope * Non-dev/product running meetings? Nope. Shouldn't happen and if it does, it's nothing to do with agile (or waterfall!) * Borderline abusive?
frant-hartm 5y ago
> We had elaborated waterfall processes like Rational Unified Process (RUP) in the 90s This is factually wrong. RUP is an example of iterative process, not waterfall at all.
swiftcoder 5y ago
No matter what process we adopt, we'll always have waterfall as long as the sales side of the house needs predictable features and release dates. There isn't really anyway round that - if we can say with confidence that we'll release features X, Y, and Z in a release 6 months from now, then we don't have room for more than localised iteration. Agile-ish systems work great when you don't have pre-determined delivery dates, but unless you are an internal-facing team with only a backlog of tech-debt to burn down... who is actually in this position?
Chyzwar 5y ago
There are even companies selling scrumfall consultancy known as SAFE. In my experience, there are few problems with agile. - scrumfall that is mostly cause by stakeholders wanting to have yearly roadmaps and KPI tied to delivery of increment. Plenty of organizations have separate engineering and product orgs that create this disconnect. - groomorgy when teams spend more time on analysis than actual work. Driven by middle managers thinking that doing less is better than not finishing the sprint in time. Middle managers that do not understand tech or business but can track progress of tasks. - cost-amnesia When feature is build over many increments is hard to estimate total cost and long term maintenance cost. You might have teams re-inventing a wheel and having a massive amount of slowly rotting code. - conway-architecture. Because people think that agile is all about small independent teams, it naturally leads to service oriented architecture. In many places, SOA is a bad fit problem or organization. Small company with limited resources doing micro-somethings will create death trap. - teflon-promotions You will have teams and projects doing terribly over a longer period of time, but in initially phase they delivered value. You will see people promoted in the organization based on early wins, even if they left behind dead bodies. It often encourages tech dept over long term maintenance. I still feel that agile is great. Most of these problems are people problems, not agile itself.
clement_b 5y ago
People or teams managing software development workflows usually silently tailor them, fitting the reality of their constraints, often outside of Scrum and Agile (despite claiming otherwise in job descriptions or developer posts)! And that's OK! There is nothing wrong with taking the best from waterfall or Scrum, or you name it, and adding a pinch of personal/novel ideas if a precept from an existing framework doesn't apply out of the box. These concepts are decades old; new tech and new constraints have arisen. People have changed. New answers are needed, or at least worth a shot. It's also OK to re-appropriate out-of-fashion concepts when those are a better fit. The key, in my view, is to remain open to new or old ideas and to interpret and adapt dogma rather than blindly follow it.
andrewingram 5y ago
In my mind agile, is about avoiding committing to a particular direction before verifying that it's the right one, and in a lot of cases (particularly in the startup world), verification requires shipping to potential customers. Agility doesn't promise fastest time to delivery. It's acknowledging that you'll probably build the wrong thing, so it's about making it easier to course-correct. The failure state of agile (waterfall hidden behind agile ceremony) is usually triggered by leadership/management teams not willing to _truly_ delegate. Once process becomes dominated by accountability and visibility (which I've never seen not happen with Scrum), rather than supporting the people doing the work, all bets are off.
ochronus 5y ago
Yup, when people (semi-blindly?) adopt a process but not the principles, this happens. There are a tons of fallacies in product development on multiple sides... also trenches too deep between disciplines sometimes. These are hard to fix. I've written a short one about some typical fallacies: https://leadership.garden/product-development-fallacies/ https://leadership.garden/product-development-fallacies/
dennis_jeeves 5y ago
The Agile/Scrum emperor has no clothes.
known 5y ago
"You can't produce a baby in one month by getting nine women pregnant” --Warren Buffett (b. 1930)
ben7799 5y ago
I started working prior to Agile becoming a thing but wasn't around for the entirety of the 1990s. I have seen both waterfall and agile products fail or succeed. I don't think the process is ever to blame when they failed or deserves much credit when they succeeded. My take on it is both processes have their strengths and weaknesses and perhaps a product needs to start Agile and slowly morph towards Waterfall as it matures. Agile is great for the pre-1.0 phase when no one is sure what exactly the market needs yet and you're working on a software product with low cost to acquire customers. If you're iterating over different ideas trying to triangulate what is going to sell, and you don't need to scale yet before you figure out if you can sell it, then Agile has a great role to play. This is kind of risky startup time for sure though. But when your product has become huge, mature, and you're signing $1M+ annual contracts with enterprise customers and your new features are getting very complex Agile doesn't work as well at that point as the tech debt it creates become more and more punishing as the project size grows, and the complex features become more and more difficult to fit into sprints without causing disasters. If a feature takes 6 months it can be a disaster to force it into 2 week sprints that just build tech debt in the name of being able to demo. I've been on the current product I work on for about 8 years and have watched it morph from a pre-1.0 Agile product to a $500M+/yr complex product. We've been lucky to have good management and the process has gradually changed as the needs of the product have changed. My career has mostly been enterprise B2B software... the best process for B2C, B2B, aerospace, military, etc.. is not necessarily going to be the same. One thing for sure though is Agile has largely become a religion and less so of a pragmatic process as time has gone on.
- bradenb 5y ago
  What I've found while working in defense is that when your customer issues a statement of work with clear high level requirements then you're going to need waterfall (even if just at a high level).
  - kevinmchugh 5y ago
    Yeah, I think this is uncontroversial. If your problem domain generates strict, well-defined requirements, agile has less to offer. https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff There might still be some useful agile practices, and you could have the less defined work (eg internal tooling?) be more agile.
bdcravens 5y ago
Agile tries to create dynamic output with a typically static input (developer salaries), so there will always be drift towards a natural state.
SideburnsOfDoom 5y ago
> Efficiency is the key driver for waterfall. Why work on things together as a team? Is is often forgotten that the efficiency of the individual is not the same thing as the efficiency of the team. Understand this and the case for waterfall is weakened, perhaps fatally.
dandare 5y ago
I am ok doing waterfall - what I can't stand is doing waterfall dressed as agile&scrum. Agile&scrum are internally inconsistent methodologies which means that a bad faith actor (be it a smart but asshole engineer or clueless boss) can always point out you are doing something wrong (against the theory), regardless of the flavour/school you are using.
AtNightWeCode 5y ago
Another conclusion from the same input is that product owners in the Scrum world are just waste. In a lot of teams I worked with POs are just mediators between stakeholders and the developers.
boublepop 5y ago
If you read the original waterfall methodology descriptions, even waterfall isn’t supposed to be what waterfall turns into in organizations.
andrei_says_ 5y ago
In 2015 Dave Thomas, whose name is on the Agile Manifesto, gave a talk named “Agile is dead - long live agile”, addressing the intent behind the manifesto and the Agile Industrial Complex / cult-like movements which spawned from that. https://youtu.be/vqz8ND-N1hc https://youtu.be/vqz8ND-N1hc
- passwordreset 5y ago
  I've watched this video a few times, and I recommend the part at 25:43 which describes agility. To repeat it here: 1) Find out where you are 2) Take a small step toward you goal 3) Adjust your understanding based on what you've learned 4) Repeat I think this is useful as a high-level guide, and it's both easily memorizable and generally memorable. I use a silly mnemonic "FI-TA-AD-RE", and I come back to it whenever I'm working and get to a point where I have to ask myself "What the hell am I doing?"
devnull255 5y ago
"Scrumfall" sounds like a rejected James Bond movie script.
bastardoperator 5y ago
The sooner people realize that agile and scrum are sales pitches with little substance the better off everyone will be.
- spookthesunset 5y ago
  I don't know if I agree with that. Rather than have every team on earth invent their own process from first principles, they provide adequate starting points on which to grow. Agile, Scrum and Kanban aren't perfect but they can get a team started. Good teams will take them as templates and tweak as needed.
  - regularfry 5y ago
    If you look at Kanban specifically, you can tell if it's been implemented well because it's not just affecting the team. It's a tool to improve the entire value stream.
    - bastardoperator 5y ago
      Even that is a bastardized version when compared to what Toyota developed. The reality is software engineers are not factory production line workers. Also, kanban negates the fact that cars are completely spec'd out (aka waterfall) by the time a car is ready to be built on a production line.
      - regularfry 5y ago
        Yes, and a vast amount of the design detail that goes into car design is to make building it easier. You're right that software engineers aren't factory production line workers, but I'm not sure it actually matters. The only detail I can see relevant to whether kanban can work in is the distribution of how long each piece of work takes, and while you'd expect the distributions to be different between "bolt lump A onto tab B" and "add feature X to website Y", I don't think they'd be different enough to completely break the queueing model. I'm not sure that it matters that each piece of work through the team is unique versus the completely repeatable part assembly stereotype of factory work. The main issue I see with kanban as a software development idiom is that in every place I've worked, supply cannot be effectively constrained, except artificially, at the gate into the team. There is always more work to do than time to do it in. Now part of that is a cultural problem to do with politics and the place of the CIO (or equivalent) in a typical company, but it definitely feels like kanban needs to be driven from outside the tech org to work well.
mkl95 5y ago
Title describes my current job. Basically a thin agile wrapper around a broken waterfall process with gargantuan releases plagued with heisenbugs and shoddy QA. It's fun but I'm still not sure if it's a viable project or a death march.
Sparkyte 5y ago
They have different purposes and should totally both be used but not onto of each other. Agile should always be toward application development and the life cycle of rinse repeat improvements on code. Waterfall should always be used to track initiatives goals with completed deadlines. Things that can be seen to a completed state. Agile is about micro managing. Waterfall is about progress tracking. It is about using the tool for the right job not trying to do everything with one tool. You can open a bottle with a screwdriver but should you?
daveslash 5y ago
We call it "Scrumerfall"
greatgib 5y ago
When I read in this article "but we build things that no one wanted in the first place or no longer wanted", then I know that this goes has not a clue of what he is talking about, but just want parrot buzz world. Otherwise, I agree that waterfall and scrum both sucks!
phkahler 5y ago
>> Waterfall kills iterations because everything needs to be finished the first time for waterfall to work. Well, if you look at some presentations on waterfall you see the big V and there are loops where testing feedback goes back to the left side. What happens is that A) some slides don't show that, and even if those loops are present, B) The V is flattened vertically into a timeline by some manager and the loops are lost.
dd444fgdfg 5y ago
being agile does not mean "not having a plan", it means having a flexible plan and adapting the plan as things change.
vjust 5y ago
For a business stakeholder to understand, and clearly state business requirements, roadmaps to IT. That's a big ask in many organizations, in some cases where the business is evolving in response to customers/economy/random changes (pandemic for example), and given the average business stakeholder who's probably just trying to get thru some crises etc. As I type this, it makes me realize what a shit-show it is, and justifiably so - i.e. welcome to real life. Its messy in its natural state, because you don't control your customer, can't dictate to your customer or the economy or anyone outside your company for that matter - that's almost an invariant.. and is legit the dog that should wag the tail. One thought that comes up is messy is ideally suited for agile, maybe if everyone pulls together , i.e. sees things the same way (without things being rammed down ). I've had an experience recently when I emerged from the mess, switched jobs, and went into a much more 'orderly' (read large/glacial) organization, I realized how effective messy agile is : No scrum masters, almost no managers, your Kanban and sprint board is the only work record (plus confluence), No word documents, absolutely no PPTs. It just worked .. I did hate some parts when I was in it but those were some social aspects. Taken by itself we shipped, as a flat team, and everyone knew everything, we were agile. This was what it took to ship. In those uncomfortable 18 months, I'd made the transition from waterfall to agile. Work items have to be brutally meaningful and direct.. self-organized, without any of "lets do an AI project or neat dashboard". So you need capable business leadership, and capable tech leadership - both of whom should be able to cut thru jargon, frameworks, bleeding edge tech toys etc.. and just set priorities. The engineering team executes on those in a self organized way. As for scrum, safe-agile - if it has a certification for it, that's self serving with some vested interest, causing much overhead, you either need technical engineering people or product owners.. otherwise it just leads to org bloat.
somewhereoutth 5y ago
In any line of work, things happen because a bunch of people who know what they are doing - and get along reasonably well together - are for some reason motivated to make those things happen. The rest is noise.
dwenzek 5y ago
I see as the key point of this post the following point: > I believe we urgently need a new process for working remote. I do believe the same. Working remotely forces agile processes to be adjusted. Information radiators are no more the same. I can no more notice that 3 guys are arguing since an hour in their corner. I can no more notice that 1 guy is struggling alone with his compiler. It's more difficult to agree on a design on the whiteboard. The pace of our days has changed too, with more strict alternation between meetings and individual activities. We need other channels, more written communication, and a bit more of planning. In no case a whole up-front plan. Definitely not. But the minimum of planning that will help to cope with the distance and the changed pace.
friendzis 5y ago
Well, if you look closely Scrum is a waterfall system. "Classical" waterfall just works on larger chunks - releases or even whole projects. Scrum focuses on "sprints" - small chunks of functionality - but still applies tiered, waterfall approach: you start a sprint with planning, move to development, run quality controls and deploy. You should see waterfalls in your Scrum. The only question is whether the chunk size you apply the waterfall on is appropriate

197 points by KingOfCoders 5y ago

It strikes me as impossible that no one realized that projects needed to adjust to unforseen events before a bunch of consultants decided to write a manifesto while skiing in Aspen.

sklargh 5y ago

Agile, MBA for, "I would like it immediately regardless of consequences for others."

Flankk 5y ago

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity.

moritonal 5y ago
Agile (if the culture incentivises honestly) does have the benefit of feedback. Rather than a black-box which "could" be done in a month, you can instead see that the team on-average under-estimates by 10 days, has x stories left, so it'll likely be done in 2-3 months at this rate. The downsides are that it opens up the team to feature-creep, introduced a pile of weird buzzwords, and can be massively wasteful if the team doesn't want it and it's forced on them.
- lelanthran 5y ago
  > Agile (if the culture incentivises honestly) does have the benefit of feedback. Doesn't Waterfall incorporate feedback? In my memory and experience, it does. My memory of learning Waterfall back in the early 90s is a bit hazy, but I distinctly remember that one of the advantages touted was that mistakes earlier in the process of developing software are cheaper to fix than mistakes later in the process (no matter what the process is). Finding an error when drawing up the requirements is orders of magnitudes cheaper to fix than finding an error after piloting at the client. As I remember it, Waterfall was taught (to me) as a way to avoid developing the wrong product, or a product that does not meet the requirements of the end-user (sound familiar?) My SDLC textbooks from back then were filled with different ways to elicit requirements, because fixing broken requirements after the product was developed was (and probably still is) bloody expensive. In the same way, fixing bugs during a test phase is a lot cheaper than after a deployment phase (hence various types of testing were introduced by the textbook). Fixing bugs during a pilot phase is a lot cheaper than after a full deployment, hence piloting was in the textbook as well. Agile aims to deliver features one sprint at a time. Waterfall aims to deliver the specified system as a whole or not at all. Which one works better is probably contextual, but I cannot see either one being unconditionally better than the other.
  - DnDGrognard 5y ago
    Exactly each waterfall phase has its own iteration loop
  - db48x 5y ago
    Yes, though as originally documented the Waterfall process didn’t have much to say about iteration. It was simply left to the reader to realize that they would be releasing version 2.0 of their software a year or two later, and that they could incorporate feedback from the users of version 1.0. Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too.
    - lelanthran 5y ago
      > Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Well that makes sense with my belief that WF aims to "deliver the system as a whole or not at all". There's no point in delivering an MVP G2A missile system that is not complete. > Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too. To be sure, CI/CD pipelines make the fixing of bugs in the code cheap enough to simply deploy when you can. However, bugs in the specification aren't going to be cheaply fixed after deployment, and these are much more common[1] and hard to get correct than any other type of bug. [1] I.e. the code does exactly what the programmer intended it to, but what the programmer intended it to do is different to what was needed.
mytailorisrich 5y ago
I don't think it's any issue of individual raw productivity. It's about not wasting that work by focussing on building exactly what the customer wants as fast as possible. With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. This means a longer lead time to working software and to any sort of feedback, and usually a waste of time in the docs/specs phase. Even trying to write a whole perfect spec before doing any coding prevents you from benefiting from the practical feedback that comes from actually doing. For some types of software this works mostly fine, but others not so much. Hence why most methodologies since then have feedback loops and try to make then small. IMHO sprints are not to pressure (though the name may not be well chosen in that respect) but to enforce small-ish iterations rather than spending 6 months developing something in isolation.
- lelanthran 5y ago
  > With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. (see my reply above, for some context and why I might be wrong :-). My recollection of Waterfall is that there is always an "acceptance" phase at the end of every "fall"[1] - IOW, there is a sign-off by the stakeholders that what's in the phase is correct. So your requirements are engraved in stone, your test protocol is engraved in stone, and your UAT is engraved in stone, and your "pilot performance acceptance" is engraved in stone. If it turns out there is an error in any one of the phases above then that error, and that error alone, is signed off on and goes through all the phases (or "falls"?) again. Since this is more expensive the further in the falls the error is, there is pressure to get as much sign-off as possible for any issue before that issue proceeds to the next phase. [1] I like the word "fall" to describe each phase of waterfall :-) I'm going to start using it more often and see if it catches on.
mr_toad 5y ago
> Waterfall was never that bad anyway. If you’ve never seen a project that wasted its entire time in the scoping and planning phase (and not produce anything), then you’ve never seen how bad waterfall can get.
- avian 5y ago
  Just to make a counter point, if you never spent your days in planning poker meetings, endlessly discussing hundreds of tiny scraps of yellow paper stuck to a white board (and never produce anything), you've never seen how bad Scrum can get.
drran 5y ago
Water is a good, predictable process. It's just result bad. If the result is not important, then use waterfall.
- jollybean 5y ago
  "Water is a good, predictable process" No, Waterfall is bad precisely because of the inherent unpredictability of a given project. Never in all of history was a large software project speced out and built on time. Software lives in a dynamic environment, so the process has to be mutable. Maybe the answer is not 'Agile', but it's definitely 'agility'. If we set longer term term, rounded goals, but with smaller iterations, then there's a possibility, but not a big Waterfall.
  - drran 5y ago
    SCRUM is just a bunch of small Waterfalls. In SCRUM, we have 2-week sprints. It's not important when one of the sprints will fail, because we will adjust following one. Moreover, we plan for first 2 sprints to fail anyway. Why we should use something else, more complex, instead of Waterfall, for a single sprint? Waterfall is good enough and predictable enough for a 2-week sprint. Yes, the result of a single waterfall will be bad, we plan for that, but accumulation of knowledge will lead us to success.
cube00 5y ago
> As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity. This is why I hate agile, it's incredibly stressful. Daily stand ups to justify your last 24 hours, affirmations in said stand ups which must begin with "Yesterday I committed to... and did/did not achieve this because..." followed by "By this time tomorrow I commit to delivering....". JIRA burn down charts dropped in our group chat to "remind us" to keep following the planned burn down line, looking for stories we can close out to try and sneak the chart to match the line and somehow try and catch up after they're closed. It's horrible.
- detaro 5y ago
  None of that is a requirement for agile processes. (Indeed I would argue that unless you have decided that's the best tool for your team, you're probably not being very agile. And no, when management of a big-co dictates how you work, they can call it "agile" as often as they want, it's not. Of course still extremely common, sadly)
- iamflimflam1 5y ago
  That is not agile it is SCRUM.
- littlecranky67 5y ago
  All you say is agile not implemented correctly (which is very common). I am a contractor and switch projects and development environments very often. I've seen agile working really well when it is properly implemented, and really poorly when it is wrongly implemented. The biggest problem I see that people never really get educated in agile. I see PMs/POs/Developers etc. that never had any formal training in agile/Scrumm (books, courses, experience) but rather learn-by-observation, i.e. "do what others do". And I have seen scrum master with zero expierience as a developer, just blindly trying to follow written guidelines in the books (scrum manual etc.) without being able to adopt those to a real development process. Take for example your metion of standups: They are really valuable, and are not meant to "justify" your last 24h - but some managers think that this is the case, i.e. make sure your developers are not slacking and surfing on hacker news all day. Instead, one of the purposes is to detect blockages in any way. I mean if a dev takes very long for a task without it being justified (i.e. no other developer would understand why it would take so long), it might just be due to lack of skill and the dev might need some more training or senior assistance. It could also be that the task is more difficult than originally anticipated, in which case the team should possible act on it and change the scope etc. Sometimes it could also be a very eager junior dev, who just doesn't want to admit struggling with something out of pride or even fear etc. As a developer I can totally say, it actually takes quite some guts to come out in a group of devs and freely admit: "Hey, I struggle with that task, I don't know what I am supposed to do, or am not familiar enough to debug that code, can somebody help me on this?" - but admitting that you are not perfect is something lot of people struggle, especially juniors as they think they must be capable of doing everything.
littlecranky67 5y ago
> Agile doesn't magically make people more productive AFAIK not only was that never a claim/scope of agile, but rather the opposite is deliberately accepted with agile: You accept quite some overhead during development, plan for constant refactors, shift of scope etc. The justification is, that while waterfall in theory is the most efficient and productive, in practice you very often end up with a product that doesn't fit your customers/users need. So working 2years on a product that is thrown away in the end and started over is less efficient and more expensive than working 3years on it in an agile way and getting (mostly) what you want in the end. Note that is the one of the reasonings of agile, I am not claiming that these statements and premises have actually proven true in the real world.

rdxm 5y ago

Agile fails not because of the engineering side of the house but because the business can't "get it", and just ignores it...seen this too many times to count across many different biz domains.

zogomoox 5y ago

A version of this is Scaled Agile (SAFe) which somehow manages to combine the worst of both worlds. If you see your organization preparing to go SAFe, run!

otagekki 5y ago
A major French bank where I'm currently working at has implemented this method for its development teams... While we do have deadlines there is so few pressure compared to the other teams I had worked with before, that we actually have the luxury to build our features and being actually satisfied with what we're delivering
RealityVoid 5y ago
Even the name is hillarous. It's like one of those cryptocurrencies that try to be sellable by a pump&dumpy name, like SafeMoon, haha.
chewyfruitloop 5y ago
SAFe seems to be a pyramid scheme to get you to pay for the latest SAFe badge its overly complex and seems to be there to make management feel better about itself
sgt101 5y ago
I misread your comment and thought you wrote "best of both worlds" and embarked on a rebuttal! One of the places I am working at is now ditching SAFe, because they have recognised the issues. The process as implemented there both burns vast amounts of time and is widely ignored. OUTSTANDING!
drran 5y ago
SAFe works just fine when Agile is perfected, i.e. about 5 years after every day practicing of Agile. If you have no Agile to begin with, then you cannot scale it.
allo37 5y ago
Last place I worked tried to do SAFe (I think? They kept repeating it and had all the branding on the presentations). To me it seemed like the idea was to replace a dedicated project manager (or team of them) with a week-long meetingfest every 8 weeks where all the different teams tried to self-organize based on what the business' objectives were. Apart from the colossal waste of time of those week-long "PI-planning" meetings, it was OK I guess...

buro9 5y ago

The extremes were bad, not the essence of the idea. Stay lightweight and you can have the best of everything. When anything is non-trivial to implement, i.e. it has dependencies, then it benefits from _some_ waterfall planning. Meaning to think before the work begins about the approach being taken, all of those dependencies, and who you need to engage and when... tada, you've made a GANTT chart in your head and are now waterfall because you put some thought into the dependencies and the order of execution. Within that, each epic / task can be SCRUM or agile or whatever... all you really need here is an idea of a "definition of done", to prioritise the work so that you hyper-focus on just doing what needs to be done to get you to done. You probably want to continuously remind yourself of those priorities... tada, you've created an agile process. The names are irrelevant, understand the essence of project / program management and do the least you can do execute on that. It's when the processes become formal, tooled up, etc... this is when the worst creeps in. The status meetings for middle management, the reporting of time to project management tools. But no-one has to do this, lightweight project management can work without any of this stuff.

mytailorisrich 5y ago
> then it benefits from _some_ waterfall planning. Meaning to think before the work begins about the approach being taken, all of those dependencies, and who you need to engage and when... tada, you've made a GANTT chart in your head and are now waterfall because you put some thought into the dependencies and the order of execution. Agile does not mean that you should forego all of this and code first, think later. What you describe does not oppose Agile and Waterfall.
- buro9 5y ago
  I know :) But people did take agile to an extreme and they did forego the essence of other processes. I feel that the line "everything in moderation" applies well to project management. Moderation being the key part.
HelloNurse 5y ago
The "extremes" are good in their appropriate extreme niche: spacecraft flight control software is definitely engineering and it has to be perfect the first time (no exploration or iteration), while the only prudent and efficient way to publish a website with a day's notice requires a rushed MVP and then as many small edits and additions as fit in the available time. In the middle of the spectrum there are varied tasks, for which an excess of waterfall can force the creation of low-value documents (e.g. hundreds of pages of up-to-date screenshots of complex forms instead of describing in detail only interesting data and interesting workflow and honestly stating that UI layout will be arbitrarily reorganized according to stakeholder feedback after every demo until they are happy) and an excess of agility can be an obstacle to correct design (e.g. publishing a mock incomplete version of some service without taking a couple of days to determine whether the data needed to actually implement it is going to be available).

xondono 5y ago

To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. The whole thing is about processes, and tools (jira)… the complete opposite. The reason everyone ends up doing waterfall is that it’s not the devs who you need to convince when selling agility, is the chain of command. Being agile means having no long term plan. If the C-suite can’t handle that, you’ll never be agile.

cube00 5y ago
The C-suite only hear "fast delivery" and ignore the other parts while also demanding the waterfall parts that suit the ways they need to work such as committing devs to deadlines one financial year out when funding bids have to be submitted. There is something ironic about being ordered to estimate a 12 month work order while also being told make sure "it's agile" and delivered on time and on budget by ++currrentYear.
- clairity 5y ago
  yes, non-agile organizations try to bolt on agile at the 'bottom' of the hierarchy, and that's a sure recipe for failure because of the significant impedance mismatch that causes. the c-suite wants to hand down directives, and the agile teams want to listen to the customer first, leading to conflicting interests. an organization has to be receptive to turning the marketing function upside down (product being one of the 4 P's of marketing) to be really successful at agile. that's why consulting firms tend to be more successful than ordinary product/service firms at it, because they're already inverting the marketing function (to lead with what the customer wants and then trying to execute on that). executives don't tend to want successfully implemented agile, as it undermines their control of (customer/market) information, and the organizational power derived from that.
  - imbnwa 5y ago
    In my mind, this sorta proves that most companies should not have in-house engineering divisions and instead most of us should be working for software engineering firms much like actual architects. This would likely also solve the career development/engineering pedagogy problem that is so lamented since firms would have better control over time internally.

boffinAudio 5y ago

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated/verified with a Qualification step, and then it gets released to the end user/product owner, who sign off on it. This is a natural flow of steps, and it always appears to me that the new-fangled developer cults are always trying to 'prove' that these aren't natural steps, by either cramming every step into one phase (we only do "Analysis" and call it Scrum) or by throwing away steps (Qualification? What's that?) and then wondering why things are crap. Too many times, projects I've seen fail could've been saved if they'd just gotten rid of the cult-think. Its nice, therefore, to see someone else making the observation that Waterfall is a natural process and all the other -isms are just sugar/crap-coating what is a natural consequence of organizing computing around the OSI model - something that has been effective for decades now, and doesn't need improvement-from-the-youth antics.

jason-phillips 5y ago
> I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor... Because layers of management who need to continually justify their existence can never, ever keep themselves from putting their big fat thumb in the pie and fucking everything up.
littlecranky67 5y ago
The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. Additionally it is really hard for project management to get metrics/early warnings if something is not going properly (no project - waterfall or agile - is without problems during its lifetime). How would you asses the quality/progress of a project based on a couple of a specification or requirements documents 1-2years into the project with no (immediately usable) code being available? How would you asses if the approach taken after 3years in a project will be accepted by your endusers? Waterfall is just a big black box to management and stakeholders with the hope that after 5years something usable will come out of it.

OneTimePetes 5y ago

Waterfall is just a mapping of the dependency graph back into work-packages. As all things are hierarchical in some way, large changes and additions, always lead to a larger change allover the graph, making it necessary to go all the steps back. Change something large enough, and the process forces you back to the architecture drawing board.

pydry 5y ago

I noticed this as well. No matter how dedicated the team is to not doing waterfall, waterfall nearly always creeps its way back when anything that even smells like a deadline rears its head. Waterfall planning tends to get ramped up for four really common reasons: * Managers who simply cannot conceieve of non waterfall planning. * As a response to failure (ironic coz it tends to increase failure rate) * Because it's basically the job of most middle management to do waterfall planning. * Because if your managers manager wants deadlines, tough shit it's deadlines all the way down. * Because ultimately, upper mamagement tends to prioritize control over profit even if that control is somewhat illusory. Waterfall planning is kind of infectious, too - if the team does it in one area it spreads to others. I would say that 90% of teams experience this kind of "waterfall whiplash". I worked on a couple of teams where upper management didnt set deadlines or create roadmaps or anything. These rare occasions were the only time when I was entitely free of waterfall and we were way way more productive because of it. Like night and day. However, 90% of companies can't even envision this, let alone do it. Most people dont even believe its possible - developers included. I suspect this is one component of the secret sauce of high performing startups that defeat wealthier, more established incumbents.

jollybean 5y ago
Waterfall creeps in because it's the most rational and linear way to do anything and we do it in all activities is our life without even thinking about it. When you build a deck, you 'Waterfall' it. Iterative development is slightly counter intuitive, until you write software for long enough, then it's definitely the intuitive approach. I suggest the simplest, easiest, best way to combat the urge to overplan is to break the waterfall down into iterations, do those iterations, assign maybe risk to different iterations given unknowns and to expect change.
- pydry 5y ago
  I actually started to notice after being a developer for a decade that a lot of people run face first into a metaphorical wall applying waterfall to their personal life where it didnt really work as well. It's definitely "natural" though. I wonder if it's a cultural hangover from our agricultural past where lack of waterfall planning = dead.

sgt101 5y ago

I find that waterfall comes with technical certainty. Waterfall is disastrous with erroneous technical certainty, if the customer is convinced that the solution is technically clear and yet there is still uncertainty then what will happen is that a number of good components will be developed and delivered all of which are useless. If you can communicate (you must) the uncertainty and the potential branch points in your project then one of two things happens: - it stops (often) because the client does not have any appetite for risk. This is painful, but it is better than the car crash of a failed waterfall (which is what is going to happen). The opportunity cost for the team and you is very high here - kill it now and get something viable. - you go to agile and make it stick. As soon as you are certain about the solution the design is frozen and you can plan effectively for delivery. This is now waterfall and everyone is happy.

m4r35n357 5y ago

Waterfall == Engineering Agile == Wild West There you go . . . you're welcome!

moksly 5y ago

Most project models are sort of useless in the modern office environment. Waterfall is useless because nobody ever follows it. I agree that it’s sort of the “default” mode, but show me a project that didn’t go back and change something from a previous step. Agile stops working the moment you need to sign any form of contract with anyone, because nobody is going to sign a contract that doesn’t tell them what they are going to get for X amount of money. Its processes are sort of fine on the smaller scale because it breaks project tasks into neat to-do-lists, but it’s utterly useless for actual project management because estimates are a lie and delivering on time is what is required to drive a project successfully. Then there is everything in between from the various stage-gate models to UP and what not, and they are all equally useless because nobody ever really follows them and because they can’t really apply to every type or project which is what organisations tend to want. I haven’t worked in a FANG or whatever you call the big American tech companies, but I have worked in the European Public sector and it’s affiliated private sector companies for years, and nobody has a magic project model in my experience. In many ways the most successful companies tend to be the ones who simply use some sort of Kanban board and refrain from giving estimates in intervals lower than weeks. I fully understand why organisations waste resources on this area of course, I’ve been in the trap myself many, many times and I’ll likely end up in it again, but the simply truth is that every project manager or business process person that you have is one less developer, and these helper functions don’t really add anything to your value chain the moment they start making up work for the sake of having the “right” processes in place. The best way to handle project management is to hire good developers who know how to deliver projects that are build safely and maintainable. That’s not easy, but no amount of project management is going to make up for the lack of them. And I’m not saying you shouldn’t need project managers or have an organisational strategy, but if you’re hiring more support staff for your developers than you would for the tradesmen you’d hire to build your house then I think that you’re doing management wrong. We build an entire city hall, a process that took almost a thousand different employees from very, very, differently ones of work and we did it with 1 project manager, 1 architect and 10 lead engineers. We did it on time and under budget, and that is how we build our IT projects as well. It’s sort of waterfall, because it’s what we default to like the author gets into, but maybe that’s because it works?

cowl 5y ago

Guid_NewGuid 5y ago

I'm just wrapping up an Agile project, truly agile, and it was actually quite fun. At the start they tried to get us to use Scrum and 2 week sprints and I pushed back. We had basically no fixed meetings except a weekly sync and a couple of weekly meetings with stakeholders. In the first 2 weeks we were producing analysis of whether we should do the project at all and my week has been pretty much 20% meetings with product since then and it has been fantastic. We used JIRA but only as a log of tasks, sometimes we were asked to report up some more detailed estimates so we made a rought Gantt chart type plan, but otherwise we've been left alone. We've done the project in a way that truly matches the agile manifesto. And we're only a week or so past the original estimate in a 3 month project, so pretty on-track. It just reinforces for me that Business Agile is a load of crap[0]. [0]: https://d22qefpbdavdoz.cloudfront.net/#agile-is-hell https://d22qefpbdavdoz.cloudfront.net/#agile-is-hell

sornaensis 5y ago

In my few years working as a dev, I am absolutely convinced that scrum and agile are the worst possible development practices you can have from the perspective of a developer, even though they are sold as 'developer centric' or that seems to be the impression a lot of people have at least. It makes no sense at all to me to constantly have work interrupted with customer meetings that produce NO concrete specifications because everything is expected to be done just-in-time, on a whim essentially. It seems to nearly universally lead to dev whiplash, poor product architecture and large amounts of technical debt. Many companies also seem to end up employing tens of people who don't actually have any role at the company-- they just show up an 'moderate' these 'ritual' meetings. I'm sorry, what exactly is the value add for having a person with no understanding of either development or product, running meetings that center around product development??? It just seems like a scam to create jobs for people with otherwise useless business degrees. I'll take however many weeks of blistering specification followed by diligently developing against hard deadlines to the insanity of rolling technical debt and borderline abusive micromanagement that agile methods all but enforce. /rant

simonbarker87 5y ago
Ahhhh, I couldn’t have put this better myself. Agile is forcing devs to change how they work to solve a problem caused by poor product and business management and all the problems it creates are swept under the rug as “technical debt”
lbriner 5y ago
It makes a lot of sense, which is why a lot of people follow it. Your comment is implying that somehow 1000s of people around the world don't realise they are doing something stupid. You are portraying a poorly run implementation of agile as the only way and then destroying it. We call it a straw-man. * My development team are rarely interuppted with customer meetings * The meetings we have will always have outcomes, even if those are high-level "would this be possible?" * Everything is not expected to be done "just-in-time" "on a whim", it is simply a case of allowing the highest priorities to be looked into in much shorter cycles. * "Dev whiplash". Nope, not here. Poor architecture and tech debt? I haven't seen any more in the agile projects I have worked on compared to old waterfall projects. * Tens of people who don't have any role. Nope * Non-dev/product running meetings? Nope. Shouldn't happen and if it does, it's nothing to do with agile (or waterfall!) * Borderline abusive?

frant-hartm 5y ago

> We had elaborated waterfall processes like Rational Unified Process (RUP) in the 90s This is factually wrong. RUP is an example of iterative process, not waterfall at all.

swiftcoder 5y ago

No matter what process we adopt, we'll always have waterfall as long as the sales side of the house needs predictable features and release dates. There isn't really anyway round that - if we can say with confidence that we'll release features X, Y, and Z in a release 6 months from now, then we don't have room for more than localised iteration. Agile-ish systems work great when you don't have pre-determined delivery dates, but unless you are an internal-facing team with only a backlog of tech-debt to burn down... who is actually in this position?

Chyzwar 5y ago

There are even companies selling scrumfall consultancy known as SAFE. In my experience, there are few problems with agile. - scrumfall that is mostly cause by stakeholders wanting to have yearly roadmaps and KPI tied to delivery of increment. Plenty of organizations have separate engineering and product orgs that create this disconnect. - groomorgy when teams spend more time on analysis than actual work. Driven by middle managers thinking that doing less is better than not finishing the sprint in time. Middle managers that do not understand tech or business but can track progress of tasks. - cost-amnesia When feature is build over many increments is hard to estimate total cost and long term maintenance cost. You might have teams re-inventing a wheel and having a massive amount of slowly rotting code. - conway-architecture. Because people think that agile is all about small independent teams, it naturally leads to service oriented architecture. In many places, SOA is a bad fit problem or organization. Small company with limited resources doing micro-somethings will create death trap. - teflon-promotions You will have teams and projects doing terribly over a longer period of time, but in initially phase they delivered value. You will see people promoted in the organization based on early wins, even if they left behind dead bodies. It often encourages tech dept over long term maintenance. I still feel that agile is great. Most of these problems are people problems, not agile itself.

clement_b 5y ago

People or teams managing software development workflows usually silently tailor them, fitting the reality of their constraints, often outside of Scrum and Agile (despite claiming otherwise in job descriptions or developer posts)! And that's OK! There is nothing wrong with taking the best from waterfall or Scrum, or you name it, and adding a pinch of personal/novel ideas if a precept from an existing framework doesn't apply out of the box. These concepts are decades old; new tech and new constraints have arisen. People have changed. New answers are needed, or at least worth a shot. It's also OK to re-appropriate out-of-fashion concepts when those are a better fit. The key, in my view, is to remain open to new or old ideas and to interpret and adapt dogma rather than blindly follow it.

andrewingram 5y ago

In my mind agile, is about avoiding committing to a particular direction before verifying that it's the right one, and in a lot of cases (particularly in the startup world), verification requires shipping to potential customers. Agility doesn't promise fastest time to delivery. It's acknowledging that you'll probably build the wrong thing, so it's about making it easier to course-correct. The failure state of agile (waterfall hidden behind agile ceremony) is usually triggered by leadership/management teams not willing to _truly_ delegate. Once process becomes dominated by accountability and visibility (which I've never seen not happen with Scrum), rather than supporting the people doing the work, all bets are off.

ochronus 5y ago

Yup, when people (semi-blindly?) adopt a process but not the principles, this happens. There are a tons of fallacies in product development on multiple sides... also trenches too deep between disciplines sometimes. These are hard to fix. I've written a short one about some typical fallacies: https://leadership.garden/product-development-fallacies/ https://leadership.garden/product-development-fallacies/

dennis_jeeves 5y ago

The Agile/Scrum emperor has no clothes.

known 5y ago

"You can't produce a baby in one month by getting nine women pregnant” --Warren Buffett (b. 1930)

ben7799 5y ago

I started working prior to Agile becoming a thing but wasn't around for the entirety of the 1990s. I have seen both waterfall and agile products fail or succeed. I don't think the process is ever to blame when they failed or deserves much credit when they succeeded. My take on it is both processes have their strengths and weaknesses and perhaps a product needs to start Agile and slowly morph towards Waterfall as it matures. Agile is great for the pre-1.0 phase when no one is sure what exactly the market needs yet and you're working on a software product with low cost to acquire customers. If you're iterating over different ideas trying to triangulate what is going to sell, and you don't need to scale yet before you figure out if you can sell it, then Agile has a great role to play. This is kind of risky startup time for sure though. But when your product has become huge, mature, and you're signing $1M+ annual contracts with enterprise customers and your new features are getting very complex Agile doesn't work as well at that point as the tech debt it creates become more and more punishing as the project size grows, and the complex features become more and more difficult to fit into sprints without causing disasters. If a feature takes 6 months it can be a disaster to force it into 2 week sprints that just build tech debt in the name of being able to demo. I've been on the current product I work on for about 8 years and have watched it morph from a pre-1.0 Agile product to a $500M+/yr complex product. We've been lucky to have good management and the process has gradually changed as the needs of the product have changed. My career has mostly been enterprise B2B software... the best process for B2C, B2B, aerospace, military, etc.. is not necessarily going to be the same. One thing for sure though is Agile has largely become a religion and less so of a pragmatic process as time has gone on.

bradenb 5y ago
What I've found while working in defense is that when your customer issues a statement of work with clear high level requirements then you're going to need waterfall (even if just at a high level).
- kevinmchugh 5y ago
  Yeah, I think this is uncontroversial. If your problem domain generates strict, well-defined requirements, agile has less to offer. https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff There might still be some useful agile practices, and you could have the less defined work (eg internal tooling?) be more agile.

bdcravens 5y ago

Agile tries to create dynamic output with a typically static input (developer salaries), so there will always be drift towards a natural state.

SideburnsOfDoom 5y ago

> Efficiency is the key driver for waterfall. Why work on things together as a team? Is is often forgotten that the efficiency of the individual is not the same thing as the efficiency of the team. Understand this and the case for waterfall is weakened, perhaps fatally.

dandare 5y ago

I am ok doing waterfall - what I can't stand is doing waterfall dressed as agile&scrum. Agile&scrum are internally inconsistent methodologies which means that a bad faith actor (be it a smart but asshole engineer or clueless boss) can always point out you are doing something wrong (against the theory), regardless of the flavour/school you are using.

AtNightWeCode 5y ago

Another conclusion from the same input is that product owners in the Scrum world are just waste. In a lot of teams I worked with POs are just mediators between stakeholders and the developers.

boublepop 5y ago

If you read the original waterfall methodology descriptions, even waterfall isn’t supposed to be what waterfall turns into in organizations.

andrei_says_ 5y ago

In 2015 Dave Thomas, whose name is on the Agile Manifesto, gave a talk named “Agile is dead - long live agile”, addressing the intent behind the manifesto and the Agile Industrial Complex / cult-like movements which spawned from that. https://youtu.be/vqz8ND-N1hc https://youtu.be/vqz8ND-N1hc

passwordreset 5y ago
I've watched this video a few times, and I recommend the part at 25:43 which describes agility. To repeat it here: 1) Find out where you are 2) Take a small step toward you goal 3) Adjust your understanding based on what you've learned 4) Repeat I think this is useful as a high-level guide, and it's both easily memorizable and generally memorable. I use a silly mnemonic "FI-TA-AD-RE", and I come back to it whenever I'm working and get to a point where I have to ask myself "What the hell am I doing?"

devnull255 5y ago

"Scrumfall" sounds like a rejected James Bond movie script.

bastardoperator 5y ago

The sooner people realize that agile and scrum are sales pitches with little substance the better off everyone will be.

spookthesunset 5y ago
I don't know if I agree with that. Rather than have every team on earth invent their own process from first principles, they provide adequate starting points on which to grow. Agile, Scrum and Kanban aren't perfect but they can get a team started. Good teams will take them as templates and tweak as needed.
- regularfry 5y ago
  If you look at Kanban specifically, you can tell if it's been implemented well because it's not just affecting the team. It's a tool to improve the entire value stream.
  - bastardoperator 5y ago
    Even that is a bastardized version when compared to what Toyota developed. The reality is software engineers are not factory production line workers. Also, kanban negates the fact that cars are completely spec'd out (aka waterfall) by the time a car is ready to be built on a production line.
    - regularfry 5y ago
      Yes, and a vast amount of the design detail that goes into car design is to make building it easier. You're right that software engineers aren't factory production line workers, but I'm not sure it actually matters. The only detail I can see relevant to whether kanban can work in is the distribution of how long each piece of work takes, and while you'd expect the distributions to be different between "bolt lump A onto tab B" and "add feature X to website Y", I don't think they'd be different enough to completely break the queueing model. I'm not sure that it matters that each piece of work through the team is unique versus the completely repeatable part assembly stereotype of factory work. The main issue I see with kanban as a software development idiom is that in every place I've worked, supply cannot be effectively constrained, except artificially, at the gate into the team. There is always more work to do than time to do it in. Now part of that is a cultural problem to do with politics and the place of the CIO (or equivalent) in a typical company, but it definitely feels like kanban needs to be driven from outside the tech org to work well.

mkl95 5y ago

Title describes my current job. Basically a thin agile wrapper around a broken waterfall process with gargantuan releases plagued with heisenbugs and shoddy QA. It's fun but I'm still not sure if it's a viable project or a death march.

Sparkyte 5y ago

They have different purposes and should totally both be used but not onto of each other. Agile should always be toward application development and the life cycle of rinse repeat improvements on code. Waterfall should always be used to track initiatives goals with completed deadlines. Things that can be seen to a completed state. Agile is about micro managing. Waterfall is about progress tracking. It is about using the tool for the right job not trying to do everything with one tool. You can open a bottle with a screwdriver but should you?

daveslash 5y ago

We call it "Scrumerfall"

greatgib 5y ago

When I read in this article "but we build things that no one wanted in the first place or no longer wanted", then I know that this goes has not a clue of what he is talking about, but just want parrot buzz world. Otherwise, I agree that waterfall and scrum both sucks!

phkahler 5y ago

>> Waterfall kills iterations because everything needs to be finished the first time for waterfall to work. Well, if you look at some presentations on waterfall you see the big V and there are loops where testing feedback goes back to the left side. What happens is that A) some slides don't show that, and even if those loops are present, B) The V is flattened vertically into a timeline by some manager and the loops are lost.

dd444fgdfg 5y ago

being agile does not mean "not having a plan", it means having a flexible plan and adapting the plan as things change.

vjust 5y ago

For a business stakeholder to understand, and clearly state business requirements, roadmaps to IT. That's a big ask in many organizations, in some cases where the business is evolving in response to customers/economy/random changes (pandemic for example), and given the average business stakeholder who's probably just trying to get thru some crises etc. As I type this, it makes me realize what a shit-show it is, and justifiably so - i.e. welcome to real life. Its messy in its natural state, because you don't control your customer, can't dictate to your customer or the economy or anyone outside your company for that matter - that's almost an invariant.. and is legit the dog that should wag the tail. One thought that comes up is messy is ideally suited for agile, maybe if everyone pulls together , i.e. sees things the same way (without things being rammed down ). I've had an experience recently when I emerged from the mess, switched jobs, and went into a much more 'orderly' (read large/glacial) organization, I realized how effective messy agile is : No scrum masters, almost no managers, your Kanban and sprint board is the only work record (plus confluence), No word documents, absolutely no PPTs. It just worked .. I did hate some parts when I was in it but those were some social aspects. Taken by itself we shipped, as a flat team, and everyone knew everything, we were agile. This was what it took to ship. In those uncomfortable 18 months, I'd made the transition from waterfall to agile. Work items have to be brutally meaningful and direct.. self-organized, without any of "lets do an AI project or neat dashboard". So you need capable business leadership, and capable tech leadership - both of whom should be able to cut thru jargon, frameworks, bleeding edge tech toys etc.. and just set priorities. The engineering team executes on those in a self organized way. As for scrum, safe-agile - if it has a certification for it, that's self serving with some vested interest, causing much overhead, you either need technical engineering people or product owners.. otherwise it just leads to org bloat.

somewhereoutth 5y ago

In any line of work, things happen because a bunch of people who know what they are doing - and get along reasonably well together - are for some reason motivated to make those things happen. The rest is noise.

dwenzek 5y ago

I see as the key point of this post the following point: > I believe we urgently need a new process for working remote. I do believe the same. Working remotely forces agile processes to be adjusted. Information radiators are no more the same. I can no more notice that 3 guys are arguing since an hour in their corner. I can no more notice that 1 guy is struggling alone with his compiler. It's more difficult to agree on a design on the whiteboard. The pace of our days has changed too, with more strict alternation between meetings and individual activities. We need other channels, more written communication, and a bit more of planning. In no case a whole up-front plan. Definitely not. But the minimum of planning that will help to cope with the distance and the changed pace.

friendzis 5y ago

Well, if you look closely Scrum is a waterfall system. "Classical" waterfall just works on larger chunks - releases or even whole projects. Scrum focuses on "sprints" - small chunks of functionality - but still applies tiered, waterfall approach: you start a sprint with planning, move to development, run quality controls and deploy. You should see waterfalls in your Scrum. The only question is whether the chunk size you apply the waterfall on is appropriate