How Agile failed software developers and why SCRUM is a bad idea
ฝัง
- เผยแพร่เมื่อ 16 พ.ค. 2024
- 20 years ago Agile has transformed the world of software development, but today's Agile practices and tools fail to catch up and they work against software developers. In this video I talk about how and why it happens.
Scrum and Jira are just 2 examples of tools that focus on the process instead of outcome, they're optimized for project managers and scrum masters, not for software developers. In comparison with the progress that we made on the technology side with web applications, continuous deployment or SRE practices, management in software development can't catch up and focuses on the wrong things.
📝 My other related content:
* why estimatig using time sucks - • Agile estimation - why...
* how t-shirt shizes make estimation suck less - • T-shirt Size Estimatio...
* moving to async stand-up - www.notonlycode.org/ive-moved...
🎥 timeline:
0:00 Intro
0:24 From waterfall to Agile
1:47 Why Scrum is anti-productive
4:44 Why Jira is not Agile
5:50 Why Agile has failed developers
8:04 How software developers can work around Agile
10:26 Summary
📝 Credits
Videos used in this episode come from pexels.com and were provided by fauxels, Kindel Media, Artem Podrez, Mikhail Nilov and Ketut Subiyanto
Images come from atlassian.com (Jira logo), scrum.org (scrum.org logo), scaledagile.com (beautiful and totally Agile SAFe chart), scrumalliance.com (certificates)
If you enjoy this kind of content, check out my website, 🌏 notonlycode.org, where I publish more in-depth articles about software development.
As always, if you have any questions, suggestions or feedback, you can contact me:
✉️ email: gregory@notonlycode.org
🐦 Twitter: @GregoryWitek
Shielding your team from corporate BS is crucial to productivity.
How ?
@@maxron6514 how? A manager that doesn’t know how to do this shouldn’t be a manager? Find ways to make sure your team is productive and not switching directions every two seconds and getting nowhere, or focusing on something very niche and a more general failure. Find ways to avoid doing things and fail to enforce things that hurt team morale. If you’re directly told to do something, you can do it and still communicate with your team your disproval of it and inform them if the decision is made versus a battle is still ongoing. There’s so much to shield
Big companies understand that, they don't use scrum, but they do have ownership which means many good things and all the bad too.
They are fluid to whatever gets the job done, it IS a team effort after all.
How do you shield a team of engineers from bs like scrum@@EbonySeraphim when it is already established and like, the norm then.
Nothing wrong with having a product owner who pushes back against sales drones who want a color display on your toaster. You don't need SCRUM for that. And SCRUM is no guarantee your team actually is shielded from corporate BS, only when the PO and SM do their jobs.
In my experience, I think the problem with Agile in many companies is that, outside of maybe some high tech places like silicon valley, in most organizations software developers are treated as a sort of red headed step child of the company. We are a necessary evil for them to ship the product that the true stars of the show, the sales team, promise to customers. We are the absolute bottom of the totem pole in most corporate environments, ranked somewhere just above the homeless guy who lives in the woods outside of the building and just below the cleaning staff. In such an environment, software developers will never be allowed to self organize and make decisions like the intelligent engineers that they are. Instead, Agile is implemented from the top down and used as a way to micromanage the dumb lazy code monkeys who can't be trusted to pick their nose unsupervised. The best part is that management can just go out and buy Jira and they are off to the Agile races, because it turns out that Agile is actually 100% about tools and processes and 0% about people and interactions.
I see a twofold issue. Unless the actual product being sold is software, developers are seen as a cost center, you're in that same category as customer assistance where it's something ancillary to the product that is expected to exist for the customer but doesn't provide real value. The other problem is that businesses like processes and there's an infatuation with taking all work, no matter how complex, and distilling it down to a series of steps on a checklist that anyone can perform with no training. To an extent this brings efficiencies and eventual automation to the workplace, but when that same mentality is applied to agile, you transform from a set of loose rituals, guidelines, and mindsets to a rigid workflow that is about making an inflexible "efficient" process.
Companies don't like non deterministic workflows where everything is decided by knowledge, experience, and compromise, opposed to measurable distinct steps and results. And it's understandable as they need methods to evaluate employees, but that just doesn't work well with software.
Funny part is AGILE was developed by and for developers. In my view it started out the opposite. AGILE was done to “protect” the devs from the evil waterfall PM
TBF AGILE is the opposite of micromanaging as the ownership of the user stories is handled to the devs. And in a committed sprint the PM can’t go in and fiddle. So it’s interesting that you feel that about micromanaging.
For me AGILE sucks in too to bottom the worst people. The pampered devs that want to do stuff “their” way and is protected by the user stories. The PM who feel they want to regain control through endless meetings. And scrum masters and agile coaches that usually don’t have a clue, is not needed and don’t want to feel left out it so at every chance try to change to “improve” the process. (Which again ironically not is what AGILE really is about)
But most interesting is that it seems that both “sides” devs and product owners feel AGILE takes away their ownership.
I still just need to remind that AGILE was pushed and owned from Start by devs and not management. In the contrary it’s only the last 10y or so upper management have embraced it as they started to read how cool and how much better everything is with it. (Without any rel data to back that up apart from the praising of… guess who. The AGILE evangelists themselves…)
Also for most managers JIRA is to technical so they don’t even know how to use it so they order devs to set it up for them in the totally wrong way.
It’s so ironic
@ianajax currently experience this at my job. I don't think any of the PMs really understand how to use it and generate dashboards
That is not just software developers, any developer is treated like that. To paraphrase the wire, "Do you think the guy that the invented MacNuggets is rich? No, he is just a nobody that no one cared about."
Making introverts tell each other what they're doing every morning on a long term project when sometimes days go by with very little being achieved is effing painful. Just a way for management to micromanage the sh.t out of everything
That really depends on the team and the manager. The fact is, that meeting only needs to take 15 seconds. The basis is for everyone to have an opportunity to keep each other abreast of any *important* information, and for people to exchange ideas they may have had that might affect something someone else is working on, and an opportunity to highlight any issues people can see coming down the pipeline.
It's only painful when you're doing it wrong.
@@fredmercury1314 Every time I see some criticism of agile I see exactly what you say "you're just doing it wrong".
Most places are doing agile wrong but it's impossible to change because management has been told that agile will solve all their problems if they just follow some rigid principles. It's useless to say "you're doing it wrong" because management doesn't have a clue about how it's supposed to work and just love the micromanagement of standups and the rigid timescales of planning and sprints.
“Still working on X…just like yesterday”
@@buxton5165I know. But in the right company, with the right team, Agile works and works extremely well.
I'll never understand how people can equate "agile" and "rigid". You literally can't have one with the other... lol
I'm not even an introvert. That's not relevant. Me having to be on a call every morning to tell everybody what I was working on yesterday and what I'm going to work on today *is a complete waste of time.* They don't care what I'm working on right now and I don't care what they are working on right now. If I need to talk to someone, I can walk over there or pick up the phone any time. Agile is BS, always has been, always will be, and everyone who says "you're doing it wrong" should just DIAF.
Here's how you run a software project: use an issue tracking system, and have meetings once a week or once every other week to talk about whatever the team members want to talk about with the entire team, and to discuss if priorities need to be adjusted. There, done. And now put that useless Scrum Master to work on some actual coding.
Very common for strict, top-down management to impose "agile" processes to make sure they have maximum control. The word "agile" has barely any meaning in corporations now.
Working as a software engineer was better back in the 80's and 90's before agile scrum. I graduated college in 1982 with a degree in electrical engineering and worked as a software engineer since 1987. I started working exclusively as a contractor in 1990. Since I mostly work in real time embedded, safety critical software, I hadn't heard of agile scrum until 2016. I worked at a job that does agile scrum in 2021 to 2022 and it was like being a character in a dystopian sci fi movie, with all their cult like behaviors. Most of my career I worked autonomously and was treated like an adult. With agile scrum and the pointless daily morning meetings, employees are treated like six year olds. I just started working what will probably be my last contract job before I retire for good, with a former employer in the commercial avionics industry. The reason I went back there, and not some other companies is because they are not doing agile scrum. It is good to be able to work autonomously and be treated like an adult.
But the whole point of scrum is : Employees are intelligent and can work for themselves. I am sorry but seems like scrum was being implemented in a bad way with your company.
@@sunay72 Scrum doesn’t work well with real time embedded software. There is no user interface for people who are easily amused by shiny flashy bells and whistles on an inertial navigation system for a commercial jet for example. For an indivisible product like this, an MVP is a complete product. Tell me how you would break down the design and implementation of a kalman filter into a bunch of infantile two week sprints.
@@sunay72scrum doesn’t work for shitty business widgets either
u must have god tier coding ability after 35+ years experience. I've been coding for 1 year and everything is too simple to get a deep understanding.
@@sunay72 the point of system does not have to agree with design idea. That is where ideas that turn out to be bad after 5s go into real world. It sounds good on paper but it creates so much misery that all you can say is:"You haven't tried it the right way".
I recently got a new scrum master. They moved our daily stand up to right before lunch, and also made them less mandatory, and only require people to attend on Monday and Friday, for a plan of the week and weekly recap. Our team productivity and quality increased, and it also increased our team moral since we were getting ahead of schedule
👏🏻😊😊
Not a dev but I am an engineer. I worked at a company where we were doing the intent of agile and I never even realized it until the next employer brought in a bunch of consultants and we all got trained in agile.
The former was a breeze, we were extremely productive and things ran incredibly smoothly... The latter was a disaster... You had to have a scrum in the morning, you had to have a retrospective, you had to play that condescending planning poker. It took a six month project and made it take three years.
You know what the defining featuee of the good one was.... One key phrase that was uttered frequently by the scrum master and product owner... "is anyone getting anything out of this or are we just wasting our time"
@@KandrallaNo, you were doing Agile then you started doing Scrum.
They're not the same thing. Scrum is for management, Agile is for customers and developers.
so skipping 15 minutes of a call per day less improved productivity? sorry, I don't buy it.
The way that i learned SCRUM is that it is not the job of the scrum master to organise the meeting, or to determine the when and where, only to make sure it happens.
Jira was not created to manage teams for product development it was designed initially as a support ticket tracking system. These are two things that are done very differently. When I first started using it years ago I could tell that it had been morphed and mangled into something that could be used to manage projects and it did it very very badly and it still does. This is why it's one of the worst tools to manage projects still.
Sadly, we moved to Jira from Asana after a merger.
Hate it!
Yeah, the "agile" process features were initially a plugin which was later aquired by Atlassian.
Depends on what you were using before. If you were MS Project, Jira feels a lot better.
@@MK-lh3xd actually I disagree, Microsoft project was a lot easier to manage projects. The only real problem was it was hard to be multi-user and it was expensive. But jira has always sucked as a project management tool
Snake oil salesmen is what “Agile” coaches are. It’s just amazing how they have lasted this long, and largely succeeding. Not success is terms of their processes improving developer output, but success in raking in the dough without breaking a sweat.
@@Rcls01 What's the difference? Developers need to code. The people you describe sound basically the same except the second is delusional to the point of believing the snake oil really works. They see themselves as a martyr that nobody appreciates. Whatever shielding they think they're doing is likely leading to critical information not making it to the developers because it's incorrectly relayed or blocked altogether. When done incorrectly things can go from good to bad, and then bad to worse.
they tell management what they want to hear and give them what they want. that's why they make so much money selling bs.
@@mikeryan2388 Actually, no. Coding is waste and should be eliminated. The less code and the cleaner design THE BETTER. But SCRUM 'oh-so-agile' requires metronomic pace, like slave-rowers on galleries, therefore some junk must be commited because "this is value!"
Same for "LEAN" coaches. Real LEAN coaches make sure the CEO is actually on board with it, and test this by publicly humiliating him, blaming him for all the dysfunction in an organisation. If he takes it on the chin, they will work for him. If not, goodbye.
But most "LEAN" coaches butter up to the CEO and blame the workers instead of those who are actually responsible.
@@elcapitan6126 A competent manager who understands cost accounting principles and sound engineering practices will see through the BS.
I tried implementing Scrum for a project a decade ago. About a month in, the feedback was “it’s way too rigid!” People were really unhappy. So I sat down with the team to listen to which parts worked, and which parts didn’t. We kept only the parts that the team didn’t mind, and it resulted in a rapid, focused, and ultimately complete bring-up of a new project, using only a small team. Our tailored-to-the-team “Scrum lite” really helped us stay focused and allowed us to quickly react to new insights along the way. Now I work in a much larger team, on well-established decades-old software, and Scrum would make zero sense here, I think.
I love that approach & is the fundamental principle of Scrum that I rarely see adopted.
Scrum is a set of guides not rules. Use the parts that make sense for the team & environment.
Plan your work & work your plan 🔁; usually in small iterations.
Which parts did you keep, which did you skip?
That's why you have retros, to adapt scrum to suit your team.
The height of productivity and developer happiness was in the 90s and early 2000s with true agile, working simply from a backlog of roughly prioritised items and being almost completely autonomous in a lot of web agencies at the time, with simple tools and frameworks, just enough to get it done. Now everything has been bloated beyond comprehension. What used to take a dev a week now takes a month or more and multiples of engineers.
EXACTLY THIS.
Agile was killed by the management. This is not Agile.
As we get old, new stuff will always be annoying. It doesn't matter the decade, people from the 80s probably hate the 2000s
Scrum really needs to do an introspective on itself. But I am afraid that the inevitable result would be that Scrum isn't doing Scrum right and if Scrum would just do Scrum right then all its problems would be solved and productivity would jump up by 10x.
There is no right way to get bitten by a rattlesnake. It is better to just avoid rattlesnakes
"True Scrum has never been tried!"
When all the excuses for scrum's widespread hatred sound exactly like the excuses as for why snake oil didn't cure my gout, it makes me wonder about what's actually being sold and who is benefiting.
@@fabiolean It gives useless managers something to do and track.
Let's have a short 2 hour brainstorming meeting about this.
I can't descript how much I hate agile. I feel I'm like a mice running on an endless mice wheel. I'm overwhelmed with all the meetings and processes. No time to think. Agile is harsh to developers. If you want to work life balanced job get out ASAP!
Agile and scrum/SAFe/etc are different things. Agile is defined in the agile manifesto, which doesn't say a single thing about meetings or processes.
@@-Jason-L actually it does. "Individuals and interactions over processes and tools."
Want to get out too. Where I can find those organisation doing proper engineering practices so they hire me? I am overwhelmed by Agile rituals.
This is exactly my experience. The 2 week Sprint rolling into 2 week sprint rolling into to 2 week sprint is just a nightmare. Tickets tightly estimated and packed into the 2 week period with daily progress reporting(often multiple times a day), leaving you feeling rushed with no time to actually think, plan and coordinate because you are to busy implementing, implementing, implementing. Trying to meet imaginary deadlines based on imaginary estimations of complexity that are always wrong. Nobody has time to actually communicate and collaborate because everyone is equally rushed on their own tasks and don't have time to actually discuss and plan properly one with another.
If I was in college right now and majoring in computer science I would take extra math like liner algebra and electrical engineering courses to get jobs in more math intensive industries like inertial navigation systems because they tend to be more scrum proof. Agile scrum makes me glad to be nearing retirement.
Working as a software engineer was better back in the 80's and 90's before agile scrum. I graduated college in 1982 with a degree in electrical engineering and worked as a software engineer since 1987. I started working exclusively as a contractor in 1990. Since I mostly work in real time embedded, safety critical software, I hadn't heard of agile scrum until 2016. I worked at a job that does agile scrum in 2021 to 2022 and it was like being a character in a dystopian sci fi movie, with all their cult like behaviors. Most of my career I worked autonomously and was treated like an adult. With agile scrum and the pointless daily morning meetings, employees are treated like six year olds. I just started working what will probably be my last contract job before I retire for good, with a former employer in the commercial avionics industry. The reason I went back there, and not some other companies is because they are not doing agile scrum. It is good to be able to work autonomously and be treated like an adult.
I’ve used agile for years and understand what it is. But to me it has come to mean being asked every morning by someone who does not understand anything about programming, if I have finished the task yet.
That sounds like a manager or product owner is at the daily. They should not be there. The daily scrum is only there for the team to identify bottlenecks and help eachother. If there is nothing special, the meeting can be over in one minute.
@boldvankaalen3896 This fact should be the primary element of the daily stand-up.
This absolutely this
Nobody implements it properly, c'mon. Who cares if we turned a daily sanity check into an opportunity to micromanage and nag? 😂
With email, chat, and video conferencing available on every workstation, there's really no need for morning meetings other than to socialize. I always liked drinking coffee and cracking jokes to start the day. My favorite one was "That's going to take a few days, would you like me to explain how I'm going to accomplish it?" It's a joke because they usually laugh and say no, since I'm more than happy to tell them the excruciating technical details. I'm a facilitator, I like teaching people about things so they can maintain them when I move on to another project or employer. 😂
Does the Agile team agree to their commitments each Sprint? If so the TEAM agrees on the work and attempts to get it done in the arms of the Sprint. To hard for you?
Agile turns software engineering into a cycle of desperate scrambles plus your attempts at recovering from the same. When I went into software it was somewhere in between research and production-line work. If you were good at it, you could have "good days" while pacing yourself through the ebb and flow of the creative process, adding up to high productivity overall. No more. The work has lost most of its dignity and you find ways to survive it. Nowadays I mostly watch my investments waiting for the right time to retire.
meh it's "easy" to cruise by now since it is so process and rules heavy. as long as you don't forget it's all a bit pointless you can just enjoy the ride and even tinker with more fun stuff while working.
Scrum does that. Scrum is not agile.
@@dgmstuartIt's amazing how many times I seem to have to tell people that. Agile is not "agile", which is the word co-opted by middle managers so they can sound cool.
The Agile crowd think that they are self managing and will produce gold if they can ignore business constraints like governance requirements and risk controls. Far too many Devs are Prima Donna artists masquerading as engineers who believe they should never have to provide evidence of defensible decisions or show alignment with strategy.
Way to many development projects turn into burning money pits that never delivers reliable tools (yes software is just a tool) for people to perform productive tasks.
Without process there is no quality nor governance and without those the risk of catastrophic failure ending up in court is greatly increased. That what process is ultimately for, stopping the practitioner from destroying their customers and organisation.
@@SurmaSampoUntrue. Agile is *built* on business constraints, and working with the client to produce what they need, not what they want, without the need for a BS spouting middleman who makes bad promises that can never/should never be fulfilled.
Plenty of Prima Donna devs in the world who don't use Agile... I know because I've worked with them.
What I hate most is the fact that 1-3 devs have to do all the work while scrum masters/PO/PM/analists/governance analysts/etc just get away with planning meetings that don't really go anywhere all week and get to send 'sorry not going to make this dsu i have another meeting'
yep and they go home on time and are promoted through management. skilled devs are treated as factory / IT support workers
@@elcapitan6126don’t pull in the Producers and Product Owners into the mess they hate AGILE more than anything. Funny part is that AGILE was done by developers for developers.
Key thing is for big waterfall bank projects it was probably good. Where they made plans 3 years into the future for almost only data handling software. With no UI or real user interaction etc.
Then the AGILE moment spread and was embraced by devs at it actually empowered them.
Problem is that over the years the devs that did the least, liked to discuss architecture and solutions the most instead of coding is the one who used it. As it protected them from the “evil” PM who wanted them to work. Creating an even bigger wedge (I mean in some scrum then don’t see the PM as part of the team - pushing it away from them)
Then this spread to other sectors. People taking 3 days courses to be scrum masters, AGILE PM, Agile coaches etc etc. again people who mostly like to talk and discuss and feel important.
This is for me the real problem with AGILE. Not AGILE itself that has pretty ok standings
But let’s be fair one can summarize AGILE like this
Talk to each other on the team. Break down things. Prototype. Don’t commit to things to far ahead in time. Talk to the end user. Try to be cross discipline. Talk to each other about progress. How you solved things. Shout if you have a problem. Share knowledge. Test asap in real world scenarios the work if possible.
Or even shorter. Communicate cross and up and down. Test and iterate.
And well… this is what normal funcional teams have been done since the 70s… it’s just did not have any name as those teams was focusing on doing and delivering stuff instead of having meta coffee talks all the time.
I ain’t bitter no
Those meeting have a very important function: planning the next meeting!
You would hope developers doing one project at a time are the main focus of a meeting. PM ls can be managing 5-10 different projects.
If you think that the only work those roles does is planning meetings then you can’t have worked a lot in development. Or have not cared to know the roles more. Also calling the programming / code engineeeing part “all the work” also is very off
Well said!! You struck a chord with me here. In my experience, it is a nasty micro-managing tool which pressures teams into a tedious slog. It removes any enjoyment from the job. If I say this , then there is always someone telling me that I wasn't "doing it right". Whatever...
There is no right way to get bitten by a rattlesnake. It is better to just avoid rattlesnakes.
Exactly right ❤
I do agile in my company.
- There is exactly 1 team meeting every 2 weeks - the sprint meeting.
- I casually stand up once or twice a day and ask "Is everyone doing okay? Does anyone need anything?"
- When something is difficult, we get into pairs.
- No pull requests, no dev ops beyond having "master" for client-builds and "dev" for production. Everyone pushes and pulls in the branch they're working on several times a day, and solves the minutia daily by talking to others involved.
- 2 to 4 times a year (depending on the person), I talk to every team member in a 1:1 to see how they're doing.
- There is exactly 1 person from our company in client meetings - me.
Productivity is good. We are fast. The clients are happy and keep hiring us. This is what agile is supposed to be, not some retard who cannot code calling you 3 times a day to ask for feedback.
I teach software development at a university and I use Scrum to coach the first student projects. I find it a good learning tool for students who haven't worked together on a project before. It's better than having them reinvent the proverbial wheel.
On the other hand. I see it as a phase you go through. The faster you can move away from it, the better. I cannot see myself working at any organization that still uses Scrum in a professional context. And I absolutely hate the concept of professional Scrum masters (who can't even do the actual work) with a passion. For at least 80% of workplaces it's a bullshit job scam, plain and simple.
100% this: Scrum is as good a starting point as any, but the goal is to iterate away from it towards something which works for your team.
Scrum is a good approach for defining bite-sized tasks that unskilled developers can be assigned, but this is not suitable for a professional environment.
Good organizations allow each team to choose their agile practice. Scrum, Kanban, Scrumban etc. When the choice is made by management that's where things can come unglued as practices don't match team maturity and ability to self manage. As a scrum Master it was always my goal to make myself unnecessary. My ability to accomplish that depended upon the corporation's approach to agile. In one organization I was only able to manage one team due to practices imposed on me and my team, which was silly, in others I could help 3 teams before my day was full.
@@JeanPierreWhite How teams choose what to work on isn't the problem, Agile is. Teams can't work efficiently when there isn't a formal specification for the entire program. Agile ensures that development will be inefficient, will cost more than budgeted, and will either face schedule delays or have features eliminated in efforts to deliver something on schedule.
The use of Agile is almost a guarantee that a project will fail. Over the years, I've witnessed poor software project management destroy entire divisions of large corporations.
At its core, Agile is a failure to plan (at least beyond the very near future). There is an old adage that goes, "Failure to plan is planning to fail." It is impossible to measure progress and success when all requirements are not known.
@@gaiustacitus4242 What you are describing with a full and complete formal specification is akin to waterfall approach. This approach has had many of the failings you listed in your reply, especially on large complex projects. For shorter projects of 6 months or less waterfall may make sense and even be preferable when it *is* possible to know all the requirements with a reasonable degree of certainty. Once a project continues beyond 6 months or is part of an ongoing open ended product development over many years then waterfall is almost sure to fail, agile was created for such long and complex projects where requirements cannot reasonably be expected to be known. Even if the requirements are well known today, if the project is over many years those requirements will most likely change anyway requiring a flexible development methodology, not a rigid one.
A good portfolio manager worth his/her salt will be able to determine at project initiation if waterfall or agile is appropriate. I would agree that using waterfall for all projects or agile for all projects is a mistake, there is a decision that needs to be made upfront. It doesn't have to be either or.
Agile philosophy (i.e the manifesto) is critically important. Agile process is an anathema to 'agile philosophy' - quite literally, it is the first (and most important) point 'Individuals and interactions over processes and tools'. I'm sad that 'agile' has been co-opted into what many experience today.
Hear hear.
Exactly
Fantastic. Great to hear that there are devs out there noticing the problems. It feels like everyone is just doing scrum and not questioning it. Lets keep up the push.
Where I can find those organisation doing proper engineering practices so they hire me? I am overwhelmed by Agile rituals.
@@rmworkemail6507 Scrum is a systemic problem, very hard to find a company that will actually adapt to each teams needs.
A few things to think about
1. What is "proper engineering practices", every team/company is different and this changes over time, so the goal is to find a team that aligns with what you are looking for?
2. Agile does not prescribe any rituals, I think you mean scrum rituals? Scrum != agile
But yeah, its a shit show at most companies.
Unquestioned because questioning the agile idolatry is a career limiting move in most companies.
@@Srulio first, scrum != agile most companies that do scrum are not agile (some are). Second, if your company is limiting your career because you are questioning your own ways of work, then leave. Companies like that need code monkeys, not engineers.
If you don't question you have given up.
Omg, I really hate those processes. I changed some processes in my team and later we were obligated to go back to do daily meetings. As a manager I decided to use those daily meetings to talk about flags issues and conflicts from the previous day. Sharing those issues with the entire team. It was 100% more productive than talking about our tasks for that day.
What you mention is the worst part for me - I find some process that works for the team, works for me, works for product owner, but the agile coach says that everyone has to follow exactly the same setup, so now we're all stuck in a meeting that we find useless. Glad you found some productive way to use this time, though!
you should be flagging issues, impediments, conflicts. Just do it right and don't blame it on a framework perhaps, which actually you are doing.
Forcing processes on teams and not allowing to change is the definition of NOT agile.
@@NotOnlyCode Ironically the Agile Manifesto says to be open to change and adapt. However, the agile evangelists are the most rigid and unwilling to adapt people I've met in the industry. Almost to a cult practice.
Stand-ups are about blockers... Not about tasks for the day.
The really hilarious part about agile is most companies employ it, but still put a line in the sand on the due date
Exactly - it’s just a veiled way to capture aggressive due dates while appearing flexible.
Without a due date most development projects never deliver and nobody can plan around the delivery.
Sometimes the due date is all important. Think Y2K.
One project I was involved with it became obvious that the ability to deliver the product by year end with all the features was not going to happen. We gave the business leaders two choices. Allow us to take longer or remove features to hit the date. They chose to remove features, we delivered on time. It was considered a success by all.
@JeanPierreWhite that's not how it ever works though. Instead you're told to deliver it a day early with more features that weren't planned because the customer asked.
@@whistler9 It worked that way at a place I worked at that I gave an example. Maybe your experiences have all been at companies that don't respect their workers as they should. If you are given ultimatums you are working at the wrong place.
I'm 42 now, so I've seen several of these paradigms come and go over the years. In my humble opinion the fundamental problem of software development comes from demand being far greater than the supply of competent programmers. As a result, management are always looking for ways to scale the teams up using less capable people, which seldom works and can actually make things much worse. A single, competent programmer with design authority can often be more productive than ten average programmers being micromanaged. I used to part own a successful business with separate development teams - the team with just two highly competent individuals produced far more value far more quickly than the team with 20+ individuals who followed "Agile" practices.
This!
100% - 2 or 3 good focussed engineers can run rings around teams 20x the size made up of average people. Average people generate low leverage code and end up stuck in a mire of their own making.
I try not to even hire average people. If I have to work with them then I'll assign them unimportant stuff that won't have disastrous consequences if they screw it up.
Seen this, experienced this, and consultants have even outright explained to me that this is their job (providing a way for companies to make a project work with less capable engineers because finding enough talent is more difficulty/expensive). Do you think that we lack proper mentorship in the industry, or is this just a fundamental difference between people?
@@LordOfElm That's a very good question. I think it boils down to the differences between people, but this is not necessarily due to personality but rather experience. I have found that software engineers (engineers in general) are much more diligent when they are personally responsible (or have been previously) for dealing with the fallout of their programming. People who have experienced the customer being distressed, or at least being demanding, are far more likely to do a better job as they are used to experiencing the consequences of not doing a sufficiently good job.
I once brought up in a planning meeting that by the time we've spoke about it, I could have built and released the component. I was then shouted at "YOU MUST FOLLOW THE SCRUM MASTER" and I removed the swear words. It's become a cult, as a developer I think it actually slows down development.
Research "cargo cult".
I was in similar situation... I quit that job.. I suggest you do the same...
Exactly. If you had just given me the project and the requirements, I could have already had it done by the time we were done discussing when we should do it.
In 2000 the company I worked for hired Kent Beck to coach us in XP. That included paired programming, daily standups, user stories and test-first programming. Some people loved it (almost like a religion) and my career in SD definitely benefited from it. But, this methodology was quickly perverted into Agile and all it’s variants. Suddenly we had PMs and analysts acting as coaches who had no business doing so. Clients also didn’t like paying for double the number of programmers for only 1/2 the output and who can blame them. As the early 2000s progressed we often joked that Agile was just a label that meant: we have no real process or discipline, because we’re so agile!
Pair programming pays off in spades for debugging and coming up with good design early, and it's the best way to spread knowledge across the team, but management just sees 2 people at 1 computer and thinks we're pulling the wool over their eyes.
That's the skill all managers should have: the ability to adapt or pivot their processes according to THEIR TEAM's current needs, and not just copy and paste a "methodology" that is supposed to work for every company/team. An open-minded and experienced manager worths much more than an average Joe with a dozen Agile/Scrum certificates.
Agile is not a Methodology just fyi. Agile isn't defined by a set of ceremonies or specific development techniques. Rather, agile is a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement. And yes you should adapt to your teams needs.
@@jenniferhunter7629 agile is a set of values and principles put forth in the agile manifesto.
Agreed. How the team self organizes is a team decision, not senior management. Finding companies willing to ceed that level of control.......
I suggested once that individuals should have a say so in which team and which products they worked on. That was WAY too radical. Managers don't like to ceed that control, but they need to to make agile successful. Therein lies the problem for many organizations.
Yes agile is a whole industry. The agile training industry is a joke. Why do you need 16 hours to tell me how to write a user story or use a sticky note... Is all bs to make $$$ I spent at least 4 hours a day in bs meetings
there's so much money to be made exploiting management naivety. managers wouldn't buy it if it was brutally honest (e.g. if we said "estimates are bs")
So funny to hear this now! I used to work as a PM some time ago at small level enterprises and it was pretty easy job for me (at least, at that level, cuz it's basically all about listen and talk). When I decided to move to other city and find a better paid job there, I came across with that obstacle, that people call Agile. The moment I started reading about it, I was like "Wait, this just makes things more complicated and adds tons of new vocabulary, both things are unnecessary. I don't like it." And guess what, I couldn't find the job, I got rejected so many times, that it just put a cross on my PM career. I see this topic being raised right now, in 2022, but good to know I wasn't the only one all this time. Maybe I can finally find a normal job again?
Remember that JIRA started out as a issue tracker for bugs and support teams. Not development. I mean it took JIRA a long time until they even had support for AGILE
Scrum should be outlawed for safety critical products. It puts unnecessary time pressure on developers and testers, which could make them overlook latent bugs in the code.
I have worked as an engineer since 1982 and as a software engineer since 1987, mostly in safety critical real time embedded software in the commercial avionics and medical device industries. Agile scrum is incompatible with embedded safety critical software. In making big architectural changes, a task can take much longer than a silly two-week sprint with nothing to show for it until the task is completed to some degree. The same can be said when working on low level software that interfaces the hardware, such as when you have to spend time in the lab using an oscilloscope to verify the data coming across a shift register. Sure, it doesn’t interfere with your work when doing something trivial like changing the layout of a few buttons on a GUI, but even then, with all those pointless meetings, it is a colossal waste of time. In my first DO-178 (safety critical standard) job, by not being rushed and micromanaged, I was able to discover latent bugs in an avionics product that was written in assembly language that other engineers had overlooked. It was usually a comparison statement using a variable using indirect addressing versus direct addressing. That is similar to misusing a variable that is defined as a pointer to an int as an int or vice versa. The data that was in that location just happened to be a value that coincidentally would work, but it was subject to change to something that might not work in the future. Getting things done FAST should NEVER be the primary goal in safety critical software. And I am not anti-process. Safety critical standards like DO-178B in aerospace and IEC 62304 in the medical device industry define the SDLC, but the things they deinfe make sense, like requiring 100 percent path coverage in testing flight code, because you don’t want to be flying near an airport and find out the altitude reading froze up because the code is stuck in a while loop. All the things I see being done name of agile scrum make no sense.
Unfortunately, even some aerospace companies are starting to do this agile scrum nonsense. It has the look of - All the cool kids do agile scrum, so the cool kid wannabes emulate the cool kids to try to be cool themselves. Fortunately, after starting a new contract job that will likely be my last job before I retire, they aren’t doing agile scrum. I actually sent a resume to them because I figured they weren’t doing that nonsense and didn’t send a resume to some other companies advertising for SW engineers because they said they were agile.
Things that make me glad to be nearing retirement: Agile scrum and open office seating arrangements. Working remote at least mitigates open office seating arrangements. Fortunately, working in what will likely be my last contract job before I retire, working on a safety critical product in commercial avionics, they are not doing agile scrum.
Please, speak up more👍 we need this
Yes! I understand moving away from waterfall development, but I think having spiral development provides those intermediate milestones without abandoning the fleshing out of requirements and coding to requirements instead some user story a coder wrote based on a five minute read of those same requirements. I'm also 30+ years of safety-critical software development.
Agile without the Scrum is what you want. Scrum is clutter.
Agreed - Agile(tm) priests deemphasize the most important part of the manifesto, which itself only touches on what is truly critical - deep comprehension of the problem space. Agile(tm) treats every project like it’s just adding web pages - rethinks simply don’t fit.
Some elements are good, such as avoiding the trap of spending months writing all the design documents up front and leaving all the development to the end.
The issue is, management see agile as "daily stand ups" and "two-weekly sprints" only.
When we were trained in Agile, we were repeatably told not to let the process get in the way. Use what makes sense. We had meetings once a week, and the daily stuff was just typing what you were working on in a sentence or two in a teams chat. Agile absolutely did transform our efficiency in our case.
I wish lol. The bad companies insist on at least 1 pointless meeting per day. And God forbid you're contributing to more than one team, you're gonna have multiple standups plus whatever dumbass reviews and planning meetings fall on that day. I dunno how some people tolerate it for years and years but I guess you get accustomed to the inefficiency
There is agile, and there is Agile(tm), and they bear almost no resemblance. Being agile is like having the Golden Rule. Agile(tm) is a giant religion complete with priests, holy writ, incantations, sins, penance, and Inquisitions. They would declare your agility to be heresy in the same breath they declared it to be their very goal, and they would absolutely drive you out. I have witnessed senior developers be treated like 4 year olds who shit on the carpet because they said a task was harder than a “5” rating but easier than an “8”, and that wasn’t allowed. This from a billion $ company who spent millions on indoctrination and brags about it to this day. Count yourself lucky.
Agile can work, IF: the team is accountable to each other and communicates well, the Scrum Master keeps management out of the process, Management "Buys" into the methodology, The backlog is "properly" converted into good stories, and that the work is not broken down into hours instead of "story points". Since that is a pretty tall order, it usually fails. I been on teams where it works, and where it doesn't.
Let me share an amusing tale from my days at a renowned company in 2014, right in the prime of the scrum master era. Our scrum master, much like his peers, was a staunch advocate of conducting scrums while standing - aptly named standups. One day, I chose to remain seated during a standup, sparking his disapproval. Curious, I questioned the rationale behind this practice. He proudly cited numerous studies claiming that standing boosts focus and productivity. I couldn’t help but retort, “And what do you suppose developers do all day?” This moment highlighted the glaring disconnect between these so-called experts and the real movers and shakers who drive progress.
Maybe they would be more productive if they did their work standing up. If you haven't tried and measured it, you don't know.
Scrum is a product. Period. Of intents of profit. They need to keep certifying Scrum Masters, sellings books, selling courses and consultancy services.
TLDR: The value of SCRUM depends on the team and management.
I think it really depends on the environment. When the team is fairly large with a lot of junior developers, the per-team standup can help a lot. There are too many times where a junior developer had been stuck for two days and didn't tell anyone. Even worse if they were redeveloping something that already existed in the framework or they didn't like the implementation of.
Our PM's were generally not invited or optional. Each person is limited to no more than two minutes. It can pull a dev out of the flow, but the value out weighed the ~15 minute remote call.
The review can be another useful item. It depends on the environment, but there are times when management doesn't verify that what was delivered met their expectations. It's not uncommon to have course corrections after a sprint review. It generally boiled down to management not having time to verify at the delivery, but had time later to say the signed off spec is not what they wanted. Or if there was a misunderstanding (which we devs never, ever have ;) )
On the down side, sometimes the review took too long since a system may need to be setup in a certain configuration to show all of the functionality. However, it was much easier to do so when it is still fresh in the dev's mind rather than months later.
As you have mentioned, it can be a long process to change how management does things, if at all. Especially if venture capitalists have purchased the company and removed a good portion of the staff to make the company valuation look good. (Hint: That's a good time to find a new job.)
I think the worst part was the planning. The meeting can bring in too many resources for too much time. It worked best for small teams which have a smaller feature set to deliver per sprint.
I've never seen a SCRUM Master as the only thing a person did. The role was generally handled by the team lead or a senior QA member to simply keep the process on the rails.
In summary, IMHO, it depends
That’s my experience too. It really depends on the team dynamics and the concrete implementation of the meetings. For my employer scrum was a solid step forward in terms of productivity overall.
Yep. I have to agree. We pick what works for us and leave things out where we see no benefits. Daily meetings range from 10-15 minute "everybody is on track, nothing big came up" to 40 minute "ok this is important we need to collect Infos and assign tasks".
IMO The same concept applies for project management/workflows as for tools. Choose the right one for the project, don't try to force the project into the tool. Same here, choose the workflow for the project/team, not the other way around.
Bluntly, for the most time scrum works best, when the team is most successful in ignoring it. It's just yet another process.
No, it's a fail by design
Compared to Waterfall, Agile looked GREAT! But you're absolutely right: In the era of CI/CD, the effort necessary to conform to Agile processes takes time away from development and testing. Communication and documentation should be done via your development management system. And if you have a separate problem reporting/ticketing system, they should be integrated, instead of having to key work requests into two separate systems.
Good! My B. Sc Thesis was about Scrum and Agile - thought it would be a good idea back in 2012. After 7+ years in Software Development, witnising the Jira Madness every day my view has changed a lot. Agile and Scrum were ment to empower the Developer - and don't give the management another tool to play arround and meassure ppl's speed and productivitiy. Scrum has become an abomination. And yes - Jira IS a bloated dystopian Nightmare. The workflows i've seen.. give me nightmares to this day. My workplace is using the same methods. Switched from Development to a more support role. Its not perfect either, but i can sleep a bit better.
I feel so frustrated with Agile in our company, the scrum takes 45min EVERY DAY (with 35min only for the manager to rumble the same things over and over), and we are a small team of 4 people. When we add the sprint planning, the sprint review, the sprint retrospective, the backlog, we are literally burning 93hours per month for nothing... Without this we could almost hire a new developer, but yeah agile is for efficiency...
Jesus christ, that sounds horrible. Our daily is 10 - 15 minutes and my bosses are fine with me asking them to move their long speeches to the end of the meeting so we can go do actual work.
@@sealsharp Your bosses should not even attend the daily meeting.
@@mk1roxxor that is true.
I've been there. Best ever was a 23 person morning scrum (in a very small office). Went straight to lunch afterwards.
Correction: 93 hours per month PER PERSON. Keep that in mind
The problem with SCRUM is that it looks like a way to convince the managerial staff that they have oversight and control over development. What actually happens in practice is managerial staff are adept at managing, so they turn the process round so it becomes a way to convince developers they are doinng agile while actually doing all the corporate bullshit.
Thanks for sharing! Personally I really hate dealing with various processes when I was asked to deliver outcome in a tight schedule
Right?! Once I spent the whole day on planning session because people were arguing for 30min about estimation of every user story, and that was in a start-up that was rushing to launch a new product
it's almost like programmers know more than managers when it comes to the best way to build software. Crazy!
It is the concept of being promoted into incompetency. People who does their job well get promoted into roles with different job descriptions that they are not suited for.
That is because they do. The hardest move to make is from programmer to manager. Its almost like you have to unlearn one skillset and learn a new one. A person who is good at both, and can keep up with new technology, that person is gold. If you can make that transition you will be very valuable wherever you work.
@@Hannodb1961 Yup. The two skill sets, programmer and manager, are almost like oil and water. Difficult to achieve, difficult to maintain, very rare thus extremely valuable.
Thinking about my experience with scrum meetings is that the meetings where we look throusgh the board i personally zone out quite a lot since there are too many people doing too different things that are not relevant usually to me, as in entierly different systems. The best recuring meetings are between those you actually work with where you bring up what's going on and think of a plan for the day based on that.
I do think that the jira scrum whatever meetings have their value in gettibg the team updated on what's going on. For some people it might work vetter than others.
I'm no big scrum fan, but what you mentioned is not part of scrum.
I’m a digital marketing specialist. I’ve had three bosses in different companies trying to implement SCRUM… for marketing 🤦🏻♀️
Thankfully, all three practices fizzled out.
I couldn't agree more. I can't get any work done in agile methodology. Just way too many meetings.
I completely agree with you and your assessment of agile. Unfortunately, I have seen and experienced the degradation of productivity due Agile and its dogma. I often tell my colleagues what an airplane would look like if the Agile process was followed. It would have a fuselage and wings but no engines. When asked why the engines are missing, the engineers would say it was not in the story.
I am at the end of my career. I did software and firmware für nearly 35 years. Each 5 years our management wanted to add an new process or methodoligy. Not knowing what the problem really is. I like your video. The developer who do the job becoming less and less. The reporter become more and more. It's true!
We are living in a time in the software industry that historians will eventually refer to as the “Agile Scrum Inquisition.” Seriously, I see things going on that make me think of the Spanish Inquisition with the way this nonsense is forced on everyone these days.
I said this same thing, and… was driven out, after writing code that made several people (not me) very very well off. I refuse to work under it, and if that means starving, fuck it - the stress of it killed my best friend and nearly killed me.
What a relief to see this. I thought I was the only one who thought this way. The University I worked for adopted Agile and it has resulted in bloating of administration staff and redundancy in those on the front line ( Academic, Technical staff and department embedded front office staff). I can't imagine why they thought it would work in a University. It seems it is something designed for improving productivity of a single product ie piece of software or widget from a factory. It was never going to work in an organization that has diverse out comes ie multple subject papers and research projects. The first I heard of Agile was when a telecom company adopted it maybe around 2002 when it had a 50% market share ( though this had been dropping ). Redundancies soon followed and 10 years later their market share was 32%. Hardly a success story for Agile.
Thank you for this video. 10 years ago, I actually quit a job because they were moving more and more towards agile based development. It was slowing my development down and substantially reducing the quality of the code I produced because I was so distracted by all the BS. I hated it.
I agree with every word you say. The troubling thing about this is that there are many smaller companies who are adopting these more formal and bureaucratic working practices. I know, I've worked in them. You have to wonder what their motives are.
I don't even need to see this video, I fully agree 100%
I feel so validated lol. This completely matches up with my (limited) experience of how scrum/agile-oriented companies are in practice 👏
In my opinion, agile is very bad, agile is just meetings, estimates (always wrong), rush, lack of quality, excuses for not documenting correctly, frustration, few people actually working and many managing nothing. Scrum master is basically useless. During the rush to make deliveries, many things are left for later, we don't have time to look for the best and most optimized way to implement things. Everything is forgotten and the software is of poor quality. But it's nice to see, the manager likes to see deliveries made on time, they like to see the dashboard with completed tickets, even if the software is not of good quality.
What you're describing (except less documentation) has nothing to do with Agile. If you were agile, the dev team would be enabled to always be working on the most important stuff and not be "done" until the user/stakeholder is satisfied, then use that to prime the feedback loop. Sounds like you were in a corporate culture who read about "agile" online and decided to adopt processes to make them think they were agile (which is ironic, as a fundamental agile manifesto item is "people over processes"). Maybe they hired consultants whose job it was to bill more hours to "implement" it. Let me guess-- was this a place who referred to developers as "resources" and when deciding to do something, considered budgets before team prioritization? Dollars don't write code! Agile can't fix crappy corporate culture, bad prioritization, or uninspired cost-minimized dev teams.
Sounds like your doing no agile at all. The main issue (also the problem of your experience) is that many companies try to use agile but don't do it at all at the end. For example: Lack of quality and missing documentation can be solved through clear acceptance criteria. If you have noch documentation, you can't move the ticket to done. If the result of the specific ticket does not met the defined quality standards, you can't move the ticket to done. Quite simple. Consistently incorrect estimates also indicate a completely flawed estimation process. And if the Scrum Master seems useless, then he is definitely not a Scrum Master. In my experience, many people are pushed into this role, some of whom don't even know what the role is supposed to be.In general, it sounds more like you don't actually use agile processes and, above all, plan far too few resources right from the start, which means that there is strong pressure right from the start.
The issue is Agile supporters suggest “oh no you should have docs”, “proper estimation” etc. But the fact is Agile is incomplete without all members being experts or atleast majority. So where to we head to? A messy lasagne. And to add to it pressure to deliver in every Sprint (15 days say) “something”. So in this case std. such as quality of code, documentation, architectural planning etc goes for a toss
@@fishsauce7497 Not only team members - but also stakeholders should clearly specify (in their language, which might not be technical, which is fine) what they require from the team. Without knowing what you want to get, you will most likely receive a piece of useless garbage.
@@piotrpilinko639 incomplete requirements as we know is law of nature
In one company, the first thing a new project team did was to get themselves exempt from having to do Scrums.
Yeah, you said it well: careers depend on it. We have so many people higher up, that actually decide whether the knowledgeable developer can or can not do something (e.g. use a certain os or app in the company). It's such a bogus bloated system, but we're not gonna easily get rid of these roles because the people in these roles will do everything they can to protect the for-them-convenient status quo.
You have described the company I'm at to a T. It used to be worse but we're moving (slowly) in a better direction. The main thing slowing us down is we've had is too many people that think the current process and tools are the only way to go. But the team that bought the company a couple years ago has a solution for that - adapt or leave. It hurts to see some talented people leave, but if they're no longer a match it's better for everybody (I've left a couple companies on those terms and yes, it was better). Our biggest problem now is how to deal with a mountain of legacy code that was squeezed out in two week chunks over a course of several years without anyone ever going back and doing any cleanup/refactoring. Because you know, a new feature always trumps technical debt :) They're off to a good start but I won't see it completed. I'm calling it quits come spring, a bit sad to retire, but not much.
Bravo! Well said, for the most part, but as you point out, Jira and Scrum are not the agile that the manifesto promoted. Your closing comments about your role as a facilitator of ofthers' effectiveness (not productivity, or efficiency) has always been my favourite way of demonstrating "real agility" and I hope to work with one or two more team leaders with the tose practices before my final retirement.
What do you recommend as an alternative to traditional agile ceremonies (standups/sprint planning/backlog grooming/retro/etc)?
I don't have a strict process that I recommend, but rather a mindset - pick whatever your team needs and change it over time. To be more specific, a few examples:
Standups - I generally consider standups a waste of time (as a meeting). I usually recommend async updates (write your update on Slack in the morning when you start work). It means you have 5 fewer meetings every week, and that everything is documented, so you can go back to it later (I wrote about it here: www.notonlycode.org/ive-moved-to-async-stand-ups-and-didnt-look-back/). However, I've seen teams that enjoy stand ups and want to keep them, in which case I wouldn't tell them to stop doing that, but that's like 10-20% of cases.
Planning - I usually do it on weekly basis together with grooming. A weekly 2h meeting where we spend 90min on grooming and remaining 30min on planning. But I don't use sprints. Every week we just add a bunch of tasks to "ready to start" column in our tracking software, and product manager updates priority. Next week we just "top up" the list. There's no "sprint backlog vs product backlog" or Sprint Goal.
Retro - I recommend to do retro on a regular basis, but not too often. For example,Scrum teams usually have 2-week sprints. For me a retro every 2 weeks is too often, it doesn't work well (I wrote about it here: www.notonlycode.org/effective-retrospective/). In my teams I usually did weekly planning and monthly retro, and it worked quite ok. Also I try not to make retro weird, I really don't like the Agile approach to add ice breakers and change format every once a while (I explain more in the article I linked).
So these ceremonies are still there in a sense, but they don't follow any Scrum rules. We don't have sprints, we don't have Scrum Master, we don't have Sprint Goal, we don't have Sprint Review etc. We just follow short "prepare-execute-review" cycles, without much overhead.
@@NotOnlyCode But isn't what you describe here actually being Agile? What i have been taught: "agile is a mindset not a methodology". So how have Agile failed? Isn't it people that have failed Agile? Being agile to me means choose the tools to help you deliver better software with higher quality. If daily standup does not help, skip it. Isn't that what agile is all about? Inspect and Adapt.
@@Fedotenko2 Exactly! Agile or rather Scrum(since we are talking about the ceremonies) is not the problem. Is the lack of flexibility of the management what causes agile to fail.
@@Fedotenko2 Exactly this lol...These videos are all about the clickbait. You cnt "do" agile you need to "be" agile. If daily standups dnt work for you and you have the data and research to prove it, then skip it.
I'm currently hired by an organization that introduced SAFe about 2 years ago. That organization values satisfying its processes over creating value. I can spend almost all my time in mostly pointless meetings.
SAFe is in my opinion the opposite of agile. Many times I've been told that they cannot respond to a customer request or an unanticipated situation because it hasn't been planned in the quartly PI planning, and that they cannot deviate from plan because every planned epic needs to be signed off. This means that even a request for a trivial feature takes at least 2 quarters before it can be delivered.
Personally I don't see the point of all the overhead. All I need is a prioritized backlog. And when a feature is ready to be demonstrated why wait for a (unfocused) sprint review meeting to gather feedback from stakeholders?
I got crushed in a corporate merge and now I'm agile coach watching a SAFe rollout. Every week I say to someone: agile means deliver working software in small batches without breaking the team. I'm here to support your operational goals during the SAFe rollout. If it comes down to a choice of conform Vs deliver, go ahead and deliver and I'll support.
We're actually in a place where even safe might help, because we build feature releases twice a year, and don't ask the integrators what they think before locking down the platform code.
My company somehow managed to make an even more bloated version of Scrum. Deploying a single change to production is a nightmare
That sounds like strict deployment controls, has nothing to do with scrum.
If there is anything that I absolutely hate about software development it’s Agile. I hate the artificial timelines it imposes, like feeling the need to work flat out on a delayed task by the end of sprint. I really f*king hate it. 16 years in the industry, btw.
I have to remind my team members that the purpose of Jira is not to help them do work but rather it is to send reports to management. When you think of it this way then it's a lot easier to use the tool the way the company wants you to use it although it's still useless to developers.
It’s funny(tm), since I used Jira to tie bug descriptions to committed fixes and improvements, and to explanations of them. But as you indicate, management didn’t care about that - they paid for the Big Brother bullshit like burn down charts. Sigh.
I've seen "Agile" and "Scrum" used as excuses to not be productive and get stuff done on time. All new requests, even emergency bugs, have to go on the backlog for quarterly grooming and prioritization and get some points assigned and then not get done.
I worked in one group which got a new Director who was all "agile is our savior" and did daily standups. None of us worked on projects together, we all worked matrix with other teams, so communication between us was 99% useless. :)
Agile and scrum never ask “why”. They are only “do”. the two need to be together, entwined, at every stage. Agile and scrum divorce the why, because the appearance of productivity is more important than quality and effectiveness.
So when did you make the switch and come to that realization? Because I was just watching your video about story points from only one year prior
I still use estimation (even wrote about it recently: www.notonlycode.org/velocity) and some other Agile techniques. I'm not saying everything there is bad, the initial idea and some things that came out of it are great. Unfortunately at some point something went wrong and we came back to rigid rules, just slightly different than before
For me estimating tasks is also evil in an Agile. Most important is that we are doing it twice. First time for Scrum master: it must be in story points to have nice burning report at the end of the sprint. Second time for ordinary business people which require workdays and earliest possible date for finishing a feature. Other issues with estimations: as it was said in the video Jira does not allow two people to be assigned to a task. So we have subtasks: for analyst, programmer and tester. But only main taks can be estimated and you can't just add partial estimates because Fibonacci numbers are not additive. For example: 2 + 2 + 2 = 6, but it is not Fibonacii, so we have to choose 8. Nobody wants this story points, neither IT people, neither business people. It seems it is created for pleasure of scum masters.
@@robsosnoall software estimates are bogus. there is no science behind it nor can there be. the design process is inherently unpredictable and explorative. if it was repeatable and predictable it'd be automated.
I’ve been a developer for 25 years and most of that time was using the RAD method, for which I am very grateful.
Later I worked at a company that used the waterfall process rigorously which I felt was really wasteful and never worked as planned. There was always something unexpected that occurred and meant we had to rework and rethink much of the implementation.
When I started to work in agile teams I felt I was getting things done, the team felt like a team. But there have been times when I was part of an Agile team where the scrum master didn’t know anything about scrum and we actually used rough estimates (or story point) to estimate and plan the sprint.
So there are bad and good examples of implementing Agile.
I would say that the core idea of Agile is good but the implementation has become bloated. We should go back to basics and let the developers in the teams decide what works for them and let the reporting be done by the facilitators to shield the developers from unnecessary interruptions and noise. If the team decides that stand ups are a waste of time, scrap it. That goes for any other ceremony.
Yes common sense driven development should be the norm. Think/plan - do - check - think/plan again cycle. Most fail to think along the way. Processes does not exempt you from thinking/focusing on the problem and the solution. Agile is a myth, good software always takes time to develop.
I totally agree! I often think that processes stiffle thinking, they try to standarize everything, ignoring that every team is different and works differently
One of the results of Agile/Scrum is they leave no time to think. Which results in far more wasted time in the end. (although velocity is looking real good)
That is how we did it in the eighties and nineties when developing software in the avionics industry. Apparently we were doing something similar to waterfall, but we never called it that. We just called it doing our jobs. After working on my first agile scrum project a couple of years ago I decided to only work on math intensive real time embedded software such as inertial navigation systems because it tends to be more scrum proof. Agile scrum makes me glad to be nearing retirement.
Common sense seems very underappreciated in IT - and has been so since the first "methodologies" were made up.
I like to think that my preferred "methodology" is madness. Methodical madness, to be precise. Arguably, if you take the Agile Manifesto, it really says nothing, so it isn't even wrong. Of course that has never prevented "professional" pm consultants etc to construct a dogmatic reading and a way to ritualise processes, making it about form rather than content.
Scrum, is one such construct of rites.
Now, using rites - and, less severe, routines - is not intrinsically bad, it seems a very common pattern in human behaviour. Saying "good morning" is a kind of rite. Also, rites are a good way to allow slack - as long as you do the rites right, you don't need to do anything else.
I like to compare this with some of the elements of ITIL. (Disclaimer: i am certified in ITIL v2, and have no idea of how it carries over in later versions, I don't even know what version ITIL is at.) This is how I see it:
If a Incident is a Known Problem, it means there is a rite for it. Like the help desk mantra, which I now can only recall mentally with an Indian accent: "Pleaserebootyourcomputersir." There is no objective reason to believe that it will solve whatever problem I have, but in some cases it might, so therefore this is the first rite of help desk. And it doesn't matter that I _know_ the problem is not with my computer, as everyone in the office has the same problem, indicating that the problem is the building's network. Helldesk doesn't care - rites must be followed.
We are more prone to rites and magical thinking than we like to admit. A smart pm consultant would make conscious use of that. A good one would use it to promote sane, sensible routines. A less good one will promote Scrum.
@@recmtnbiker4368 Waterfall has the problem of being implementation of complete product via the design. It is inflexible. We should do something in between. But if dev team says that running java 1.5 is probably bad in 2023 it probably is best to listen to them not try to push for another feature. We do software nowadays to whims of investors ( which is fine but along the way there is no quality because investors aren't coders, they won't know untill the bugs cause massive exhodus of users or make a data leak )
I hate making demos for sprint assessments. In embedded development, many of the features or things I’ve worked on are challenging to showcase, often reduced to a few lines in the logger. It feels like a waste of time preparing demo scenarios just to prove to the CEO or other managers that I wasn’t useless in this sprint.
Yup, this pushes to avoid refactoring which is a big issue.
Refactoring can’t have demos because the product looks the same. As it should. But now Management is gonna think nothing is being done. 🤦🏻♂️
Very good commentary and very true! I’ve heard so many executives tell me they want to be an agile organization having no idea what it means.
Up-front architectural design is very important in safety-critical systems. On air data inertial reference units, there is partitioning in time and memory space. These partitions both produce and consume data used by other partitions. The lists of producers and consumers of data are in xml files. This is done to protect the most important data producers in the system.
For example, the sensor monitors like the gyro life monitor is a "nice to have" partition that is used for preemptive maintenance to replace a part before it fails. The inertial reference partition that produces the pitch, roll, and yaw angle of an airplane produces data that is safety critical. By using this partitioning, if the sensor monitor gets stuck in a while loop, it won't prevent the inertial reference partition from producing its data.
The air data component that produces altitude and airspeed is on a separate circuit card, with a different processor and different compiler to eliminate any potential common mode failure source.
On medical devices I have worked on there are similar architectural decisions that have to be made up front. Usually there is a "front end" GUI and a "back end" embedded component. The back end is safety-critical and tested to a much higher standard and it is understood that since the front end isn't tested to the same standard, the back end validates any messages received from the front end for safety.
Up-front architectural decisions like these don't fit nicely into these infantile little sprints and daily scrum meetings.
Sometimes it seems like Scrum was invented by managers who are don't know sh*t in software development, but want to control software engineers to pay less )
I 100% agree with all of your views. Scrum might be a good idea in theory, but it just adds a lot of unnecessary overhead. And when I have to explain to a so called Scrum Master why it is important to address technical debt and that very Scrum Master replies with "How can we track that?" you know that you just don't want to deal with any of this. People over processes? Right... The part where you showed that bloated chart really made me laugh, it shows in such a simple and easy to understand fashion what's actually wrong with development in large companies.
I once worked at company where they were using Agile. It was an awkward experience and there I learned that if a team uses Agile, run, don’t join that team, let go of that job as they are babies in the world of project management who are being curious about a toy and like to play with it. They are long way from actual managing a project!
Hell yeah - agree 100%. Agile/Scrum is a godawful process and i wish companies could see this. I detest having to work in frantic two week cycles to meet some velocity ‘points’. What a stupid way to approach software development
At last, someone points out the obvious! Imagine being in a team where your task takes a day or two then you have to wait for a few days doing absolutely nothing because the other moving parts with longer tasks, are also required to be present to discuss the specs of your new task. Meanwhile you attend daily meetings and watch other people talking.
The main problem with all "Agile" as practiced is that its commercialized towards Project Management, as Scrum and SAFem and not target at software developers who see an actual benefit from it.
In this current state of the industry it is hard for find a company that understand the values of the manifesto, let alone having self-organizing product teams who are engaged and empowered to make decisions. Who want to be responsible. Developers are simply coders who wait for instructions from Management, just like with traditional project methods.
Just that the processes are different.
Yeah, problem is software is just not a job like producing nuts and bolts ( although CNC is fun too, but at a large scale it's just running the same thing over and over )
@@jakubrogacz6829 Exactly, but that is sadly how it is treated. Not as the creative and collaborative process it should be. I have seen many developers who live for their work - are very good at getting stuff done- but they always maintain that it is just a job. Creating this barrier between work and home. Not coding or learning new things outside work.
What alternative for Jira do you recommend then?
What would you recommend as project management tool
This whole thing about mandating a specific type of planning process has to be the dumbest idea ever adopted by corporations. Requirements are always changing due to budget constraints, deadlines, a bottleneck dependency, newly discovered information about a design path that presents a dealbreaking compromise... Projects need to be handled fluidly with a specific person or group of people that must call the shots for the bigger picture while the weeds of the details can be sorted out by the developers and designers in the trenches. You can't just plan on doing anything of substance given all the unknowns that can and will pop up.
Absolutely. Once I worked at a place where my whole department (300+ people) had to start and end the sprint on the same day. There was absolutely no room for any flexibility, and the only happy people were the SAFe consultants that introduced this process
@@NotOnlyCode I work on the hardware design side of our products and they try to shoehorn this process onto us. Most of us don't even bother updating our stories because of how complex our dependencies are.
Software has the advantage of releasing things even in buggy states as long as they don't break anything else. A mistake on our side is costly in terms of both time and materials, so we can't exactly "release" anything during our sprints. They essentially just use this whole thing as a product lifecycle tracker and hoping people will just micromanage themselves to have visibility on how far along we've gotten. A simple status meeting every week could accomplish this, but somehow they think the SAFe process is amazing and necessary for whatever reason.
@@NotOnlyCodeOMG SAFe is the least agile thing that has ever existed. It’s a monstrosity. So gross
@@dgmstuart "Here's tons of work that got piled on after our fake planning sessions. By the way, we are going to have you do all sort of microdocumentation to track your progress and we are going to hold regular meetings about how you aren't getting anything done as fast as we'd like."
Some 25y ago I was involved in a large software project at a bank. No agile and scrum nonsense in those days, but there was corporate bs of course. A very clever guy who was working on it too and on whom many things that actually needed getting done depended always used to say about management: keep them confused! That was excellent advice.
I get your arguments, as a SM, I've felt similar things, though it is also my experience that SMs are hired kinda like enforcers. Like with the responsibilities of PMs, but without the powers, which usually lie with the POs.
Personally I've had issues with Leads and other superiors because I've refused to implement changes which were both less efficient and the team was against it.
Also the principles of agile often get lost under the need for reporting and standardization, the need to command an control coming from the top and sometimes the SMs or POs is in my view quite common and something one should look for always.
When it comes for your opinion with dailies, although I understand that everyday might be a bit over the need, I do see the need for it to exist, depending on the project you might be able to work with more of less dependencies, and dailies help allot getting those sorted up, also specially for remote teams, the daily is the single moment were one has space to get people to know each other and smooth personal relations between the team, AKA actually have a team and not a bunch of randoms working on the same thing. I would agree that an stable team with no changes in the people in it will be much less dependent on the daily.
The need for daily meetings is also real just to keep up with those who don't really act like adults, although not common I've had them in my teams, and the only way I've got to vouch for the team with Leads is by observing the daily, which is much less intrusive than other options.
Never has the insight of "this is how our team performed this sprint" been more valuable than "this feature is now implemented".
I avoided that Scrum thing and I outlived it. What I hear here 12 minutes in is micro mgmt. Nothing is worst in every sense than micro management with micro managers... We started pair programming back then which was efficient if you have the right partner, so small teams with people who know and respect each other. There are also a lot of pros on waterfall methodologies but the two most important ones are: think it through as far as you can in the beginning and a good option for competitive biddings for contractors.
Well, I'm a program manager that does not employ Scrum or AGILE and I face a problem of always shooting at a moving target. Priorities change and it feels like you are always putting off fires. There is certain calm in taking a step back and planning the work for the upcoming week or two and having the ability to commit resources to important things that would not be worked on because of "urgent" things that arise. The idea of sharing your progress on a daily basis is also good as it helps you prevent people from getting stuck and correct course. So as long as you think about the purpose of the tools and techniques presented by these methods and do not follow them blindly, I think that these are great ideas. Also, depending on your market, companies need a release cycle that can be the used by other areas in their planning and execution. True that now continuous integration and deployment are available, but they are not silver bullets either. I agree that flexibility is key, when paired with using the right tools for the right reason.
No, problem isn't in method. Problem is that it isn't used as method but as a tool to measure performances or budget the payments.
Brilliant. Another reason agile lingers is its allot easier to blame a process and address that by changing a board or introducing a step rather than dealing with the core issue which often is a people/team problem. And that is why i believe devs dont stay long... because the real issues never get resolved.
This was a refreshing talk. I have found out exactly the same as you, and try to communicate this to my organization. Now I'll share your video! Thx 🙂👍
Where I can find those organisation doing proper engineering practices so they hire me? I am overwhelmed by Agile rituals.
I usually ask the companies about their processes and usually it's quite clear whether they're very strict on it or not. If they say that they have full-time Scrum Masters, or that all the teams follow 2-week sprints, or they throw some major framework like SAFe, I know this is not for me. Basically all the companies these days will say they use Agile, but you can find companies that are very easy on that and allow the teams to decide on how they work
@@NotOnlyCode good, makes sense
If I was in college right now and majoring in computer science I would take extra math like liner algebra and electrical engineering courses to get jobs in more math intensive industries like inertial navigation systems because they tend to be more scrum proof. Agile scrum makes me glad to be nearing retirement.
Working as a software engineer was better back in the 80's and 90's before agile scrum. I graduated college in 1982 with a degree in electrical engineering and worked as a software engineer since 1987. I started working exclusively as a contractor in 1990. Since I mostly work in real time embedded, safety critical software, I hadn't heard of agile scrum until 2016. I worked at a job that does agile scrum in 2021 to 2022 and it was like being a character in a dystopian sci fi movie, with all their cult like behaviors. Most of my career I worked autonomously and was treated like an adult. With agile scrum and the pointless daily morning meetings, employees are treated like six year olds. I just started working what will probably be my last contract job before I retire for good, with a former employer in the commercial avionics industry. The reason I went back there, and not some other companies is because they are not doing agile scrum. It is good to be able to work autonomously and be treated like an adult.
The only problem with agile is that it was conceived by smart software engineers, for other smart software engineers, but is being led and implemented by idiots who grew up in a house with a swimming pool, surrounded by money, and with an economics degree their father bought in some expensive place.
A little harsh maybe, but yes, many organizations who implement agile do so very poorly without regard to the needs of the team members that actually do the work.
Do you have a thought/observation for small teams that develop their own projects and software? I've leaned in towards a kind of pure Kanban approach, but have you seen something better or is that a good fit in your experience?
Every professional knows that process can't rescue the quality of your team. If your employees don't know what they are doing then you either have to train them (a the technical, not the process level) or you have to replace them with better performing employees. If they do, then process won't make much difference. At most it will annoy an otherwise good team.
@@schmetterling4477 your remark doesn't seem to have anything to do with my question...
@@ylluminate The point is that it's people, not processes that do engineering.
@@schmetterling4477 conversely you can have the best engineers - best people - on the planet, but if there is no cohesion or bad tooling and bad organization (insufficient unity), they they are doomed to failure regardless.
@@ylluminate Yes, it's both, people and processes that mess up engineering. At most you could hope that processes keep bad players out, but they don't.
Pretty true, the moment we tried to make the projects 'Agile' our team was less agile. But Agile helps to keep our clients happy because we can record decisions and dependencies in a easy way and deflect blame when things don't go as planned.
I hate how peoble misuse Agile,
Agile will not work unless you have a good coverage of the whole requirements, and a well designed system Archeticture and guidelines from the beginning,
You should minimize important requirments discovery and technical decisions while on the go.
This exactly. Agile has become an excuse to not spend the time you should on proper requirements gathering, planning, and architecting. Agile doesn't have to result in ugly software and unnecessary stress on dev's do to large scale architectural changes halfway through the project because a crap job was done of the planning steps at the start of the project.
I am a certified Scrum Master and I ..... agree. I was an engineer and took the role because I'd seen first hand how badly it could be done. Not saying I have it figured out but things seem to be going in the right direction.
This video is strongly well done. The explanation is clear and logical…with a nice encapsulation of the history and where we now are. Excellent!
Excellent video.
The main issue is not SCRUM, but how it's often deployed in an unsuitable way for the teams in question. It's not tailored.
And .. daily scrum meetings are a huge waste of time if you calculate what it takes in a year for x team members to stand around for 15 minutes every single day
and listen to what everyone (should) already know, when you are working in team...
And sprint review: Honestly, our stakeholders have no time to check every 2 weeks how far we are in features and they don't usually underatand what all those bugs mean.
They only want to know if we are on track and if the release date is safe.
I think certifications are the root of all evil
Thanks for sharing this video. I am so happy that there is someone resonates with my view. To be frank Agile seems more like a cargo cult
I think agile is pretty good, but scrum is a shit show. I think most companies which say they are agile are not, giving agile a bad name. Companies think because they do sprints and standups they are agile, which is wrong.
@@brandonpearman9218 There is "Agile", and "agile". "Agile" is a business, cult, and religion. "agile" is just a set of values that should facilitate agility in project development. The problem is Agilists often use agile as a shield so they can always claim "you aren't doing real agile". Now if you will just hire one of our "Agile' certified coaches then they will make your company truly agile and you will finally see the 3x productivity boost.
@@jacoberinc Yeah, agreed. The problem is agile is taken over by non devs, its a scam business now.
Gregory, you're rant is totally on the mark with all your points! Especially how a good set of core ideas behind Agile has been bloated into a whole *industry* and often mutates into rigid corporate hierarchies and power structures - exactly opposite of the original intent (communicate, create, validate)!! It is exactly the same thing with CMMI, where the intent of defining how a team does their stuff made total sense but in many organizations it becomes onerous (and "just check the effing box!"). Or how obscenely bloated The UML (and SysML) became while the whole point of drawing pictures is to clarify and express aspects of something (fully specifying s/w in pictures is a fools errand... s/w can only be fully specified by.. code!) I can't say enough AMENs to your point about automating the shyte out of everything (that's what I do with our CMMI PIIDs... and many other things). If it's a recurring process it should be automated so all the humanoid brain cycles are spent doing the nonrecurring, hard engineering. As you point out, at least the growth of automated CI/CD has mainstreamed the concept, but not everyone makes the leap to it being generally applicable to any engineering. And PS, totally agree with your comments about Jira... although if you go through the pain of implementing a few simple, custom workflows and stick with that it's ok (don't get me started how Atlassian has f***ed-up Confluence tho... we're ditching it and going to XWiki). cheers!
Great Video, I can sign in on everything you say. In my experience there are additional reasons why we see "Scrum by the book" in so many projects nowadays. Due to lack of experienced team members and/or due to management trying to stay in power, Scrum can provide simple guidance of how to get over with that annoying and scary agile thing. I see many inexperienced product owners blindly following scrum rituals and communicating "See, I did everything that was asked for." to upper management. I've never seen truly experienced teams doing Scrum by the book, but always adjusting it to the point it gets unrecognizable., if using it at all. Every team is unique, so should the processes be. Again, you nailed it.
Back in 20 years, when they released software.... it fucking worked.
Scrum: Don't think of card points as units of time, think of them as units of effort!
Also Scrum: How many of these effort points can you get done in the next two weeks?
I originally bought into the Agile koolaid. The reality is that *practical* agile/scrum really boils down to waterfall\stepwise refinement with more meetings and more charts. Worse is that bug fixes almost always get downrated for priority in Agile sprints in favor of short term new "low-hanging fruit." It boils down to users saying "implement this, fix that" and developers doing it in the best priority order they can. Agile makes for pretty charts, but software still boils down to define/implement/test/release/repeat. You can package it all kinds of ways, and that makes management happy, but reality eventually settles in.
I said this precise thing earlier when explaining to someone I was interviewing why Scrum has no place in our team. Nicely articulated!
If Scrum does not fit, you must acquit.
IOW choose your own poison, if it ain't scrum it has to be something else.