We are all agile, and there is no waterfall anymore
-
@Gąska said in Spec-driven or outcome-driven development?:
Agile is overrated, waterfall just got some bad press.
Agile, lean, and «synomym» are simply software-driven business mindsets that everyone has transformed to in the Western world; it's the notion of (1) smaller changes, (2) sooner. A lot of software used to be created the way we build skyscrapers (i.e. every window and electric outlet designed first, then materials planning, then project planning, etc.), but those programs were relatively small (stories high?) and that's gone the way of punch cards.
That's not to say large software projects aren't released in multi-month or multi-year cycles, but the notion of "build it like a skypscraper" doesn't exist anymore. Planning is still absolutely critical to any business (especially software), and the idea that a business can actually run on two week sprints is nonsense, but it's an okay way for a small team to do work planning.
-
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
Agile, lean, and «synomym» are simply software-driven business mindsets that everyone has transformed to in the Western world
That everyone either thinks they've transformed to or they think they're working to, IME.
-
@loopback0 I think the transformation happened. What businesses aren't agile now? Any one who will says "were trying to do agile" now is probably talking more team-level improvements instead of business level strategy.
-
@loopback0 said in We are all agile, and there is no waterfall anymore:
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
Agile, lean, and «synomym» are simply software-driven business mindsets that everyone has transformed to in the Western world
That everyone either thinks they've transformed to or they think they're working to, IME.
Most people aren't following any particular agile cult by the book, true, but since the barriers to releasing software have gone down so much (especially if there is no distribution because your users come to your page!) that pretty much everyone releases early and often.
Waterfall was always a bit of a strawman anyways.
-
AFAIK Waterfall was, from the very beginning, just a criticism of non-working approach (http://www.idinews.com/waterfall.html and similar, CBA doing proper research form primary sources). All serious methodologies actually did include some feedback look.
Sadly, it's actually true that many organizations actually did implement straight Waterfall. Sometimes just because they heard about it and thought it's a good thing, sometimes because of basic inability to actually understand and follow the officially adopted methodology.
I've seen that... more than once.
I remember vividly my cultural shock in one such company, when I witnessed two developers arguing about some data structure (passed between two different systems) specified by specification and which side should fix the reported BUG (because the result was completely broken behavior). After several days, I said "that's enough!", found the Analyst who wrote the spec, bought him to our workplace, explained the bug and of course, his reaction was "oh, I see, I forgot about this case... this cannot be represented by an attribute, let's use element with 1..N arity.
And so we did. And every time I remember those two
and their stringly-typed list inside xml attribute... in completely new data structure for completely new application, moths before release... my blood pressure gets up.
-
@boomzilla said in We are all agile, and there is no waterfall anymore:
Most people aren't following any particular agile cult by the book, true
My line manager/scrum master did an agile course back in the day, and that really emphasised that you needed to do what worked for you. I've heard some outraged comments from the sidelines "You can't do planning poker! You're doing scrum, planning poker is extreme programming!" but that doesn't make sense to me.
I think the ideal lies in the centre. It doesn't make sense to fully plan a release a year or two ahead, you always get new insights along the line (even if those are only bug reports on the previous version). But likewise 'full agile', where you supposedly start from a clean slate every sprint, has its problems. Projects which can neither be completed in 4 weeks nor split functionally are a reality.
-
@PleegWat said in We are all agile, and there is no waterfall anymore:
My line manager/scrum master did an agile course back in the day, and that really emphasised that you needed to do what worked for you.
Yes, the irony is that they all talk about tailoring stuff to your process, but the culture is that the "rules" of the method engulf your life.
I think the ideal lies in the centre. It doesn't make sense to fully plan a release a year or two ahead, you always get new insights along the line (even if those are only bug reports on the previous version). But likewise 'full agile', where you supposedly start from a clean slate every sprint, has its problems. Projects which can neither be completed in 4 weeks nor split functionally are a reality.
-
frAgile is bending back towards a waterfallish process lately, where everything is defined in requirements up front, and when the design is found wanting, this is summarily ignored until two years down the line when everything else has been built and depends on the dumb quirks, and changing it will require massive rewrites of everything. This is also combined with the aversion to actually designing APIs, so everything is even worse.
In the projects i've worked in the last few years the only thing that gets requirements is the UI, the integrations with other systems is entirely missing in requirements or specifications. And I just magick the backend out of thin air to do what it needs to do. I don't mind that much, because I've built enough backend systems to know how to do it properly and in a modifiable way so that it's not that bad when someone wants to change something integral, but man, imagine someone that's fresh out of uni to be dumped into doing that. It'd be like IoT everywhere.
-
I used to hate waterfall but now I've started to think it's necessary when working with H1Bs. They are completely unable to make a change in a forward thinking way. So anything agile that goes on longer than 3 or 4 sprints looks as coherent as a shanty town.
-
@boomzilla said in We are all agile, and there is no waterfall anymore:
@PleegWat said in We are all agile, and there is no waterfall anymore:
My line manager/scrum master did an agile course back in the day, and that really emphasised that you needed to do what worked for you.
Yes, the irony is that they all talk about tailoring stuff to your process, but the culture is that the "rules" of the method engulf your life.
Actually, we have really followed this in one company I worked for.
In my team (I was Lead Engineer), we always struggled with estimations and sprint planning... mostly because we had several quite different systems and switched topics quite often. So we decided to completely ditch sprints and story points and just adopted hard limit of work-in-progress tasks (it's called "Kabnban" or "Scrumban"). We still had some "planning" meeting, but only when we (almost) run out of tasks. We got some strange looks form other teams, but... it worked and that's the only thing management cared about.
This company (incidentally, the same company from my previous story) is definitely and example of "Agile adoption success," if you want some. I should, however, add that this "adoption" had some "non-standard" characteristics. Notably the management attitude I've mentioned, but also strict adoption of good practices (reviews, automated tests, etc).
-
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
the idea that a business can actually run on two week sprints is nonsense
Unfortunately, it can be some very persuasive nonsense, especially when the people you're persuading are high-level business decision makers who have never written a line of code in their life. They get a fancy presentation full of cool-sounding buzzwords and before you know it they're imposing SAFe on the rank and file, which is exactly what you just mentioned, and even more nonsensical than you'd think if you haven't experienced it.
-
@Zenith said in We are all agile, and there is no waterfall anymore:
I used to hate waterfall but now I've started to think it's necessary when working with H1Bs. They are completely unable to make a change in a forward thinking way. So anything agile that goes on longer than 3 or 4 sprints looks as coherent as a shanty town.
I don't think that's really a waterfall vs. agile concern. It seems more like a 'how much designing do your programmers do' concern and a matter of code reviews. I have experienced the same with offshore developers though: Their education seems to be based on 'someone else will provide you a class diagram, and you implement it'.
-
@PleegWat I don't want to derail this thread but every time I read/hear "code review" I expect that person really means "style review." I have never been party to an actual code review outside of those I've conducted myself.
-
@Mason_Wheeler said in We are all agile, and there is no waterfall anymore:
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
the idea that a business can actually run on two week sprints is nonsense
SAFe
-
@Zenith said in We are all agile, and there is no waterfall anymore:
@PleegWat I don't want to derail this thread but every time I read/hear "code review" I expect that person really means "style review." I have never been party to an actual code review outside of those I've conducted myself.
Usually, that's mostly because people don't have the time to sit down and analyze the code, or feel confident in doing so. The confidence bit is particularly relevant when you've got people with 2 years of experience reviewing the code of someone with 15 years of experience. I've started telling people I'll put wrong but functional code in just to make them look harder.
-
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
@loopback0 I think the transformation happened. What businesses aren't agile now?
Did you ever watch TV in the US, before you got stuck in Japan? The software that runs your favorite station was most likely written at a non-agile shop. I know because I used to work there, and we were the market leader by a huge margin, especially in the USA.
We had no "agile-ness" whatsoever, and it was amazing! Developers had a clear idea of what we were supposed to be doing, because we had PMs who wrote up specs before we ever started working on a project, and if it was insufficient for our needs, we had the right to send it back to them and say we needed a better spec. We'd have a team meeting anywhere between once a week and once a month, just to ensure that everyone was on the same page; none of this daily standup nonsense wasting everyone's valuable time, because management trusted us. We had releases once every few months, across multiple product lines; any given customer would probably see a new version once every year or two. (When you're a giant TV network, there's no way you'll ever accept the hassle of frequent updates anyway!) And our releases were on time, containing the features they were supposed to contain, and for the most part they worked, and worked well.
The clients loved our software, and the developers loved working there. We dominated the market, and over the 5 years I was there we put one major competitor out of business and acquired another, because our software was just so much better than anyone else's. Our system wasn't "waterfall;" that's not even a real thing as @boomzilla pointed out. It was just common sense, experience, and trust: management hired good people, got them pointed in the right direction, and got out of their way so they could create high-quality work.
If I had known just how unusual of an experience that was, I would have never left. Since then I've been at a variety of places with a wide range of agile practices, and I've seen a pretty strong inverse correlation between "agile-ness" and quality, both of the software developed and of the workplace in general.
-
@Carnage Oh they have the time. Some of it's also dependent on code review being a discussion rather than a dictate. That same sort of unilateral direction is what's often identified as a major weakness of waterfall.
-
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
the notion of "build it like a skypscraper" doesn't exist anymore
Tell that to higher ups here
-
@sockpuppet7 said in We are all agile, and there is no waterfall anymore:
Tell that to higher ups here
They're higher up the skyscraper, right? Well they want good foundations so that everything doesn't collapse around their ears, so they should let the specialist foundation builders get on with it while they choose the colour of the wallpaper in their offices.
-
My last company adopted Agile (hired the consultant and everything). My group was already largely 'Agile'. We already had a morning "meeting" (our dev team was split across several countries, so we had a fixed time that all of us would be available to talk to each other, it was scheduled as a meeting to keep other people from scheduling meetings at that time). My team had switched to a quarterly release cycle several years prior to the agile edict (moving the other teams from a 1-2 year release cycle down to quarterly). The only significant change was the two week sprints and the planning meetings. But we could push cases from one sprint to another with ease, so it didn't really change much for us lowly coders (management had more meetings, which they all "loved")
We even got to use the changes to improve our process. We got to bring back our customer adversary board, finally had the push to get nightly builds going (IT didn't want to give us the hardware) and we were able to expand our QA team.
In the end, for my team, the Agile edict was a positive change. That being said, my team was never "true" agile. I know several of the other teams were required to make more drastic changes (going from 2 year cycle to 3 months is pretty drastic) and they were far more displeased with the change than we were.
(as a side note here, the 2 year release team, was technically a 1 year release team that always pushed releases back another full year, so something needed to change, not sure agile was the right choice, but it was change)
-
@Dragoon said in We are all agile, and there is no waterfall anymore:
management had more meetings, which they all "loved"
That worked out positively in both directions for us - management got frequent moments to give input (every sprint), while we didn't have them breathing in our necks all the time anymore.
-
I worked in waterfall and generally liked it. I saw some bad stuff in it and thought that it could be improved.
So when agile/scrum showed up I was quite enthusiastic.It sounded great, seemed to address problems I had with waterfall and promised so much more. In practice it was also good, in the beginning.
But then I started noticing bad things. From low level every day stuff, to general process handling and attitudes that were promoted. Fighting against those things proved to be impossible, because solutions would be 'not agile' or 'breaking the process' or people genuinly liked the bad stuff.
And so I grew to hate agile and steer away from it as much as possible. It kills forward thinking and real planning, establishes low quality as the norm and encourages bad attitutes.
-
@Mason_Wheeler said in We are all agile, and there is no waterfall anymore:
Since then I've been at a variety of places with a wide range of agile practices, and I've seen a pretty strong inverse correlation between "agile-ness" and quality, both of the software developed and of the workplace in general.
Depends on what you mean by "agile-ness". Buzzwords and silver bullet management frameworks certainly don't work. But to my surprise, I recently found out that doing Scrum correctly is actually fun and productive. I like short (!) daily stand-ups, being shielded from management by the product owner and, most importantly, actually adapting the processes to the team (which is what agile is all about).
I guess it really is true that agile got a bad reputation from those who bastardized it into a strict management framework and/or misunderstood it to mean that you shouldn't design architectures and write specifications at all.
-
@PleegWat said in We are all agile, and there is no waterfall anymore:
That worked out positively in both directions for us - management got frequent moments to give input (every sprint), while we didn't have them breathing in our necks all the time anymore.
Our PM (for a majority of the time, than she left and we went through a lot of them) was really good. She wasn't super technical so she never got involved in the day to day stuff. She would ask for updates on high-priority tickets, advice us on what the customers were talking about and give us any feedback from the customers that she had heard. It worked really well for our team and our customer satisfaction was the highest we had when she was there.
-
@Dragoon said in We are all agile, and there is no waterfall anymore:
management had more meetings, which they all "loved"
One of the good things about our development process is that managers are strictly kept out of all the team-internal meetings. Which I think is what Scrum actually recommends. They're present in the monthly planning meetings of the larger organizations and you regularly have short 1:1 meetings with your manager, but team meetings are taboo.
Fighting against those things proved to be impossible, because solutions would be 'not agile' or 'breaking the process' or people genuinly liked the bad stuff.
Once you hear the words "not agile enough" or "breaking the process", purchase a clue bat, print the first bullet point from the agile manifesto on it and apply it vigorously.
-
@boomzilla @Kamil-Podlesak I used to think that Waterfall was mostly a strawman, but my experience from Japan though has led me to think otherwise. There's the notion here of "outsourced IT" (which I guess is in some of the Korean market), where a large organization's IT function is often outsourced to massive service organizations, that are usually a joint venture between the user company (like the bank) and the consulting company (like the IBM). This yields multi-thousand page specification/contracts that describes all of the planned work that massive (1,000+) engineering groups will perform over 2-3 years, at a fixed cost of billions.
@Mason_Wheeler I think you described the real spirit of agile business:
Developers had a clear idea of what we were supposed to be doing, because we had PMs who wrote up specs before we ever started working on a project, and if it was insufficient for our needs, we had the right to send it back to them and say we needed a better spec
As you identified, this requires trust all around, which is difficult to build-up culturally inside of an organization. You need to trust management (otherwise you waste time CYA-ing all the time), the PMs need to trust engineers (that you'll ask questions if it's unclear), etc.
I've seen a pretty strong inverse correlation between "agile-ness" and quality
On the topic of software, the agile mindset opens up the door to the quality conversation, and lets the quality decision shift to the buyer (where it belongs). Not all software needs to be engineered like a safety critical system, and a lot of times it's totally fine to ship software that barely functions. It's more a business model / business decision thing, with input and advice from engineering. Without the agile mindset, I don't know if it's possible.
@dfdub "I guess it really is true that agile got a bad reputation from those who bastardized it into a strict management framework and/or misunderstood it to mean that you shouldn't design architectures and write specifications at all."
Ah yes.... this is why I say agile is a business mindset we've shifted to, and finding the right management framework at any given organization takes practice and experimentation. Everyone remembers the failures, and forgets about it the success once "it's working".
For example, following Scrum™ would never work at Inedo, because of the relationships between end-users, buyers, management, and products engineers. As a development tools maker, we're a very rare business where our products engineers can actually experience the value of our tools; can't really do that when you're building, say, accounting systems.
-
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
Ah yes.... this is why I say agile is a business mindset we've shifted to, and finding the right management framework at any given organization takes practice and experimentation.
I would even say that agile development models are almost entirely orthogonal to finding the right management framework for your company. The only thing Scrum replaces and forbids is daily micro-management of your employees at the team level, which is widely recognized to be harmful anyway. How you build those teams, manage your teams, manage priorities communicated to those teams and manage every single employee is still up to you.
The "business mindset" is important, though. Management needs to understand that micro-management is out of the question and encourage as well as actually take into account feedback from the teams for any kind of agile development model to work.
-
@dfdub said in We are all agile, and there is no waterfall anymore:
@Dragoon said in We are all agile, and there is no waterfall anymore:
management had more meetings, which they all "loved"
One of the good things about our development process is that managers are strictly kept out of all the team-internal meetings. Which I think is what Scrum actually recommends. They're present in the monthly planning meetings of the larger organizations and you regularly have short 1:1 meetings with your manager, but team meetings are taboo.
Fighting against those things proved to be impossible, because solutions would be 'not agile' or 'breaking the process' or people genuinly liked the bad stuff.
Once you hear the words "not agile enough" or "breaking the process", purchase a clue bat, print the first bullet point from the agile manifesto on it and apply it vigorously.
Everywhere I've worked, agile had pretty much meant more micro management, heavier focus on The Process than Getting Shit Done, and general misery because of excessive stress for everyone.
My current gig is government, so dumbfuckery is expected, but here they are actively forcing bastard-SCRUM down everyone's throats, mandating that managers are in on all meetings and in general being retards about everything. My team work mostly like Kanban, because management keep shoving new shut into every sprint, and then we have hours long meetings to figure out why we never manage to complete all the tasks we said we would.I used to have a girlfriend who found it fun to design new processes and did it as her job, and she always said that the process should be designed by the people that did the actual work, because they know both the how and what. In IT, we have a bunch of high priests that design The Process and ordain it to the unwashed masses, and the people that is Getting Shit Done gets to waste massive amounts of time genuflecting The Process instead of Getting Shit Done.
And I fucking hate it.
-
@Carnage said in We are all agile, and there is no waterfall anymore:
I used to have a girlfriend who found it fun to design new processes and did it as her job, and she always said that the process should be designed by the people that did the actual work, because they know both the how and what. In IT, we have a bunch of high priests that design The Process and ordain it to the unwashed masses, and the people that is Getting Shit Done gets to waste massive amounts of time genuflecting The Process instead of Getting Shit Done.
I'm one of the fortunate ones. Our processes are those that are designed by the team ourselves, and are there to support Getting Shit Done Without Fucking Up. Even better, the management I'm working for is generally happy provided Shit Gets Done, and we've ended up with really good reputations within the (multi-institution) project as a result. I guess it helps that we're good enough at reading the runes in the wind to be able to have the complex parts of what others need usually before they ask for it.
-
@Carnage
It doesn't have to be a clue bat, but I would seriously consider printing out a giant version of the agile manifesto, circling “Individuals and interactions over processes and tools.” and pointing to it whenever management demands that a stupid, supposedly agile process should be followed.Also, TIL my current employer is a unicorn. I guess I should stay here for a while.
-
@dfdub said in We are all agile, and there is no waterfall anymore:
It doesn't have to be a clue bat, but I would seriously consider printing out a giant version of the agile manifesto, circling “Individuals and interactions over processes and tools.” and pointing to it whenever management demands that a stupid, supposedly agile process should be followed.
If you've got a giant version of the agile manifesto, you can roll it up and use it as a makeshift clue bat.
-
@dfdub said in We are all agile, and there is no waterfall anymore:
@Carnage
It doesn't have to be a clue bat, but I would seriously consider printing out a giant version of the agile manifesto, circling “Individuals and interactions over processes and tools.” and pointing to it whenever management demands that a stupid, supposedly agile process should be followed.Also, TIL my current employer is a unicorn. I guess I should stay here for a while.
You should check up on SAFe. It misses the point of agile even more than scrum.
-
@Carnage said in We are all agile, and there is no waterfall anymore:
You should check up on SAFe.
Yeah, no. The horrible acronym and the gif above provide a sufficient description.
-
Extreme waterfall and extreme agile are two ends of a spectrum, and like the extreme ends of any spectrum are WTFs in almost all circumstances.
Extreme waterfall - planning everything up front and then doing exactly what you said originally, even if requirements change or you didn't think of something or user expectations never made it to the spec - will, even if done well, result in a large, expensive and slow release, which probably won't do what people actually want. With no feedback cycle before release, the software will be full of usability WTFs, at the very least. And without the feedback cycle it can easily end up in a multi-million pound black hole where nothing ever gets delivered, and can run to release time before anyone notices.
Extreme agile - not planning anything up front, but trying to do everything in the scope of single sprints - makes it impossible to write any kind of coherent structure or framework with a visibility of more than one sprint. Even if done well, you'll end up with a lot of small, disconnected features and components which don't fit into a coherent whole, which will probably be a deployment nightmare. It opens the door to painting yourself into a corner, so a feature that could have been easy if you'd thought about it in the design, becomes really hard.
And for some reason - despite 'people before process' literally being the first thing about 'agile' - businesses seem to get really tied into a particular process that they call 'agile', even if it's not actually helping development effectiveness.
-
@bobjanova said in We are all agile, and there is no waterfall anymore:
Extreme waterfall - planning everything up front
Waterfall: Even the bugs are planned up front!
-
@Carnage said in We are all agile, and there is no waterfall anymore:
the process should be designed by the people that did the actual work, because they know both the how and what
"designed" is a very high bar; in my experience most individual contributors want to be told what the process is because it limits their responsibility to successful execution of the process. Otherwise they are responsible for output, which is a much higher bar.
But "improved", yes. Still it requires a lot of training though. I try to demonstrate the ability to improve early on by training on highly inefficient process
-
@bobjanova said in We are all agile, and there is no waterfall anymore:
Even if done well, you'll end up with a lot of small, disconnected features and components which don't fit into a coherent whole, which will probably be a deployment nightmare
One of my favorite anti patterns, the micro-service based monolith! I need a better name....
-
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
@bobjanova said in We are all agile, and there is no waterfall anymore:
Even if done well, you'll end up with a lot of small, disconnected features and components which don't fit into a coherent whole, which will probably be a deployment nightmare
One of my favorite anti patterns, the micro-service based monolith! I need a better name....
That's not exactly what was being discussed, but if you're looking for alternative names then "distributed monolith" or "micro-monolith" seem to be proposed in the past.
-
@dfdub said in We are all agile, and there is no waterfall anymore:
@Carnage
It doesn't have to be a clue bat, but I would seriously consider printing out a giant version of the agile manifesto, circling “Individuals and interactions over processes and tools.” and pointing to it whenever management demands that a stupid, supposedly agile process should be followed.Also, TIL my current employer is a unicorn. I guess I should stay here for a while.
There is "fixed" version: https://www.halfarsedagilemanifesto.org
Also, there are more employers like that. There is a world outside Dilbert.
I my experience, however, real working teams require good, competent and motivated people. If you don't have people with sufficient analytical skills at key positions (coding skill is not enough!), or if they just don't care, or both... there is no help.
-
@apapadimoulis
Microsoft Office 365
-
@apapadimoulis said in We are all agile, and there is no waterfall anymore: the micro-service based monolith! I need a better name....
Continuing the geology analogy theme - conglomerate. A bunch of unrelated clasts (often of different types and not aligned in the same way), held together by an amorphous matrix.
-
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
One of my favorite anti patterns, the micro-service based monolith! I need a better name....
The ravioli code mountain!
-
@bobjanova said in We are all agile, and there is no waterfall anymore:
@apapadimoulis said in We are all agile, and there is no waterfall anymore: the micro-service based monolith! I need a better name....
Continuing the geology analogy theme - conglomerate. A bunch of unrelated clasts (often of different types and not aligned in the same way), held together by an amorphous matrix.
Gravel pile. Pieces of the pile are always shifting and you never know when adding some more will cause a catastrophe.
-
@apapadimoulis said in We are all agile, and there is no waterfall anymore:
@bobjanova said in We are all agile, and there is no waterfall anymore:
Even if done well, you'll end up with a lot of small, disconnected features and components which don't fit into a coherent whole, which will probably be a deployment nightmare
One of my favorite anti patterns, the micro-service based monolith! I need a better name....
The modulith:
The Modulith
Much has been written about all the myriad ways to go wrong when writing software. Poor management; scope creep; too little structure, not modular enough, and it’s a “big ball of mud…
