Agile was the software component of a business trying to take the driver's seat. The MBAs and the lawyers were always going to outlast the dwarves that typey-typey all day.
Agile has become synonimous with releasing products that years ago would be alpha stage versions and never getting to fixing the technical debt because it would break compatibility for the existing user base. In other words, releasing shitty software that barely works way too early and passing the cost down to the users.
I love the feeling that you're on a never ending "death march" 😆. I really didn't like the usage of the word "sprint". In the real world, a sprint is "run at full speed over a short distance", but resting after such an activity is necessary. In software, there's no perceivable finish line, so you're just racing towards burnout. I want to add, too, that you can have a sprint in which you're working at 100% efficiency as an individual contributor, but you're only as effective as your PR reviewers. We had one guy we ALL prayed didn't review our PR's. He only did them on Friday afternoons after your PR's had been sitting there for days on end. So now the weekend was here and, unless you wanted to stew over all his nitpicks all Saturday and Sunday, you just had to put in the OT to get the comments out of the way so you could enjoy your time off.
Great point about individual vs/ team effectiveness. How each team member could be high performing the but the team still crawls along due to other bottlenecks.
Glad to see you warning people against abandoning agile despite it being co-opted. It’s a bummer to see so many people “throw out the baby with the bath water”.
Scrum by the book is more agile than what preceeded it (e.g waterfall and unified process), but it is also way more bureaucratic than it needs to be in terms of successful software development. However, for those of us who was in the business back in the day, we all remenber that it would've been impossible to sell the very lightweight agile practices that we have today. Most IT investment back then was entirely contingent upon a bunch of artifacts up front before a project could even start. Waterfall and UP provided all that stuff, but usually failed. Scrum provided some of the stuff, enough to satisfy some investors, and had a lower failure rate. In other words, scrum was sortof a agileish gateway into good agile.
That was my experience too. Scrum's main issue is it didn't adapt/iterate fast enough to keep up with the agile crowd that moved past the need of it's constraints.
I abstract Agile more and more to "cooperative PDCA" (plan do check act) on my side same time ignoring other buzzwords and focus to give team members the opportunity for the ownership they need or are willing to take.
I like that. It makes me think of the fighter pilot loop: Observe, Orient, Decide, Act. If only we could take-back the planning horizon from leadership's quarterly+ down to developer scale of one or two iterations / loops. I'd be happier with an approach closer to orienteering: check the compass; what's the next visible goal that gets me closer to the target; go there (while dealing with the obstacles that couldn't be seen until they're in front of you).
@DouglasDickinson too soon on "quarterly+" planning... I'm actually in a 3 day quarterly planning session as we speak. tbh it's not horrible but the batch size is way too large.
Perceptions of what software *is* are still fluid and mismatched. Do the dwarves make a 'software product'? I say not: software is literally (literally-literally) a program, i.e. a process. Designing and building a process is different from building a product. In the same way building a factory to make a product is different to running that factory to spit out the products. It's a fact of design, that the design is not 100% revealed until it is complete. A software program is not completely understood until it is finally stable (enough) and bug-free (practically). Software engineers themselves are unclear on this. Even tech-lead businesses think like primary producers & so accept mismatched incentives and KPIs.
you should write a blog post or something to flesh out this idea, it's an important distinction that people outside of software don't get at all, and people inside can't properly articulate (including myself).
@@FixingSoftware i know, me too! I didn't get to this sense until 20 years in, and mentoring a 2nd year who was proud (or not) of producing his idea of some LOC. I was shocked that 😳 was even a notion. (ed: "still")
Super interesting! This reminded me of how chemical engineers talk about scale-up problems: what works in the lab (~software plan) cannot be multiplied by 1000 to get a factory (~software "product").
I remember back in the early 90s a manager wondering why the staff took a break after we shipped, he started telling me that everyone should be immediately working on the next version, exhaustion be damned. These people truly see programming merely as a means to an end, that they'll get richer sooner if the devs keep typing constantly. It's no surprise that they twisted Agile into a hellhole. They want to turn programmers into factory workers.
I find this fascinating. Especially Kyle's take. I even wrote a post about this a couple of months ago, but emphasizing that the same thing is happening within the DevOps sphere. Thank you for a good video.
The worst of Agile is when businesses insist on using it on places it shouldn't belong. Developing an internal tool or implementing a proof of concept cannot be treated as a complete product in maintenance mode where any and all changes will be bite-size and deliverable in a week or two. There is no value added by pressuring projects to conform to an artificially "agile" schedule.
I had always thought Agile was just a shortcut to critical thinking about why pragmatic development is the way it is. I think all the things in Agile are derivable via analysis, but people may gravitate towards reading the words as canon instead of understanding the underlying justification
Thoughtful comment. Reminds me of the concept of "destructive abstraction." I've never considered Agile to fall into that category but you're making me think twice about that.
You're totally right that the word "Agile" has been hijacked, and there's no longer any point in crying about it. But that doesn't mean the problem has gone away. Sadly, "Agile" is such a great, great name. If you go to management and ask "Do you want the team to be agile?" ... well think about its antonyms for a few moments, nobody would want to be those! Which is why it was always such an easy sell to management. So in losing the brand, we've also lost an incredibly powerful word. If we need a new word, it had better be something with wholly positive connotations, and truly awful antonyms. To get the ball rolling, can I suggest: ADVANCE.
When I was learning SAFe I couldn't get passed the Dual Operating System part. Unix and Windows? AIX? Oh Value Stream and Hierarchy illegitimate offspring. To me it was a way to reassure both parties they have a role ... until the redundant Hierarchy could get AI to a position to remove the value stream :-(
I had the same reaction to "bi-modal IT" when I first heard that. Just yesterday I saw "double diamond" for the first time and lol'd. Yet another big batch, sequential planning framework.
Fortunately there are still places where real agile and not “modern agile” is being done. Modern agile is an abomination making everything just worse. Probably the reason why software quality is deteriorating.
Just a great chance to get an interaction with an author of this cool channel before it explodes ). Really liked the authenticity of the guy, so enjoyable.
I appreciate your comment because I think you're hitting on a key "us vs/ them" issue. You have a different definition of "Agile" than I do, which is the point of the video. Can you expand on your comment?
> Badgile or Sadgile > Moral compass > Human approach Yea I can feel it Us nerds can be lost in the machine sometimes, Agile helped to stay present in the real world. Now it is corrupted, we're squeezed by the real world to accomplish a mediocre job while coping by using OpenSource software by people who were able to code on their own for a long time without necessarily Agile and without being squeezed just for the Jira to progress on a Burndown chart so a middle-manager that don't understand a single word of what we're talking can have a smile on their face while we're getting closer and closer to a burnout. ahah
@@FixingSoftware If the company chooses agile style of operation, it's a bottom up approach so the devs/teams are in the lead and managers accommodate the teams. But alas it's a bottom up vs top down battleground these days in large corporations.
The problem with agile is management. Agile doesn’t mean run the SWD cycle faster so you can end the project faster. It is an issue of ethics. There are too many software that are “non-critical” however ever every construction project is critical. SW quality needs to be more critical somehow.
Honestly the only way I see to ensure quality is critical is to obfuscate the 'how' of it to the point where management can't cut it out. So we never talk about unit tests and give an option to cut them out of the process. Issues with this approach are numerous of course. And always there will be engineers willing to cut corners to make the paycheck (we all fall into that boat).
@@FixingSoftwarefaling Scrum is a hot topic right now! The real issue is IMO not Agile perse, but Scrum: on the longer run Scrum (not Agile itself, Agile is just an other word for working iteratively, versus Waterfall) leads, because of its structure and roles/responsibilities, implicitly to technical debt and architectural debt and thus low quality, as there is no ownership (teams responsibility), no person responsible for software design (like RUP did), there is no architect role taking technical desiscions given non-functional requirements. There are other Agile methods that can fix that a little bit, like XP and RUP and make every person in the group to have 1 main responsibility (so that person can take to learn ownership). Also bear in mind that the last 10 years people did not to have a CS degree to get hired (bootcamp was enough), so the average quality has dramatically decreased IMO. But now that the software world agrees about it, there is hope for change!
@@FixingSoftwarefurthermore I agree engineers should not ask to project managers/product owners if they are allowed to write unittests or refactor. And that is also the opinion from Uncle Bob/Robert Martin. Now if we can get all those points into a new religion we can save the software engineering world! 😅
I also get frustrated by big influence on youtube & twitch attacking agile&scrum but all what they saying has mostly nothing to do with both . Yes because the word has been taken over I read a dev article in my language calling it more precisely dark agile (or fake agile). I'm going currently through dev training (complicated story in IRL) anyway my couch who teach us also consult companies and start-ups and he reported 80% of them do anything but agile/scrum but call it this and this is not big tech USA. Looking deeper agile in its core just means you are flexible which shortens delay and production time , big companies have very often control structure and fixed processes which does not mix with this but they want this because they need 3-4 times the personal to do the the same. I have also a family background in construction I see there also a very similar pattern small companies to boss talks with everyone 10 to 15 minutes , stuff are ordered on demand l, boss comes every 3 to 7 days on site and foreman documents and report to boss at closing time this is very agile like. In big companies this looks very different....
I've never worked at what could be considered "big tech" but anecdotally it does sound more "agile" generally speaking. With the exception of Amazon maybe? I don't really know. But yes in my experience the larger established companies and the big consulting firms are the ones who have created their own definition of agile. Agile seems to shapeshift most in cultures that are more hierarchical - both company and human cultures.
Well if Scrum is not Agile, then Agile is also not a fair comparison to waterfall. Methodologies/Frameworks vs/ principles. But here's exactly what I mean about the meaning of words. Or are you saying that Scrum does not properly "instantiate" Agile?
@@FixingSoftware I generally describe my approach as Bespoke Agile. Through experience I aim to find the best way for a team to achieve the best possible results and everything is negotiable. There's no framework or set processes, if something isn't adding value it's gone. I dropped Scrum years ago when I started to realize so many of the ceremonies were slowing teams down and didn't fit with their culture. I've also started to see Waterfall work for some teams. Pushing Agile into teams where its not needed is a mistake.
Makes sense. I agree each situation is different and requires experienced leaders to guide. That said, I'm also a fan of patterns. I don't know that we need to re-invent the wheel over and over again. Are you familiar with pattern libraries like this? www.scrumplop.org/
Thanks for the comment. I agree about the control piece. But now having been in management for a while, I can respect the need to have some level of control and predictability over outcomes. even at a low level of precision. Every company I’ve worked for operates on schedules and budgets and commitments. I know there are companies out there where dates are less important though.
@@FixingSoftware I understand your comment, but in the end it's engineers that drive projects forward. I've done both jobs, I can't see any manager succeeding in any domain that's not fairly intimate with the job, the best managers I've worked for were former engineers. The job of a manager is to facilitate engineers, not to rule over them. How many breakfast meetings I've attended over the last 40 years that moved the project forward not one iota. I've not explained myself well, but I reckon you've caught my point.
Back to waterfall Define requirements and let AI write the code. The rub is defining requirements is not easy - I use the three C's - Comprehensive, consistent and correct.
I do think this is what's happening to programming in general. I don't think it's a 'now' thing though, will take time. But eventually the LLMs will be writing most of the code. But as someone else astutely observed, if LLMs kill junior coders, but we still need seniors, who becomes the seniors? LLMs eating themselves.
