Why Does Scrum Make Programmers HATE Coding?

[@HealthyDev]

Does scrum feel like it hurts more than helps on your project? What are you doing to rescue scrum from the grip of overreaching micromanagers and keep the product moving forward? ►► Know your options! Access my FREE data hub for the top 25 software industry roles, TechRolepedia → jaymeedwards.com/access-techrolepedia/

[@Account.for.Comment]

By not giving a crap. It is a bunch of buzzwords. Good teamwork is good teamwork, bad teamwork is bad teamwork. I can call my corporate headquater, a castle or a fortress or a citadel or a palace, it is still the same building.

[@MichaelAuerswald]

I kept complaining until we moved to a Kanban-light instead.

[@bcbc6195]

Daily just feels like an everyday confession... 🤒

[@bcbc6195]

I hate scrum

[@WarrenPostma]

@@MichaelAuerswald We do a bastardized "not kanban and not scrum" process that prioritizes: 1. honesty. 2. flexibility. 3. we don't do estimates at all. I like it. We don't have a heavy process. We just realized that certain things (guessing how long things take) are impossible.

[@andrewdale3695]

In my nearly 40 years as a software developer, I worked in pretty much every development process known to man, from total seat-of-the-pants with no rules or documentation to the most rigid waterfall possible. I never cared, I could just make it work. Scrum defeated me, I never felt so utterly disempowered. Nothing but meetings and micro planning. It got to the stage that I was standing outside the office for 15 minutes every morning getting my head together before going in. Eventually, I just retired.

[@bioshazard]

I still think Scrum has very powerful. But recently I have adopted a stance of: no one actually cares enough, scrum can't be done, don't bother, you will never find a team that cares or competent management. scrum asks too much of lazy, jaded, incompetent people to ever actually work. I have only gotten it working once and it was glorious. zero chance I will see it again.

[@leshracevil]

I feel the amount of cognitive overhead upon the developers is overwhelming. So many assumptions being thrown around by product, business and people managers in everything possibly imaginable expecting a clear answer by devs. Everything boils down to the scrum squad

[@bioshazard]

@@archi-mendel it is strange tho how often people call this oddly consistent outcome of the similarly ignorant, "scrum"

[@bioshazard]

@@archi-mendel the concepts aren't stupid, but if too many implement them the same wrong way over and over I do think it's fair to examine it's accessibility and caution recommending it given it's strange tendency for lazy cowards to micromanage developers in it's name. I think we are on the same page about it's viability but maybe disagree about it's practical accessibility

[@edwardroh89]

@@leshracevil it benefits product, business and those managers because those people can contribute jack all to the project and still order people around and act as if they have ANY idea what is going on

[@ruynobrega6918]

If the management is incompetent, the methodology will always suck, no matter which one you use.

[@jacoberinc]

But some definitely magnify the negative effect of bad management more than others. Scrum is one of those.

[@timdietel9797]

Amen. Scrum is just another tool for micro managers to abuse...

[@chordsbyriku]

@@jacoberinc that could be a good thing for programmers also. If it's magnified then it's pretty clear management is to blame for failed projects.

[@chpsilva]

@@chordsbyriku This may be obvious at squad level, not so much on upper management tier, which is fed with data provided by this same incompetent management.

[@michaelkronenberg3712]

this is true

[@boldvankaalen3896]

I had a boss that thought that agile working meant they could dump extra work on their employees at any time and employees should be "agile" enough to deal with it.

[@InconspicuousChap]

I've seen dozens of bosses like that.

[@jonniuss]

Absolutely agreed. Any clues how to deal with them?

[@InconspicuousChap]

@@jonniuss If that's your firm, fire the idiot and explain that to the others. If not, leave if you can. The organization is spoiled.

[@boldvankaalen3896]

@@jonniuss Walk out before it is too late. I made the mistake to try to work around them.

[@lancelotthefallen763]

well.. they're not exactly wrong..

[@robertbeckman2054]

I just finished 18 years of hell as a coder. Scrum was never used right. Story point always converted to time. I was given harder projects with similar points, with almost no acceptance criteria. I’ve always felt like the problem. Now I’m 48 with a family, and am starting over in another career. I’d rather die than go back into one more scrum meeting on one more team at one more company. I’m not the smartest, but I know when I’ve been screwed over . Thanks for sharing.

[@atomichx3342]

Same for me. Im in a complete career change right now. No more IT, because of scrum. They treat experts like children. And the scrum master is the elder supposed to watch the kids. This is so disfunctional.

[@gregsimoes8645]

I think I'm on the cusp of this. I've been a coder for decades, but only been dealing with agile/scrum recently. My experience is it's a framework to micromanage while pretending that's not what you're doing. The small clip at the beginning that was a preview of later with the manager saying "forget the acceptance criteria and just get to work" is all the worst aspects of what I've been doing recently, and then that's used as a cudgel against you with browbeating for bad software or overloading your work trying to do all the stuff that should have been caught in design phase with solid acceptance criteria.

[@ImLasu]

We do estimation in time, but it's normal to make it in half time, double time, or whatever multiplier, passing estimated time is only indication of: developer need help, developer cannot be interrupted or we need to communicate delay to client.

[@InconspicuousChap]

Estimations (whether in days, story points, parrots or whatever) make more management jobs, that's why they like that. "Give me a date, and if you don't fit it for whatever reason, I'll f..k you up" - that's the primary use of them. The other use is endless meetings to get the delivery date shift approved. In order to meet artificial esimates, managers start "accepting the risks", i.e. releasing buggy software in a hope that the consequences won't hit them personally but are deferred until the manager moves to some other job. The only proper estimate possible for a complicated development task is: "it would take whatever it takes to implement it properly", and that's it. But that's something that only really senior guys could afford, like David Cutler or so. Everyone else saying that would be just screwed by suits.

[@75yado]

@@atomichx3342 looks like there are no experts in SCRUM features and tasks must be dumb down and split so they can be finished in one sprint by anybody. The whole mess starts from Uncle Bob's sentence that tthe industry is in the state of permanent inexperience as in any point in time at least half of the programming population has less than 5 years of experience to the point that there is not enough seniors to teach the rest.

[@ToyKeeper]

Lately, when a job description talks about being an agile, fast-paced environment with rapidly changing requirements... that tells me they have bad management and I definitely don't want to work there. Instead, I look for places which say they need someone self-directed who can figure out what needs to be done and do it, without having to be micromanaged. At my last job, I talked to my manager like once a month, along with casual chatter with the team over IRC, and it was great for everyone involved. When upper management inflicted scrum on everyone though, everything fell apart -- people left, projects failed, and eventually they cancelled almost everything and laid off a third of the company.

[@HealthyDev]

Good call. I saw one once that says "thrives on ambiguity". Uh, no.

[@j1shin]

Why is this comment describing exactly how I observe things going as soon as Scrum is involved. It is so sad.

[@iojourny]

I need to show this comment to my company lol

[@slimjimjimslim5923]

But watch out for the "self manage necessary to provide best to market timeline.". This translate to "here's a bunch of work you cannot finish in 3 weeks but make it happen anyway, don't care how it's done, just get it done". This kind of top down waterfall is usually what cause most engineers working over 60+ hours.

[@EmilNicolaiePerhinschi]

software is R&D, and there are very few managers properly trained to manage R&D projects, they try to transform it into a proper manufacturing process where everything can and should be known from the start software is R&D: you formulate a hypothesis about what the users need, you write the code, then you test it on your users as soon as possible ;-) and get feedback

[@PabloEdvardo]

Well said... software writes the machines that run the factory, they don't sit on the factory floor themselves!

[@j2csharp]

Thank you for this perspective.

[@EmilNicolaiePerhinschi]

@@PabloEdvardo there might be a misunderstanding, on my side possibly: I meant something else. In manufacturing you already know the sizes and the qualities of the piece you want to make, your concern is to make it in the time , not necessarily as fast as possible but usually that is a concern. In software you don't know from the start what you're going to have to build. You might have a good idea or imagine you have a good idea but even when you automate a business process you might discover that what the managers think the line workers do is not exactly what the line workers really do:-) ... designing software is a work of investigation that looks more like police work than like taking orders from your boss :-). Then you have technologies that constantly change, and by "change" I mean security issues are discovered too. In software you can't design a product 100% then implement it. ... I mean, it happened a lot in the past and still happens for a team to attempt to do the design 100% at the start then implement it as designed, but most of the time that process ends in failure. Unless you're writing yet another copy of Notepad the information you have to deal with is simply overwhelming and you don't know all the stakeholders and all the corner cases and most of the time, even when writing accounting software, you don't know you're doing it wrong until you run data in parallel with the human accountants and find that you diverged at some point over a point of procedure that was not documented but the human accountants were doing because it was "how things are done". Software is R&D in the sense rocket science is R&D and astronomy is R&D: when a project starts there is a lot of information to discover, algorithms to design, tools that were never thought of before to write etc.

[@rty1955]

Haha wow. This never happens in my shop. Users are not guinea pigs. Remember w/o users there would be no programmers. Developing. Software is Sooooo simple. No need to over complicate things. Bad design WILL lead to bad software. So spend time designing and less time coding. Geesh

[@CynicalOldDwarf]

People always forget the science part of Computer Science

[@duckeydutch2088]

I have one more point i hate scrum for, the endless amounts off meetings. Stand ups, refinements, demo’s, retro’s, all kinds of in between meetings and all that on top of the normal questions you get from coleagues. … it hampers your day so terrible . Neve just 1 day uninterupted working…

[@Pongo8844]

As a doctor, I send my condolences to you and other developers. Medicine has the same problem with middle management started to "manage", "improve efficiency" at the cost of patient care. Your subtitle for the episode can be "When Managements move in."

[@WarrenPostma]

Those who can, do, and those who can't, ask those who can, how long it will take and then ask you do it in 50% of that time, with less resources.

[@goldenknowledge5914]

as a fellow doctor I share your sentiment. it seems that these 'little napoleons' are a global occurence

[@valueforvalue76]

I think this is everywhere and in everything. Real creativity, real efficiency went out the window. It's all a numbers game anymore, they don't care what it takes or if there is a better way. As long as the numbers say it's happening efficiently. Which is why the biggest part of everyone's jobs now are figuring out how to manipulate the data and keep their jobs and sanity.

[@cybernd78]

@@goldenknowledge5914 Reminds me on a talk from Simon Sinek. AFAIR: "He pointed out that we started an experiment half a century ago: We have subordinated everything to finances. He called it an experiment, because there was no evidence that this would be a sustainable way to manage our world." Most of todays struggle are the consequences of that stupid decision we made in our past.

[@MeGrimlock511]

It's a matter of responsibilities. Everyone needs a manager, even managers. I've been on both sides of the table for around 20 years .. and developers always want/need more time for analysis, development, etc... That's why they need someone to point out the business side of things, budget status, and make sure that things are delivered in time. Asides form that ... SCRUM sucks. 😂

[@natalieeuley1734]

The funny thing is, every time I had SCRUM training, I always felt like, yeah, this process is great! But then the day to day, I had so much stress and anxiety or loneliness, and I couldn't figure out why. Now I get it

[@InconspicuousChap]

It's just psychologic tricks the trainers employ to make the audience feel great. A few of my colleagues and I attended an event like that 6 years ago. The guy listed Agile principles wanted us to bring up examples confirming those. A few people came with examples from their experience of Agile principles not working. He completely ignored that and moved on to the next section, based on "as we have already seen, Agile is so universally good, now how do we implement it?" After we left for lunch, our group has never returned there, leaving him to talk about Agile to himself without us listening to that madness.

[@tr1ckster726]

I'm laughing out loud watching this. Everything you mentioned is so spot on, it's amazing how consistent it is across nearly every company. I think the biggest problem is that you have non-technical people in positions over power where they tell the developers what to do. We have always been at the bottom of the totem pole and until that paradigm shifts, we are screwed.

[@atomichx3342]

But there is one change since waterfall. AT waterfall times we could read the entire plan and then create a plan oureselfs how we technolical achieve the waterfall plan. Nowerdays they micromanage us with thousends of manage small tasks. The programer ifvtoday is a taskmaker. He has no freedome anymore. And the Deadline is always one or two weeks away (always pressure).

[@TheJimmartens]

I was putting some thought into a useful reply to this but you beat me to it. Spot on this was so well done.

[@rohitbahadur2504]

Actually so true. I have been a QA since many years and I still struggle to find the non tech talk about "why can't we code this and make it Done!" I am always like "Code for what"! Do you even understand what is happening. And then it comes down to the same old story of "Oki so can we deliver it :P"

[@errrzarrr]

Same for me. Scrummists / Agilists swear is different for everyone and once it all fails how you failed to Implement Agile the "correct way". However, everywhere I take look it's all the same. Even cultures way different than US and very far from there it's all the same downwards path when non-technical gets in charge. Same story, you just have to change characters' names and locations.

[@InconspicuousChap]

Non-technical people telling developers what to do is 99% of the industry. Many developers are comfortable enough with that because they are lazy enough to learn, to understand the subject area or make decisions. Suits use their silent acceptance as an argument for Scrum or some other shit.

[@brucerosner3547]

I've been a software engineer for over 40 years. When I started older sages advised me that "you can have it fast, or good or cheap" pick two. Perhaps I wasn't as good as the old guys because I have found you can have only one. Faddish methodologies like scrum do not change this.

[@paulcarroll6995]

Im so glad you called it a fad, honestly there are just un-necessary people involved making shit decisions based on stuff they don't understand how to do. Throws the "cheap" option straight out the window.

[@timatovstyzhenko9932]

Is your comment related to the topic? IMHO cheap and fast are not options. They are mostly good, in time and in budget. Two last are more about PjM and less about scrum . Fast and Cheap - they might be requirements at discovery and design stage

[@binishthomas2675]

"you can have it fast, or good or cheap" pick two [Fast & Cheap]........that's how Sten gun in ww2 was made.....but at a big cost of Soilders dying due to gun malfunction

[@MichaelPohoreski]

That's the Project Management Triangle. Another great one are Murphy's Computer Laws: *Meskimen's Law:* _There's never time to it right, but always time to do it over._ *Hoare's Law of Large Programs:* _Inside every large language is a small program struggling to get out._ *Pohoreski's Corollary to Hoare's Law:* _Inside every programming language is a smaller, simpler one struggling to be recognized._ *Weinberg's Law:* _If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization._

[@andrewallen9993]

@@binishthomas2675 And more soldiers lives saved by more soldiers having access to a submachine gun. The sten was so good that the Germans mass produced an exact copy.

[@lappynet]

I was a dev, and became a scrum master (and now agile coach) because of bad scrum masters and bad management. I've helped a few teams, but some organisations insist on this stuff we all know is bad and it is hard to tell your boss no. I've been fired because I'm standing up for the team, and that's a big sacrifice to make for one's colleagues.

[@DailyFrankPeter]

Does it pay off?

[@TheHeavenArt]

Same thing happen to me :/

[@StewartWild]

My story is the same.

[@Meeffoc]

Same thing here, difference is that I’ve not been fired (yet)

[@ddanielsandberg]

1. Scrum master was never supposed to be a position or a title. It was supposed to be a role that was rotated within the team each sprint of 6 weeks. 2. Most scrum implementations ignores the technical practices that are required to make it work in the first place. 3. Installing Jira, sprinkling a bunch of burnups, burndowns, story points, sprints, stand ups does not make anyone agile. 4. Stand-ups is not meant to be a reporting function, it's a sync meeting around "what is the most important things to focus on/resolve today?". 5. Story points are BS by and for people not doing the job. 6. And then programmers end up hating agile because they've been told that their dysfunctional scrum is "agile". 7. And no one read extreme programming explained or the agile manifesto, and the second page is totally unheard of. As Ron Jeffries said "I like to say that I may have invented story points, and if I did, I'm sorry now." PS. Don't mention SAFe - the devil's spawn by the old waterfall and RUP people. Pyramid scheme.

[@koh-i-noor123]

^^ This! Ron Jeffries apologized for inventing Story Points and I think it's time to move on.. Everything you wrote is spot on.

[@LajosNagy]

I've spent the last two years of my miserable existence in SAFe as an integrated infrastructure person ... devops? Cloud ops? I despise SAFe so much I am not even going to entertain an offer from a company that runs it. It is everything that is wrong with software development from an engineer's perspective. I have to run my own kanban board to understand what needs to happen because the story board only bears tangential resemblance to the work I actually do/need to do.

[@AleksandarIvanov69]

@@koh-i-noor123 Not true. If you actually take a bit of time to read Ron's article from 2019, you will understand that he doesn't have a problem with the concept of "relative unit of effort", which is of course expected. He is of course referring to the MISUSE of the concept.

[@antonybooth3293]

Scrum masters are typically Business Analysts transitioned because Waterfall went away and their role became obsolete, or worse, Project Managers who can't get it through their heads that they're not managing a project anymore, who actually impede the sprint, serving management and interrupting for status reports and unnecessary meetings, rather than holding back manager requests and other metrics hoarders in order to let the developers stay focused on development work. As for SAFe (Scaled Agile Framework with an 'e' for some unknown reason), it's Watergile; it's RUP as fake Agile to make Waterfall companies think they're now doing Agile, planning multiple sprints in a Waterfall like way, but without the Waterfall planning and estimating, so you end up with a bunch of sprints destined to fail weeks before they've even started. SAFe exists solely as a scam by companies selling SAFe training to companies with a new CIO wanting to make his mark by pretending to bring his department into the present world, full of managers who are clueless about how to work with Agile teams and how to adapt their monthly reporting spreadsheets using a system that doesn't generate metrics by having one that turns Agile information into line charts. Agile or Waterfall by themselves are much better solutions.

[@mudi2000a]

Thanks for mentioning SAFe. My company is doing it as well and I think that it is completely useless. Also other bad practices like using story points as time are used. Fortunately I am in a Devops team which runs kind of besides this process and we can run our own process ( especially no PI planning which looks like an incredible waste of time. )

[@kassios]

One thing that I found quite laughable that I heard in a sprint meeting was that being "agile" and making specs on the road means for the developer to foresee any possibility and be adaptive beforehand! I knew we are seen as magicians but that takes it to a whole different level.

[@alexdegaston422]

Like designing the parachute after you jump out of the plane and hope that the raw materials are floating around the sky? Have a safe landing.

[@markw.schumann297]

Management always has a choice: they can get the work done most effectively, or they can reinforce their own sense of control. Almost always they pick the latter. That's the motivation behind almost all of the issues you mention here.

[@alexisfrjp]

If the management doesn't want the best outcome, why would you? You know the rules, play the game following them and eventually switch job.

[@notinusesoon4975]

@@alexisfrjp be sure to give them shit before you leave, wouldn't be satisfying otherwise

[@GackFinder]

Then you need to start selling the "work done most effectively" in terms of "sense of control", because they are definitely related. Management types are driven by one of these three basic incentives: fear, greed, and laziness. A management type person that wants to reinforce their own sense of control is most likely driven by fear of failing his own responsibilites in the company. You can utilize that, by reminding the management type person in the following way: I, as a developer, is now officially informing you, with paper trail in form of this email, about issue X. Issue X can only be solved by Y, but your strategy Z is currently preventing that solution from happening. If this issue isn't solved, time estimate will exceed by A, revenue will suffer by B, and ROI target will be missed by C, all of which are on your and effectively your bosses head, i.e. it's your heads that are gonna roll if we dont do Y, whereas I'm in the clear because I've informed you of the issue and I will still be needed for the continuous maintenance due to issue X not being solved. I've done this many times, but in much more sublte ways of course.

[@mangowu3243]

Post traumatic scrum syndrome. Too many of us have been there. It took me years to agile again.

[@HealthyDev]

PTSS - I love it! 🤣

[@anikets4699]

yes! yes! yes!

[@bb5242]

I'm actually considering getting a CDL and driving trucks. Over 20 years in the business, PhD, just don't give a fuck.

[@antonybooth3293]

@@bb5242 I guess you've watched Office Space recently? ;-) p.s. My brother-in-law was a Mathematics teacher for years, quit and now drives a truck. One of the best decisions he ever made. He's a new person, from bitter and argumentative to mellow and un-opinionated.

[@KossPetroff]

Hugs, bro

[@WebDevCody]

Story points are a waste of time. Sprints are pointless, just do kanban; the work is done when it’s done. Demo daily to stake holders when features are finished; if stakeholders don’t have the time, that’s a red flag. Stand ups feel like a tool for dysfunctional teams who can’t communicate throughout the day on slack or pair program together; if I am blocked, I don’t need to wait until standup to say so. I feel like scrum was an idea pushed by consultants to make big money training companies and then leaving them confused after they got their 💰

[@huaweihonor7714]

Excellent and accurate comment

[@kingjames1308]

As an SM that is very saddened by this comment section I can't agree more. We moved to scrumban and it was embraced compared to scrum. We are now moving to pure kanban. Our planning sessions are 15 minutes and there are no story points. I think most of the hate is by people who worked in 'scrum in name only' environments and I don't begrudge them for thinking scrum sucks since their point of reference is only bad scrum

[@rogermouton2273]

Could not agree more. Exactly my thoughts - sprints just add admin overhead - what benefit do they provide. Just divide up the work into pieces that make logical sense - why do we try to arbitrarily split work into two-week blocks? Just use effing kanban, as you say.

[@maykolpurica9451]

In the "Refusal to cancel sprint" they also would try to make devs work extra hours to achieve the goal.

[@HealthyDev]

Yup. This is why at unhealthy companies that are focused on deadines I tell people to have 100% acceptance criteria. You can't afford ANY scope creep in a sprint if you're going to be essentially forced to get it done no matter the cost. In general, I advocate putting some steps in place to leave a place that toxic. My rule #1 is I do not work overtime. Programmers make stupid decisions over 6 hours per day of focused coding. It's been well documented at this point.

[@KireFireLiar]

Can you explain the 100% acceptance criteria and how that counteracts a focus on deadlines (which then squeezes people into overtime)? @@HealthyDev

[@HealthyDev]

@@KireFireLiar hey there. I wouldn't say having acceptance criteria stops the company from being focused on deadlines. They still will be. What it does do (if you write it granular enough) is makes sure what you're comitting to is well understood and reduces "scope creep" so it minimizes the chance you get forced to work overtime. You might check out Neil Killick on twitter and medium. His concept of "Story Slicing" where the level of granularity is a single acceptance test can help with this. neilkillick.medium.com/my-slicing-heuristic-concept-explained-810ee70b311e

[@unduloid]

The best way for me to start liking Scrum is to keep it far away from me, so I can admire it from a distance. _Much_ better.

[@HealthyDev]

🤣

[@_tnk_]

Love how you randomly started plying the guitar hahaha - I was starting to feel angry thinking about my experiences exactly how you described. Then the guitar tune just instantly made me feel calm. Very nice and thoughtful touch there

[@shugyosha7924]

My previous job was doing exactly that: using story points to track employees' performance. They would expect a junior developer to manage X points per sprint, or a more senior developer to accomplish Y points. They were also treating each sprint as a contract with a deadline, so if additional complexity was unearthed mid-sprint, you had no choice but to do the overtime or whatever it took get it completed by the end of the sprint. In other words it was nothing to do with agile, just a series of 2-week waterfalls. Needless to say I left that job.

[@HealthyDev]

Exactly. 2 week waterfalls are the most common scrum team out there. The rarer ones are those that actually do scrum as intended!

[@chordsbyriku]

Good that you left that job. They weren't using scrum just waterfall and overtime. If the story points does not work for the sprint there should be no overtime. The task needs to be moved to next sprint and re-estimated because there is unforeseen complexity.

[@kkjr6673]

@@HealthyDev I’m not sure it’s even waterfall. In waterfall, at least you had a plan and a well-defined target! If these were made by experienced and qualified ppl, they would not be completely off the chart, and would include time and staffing for testing, devops, user documentation and training, and the occasional oupsies.

[@bb5242]

Yup, bad. Nobody wants to hear that you discovered some problem mid-sprint. VERY STRESSFUL.

[@antonybooth3293]

Pointing stories then becomes a game where the points no longer mean complexity, but instead a proportion of what's allocated to you and you try to point the stories you intend to grab, higher than needed, leaving less velocity for other team members stories. This means developers pick up the stories they think are pointed higher than needed to give them padding or breathing room to be successful at the expense of other team members. This also destroys the team where developers fight each other over getting stuck with the stories they're likely to fail. I bet that organization gets a lot of turnover as there's always a team member struggling to make their quota, just because they got the stories others didn't want. So overall, it turns a team into a bunch of sharks working on how best to game the system than working together to achieve a common goal.

[@testuser1337]

I constantly see scrum used to squeeze performance out of the dev teams. In the good old fashion of translating story points to developer days of work. In my opinion, scrum is where creativity and innovation dies in silence. Plus scrum master positions are often filled by ppl who found out they sucked at developing and had a certain amount of power hunger at the same time.

[@chaccmi1358]

Scrum removes the engineering from software engineering and it becomes software assembly line. I feel bad for programmers who haven't built software in the pre scrum days ( not long ago), they will not experience what real software engineering is. Scrum is beneficial for corporate marketing to say they are 'agile' ie modern and cutting edge. It is also beneficial for all who don't write code, ie managers and those who write emails and schedule meetings for a living. How did we let it reach here not sure, it removed all art and creativity from software engineering. It is making programming as a corporate job a horrible painful experience. Modern assembly line workers.

[@philhagerman]

I’ve been doing this 20+ years now. I couldn’t agree more with your statement. It has removed the art and creativity aspect and turned us into assembly line workers. Back in the day I was hopeful that Uncle Bob’s Software Craftsmanship idea would take off more. Sad to see the burning on the ash heap of history….

[@LeightonCarr]

Care to elaborate on this? I have the same opinion, but I'm curious to hear more about what you think about removing the engineering.

[@funkydankspliff]

100%

[@chordsbyriku]

For me waterfall removes creativity. Then you set long term yearly goals and can never change it as I understand it. That is how every waterfall project I worked with has worked. With agile we can as a team change our mind every sprint. I can change the entire tech stack every sprint if needed. Would probably not be that good for progress though 😆

[@chordsbyriku]

But I would say that corporate marketing and the higher ups always misunderstands Scrum and agile all the time. Flexibility has benefits but sometimes it also has costs (like money costs which they try to ignore). But they seldom want to pay for the process which turns the process into some kind of weird waterfall/agile hybrid which is worse than both agile and waterfall.

[@8020drummer]

As somebody who’s worked in organizations large and small, though not in a programming role, it’s so easy to see how basic human nature starts to warp these processes. If I had to boil it all down I’d say when everyone is 100% loyal to the success of the project, it’s easy. As more layers of management come in, and people start to care as much or more about looking good to their boss, or maxing out their KPIs in their local fiefdom than the success of the project, you start to see scope creep. One very common thing I’ve observed is “looking busy”, which can manifest in not pulling the plug on a meeting or skipping some documentation, even though it would be more efficient, because you don’t want to look like you’re not working hard (because your performance is no longer tied to product success but to KPIs, etc)

[@ipeteagles]

this is veterans affairs IT contracting to a T

[@DanStrohschein]

As an engineering manager, I absolutely hate the burn down chart. We don't use them at all - they are based on estimates, also called fantasy. No matter how good your estimating accuracy is, it's never 100%, so why would you use a chart with known fault margin to make any sort of analysis on team execution? Screw that, just watch for outcomes each sprint and as long as the team is nailing the outcomes they wanted to achieve, life is good.

[@HealthyDev]

I couldn't agree more!

[@DanielLiljeberg]

I got introduced to Scrum and agile in 2007. It transformed my life as a developer. I remember saying back then "people will monetize this, create certifications and people who actually want to be the boss of others will gravitate towards Scrum Master roles when their old leadership styles goes out of fashion. It will not actually mean they have altered their perception of leadership, they just go there because the potential for control, power and money is there". Today I sadly see this in many places I come to. But for me Scrum and Agile are still about empowering the teams themselves and I take great care to listen to their needs instead of pushing my desires Sometimes even management has almost wanted me to control more but I have gently explained that my job is not to control and command people what to do... it's to see the big picture and coach teams into seeing and understanding for themselves what they need to work on improving as a team.

[@HealthyDev]

Awesome Daniel your teams are fortunate to have you. Great mindset.

[@twaniboy11]

Are you hiring? ;)

[@DanielLiljeberg]

@@twaniboy11 As a matter of fact we are. But I'm working for a swedish government agency so one has to live in Sweden, be a citizen and pass a security screening etc :)

[@AleksandarIvanov69]

The Scrum Guide clearly states the roles. People are mistaken to blame Scrum for organizational and personal errors.

[@bb5242]

I have never once been empowered in any developer job, not ever.

[@FrocketGaming]

I became a technical product owner about 8 months ago. No experience doing it whatsoever and as I learned about scrum I noticed I shouldn't be invited to these stand ups and potentially not the retrospective too but I'm expected to be on them, so I am. However, I was aware of your first point so I've worked really hard to try and encourage the developers to be as transparent as they feel they safely can be and I try hard to take all feedback as a learning opportunity and not use it against anyone. With that being said, I'm going to talk to my Scrum master next week and ask that we try some standup's without me several times a week and see how they go. I'm sure they'll be great and I'll remove myself from them entirely at some point. I also see this 'story points == time' every week and I'm sitting there thinking... this isn't what I've read, we're doing something wrong. Thanks for this video, I'll subscribe because I think this content is really going to help me grow.

[@HealthyDev]

Hey Frocket I think it's great to get with developers whenever you want (individually or in small groups) to work through answering questions about features, getting user stories and acceptance criteria ironed out for sprints etc. It's just being in the stand-up itself where having the PO there can be a problem. You being a technical PO, if you're working on the code it might be OK to be there. I'm just sharing what the scrum guide says, knowing many teams find their PO derails the meeting and doesn't let people be safe. If that's not the case in your situation, it may be helpful to keep doing what you are. Hope that make sense.

[@archi-mendel]

Hey FrocketGaming, you definitely should be a part of Retrospective and should actually be involved into it as any other memeber of the team. I find it very important for PO to be able to talk about their concerns and ideas and to be able to listen to development team concerns and ideas. And to participate in making a collaborative decision on how to improve in the next sprint. You may be invited to dailies and I would even encourage this. You shouldn't distract developers with any questions unless they are fine with this. If you would like to ask the team if you could ask questions during daily - the best timing to ask this would be during retro. Explain why you would sometimes want to ask questions and ask developers if they're okay with this. I would suggest you to tell developers that if they have any concerns about this, then you definitely don't want to ruin their dailies and would just continue participate as a listener. There is definitely no need for you to skip dailies on purpose if developers don't have any issues with you been there. But there should also be no requirement for you to participate - this should be solely your own choice and should be based on whether it provides value to yourself to participate. Btw, try not to get used to "technical product owner" title as this is actually opposite to Scrum. If you just take requests from business with priorities dictated to you - you are not Product Owner and your organisation doesn't have Scrum. There is an only Product management role in Scrum and it is Product Owner with no prefixes. Product Owner is a person who is able to decide on priorities from the bunch of various items provided by stakeholders, developers and PO themselves. If you're struggling to get this privilege to decide on priorities - share your concerns with your Scrum Master, if they are mature enough, they will be able to help you to gradually earn decent level of trust which would allow you to get into a true Product Owner position. On the story points - this actually is not a huge deal if team uses story points relative to time. As long as story points are solely used by the team to have some guidance during their sprint planning, then this is fine. As soon as story points are considered any kind of a metric or report outside the team, then this is a much bigger issue and it has nothing to do with what you consider story point to be - story points are not to be used to measure performance or to build plans. if you're still struggling to make management stop talking about story points, raise this during retro with your team. Explain your concern. Suggest to use non-numeric estimations like t-shirt sizes. And be transparent in very basic things. If you're still struggling to figure out something related to the process - share this with your development team. Ask for their support. Listen to their ideas. Try their ideas. Discuss the outcome. Ask, listen and try again. This is the best way to build trust. And PO's positions are very strong when they are backed up by their team.

[@FrocketGaming]

@@archi-mendel I think my company calls it 'Technical' because of the technical skills they want and expect for this PO position. I prioritize the backlog and decide on the priorities for one of our production support teams which requires me to know a lot more technical detail about how our systems operate than the other PO's on my team. I also prioritize the backlog and priorities for the development team I'm on as well. Not sure if you'd consider that a PO but that's what we call it. I did have a discussion with my Scrum master and she wants me involved in the ceremonies. Previously the dev team wouldn't speak up with the previous PO on the Retro so she had stopped inviting that person so the dev team felt safe enough to bring up concerns. She's not worried about that with me and thinks I've improved the overall team dynamic by being open, transparent, and willing to listen to their concerns and adjust.

[@archi-mendel]

@FrocketGaming okay, so you are practically a product owner in a product which requires advanced technical skills. That's fine, still not sure why to have "technical" as part of the role if other product owners don't have such things like "commercial product owner", "charity product owner", etc. Anyways, this is not a huge deal, while it may highlight some issues with understanding of Scrum and Scrum roles right away. "Previously the dev team wouldn't speak up with the previous PO on the Retro so she had stopped inviting that person so the dev team felt safe enough to bring up concerns." wow, this is very questionable behaviour from the SM. How would missing PO from the retro help PO understand technical concerns and help developers find time to improve in further sprint? And overall I am not sure SM has any power to decide which team members should or shouldn't be invited to Retrospective meeting. This is a meeting for the whole Scrum team, not development team only.

[@adtc]

Any update? How did it go?

[@akuskus]

Scrum is the framework for creating burnout. In all jobs, the ones that used a scrum based project management were the most depressing and soul crushing.

[@piotrd.4850]

Scrum is basically what is done to Amazon warehouses workers, just in different name.

[@BryonLape]

Yeah, agree. There is no "loving" a weapon used by management to squeeze people.

[@RU-qv3jl]

That’s because agility started out as a way to write better software and was then taken by management to browbeat developers. Sustainable pace is nowhere to be seen these days and commitment is totally misunderstood and used to beat developers into submission and guilt trip them into working overtime. I worst I’ve seen is waterfall projects run “With scrum” so that the developers are at fault for everything because management gave them everything they needed… Except all decisions were taken by management, including that the teams would be scrum teams.

[@manishindudhar]

Every point is absolutely so TRUE - only a developer will understand :) have been coding for 15 years - hated and still hates scrum, was so pissed off when I got into scrum projects from waterfall model - felt I was more productive in waterfall model than scrum where people are just in a hurry to finish their tasks. Have got into projects where had to follow some shitty way of coding and people expected to just code in the same way it’s coded before - couldn’t refactor/change or even allowed to suggest better way of doing things.. You’re just fantastic man and have made a video exactly how I felt or rather most coders do.. Keep up the fantastic videos 👍🏼

[@HealthyDev]

Thanks for your support Manish! Glad this one was useful to you.

[@acceptablecarrot173]

My major issue with agile/scrum is it has been forced into every company today, with absolutely no consideration as to whether it actually fits the company's working style. the other thing is the fact that scrum often results in 300% increases in meetings.

[@perezidente1]

This exactly, and the more meetings that occur, the less time is being spent on tasks and actually meeting any sprint goals.

[@davidclayworth2271]

Scrum is about the least meeting-heavy methodology out there. If you think scrum has lots of meetings you've never used another system.

[@acceptablecarrot173]

I have been involved as an employee in two waterfall to agile scrum change overs. In both cases my average time in meetings doubled. While scrum done perfectly may have fewer meetings, the often observed reality is you simply add a number of ritual meetings on top of all previous meetings.

[@ThatAnnoyingGuyOnTheInternet]

This exactly happened to me. Someone came up with agile scrum and everyone had to use it no matter what. The result was more meetings that didn't accomplish anything and about 10-15% less time to work.

[@peterberg3446]

My mornings are completely shot due to the meetings, so my effective work time has been reduced by about 40% by meetings alone. If I didnt WFH I dont think I would get ANYTHING done.

[@PieMongo]

After watching this I'm beyond grateful that my PO, Scrum Master and boss are former programmers, it really makes everything much easier with them knowing the actual process of everything we have to do.

[@wiebewiersema7929]

Better name for this video: "Why do programmers hate working in a poorly run team?" Working with the incompetent leaders you mentioned would be a nightmare in any software development lifecycle

[@jacoberinc]

There is a surveillance state of developers that is created by scrum that gives crappy leaders far more power and control than other methodologies. The same crappy manager in one methodology might just be a nuisance that most developers can just ignore. But put that manager over a scrum team and they make life a true nightmare. Scrum empowers and enables nightmare leadership.

[@marshalsea000]

And now you can just get a certificate to get a job as an impediment be that SM or PM, either way - "Welcome to being the Destroyer of Software Projects/Companies."

[@archi-mendel]

@@jacoberinc "There is a surveillance state of developers that is created by scrum that gives crappy leaders far more power and control than other methodologies." this is not Scrum. Anyone can fake anything. And there is no "managers over scrum teams". I am not sure why Scrum methodology should be responsible of the fact people are too lazy to learn what Scrum is and to justify if they have an actual ability to apply Scrum in their organisation.

[@JohnDoe-my5ip]

A key requirement of any worthwhile process is to provide some resilience against bad actors. Scrum inverts that principle. I don’t think you could create a process that’s more easily abused by talentless room-temp IQ hacks with PM certs and MBAs if you tried. The incentives could not be more misaligned for long-term success. They are all aligned so that management grifters can hit some KPIs this quarter and jump ship right before the chickens come home to roost. The CIA sabotage manual is less effective at killing projects and destroying the wellbeing of workers than the Scrum guide is. It is an evil system, far worse than anything Stalin could have imagined

[@NathanielNiles]

I think a better title would be, "Scrum apologist rationalizes". Scrum believers will always find an excuse for why it fails that inevitably turns the blame on the team, or the managers, or corporate culture.

[@froobly]

I go in a completely different direction from this advice. I think the two-week delivery cadence makes it hard to prioritize code quality and consistent architecture. One of the Extreme Programming principles is "emergent design," and in order to do that you need to observe patterns as they emerge, and have the freedom to address those things immediately, whenever practical. The issue is that if every two weeks you're scrambling to get a feature done, then it becomes really hard to justify taking the time to make reconciliation steps. While a team can fight to maintain code quality, the system is going to raise red flags whenever they do so. Why did we miss sprint goals? Because this was the third time we implemented this one thing, noticed that it was done slightly differently in all three implementations, decided to codify one approach and consolidate it in a single component. Will this happen again? My god I hope so. When the last two days of every sprint are a scramble to get things "demoable," it creates a perverse incentive to hack things together even when the deadline isn't anywhere close. Sure, impose personal deadlines if it helps you get started, but once you're in a state of doing productive work, you shouldn't need to beat yourself up because it's taking a little bit longer than you initially expected. The artificial deadline's job is done, progress is being made. Why throw that productive time away just because of the lie you told yourself to get into that productive mode in the first place? The other point I disagree on is the "done criteria" being a blocker. Requiring the plan to be complete before starting has the effect of shifting the design burden right up front, and again treats discovery during implementation as an exception, rather than a rule. Instead of having a bunch of time to think about the project dependencies, everyone has to brainstorm those things in a single meeting. SAFe takes this to an extreme, by making everyone come in at 8am, hear the goals at the end, and come up with a plan, complete with stories and points, by the end of 2 days. Give me time to think about it, research it, maybe collaborate over Slack, and lets come up with a real plan based on reality, not an Iron Chef plan that falls apart the moment you try to execute because everyone was too sleepy to understand the consequences.

[@MichaelStephenson12]

We implement SAFe and I can totally relate to what you mentioned. We offset this by regularly looking at stories and estimating them during the sprints and the actual "SAFe" event for us is just us selecting which ones we would like to tackle in the upcoming iterations. This allows us to think properly about stories and bugs, ensuring that we actually know what we are committing to.

[@retroand]

In my last job as a programmer they used some "SCRUM" to get more control on us, the programmers. The responsible even bought a TV to display to every single other employer how much we had worked. They also installed control software which made screen captures at random intervals. Never before (or after) I've been in a place with such level of toxicity and mistrust.

[@xx-wp3mq]

What sector was that in?

[@retroand]

@@xx-wp3mq I was full stack web programmer, but we would not only make or depure websites, but also interface them to Sage inventory/acounting software.

[@roialnet]

I wont work in that kind of environment..so insulting.

[@retroand]

@@roialnet I suggest you not to. There was also a three-sided internal war inside that company where the egos of the three managers were feed by the company's director. Also note there were only two programmers... too many of them changing task every 15-20 minutes. Stress was so high that I had episodes of lack of equilibrium and depersonalization. About two years have passed and I still have sequels. Unfortunately that was my only option in that particular moment so I did not hesitate at the moment and the fact of having survived there for a year opened me some doors later - most people cannot endure that much in there. Unfortunately, as doors were opened ghosts also followed. At the end of the day this has nothing to do with agile methodologies. It's about that pseudofeudal relationship between employers and employees. Authorities won't protect us programmers for a reason: money. After a career I haven't been able to get more than the minimum interprofessional wage and this situation is common in my country. They also prefer to outsource programmers from South America remotely instead of paying decent wages here... They made me change my schedule by six hours to synchronize with the Colombian contractors they employed. Note that no compensation was offered for such a breach of the contract. After all we were described by the director as "cattle which should be brought to slaughter" and were treated as such. I am still working as a programmer, but I am not entirely convinced I still want to continue in this profession. To avoid further meltdowns I am considering more mechanical tasks. My piece of advice: when the very first sign of abuse is shown, just quit. Your mental health is much, much more important than any job.

[@VitorCastelo]

Maaaan! This post is almost two years-old but hearing all this it's to me like a breeze of fresh air. In another lifetime I was doing Scrum and I loved it. For the past 10 years I am working for a very large organisation where they mixed a lot of stuff in a big bowl, made a big salad and called it Scrum. Worse, call it Agile. And so, I quit. Not from the company, which has many good things to strive for, but on this corner I quit from trying to bring whatever to the table that even reminds Scrum. How could I actually? My little Scrum brain was replaced by a big Scrum salad... Ah! And I'm a developer.

[@peterlinddk]

I teach scrum, or rather I teach software development and use scrum as the introduction to project management. I’ve heard all those “hates” before, from people in the business and other teachers, and until now I haven’t understood it. But now it occurs to me, that I’ve always used scrum as a way for developers to gain better control of their process, while others have seen it as a tool for management to control the developers, and of course that leads to hate and distrust! I’ve seen teachers more concerned about the correct naming and definition of all the elements, like burn-down chart, daily scrum, product owner, etc. than using the tools to create better products, and better teams - and I’ve seen the students’ immediate dislike for scrum … I can only imagine how much worse it would be to have management behave that way 🙁 Thank you for a great video, it’ll be on next semester’s curriculum 🙂

[@HealthyDev]

Nice! I love the idea of students getting exposure to this stuff.

[@MiM-hh8xz]

Yes I also teach scrum and it's this exactly. You absolutely need to let the students control the project. I do get some push back at the start of the course but by the end they realise how powerful it can be to work like this. I'm also a former developer (who's experienced badly run waterfall projects) so maybe that's why it was instinctive for me to teach it like this.

[@57thorns]

@@MiM-hh8xz I have worked in well managed conventional projects, and for me scrum is just another way to do the exact same thing: - design, code and test in that order. But: You can always use unit testing and test-first. Sometimes the demands for integration testing is such, that it is better handled by someone else. (I am not licenced to drive heavy machinery or run a nuclear plant of fly an air plane.) This puts demands on getting your design clear. And the best way is to zig-zag down the V shape. Start with your overarching goals, then look at how to verify them. Then refine layer by layer until you are down at code level. Remember to identify the static foundations and do those first. Your car _will_ have a user interface with a steering wheel, an accelerator pedal, a break pedal and a gear selector (manual or automatic), so perhaps even a clutch. Some of those will be strictly mechanical, but you would be surprised to know how much is done in software these days.

[@BulbasaurLeaves]

In my first job out of college, we used to plan for a story point to be approximately one person-day (knowing that it would actually take longer in practice). Then, they hired this very arrogant manager who insisted he could take a bunch of metrics and make everything better. He found that a story point actually took about three person-days to complete. His solution was to cram three times as much work into a story point and still expect it to take three person days! He literally believed that changing the amount of work in a story point would change the fact that the work always took three times longer than we planned. No one could talk him out of it (especially not a junior engineer just out of college who knew nothing about office politics). And when it didn't work, he just started berating the team for not being accountable to our commitments! To this day, I'm amazed that someone like that managed to get into a leadership position.

[@HealthyDev]

I'm sorry you had to experience this! Thankfully, one thing I've learned is all bad actors (whether managers or programmers) do get found out and held accountable eventually. They just sometimes make A LOT of noise and cause a lot of suffering before that happens. Hopefully you're in a healthier work situation now!

[@pencilcheck]

ironically, those managers who make a lot of noise are the ones who will made to the leadership position because that's how leadership is being looked at in most companies nowadays. Reasons are simple, if you are trying to get a manager job, how do you stand out from others?? If you are being the nice guy, and being invisible then you get nothing to talk about since you didn't haven't done any "work". Those arrogant managers are there because they are also forced by the company rules so they need to do something about it to insert their footprint so they are not fired. It is a pity, the real evil is usually at the highest - PR or director level. But as far as developers are concerned, the evil people are the manager. :)

[@BryonLape]

That is almost everyone in management. They have to justify their existence.

[@EgonCom]

"Obsession with features" - that is my biggest gripe with Scrum, but I describe it differently: There is no architect phase in Scrum. By design. There is also no place for refactoring in Scrum philosophy. By design. All Scrum project I was participating in had huge technical debt, with no way of getting out of it. And in Scrum, that is by design.

[@flamfloz]

Aren't you supposed to eliminate the technical debt as you go along - as you work on feature? One problem with this is that it requires some maturity from the software developers to be able to work on both features and architecture at the same time (which I personally found was not often the case with devs today).

[@Ebinsugewa]

@@flamfloz in my experience management does not respect the autonomy of scrum teams to set their own priorities. We are always trying to fit backlog stories into the sprint, but they get pushed out of the way by feature work that has 'urgency'. We are calculating all these metrics and doing all this paperwork, but if scrum leads/product owners are not empowered to say NO then it's all for naught. It's also rare that any team I've been part of is sufficiently staffed. So you can try your hardest to work backlog stories at an appropriate rate. But if you're generating more debt on a sprint-by-sprint basis than you can feasibly clear out, it doesn't matter how much you try to focus on it.

[@timlind3129]

Not true and not true. Agile and it's Scrum format is so misunderstood, and this is a perfect example.

[@DanielDogeanu]

This is one of the reasons I'm starting to think that development is not for me. It's always done wrong, and it produces highly toxic workplaces. I'm severely burnt out, and I'm so sick about this stuff...

[@potato9832]

SCRUM + stack ranking + 6 month performance reviews is a toxicity factory.

[@javaman2883]

Our upper management requires most teams (even non developlemt teams) to use Scrum, and they examine the burn down to determine which teams need to make improvements. I'm understanding more now why so many teams openly share their dislike of Scrum.

[@prontopuntor]

agile makes programmers hate programming and users hate their programs; only managers are happy;

[@BenScarboro]

Now add in SAFe...

[@InfernalStateMachine]

I've been using Agile, using story points as hours, double logging time on jira and a separate timesheet app, and have it used as a performance metric for my team and each individual member, integrated with our performance management system that directly affected pay rises and promotions. As a team we had to invent 'undercommitment slack' and other cheats to work around all our impediments. When helping someone, we had to ask them for their `work package` so we can log our time against it. We ended up spending 15% of our time cooking numbers and stopped helping each other. In my new job we're using it right, but I can understand why so many people hate it.

[@HealthyDev]

Wow, yeah no scrum project is ever perfect but tying story points directly to performance is just toxic. Story point sizing is supposed to help the dev team get a relative size of items to work on so they select work with a chance to finish on time. A "3 pointer" in one sprint may be completely different than in the next sprint, since the sizing is only relative to items *in that sprint*. The original inventor of story points says he regrets having ever created them since they've been so misused. The burn-down chart was a horrible addition opinion IMHO (it wasn't there originally in scrum), and part of what drives scrum projects to treat story points as time.

[@InfernalStateMachine]

​@@HealthyDev I didn't know that story about the story points inventor, but I'd regret too if it was me :D Using kanban with t-shirt sizes works fine for me. At some point we stopped estimating at all, we just care which work gets done next, and track impediments. Processed should never be put above good teamwork and common sense

[@HealthyDev]

@@InfernalStateMachine yep. That's where the industry is headed. Estimates are a complete waste of time in software development. When teams embrace the fact that they are super unreliable, demotivate people, result in crap products, and fight against agility - estimates suddenly look like a really bad investment for the product!

[@huaweihonor7714]

@@InfernalStateMachine Kanban = Toyota 1950s, best Mgmnt approach

[@HealthyDev]

@@huaweihonor7714 agreed, I'm going to talk more about kanban in future episodes!

[@mtsurov]

Scrum was created so project managers can rebrand as scrum masters and product owners and still have a job. Id rather have one solid engineer/architect then any amount of scrum masters/project managers/ product owners. One does the work, the other talks about doing the work.

[@uclassc]

Scrum is micro management and it is that way because managers only know how to manage. I hate agile and scrum it took all the joy out of my job

[@LukePuplett]

I think this is why work is often "process drama". When you watch small kids playing a game, they spend 80% of the time discussing the rules. I suspect in mundane games humans get a more significant dopamine reward from arguing over the rules of the game than playing it.

[@TheSimoc]

Explains why 80% of all software is useless crap and 80% of mainstream software size is code bloat.

[@DangRenBo]

Bikeshedding....

[@jamesonkennedy4604]

@@DangRenBo my bike isn’t shedding, it’s molting.

[@dibqip]

Thank you - “process drama” is exactly the term for the thing that’s been annoying me

[@randysvids4774]

@@DangRenBo I get depressed if someone bike sheds my stuff in front of everyone and they all argue over what color they want...."I think this should be dark gray"......"I think this should be dark dark gray"

[@189Blake]

For me, the story points are a dumb idea in general. I have never seen them being correctly estimated, and productively interpreted. Yet we spend hours every sprint that could be used to develop, calculating (guessing) story points instead. Maybe the PO knows how many SP have been made, but that information is irrelevant as never in my life I have seen them do something useful with that information.

[@QueenOfMissiles]

If they are not useful then they are not being used well. SP should have solid well defined rules that developers can reference and have known examples to match against.

[@jeanjasinczuk7543]

@@QueenOfMissiles The main issue is that it is almost impossible to match the unknown against a known example. A complex user story has a lot of unknown.

[@sevilnatas]

IMO you might not be thinking about estimating quite correctly. The whole idea of estimates is that they are estimates and should be done relative to a touchstone user story that most if not all team members can agree is a mid tier user story. Once you decide on that mid tier user story, estimates should simply be "bigger or smaller than a bread box" type estimates, your mid tier story being the "bread box". Your estimates are going to be "not great" in the beginning because you are simply putting a stake in the ground to get started, but as you get through a few sprints, you can start adjusting based on the team getting into a good rhythm with each other, getting more familiar with the type of effort that goes into the projects "personality" and getting better at the task of estimates. Yes, estimates are going to be wildly inaccurate at first and in a little while they will be only mildly accurate and eventually they will rise to the ultimate level of almost accurate. But accuracy is far less important than consistent. And yes, their will always be unknowns. That is the nature of coding. But you are doing estimates of relative effort, not hours and if anyone is pressuring you to have them operate like estimates of hours, as the video said, they aren't doing scrum. The thing I always go back to is the story that my training talked about when he was working on the team that created scrum. He said that they ran experiments where they had teams do a full waterfall requirements documentation and time estimates that took months and documented each requirement down to the 'enth degree. They then had a scrum team do a 1 week overall scrum style user story backlog and user story estimate (boulders not pebbles) of the same project and at the end of the project being developed, they compared actual development time to the estimates. The thing that they found was that the 2 estimates were surprisingly similar and both estimates were relatively accurate to the actual development time. It showed that estimates were good enough to get practically the same result but were quicker, massively less laborious and less expensive. You just can't let a PO or SM push you into expectations that the team can't deliver, as far as points delivered per iteration, but you as the development team need to work to get more accurate at estimating as the project progresses. It is the SM that should be helping you with that or he is not doing a good job.

[@elenaml2635]

Hey, newbie Scrum Master here. My company recently introduced SP some months ago. The developers may not see the use, like you say, but I can assure you that I have to report them to management at the end of every sprint. And the higher-ups have contacted me and asked me for explanations when the % of completed SPs was low. Before, we were just using the number of completed stories/issues as our metric and, while it made Sprint Planning shorter, the real effort needed in each task was not properly discussed among the team. Having this discussion is also helping me push the product owner not to try to overload the team with stories they will not be able to complete by the end of the sprint.

[@sevilnatas]

@@elenaml2635 So my response to some of you points would be that, firstly, you may not be able to do anything about it, but management is using the estimates incorrectly. The goal is a successful sprint, which means that the number of user stories accepted into the sprint were achieved and any user stories not achieved should be analyzed at the end of the sprint to see what went wrong. Not to point fingers, but to improve the estimation process or whatever root cause can be found for not being able to accomplish the user story within the planned sprint. Secondly, this leads to the fact that the product owner should not be in any position to "overload" the team with stories. The only thing the PO should be doing during sprint planning is answering queries from developers and setting the priority of the stories in their backlog. The number of stories in the sprint almost load themselves. After all estimations are complete, the top priority stories are put into the sprint until the number of points that the team has been shown to be able to complete is reached. Their velocity is based on their past few sprints plus any extra velocity you can add because they finished the last sprint early or any velocity you need to subtract because they have not completed their plan after one or two sprints and they find that their estimates are evolving, hopefully for the better. The only measurement of productivity, by management, is if sprints are consistently being completed successfully and that the scrum master and the dev team can agree that everyone is working productively but without feeling a pressure to work unethically. In other words, not being overstressed and over worked. It has been clearly shown that overstressed and over worked developers generate bugs and write bad code, that just needs to be fixed or rewritten. That achieves nothing. The separation of duties is important in agile and for it to work, everyone needs to stay in their lane, including management. As long as the development team is firing on all cylinders, they way you get more code written is by adding resources or even another additional team.

[@rjean99]

#6 used to be called "scope creep" - I think a lot of these frameworks/methodologies just come up with new terms/buzzwords for old problems that have always existed. Bad management is bad management and there's a lot of bad management, but they usually don't think so although they might be well intentioned.

[@DanielLiljeberg]

I still call it scope creep :)

[@gwaptiva]

I thought Agile and Scrum were there to make scope creep easier?

[@archi-mendel]

@Scott Page USMC I hardly can see any other process than devops in implementing and improving products - plan, implement, release, observe, plan, ... Not sure why it should work for specific orgnisations only.

[@archi-mendel]

@Scott Page USMC to compare Agile and Scrum with waterfall and Gannt charts, you actaully need to know both. Some people have seen couple of crappy implementations of Agile which has nothing to do with Agile itself and think that Agile is crap. This is not very professional way to make decisions from my perspective.

[@camelcai]

I used to work in a team where the SCRUM Master was a former mountain climber who knows ZERO about programming or software. And we did SCRUM dances (literal dances) . From then on whenever I see a Scrum word in the job desc I just never apply. Scrum is just a power play which says the master's time is more valuable than engineer's time.

[@smallbluemachine]

Wow.

[@FHi349]

Damn!

[@PbPomper]

WTF. A scrum master is actually supposed to be one of the team memebers (software devs). Way too many people get into these roles without ever having written one line of code or even know about software development at all. They just followed a course somewhere. Terrible. That is not scrum.

[@mikelieber7256]

I was on a "scrum" projects where storypoints were linked with hours like 1 point = 8 hours, and I cannot imagine something more worse than that! When I was to exceed storypoints limit, the busyness team would pop up and ask why the task was badly estimated. Of course I'm not mentioning than up to 90 percent of the tasks didn't have any busyness requirements and mostly were like "I want thus feature, and I don't want to think how you're gonna implement that" 🤬🤬🤬🤬🤬

[@matthewconnor6817]

At least they’re still using points I suppose.. Current project is ‘sprints’ with estimating done in actual hours and micromanaged tracking of exactly how much hours you’ve spent on each ticket. It’s easily the most miserable I’ve felt in 2 decades of software engineering and will be glad when this godawful thing finishes.

[@PbPomper]

Damn, that's terrible. I feel that has more to do with the culture though. In my current team of about 7 devs and 3 testers the process works great. But that's also because everyone has coding experience (SM and PO as well). Points are not tied to time, but relative complexity. It helps that managment also come from an IT background and give a lot of trust and freedom to the teams. I think trust is the most important. You need to trust that everyone wants to deliver the best product or service and that you're ultimately on the same team. You need to help each other out instead of trying to play the blame game. Nothing worse than micro management. I'm not sure, but I think working in the EU is also completely different than the US where there is much more individualism and ruthless competition to climb the corporate ladder. But I might be totally wrong on that. Maybe someone can chip in?

[@antelectronica]

Thanks for your insight! As a person who worked in a startup for the first time several months ago with a technical background, I joined the business side instead of the product (sw dev) side. Because we we're small and of a team of 10, I joined the scrum meetings along with the engineers and passed on my insight as well. Now I know that this may be bad practice and should stay away from the scrum meetings if possible.

[@WarrenPostma]

I think you should actually ask privately (one on one) if you need to leave those meetings. In my opinion, anyone can be present, if they shut up. Scrum is supposed to have the Pigs and the Chickens concept. The pigs are the ones who have to do the work and so they have more invested than the chickens, who simply provide some ideas. I don't like the idea that anyone is not allowed to know what is said, I value transparency, it's just that when it comes down to planning activities, those who aren't doing, shouldn't plan.

[@HealthyDev]

@@WarrenPostma I remember this in the early days! They got rid of the pigs and chickens concept, I'm guessing because people weren't respecting their boundaries. Nice to see another "scrum old timer" on here :).

[@travispulley5288]

What I hated most from scrum experiences was the constant anxiety that some surprise defect would throw off my ability to deliver a complete story by the end of sprint, and how difficult it was to address the defects because of needing to coordinate with other teams and their agile/scrum processes. I'd always feel stuck and lame at needing to talk to so many people so often to make basic progress, all because some setup dependency was broken or some inexcusable js prototype pollution was in place, or I discovered a show stopper race condition and the dev responsible doesn't care, his manager doesn't understand, and my manager gets annoyed hearing about it instead of being helpful "because agile". What I hated 2nd most was looking at Jira. Between the cluttered UI and saturation of white pixels, it hurt my eyeballs just to look at.

[@prateekbhardwaj9943]

wow i m not alone

[@BarrySlisk]

I hate Jira too. What a mess it is. I like Gemini.

[@errrzarrr]

Like being put on trail on a _Daily_ basis. Begging the jury to not cut your throat, day after day.

[@DotNetDemon83]

Every single one of these is what my last company did and is exactly why I left.

[@jose6183]

Same happened to me. I quit my job pissed off because of all that. I have PTSD just listening to this video.

[@jasonpeltzer1907]

I think the best decision we've made is to not use true Scrum/Agile. Our company is small and things change quickly, we often start a project with little to no information and it's up to me as the architect/CTO/lead/whatever to make game time decisions and figure out the requirements real time. It can be quite unpredictable, but so is our business, so there's really no reason for us as a team to commit to timelines to the management when the management can't commit to an overall plan. We adjust real time and make decisions based on business requirements. I'd love to be more predictable, but that's just not the reality of a mid sized startup trying to push to the next level. It also gives me the flexibility as the architect to do the upgrades and refactoring necessary to stay relevant and current.

[@HealthyDev]

Excellent. That's true business agility. Scrum was meant to enable exactly this. Until story points, velocity, and sprint planning were focused on to appease management's desire for control. Sometimes the best thing is to throw the whole thing out. Other times practices can be tweaked to still find it of some value. If it works for you, keep doing it!

[@rogermouton2273]

Well, to me, what you're talking about is being ACTUALLY agile - responding quickly to change, not waiting for detailed specs before you start building something - because no one has the time, and even if they were written, they'd be out of date the moment they're finished. Ironically, the faster you need to move, the worse scrum is.

[@paldeusjaco9657]

Really love your down to earth real life experiences rather than the theory. Everything is perfect in theory and on paper. Remember how Mechanics would have a sign saying how much something costs if you help them? We need that, it's 1 hour to code, 5 hours if manager helps to code, 1 week if product managers want to understand and help with implementation LOL.

[@ragequitredux]

Arguably, a process that is so easily misunderstood and made toxic by one silly manager is an unstable process.

[@archi-mendel]

Are there any other processes which don't have this attribute?

[@ragequitredux]

@@archi-mendel I dunno, Doc

[@archi-mendel]

@@ragequitredux I am pretty sure that any process which is led by people who don't want to understand the process would lead to disaster and a huge struggle for anyone involved.

[@forceghostpepper]

Many of the points here are very insightful because so many of them are violated where I work, especially your point 5 where the burndown chart is shared not just with management but within internal department wide product demos. When you have a good burndown, nobody bats an eye thinking that it is the normal state of the sprint, but when there is a bad burndown, managers scrutinize more heavily with their thoughts gravitating towards developer "performance", as the lead, it's terrible because it continually affects the morale and sentiment of some of our more junior developers. Seniors have thicker skins or are too jaded to even care.

[@HealthyDev]

I'm so sorry. I've experienced exactly this. That's why the burn-down should never be shared outside the dev team. A team not burning down the work is MORE FREQUENT than successfully burning it down in my experience. That doesn't mean everyone isn't doing a great job. That means we're doing highly complex and uncertain work - software development!!!

[@philguitfiddle]

I've been writing software for over 25 years. Everything you say is true. Experienced every points you discussed in the video.

[@brianmccormick8328]

I hate scrum. Every team I’ve been on has become a slave to the scrum process and didn’t care about the actual product.

[@matthewroberts2717]

As an agile professional of a decade - I agree with everything he says. My team tries to get towards this, the struggle is middle managers who don’t understand development or agile.

[@paulburger9904]

Agile: Unlimted scope creep and poorly defined requirements. No wonder managers love this garbage.

[@foobar8894]

There's no point in having your team getting towards that. Companies are agile, not teams. If the company is not trying to be agile you should give up now because it's not going to work.

[@archi-mendel]

But as an Agile professional your role is specifically to make business understand Agile concept at first place.

[@edwardroh89]

@@archi-mendel but some useless execs and managers will never understand Agile properly. Especially ones who want to micromanage. These people are useless and incompetent because all they want is control but they disguise it as wanting to "increase business efficiency".

[@archi-mendel]

@@edwardroh89 this is why skilled SM is very valuable - it takes a lot of efforts and experience to transform mindset of company leaders, especially if they are your bosses.

[@jackie.p6891]

man, every issue you described is exactly what I'm dealing with in the company I'm working in. Another issue with it is that it's management that defines the structure we work in, and they don't listen to feedback from the dev team. so the structure changes every year or so based on what they think will improve performance, but it's just stressing out the developers even more, because it's all focused around time management rather than quality.

[@Dystopian1]

Show them this video

[@archi-mendel]

This is what I am trying to convince our management to not to do. And I like to think that I'm doing great. We've introduced some concepts to try give developers more control on their teams. One of those concepts is that when we hire a new developer, we actually have interviews with the members of the team for which we're hiring (and teams are rather small as prescribed by Scrum). We had cases when one team has rejected the candidate and another team has then told that they would actaully be happy to work with this candidate. This is a nice way to make sure team members have similar mindset and actaully own the decisions on who should be part of their teams, which also means they take a bit more efforts to help onboard the new member of the team and make sure they are not lost on their new position. I may sometimes be asked by one of the teams if they could get specific developer from the other team who they like. If we think this wouldn't harm both teams capacity much, I go directly to those developer and ask whether they would like to move to another team. In general, I still yet to hear that someone would actually decide to move (as people tend to get used to their teams and are in general happy with where they are), but if the person would agree to be moved, than I would try to organise the move with POs of both teams and engineering management. I really like such small things and conversations happening in our organisation. This adds a lot of personal feeling to all we do.

[@madzero0]

As a Scrum Master the only thing I would add to this is AMEN. Also as a Dev be proud of what you do and have fun doing your job.

[@AlanDarkworld]

We're doing Scrum too. 4 sprints, then a (manual) testing week (in addition to loads of automated tests), then the release. It may not be perfect, but it's a process. Then the sales engineer (a.k.a. technical support guy) comes along, 3 weeks before the release "yeah we need this change very urgently". I tell them no, it's gonna break stuff, wait for the release. "The customer can't wait that long, do it". And then I do the thing, backport it to the release (that alone is often a major pain), it passes the unit tests, it gets deployed, and it has unexpected side effects. The sales engineer reacts with surprised pikachu face. Who could have known. This story is on repeat every other week and I hate it.

[@57thorns]

The solution: The customer that has to have that feature, will not get the release you are working on, but in the next release after that the fearture can be included. Meanwhile, the customer is one release behind and their system is not working because it was not tested.

[@maxlutz3674]

This is a reliable, proven method to deliver releases on time provided the deadline agreed upon was "some day in the future". I know that it does not provide comfort to know that you are not alone.

[@archi-mendel]

@@57thorns agree, sometimes it is enough to tell customer when something is going to be fixed, not to fix this immediately.

[@archi-mendel]

Do you regularly find severe issues during test week? If yes, is there a way to lower probability of severe issues by applying a bit more testing during sprints? Is there a way to run autotests regularly on the release branch during development (say, nightly), not in the testing week only? Does it take a lot of time to build the release? If not, could the release cycle be shortened to, say, one week, so that the number of released changes on average is 4 times smaller and the risk of having severe issues is 4 times lower? if yes, are there any ways to speed up the release build to be able to have shorter release cycle?

[@57thorns]

@@archi-mendel The best way to reduce errors, in my opinion, is to take the design phase/stage seriously. There is an old carpenter motto: Measure twice, cut once. The same is true for writing code, make sure you know what you want to to before starting to write code. This is true, regardless if you make a "quick fix" or design the software that controls the balancing of a power grid.

[@nickfoard7139]

As an Agile coach of 15 years I really enjoyed this video. It aligns with everything I believe about how Scrum should work and my role within it. Thanks for taking the time to put this video out. I’m going to share this with the teams I coach with as well as the Middle management.

[@arthurdaly3497]

In my experience, even when you have a software company (for which I worked) pushing agile , the commercial contracts still say that the customer demands it finished by date. They demand waterfall, and everyone pretends it's Agile/Scrumm because its cool to claim that.

[@HealthyDev]

Yeah that's pretty common. I worked for a consulting agency where we actually came up with a sales approach and contract terms where we educated clients about agile and did not have finish dates. It can be done, but it takes balls, a desire to educate, and a willingness to take risk. Fixed bid projects are just as risky (if not more). They just look better on paper for people who can't fit software development's uncertainty into their worldview, so they try to bend reality.

[@modrn_]

I'm telling you right now, I've been on a lot of successful projects that were successful with Scrum, but... right now, this project I'm on is actually being HINDERED. It's absolutely insane how much time we are losing with all of these dumb-ass meetings to plan, and plan, and plan, and plan and primarily it's because there was never an adequate requirements gathering session. But either way, the number of meetings required are just absolutely insane.

[@regalternative]

This video reminded me of why I left programming. Even when scrum was done right I still hated it

[@jacoberinc]

Yep, the entire concept of fixed short time iterations packed with tasks to meet an overall point number based on always inaccurate individual task point estimates turns programming into a never ending slog from short term deadline to short term deadline. Replacing creativity with stress, thinking with sprinting and planning with iterating. For me, this is the definition of a nightmare.

[@regalternative]

@@chaccmi1358 Data analysis. There's still some programming and other stresses but not in the same way development roles are.

[@JamesJansson]

This is a REALLY good video. So many good points, and ultimately about it coming down to honesty: planning/discussion in daily standups is about honest feedback and understanding, and if managers get hold of it and use it as KPIs, then people can't be honest and communication breaks down.

[@shadeblackwolf1508]

Real perk at my company, our sprint owner/backlog owner has no managerial authority, and can actually get reprimanded for leaking such things to management

[@jamessauve2419]

I appreciated the comment on planning 6 months in advance. I was on a team that did that every sprint. We would do planning, not just for the next sprint but we always planned out what we were going to do for several sprints after. It never worked out as expected and all those future sprints had to be re-evaluated anyway. Such a waste of time. In a few cases it was due to problems that arose, but most of the time it was just management that kept changing their minds.

[@Meeffoc]

Well, I’m a scrum master and a certified developer for the product that I deliver for. Also, I act to help the dev team see all many different options and let them decide. I’m always here to back them and make them feel safe. Problem is that I report for a delivery manager that has no clue about the product, sees them as a manufacturer and don’t hesitate to blame them if her ludicrous planning doesn’t work out. Tough situation…

[@VortechBand]

Some of my favourite jobs have been where there were essentially no managers/non-technical people in the day-to-day work. Just a CEO or CTO asking the team to build a tool/bigger feature to an existing main product the company develops, and the ability to ask the non-technical actual users what they would like to have in the product, or how some existing feature could be improved. How we do it was up to the team. And boy, did we create some cool stuff that sold well (add-ons to the main product) and worked well, and it was great fun working together with the users. Unfortunately companies like that are somewhat of a minority.

[@chaccmi1358]

That is how software engineering is supposed to be running, it's a no brainer yet most companies have all these layers of non technical folks putting sticks in your wheels and bad products end up getting delivered.

[@Shaojeemy]

Our manager single handedly pissed off 7/8 of our senior engineers. Now he leads a skeleton crew

[@AleksandarIvanov69]

OP, you just described the core philosophy of Scrum. Now the question would be IF that's the core philosophy of Scrum and that is what developers love, why they hate Scrum ? Odd contradiction, isn't it ?

[@SurmaSampo]

@@AleksandarIvanov69 No really. OP is describing working at a software startup with little to no management layer. See the thing is that enterprises that are not software companies that they need to use agile/scrum too in their internal dev department that builds an maintains the applications that facilitate the operation of the business. Funnily enough the company needs specific things delivered in a specific time probably using specific technologies and practices that the rest of the business will be able to operate and maintain. The difference is that in the OP's case they were the business operation. In the second and more common case the devs are an internal supplier to operations. The OP was also in value add team which tends to be a high margin part of the business which means less pressure and more leeway. If the OP was grinding away at code maintenance on the core product life would have been very different.

[@Stonegolem6]

@@SurmaSampo "internal dev department that builds an maintains the applications that facilitate the operation of the business." describes my situation perfectly and everybody outside the guys who have to budget our time, love that we use Scrum. Under the old waterfall method, users would ask for a new feature and it would take a year to see it, and by then they'd hacked together some excel or VB script to take care of it themselves. (mechanical engineers seem to think they're software guys too)

[@nitesh-maharaj]

I've literally had a manager try to compare software development to manufacturing. Before a product goes into manufacturing, there are months, if not years of product development. Then there's a painstaking amount of time spent on working on and refining the manufacturing processes. Even with a well thought out plan, software development has a lot of discovery along the way. It's also a lot simpler when you're in control of the entire product, but as soon as you introduce integrations, then things get far more complex. Why is it that my side projects are so much more exciting than my day job? Because I don't have management involved in my side projects. Unfortunately, this is a cross we have to bare as software developers, and why we end up hating our jobs, even though we love what we do.

[@liranpiade4499]

I think what's different about software is that it's development without manufacturing. It's called software development because software only involves development. Manufacturing is just compilation which you're constantly doing anyways. With software, all you ever have are development and delivery (including marketing and all that)

[@archi-mendel]

From my perspective, there is actually little difference between manufacturing and software development. And there is specific reason for why live software product is called production.

[@georgeyoung2684]

Tying story points to time was always my biggest gripe with the way my old team used to do scrum! The lead even calculate the expected velocity using the story points per week times the number of devs. One other issue with tying points to time is that the points estimation is now tied to who is going to do it: What would take a senior one day (2 points) might take the whole week for a junior (10 points). I’ve been pushing during every planning meeting to move away from this idea of story points = time and I think I’m finally getting some traction.

[@HealthyDev]

Excellent! I always ask people who think story points are time: "If story points are time, why doesn't scrum just use hours? Does doing things in a fraction and then converting it after make it EASIER for developers somehow? No - that would just add an extra step. The whole point is software is too unpredictable to estimate - so we use points within *a single sprint* to TRY and select work we might be able to get done in a sprint. It's never hours, and it's never a commitment. It's just a tool to use by developers. If you want predictability, go work in an industry with a low complexity product that has repeatable tasks and known materials. That isn't software - we have unique tasks every sprint and the materials are NOT known!"

[@andyb4828]

​@@HealthyDev I liked your video. Even as a Product Owner ;) - The topic with story points is a tough one. As a PO, I have to predict future rollouts because our customers need to know when to build infrastructure and when to recruit people to use our software. This can take up to 3-6 months and must be planned in advance. That is why our customers depend on these predictions. In my opinion, a team's long-term velocity (story points per sprint) is static enough for meaningful planning. Story points are not hours as you said, but still a way to plan the output of scrum teams in the long run. It may seem imprecise for one sprint, but it works very decent across multiple sprints. In my experience, transparency in planning is one of the most important success factors of Scrum. That's why I invite our stakeholders to planning meetings after every sprint review to explain the consequences of the results of the past sprint for future sprints. In this way, possible delays are communicated early in small, tolerable chunks. And it works. That's why I think it's also important to talk to the PO about a decrease in velocity, such as vacation or training new colleagues. That help's the PO to explain changes in plan. Like a saying of Eisenhower: Plans are nothing; planning is everything. Great video! I am hoping for more. Thanks.

[@HealthyDev]

@@andyb4828 hey Andy, that sounds like a product architecture complication. What does needing new infrastructure have to do with the output of the software development team? This could be something unique to your product and I don't understand. If you get a moment, let me know!

[@andyb4828]

@@HealthyDev Thanks for your answer. And of course I have a moment. Maybe I misunderstood your message. In my experience, software never walks alone ;) - In our cases, there are always dependencies on customer project plans, e.g. building IT infrastructure or recruiting employees - Software has to run somewhere and people have to use it. When software rollouts aren't accurately estimated in date, people wait (and still get paid) or IT infrastructure costs rent without doing anything. So you want to keep the discrepancy between installation and real rollout as small as possible. In our business we create specialized outsourcing software that runs in our data centers and exchanges data in our customers' data centers. Therefore, our development plans have to match the project plans of our customers. This means we have to plan ahead and predict a rollout date a month or a year in advance. This is where estimation comes in, where I translate story points into sprints and where I translate sprints into project plans. And we're pretty accurate.

[@HealthyDev]

@@andyb4828 ah OK this is what I thought. You're in a business that uses a single tenant model, where you need to do development to get profit from each customer. In this situation, scrum doesn't work well in my experience. It would actually be wiser to go with waterfall. It probably still won't give you super realistic dates, but it will be give the team more time for up front requirements collection and planning dependencies as you said. And it won't have developers reporting status every day. I'm guessing y'all have a discovery phase with clients where you learn about their system you're about to integrate with. You can then do a design phase to design the software (before you build it) at least having an idea of what components, libraries, etc. will need to be built. Then estimate the time to actually build and rollout. Yeah these types of projects are extremely complex, risky, and not in my opinion fun to work on. But I realize this is just the business model of some companies. Scrum and kanban agile projects are better for multi-tenant apps or SaaS products where every change you make provides value to multiple customers.

[@zoricgames]

I'm suddenly a lot more positive about my organization and the stuff I'm pushing back against after hearing some of your stories. It's amazing how badly some organizations can misunderstand what agile is actually about. You have to change your ENTIRE organizational mindset for it to work, and some places just aren't willing to do that - often because it requires managers to give up the illusion of control.

[@Sonsequence]

I think your sound reasoning walked you straight into showing that scrum really can't be salvaged. You suggest that management should provide super detailed acceptance criteria, basically writing all the integration tests. This attempt to reduce us to code monkeys is a reason to hate scrum. And coding _is_ detailed specification. We are better suited to it so we should be provided with designs and purpose and reply with acceptance tests to be negotiated over before implementation. Also, there's no coherent way to divorce story points from time because their first purpose is to decide how much can be done in a given time. Estimation is very hard and story points are fake precision. More harm than benefit.

[@bassjakekuss2232]

You need more people watching your channel. As a fellow Tech Lead of UI development, preach it! Way too many dysfunctional agile teams out there.

[@HealthyDev]

More people having been watching as of late. Thanks everyone! I make these videos to make a difference and find coaching clients who need help - not to blow up a channel. If it gets big that kind of scares me to be honest lol.

[@bassjakekuss2232]

@@HealthyDev Totally understand. You just seem like a honest genuine person trying to help, so it's a compliment. I personally use your channel as guidance when I see dysfunction on agile teams. Stay real my man!

[@jose6183]

SCRUM made me go back to electrical engineering, what I originally studied. And I love that decision.

[@andreyburmagin3030]

I'm also considering moving to hardware... I mean embedded development, since I studied telecommunications engineering myself.

[@piotrd.4850]

@@andreyburmagin3030 Sect will find you.

[@AleksandarIvanov69]

Scrum gives you autonomy and creative freedom. Why did that make you switch professions ?

[@player400_official]

@@AleksandarIvanov69 Because ,,Scrum master” is being treated by companies as a management position. And management positions tend to be filled by power-hungry, micromanaging jerks (because they naturally gravitate towards positions of power)

[@tr1pH0p6uru]

As always, great work Jamye! I want to force all my managers to watch this video! Another thing that particularly frustrates me as a dev, is the sprint review meetings. Most of the time, these meetings are not planned properly and include demos of unfinished work, just for the sake of showing something to the business. Oftentimes the managers/product owners request the devs to demo unfinished tasks, from their local environments, and, sometimes, on the spot, without warning the dev before the meeting about this demo. Obviously, this creates a lot of anxiety and embarrassment to the dev, and it is just so painful to watch.

[@archi-mendel]

Do you have retrospective meetings every sprint where you could discuss such concerns with you PO, SM and development team members?

[@mrpapua100]

what I hate the most about scrum is, when product owner jammed a lot of feature into the sprint and we already said it is not possible to do all those things in 1 sprint, and then the product owner just said "just do your best to deliver". And in the end I won't deliver all of it even if I can

[@antoinedelequeuche4458]

As a product manager, I really like watching videos such as yours, because they help me become as mindful and respectul as possible to my software engineers. I agree with most of your video, except the daily stand-up: we completely revamped the way we operate them, focusing on blockers (sometimes I may help, at least when it's non-technical) and overwhelming issues (e.g. too many tasks at once for our QA). After the stand-up is done, I might occasionaly use the opportunity to deliver transversal news, preferring face-to-face contact rather than another Zoom call

[@HealthyDev]

Nice. I wish more developers would spend time with their product owner outside standups.

[@petropzqi]

Never really been on a project where they actually use scrum. Sure they say, we are agile and following scrum. But always missing key features, such as, scrum masters, burn down, correct user stories and so on

[@RvLeshrac]

The core problem with scrum is the idea that every sprint must produce a customer-facing change.

[@HealthyDev]

We got very good in consulting at explaining the value of work that isn't customer facing. It doesn't eliminate all problems, but it helps a lot. I find many developers who if they can't show anything, don't know how to explain what they did in terms of how it helps the overall product. It's very possible.

[@mattberry3551]

It diesn't need to be customer facing but during a sprint the team should be 'adding value' to the product as agreed in planning and with guidance from the PO. The opposite is also true, too much of an R&D sorint has led teams I've known become disengaged if they don't actually feel like they've achieved anything.

[@georgehelyar]

The trick is just defining the "customer" for each story. For example, your ops team could be the customer for a story that improves reliability, or performance or reduces cost, etc. End users don't care about that, but someone cares. They are the stakeholders.

[@barnakey]

Second to what others have said about the customer not needing to be the CUSTOMER. I'm the PM for our data team. Half our stakeholders are internal, and half of those are technical stakeholders (other dev teams) that need access to the data warehouse for their projects.

[@djVania08]

@@HealthyDev This should be work of product manager / owner. Not the programmer.

[@olafbaeyens8955]

When SCRUM always end up in a micromanagement fight then SCRUM itself has a flawed design. And you can keep on pretending that we are using it wrong, the fact that it always end into complete up the hill battles with a team feeling miserable at the demo means that it is easy hijacked people that loves power. Of course you have that so called retrospective when you can freely give back your feelings, in reality you can never be honest because it is going to be used against you. I understand the idea behind SCRUM, it should be programmers heaven, but in the field it always makes developers miserable. However towards management developers will pretend that everything is OK. Or else get fired because you are too negative.

[@HealthyDev]

Hey Olaf. Sorry you've had such bad experiences with scrum. I have too, it really does suck to see how it's abused. I hope some day when you're a manager or in a position to influence a company's processes - what you've learned can be used to setup a development team that doesn't have to put up with this crap! That's my hope in making these videos. Some people are so stuck in their ways, we just have to wait for them to retire, or find a healthier company!

[@errrzarrr]

Scrum is like Communism it is so good, so perfect in papers. Yet, in real life it always ends in mass starvation, massive human butchery and corruption beyond belief.

[@olafbaeyens8955]

@@HealthyDev We had a period where it actually functioned partly. PO creates user stories, prioritizes it and then developers took them in order they could to them optimally. No upfront goal, no upfront estimates, we went for the demo to the very last minute. But 5 sprints ago they reverted this again, Quantize and uses this as a stick to beat you when you did not keep your promise. So one week before the demo the group becomes toxic, and we actually stop developing to the day for the demo. People give up because they can not get it done or start to go into burn down just to meet the target. Officially they say that they do not put pressure in the team, that we have freedom. blahblahblah... But the passive aggression is building up strangling the team. I actually don't think that this team will survive the next months. I am already looking out for other companies.

[@Account.for.Comment]

@@olafbaeyens8955 there used to be or there is, something called "Design Management" which is how you manage groups of creative people, and have them pitch in ideas instead of one tyrant manager giving orders. Designers and the creative industry used this style of managing. I've been there and instead of one tyrannical manager, we have groupthink dominating discussion, with more introverted, original ideas pushed out. Basically, who is more popular got to do things their ways. In a traditional management crew I' ve work in, everyone got a voice because they was allowed space to do things differently and teach other what they know, and give each others pointers. It is not the process, it is always the people. There is no one-size-fit-all recipe for good or bad teamwork. You know it when you see it. Scrum supposed to have self-organizing team to do the work and a manager take the credit and be the scapegoat. Some status meetings, some lists of tasks that needed to be done. The guys that sold it embellished the whole things and the manager/upper-management can blame the strategy or implementation more than the people. It is another ways of avoiding responsibility just like any bureacracy. Any other process or buzzwords would have ended up with the same results. A micromanager in Scrum would be a micromanager in Kanban or traditional settings. In other words, an idoit would be an idoit.

[@HealthyDev]

@@olafbaeyens8955 I see this happen too often. A team gets scrum right, things go well, and it's just not enough "hard data" to keep micromanagers satisfied. Sad!

[@DQsRabbitHole]

Dude, You're the Man!! Your observations are spot-on!! The biggest problems as you describe them here go back to the assembly-line mindset a lot of companies are quick to adopt when the Agile circus comes to town. Also, nice soothing guitar riffs for the transitions, which is consistent with a theory I've heard about musicians making good programmers.

[@MachineYearning]

This is very quickly becoming my favorite channel on KZbin. It feels very vindicating to hear you discuss all the things I've tried so hard to push for in my scrum teams, and a lot of your explanations about how to feasibly accomplish improvements aligns with my experience as well. If nothing else, thank you for stroking my ego- but I'm subbing to hopefully learn more here!

[@HealthyDev]

Awesome Francis, I hope this stuff really helps you and your team!

[@ghostofrecon1]

You just brought a tear to my eye. I’ve been in environments (one in particular) that did literally every one of these

[@tokunboomonubi4329]

It's amazing how beneficial your channel is to non-devs as it may be to devs... Keep up the good work

[@HealthyDev]

That's great to hear! Thank you!

[@silentwater79]

What me always pisses me of is the Customer or the "Product Owner" as he is called in a Scrum Project, never wants to write good User Stories. Mostly they just write the Headline and that's it. The rest of the work he leaves to the Devs. They also should write the user stories. Most of the time the PO is a lazy ass who does not want to do anything. And if you ask questions because you need more information, he gets pissed. Or in other cases which I already had, the Dev Team knows the product and processes mucn better than the PO and than starts telling the PO what User Stories they need. Sometimes the PO just telly the Devs they should just write the User Stories themselves. Hell we even had a Project where the old PO changed the Department and we have been completely without a PO for like 6 month until they found a new one.

[@JGComments]

Thanks for the little guitar interludes. They kept me from losing my temper every time you brought up one of these pain points, lol. We never did real Agile. Management here just used “agile” as a magic word to mean that they could continuously move the goal line and magically expect a 2 week project to be done in one week, because we’re “agile” now.

[@johnpassaniti4417]

Ever since the Agile Manifesto, I have been watching Scrum (and before that, XP) and wanting to adopt or adapt it in the companies I've worked for. The problem is that all of the agile methodologies fall apart in the world of embedded systems. We aren't just designing the software of our systems, but the hardware that software runs on. And the hardware people have no use for a development methodology that assumes the product is as a malleable as software and the cost of change is low. Software in embedded systems starts off serving the needs to the hardware people first (initial bring-up and testing of the hardware), but at some point, we have confidence in the hardware and so agile methodologies can be used... ... except no, not really. There are two problems. The first is that something is always missed on the hardware side. The software engineers are happily writing code when someone discovers that a fundamental assumption about the hardware is thrown out the window. Maybe a part is discovered to not have a great device driver from the manufacturer. Or maybe a part doesn't work quite the way everyone assumed, and it bubbles up to major changes in the software. Or these days, the supply chain can't get you a part, so you have to substitute something else that doesn't work quite the same. End result, the software engineers have to drop what they are doing and return to work done earlier. The second problem is that the project managers often use the language and tools of agile methodologies like Scrum, but they are used in a very different way. They *think* they are doing Scrum because they have daily standups, but those are really just status meetings. Or they'll use hours for story points. And often you can't blame them-- the idea that a sprint has a clearly stated and agreed to goal makes perfect sense... until the FPGA developer says she can't get the design to fit and what was previously hardware must become software. I have been a big advocate for agile methodologies where I've worked. I've even managed to get a couple companies to adopt true Scrum, at least for the latter phases of software development. But it all falls apart at some point, and while we're all still using Scrum and other agile terminology, it's really just a wrapper around old practices with new names.

[@acasualviewer5861]

I think it's important not to be absolutist. The first think one needs to determine is what kind of software we're building. Are we building software for which the requirements may change vastly and rapidly? Or are we developing software with very specific requirements that will never change? Are we building software that can be easily redeployed if it fails? Or do will it be catastrophic. There's a huge difference in writing software for a rocket, and writing some internal tool for a company. It's very important to use the methodology that best meets the needs of the software you're building. So yeah, agile is not necessarily always the best solution.

[@piotrd.4850]

I think about 5 signotaries of original manifesto are already in 'hey, that's NOT what we ment'.

[@zoricgames]

Look up the Cynefin Framework. Invaluable tool for deciding when Scrum is appropriate and when it's not. Scrum is not a silver bullet to fix every problem.

[@kkjr6673]

I know some ppl that claim they got agile to work with embedded/hardware. I think it makes sense, at least in the original meaning of agile. The trick is that you need to get the hardware and fpga ppl into the teams. And you think about goals and MVPs in terms of the whole product, not just the SW part. This way, the SW/HW ppl get an early understanding of the processes and components of the whole system, not just their own part. So you all have a better idea of which parts of the interfaces are likely to change and which features are easy/hard to move around. Of course it would never work with the modern use of scrum: as a planning tool that is cheaper than waterfall because you skip the design phase. :-(

[@DerToooooo]

I agreed more on this video than I thought I would. 🙈 Working in a project where Story Points are directly converted into days, and where we have to argue about doing refactorings and "what's the benefit for the end user if we do this or that refactoring"... Think I have to shake things up a little bit in my team.

[@geriatricprogrammer4364]

Just get it done by this date because it says here on the spreadsheet that it should be finished by then. Then when it does not work in production...the management response is "I've done my bit...how am I supposed to know anything about it...I'm not IT".

[@zike03]

Honestly as a junior developer I had came in into a software development and thought that I am going to code most of the time. But there is so much to learn and next to my coding and learning programming, software architectures and design patterns , CI/CD’s , enivorments, frameworks, deployments and still on top of that I need to know the agile, scrum, SDLC’s and so on… I find it hard to catch up with all of these buzzwords and to me it seems like someone is speaking japanese 😢. Sometimes I just feel like my brain is bombarded too much with all the articles, tech stacks to the point when it is completely full. I am not sure did you felt all of this sometimes but I do.

[@sebastienc7717]

Jayme Edwards, I am a junior scrum master and your video is simply the amazing. I now realize several mistakes I made and why developpers are mad a me

[@mehdi5738]

I think one of the biggest mistakes companies do regarding software development is putting people who have nothing to do with software developement (My scrum master is a business analyst) in charge of development teams. I realised recently that we just speak a different language.

[@xpusostomos]

Yes. Yes! We had a textbook at uni which advocated the team be led by the "super programmer", aka the most talented programmer. Everything should revolve around making his life happy, and he calls the shots. Never saw it in real life though

[@FHi349]

​@xpusostomos real life is not movie, drama series. Often, in real life zero experience people have power over the most experienced or even highly talented people. It is what it is!

[@errrzarrr]

At least Business Analyst did a great job at gathering requirements, writing down acceptance criteria and researching the client. By moving him/her to SM you all lost a valuable BA and gained nothing but meetings and micromanaging. BAs don't have to be technical, they have to do their work which is very helpful for developers. Keeps things sane for us. When Scrum gained traction, BAs was among the good and sane things software industry lost.

[@xpusostomos]

@@errrzarrr Erm... surely the communications between BA and developer, which has go to go back and forth, is one area where a certain amount of meetings is actually helpful.

[@theaureliasys6362]

funny anecdote from a friend: her plushie unicorn was elected unanimously as scrum master by the entire team when they were forced to elect one. without hesitation. everybody knew it was the plushy. EXCEPT the one requiring them to elect a scrum master.

[@HealthyDev]

LOL!

[@drawnfunny]

Holy hell this is spot on. Out team is managed by the PO and she's not technically trained and doesn't have any software management experience. She can't even write ACs correctly. She'll write 'make parity' with another product's function. It's a total development dumpster fire. We're also having to keep a record of hours spent on each task. It's sad when management doesn't trust their employees and feel like they have to micro manage everything.

[@eiyukabe]

"We're also having to keep a record of hours spent on each task." Jeez. I would just half-ass a guess while looking for employment elsewhere.

[@xpusostomos]

Every time I've had to do that, you make up plausible shit, no way it is reality

[@tomo9908]

Making it a HARD REQUIREMENT that all PO/SM/PM's have extensive experience being a developer themselves would solve a lot of these issues in my experience. It's always the random person who rolled into software management, but who can't write a line of code, who comes up with all sorts of ridiculous crap, because they lack the required skills to do a good job. You'd think that not having a clue what 90% of the work entails would obviously mean that you cannot judge how well your team performs. But somehow these non-technical people keep landing these jobs, with their bullshit certificates and their relentless drive to sit in useless meetings all day.

[@57thorns]

Sorry, but just as doctors make the worst patients, programmers makes the worst scrum masters. They have some experience, they know what the system was like four years ago, and are now out of touch but "senior".

[@Gnight787]

Thank you! As a Scrum Master this really helps reenforce my good habits, and keep my eyes out for these pitfalls. NEVER treat points as hours lol! These are all considerations I make for my team. Thanks for this!

[@epicadventureturtle1363]

Two biggest ones I see all the time: 1) misunderstanding story points (mapping it to hours, using at as performance metric to compare teams etc.) 2) turning the daily into a status meeting. Combine the two and you get a setting where people are afraid to do less than x story points per day, which also turns the story point estimation into a nightmare.

[@waltermunozguaman7591]

i agree

[@zoricgames]

One of the first things I killed when I became the head agile coach at my organization was the idea that a Scrum Master had to constantly improve velocity. It's not a performance metric.

[@pencilcheck]

this is sooo accurate.

[@archi-mendel]

@@zoricgames we're most probably going to get rid of velocity at all and switch to non-numeric story estimation. Over time, we have realised that we're anyways thinking of the sprint as the number of small, medium and large items we take. In some teams we have agreements to not to take more than 1-2 large items to one sprint. And overall decision on what we take to sprint is just based on overall feeling that "this number of small, medium and large items looks fine". Velocity gets very artifical during holiday period, new members joining the team, etc. We have stopped using average velocity of recent sprints as a guidance several months ago - this just doesn't make a lot of sense to us anymore.

[@vonnikon]

A metric without unit is meaningless.