Why Does Scrum Make Programmers HATE Coding?

День тому

Every programmer seems to want to vomit the second the hear the word scrum. What is it about scrum that's made programmers hate coding so much, and how can you prevent this on your software development team?
In this episode, I share 7 reasons why programmers hate scrum, and how it makes our jobs nearly impossible on software projects where the scrum master, product owner (or product manager), and the rest of the software company use it to abuse programmers. These mostly get down to not understanding the scrum guide, and human nature!
In this first section of the video, I explain how management on scrum projects usually focus on speed and visible features to the point that it puts the quality of the product at risk. They treat story points like time. They resist investment in things like improved architecture, testing, deployment, and the other things needed to keep developers from quitting unless kept in check. And they fail to accept reality when bad user stories, missing acceptance criteria, and abuse of the burn down chart (and velocity metrics) turns scrum into a numbers game instead of about delivering a quality software product.
In the second section of the video, I share 7 practical tips for changes you can make on your software team to start loving scrum again! If programmers on your team hate scrum, drawing clear lines between what software developers and project managers, product managers, product owners, or scrum masters can and can't make decisions about is essential. But as programmers, we also need to be more diligent with how we follow scrum processes. We need to closely inspect the work and only move forward with 100% acceptance criteria. We can't make commitments to vague user stories. And we have to stop estimating just for programming and include time for all the things we know we need - QA, automated testing, automated deployment, infrastructure as code, software architecture - basically all the goodies that keep a project on track as it grows in complexity. This is how modern teams do continuous delivery and devops.
I hope this video gives you some good things to think about. Scrum is a complicated topic, but following everything exactly by the scrum guide is a slippery slope. To love scrum again, programmers need to work with management and the rest of the company to adapt processes to meet the way everyone needs to work together to deliver software. And that's different for every team!
#scrum #programming #coding
RELATED CONTENT
Daily Scrum Meeting: A Status Meeting in Disguise?
• Daily Scrum Meeting: A...
How Senior Programmers ACTUALLY Write Code
• How Senior Programmers...
Spot a Fake Agile Team in Under 7 Minutes!
• Spot A Fake Agile Team...
Can User Stories Make Software Projects Late?
• Can User Stories Make ...
Continuous Delivery: Are You Missing The Big Picture?
• Continuous Delivery: A...
Need help with your career? Book a free career consultation:
jaymeedwards.com/services/sof...
CHAPTER MARKERS
0:00 Introduction
0:36 7 Reasons Why Programmers Hate Scrum
0:58 #1 PO in Daily Stand-Up
1:36 #2 Overstepping Scrum Master
2:15 #3 Obsession With Features
3:38 #4 Story Points Treated As Time
4:42 #5 Refusal To Cancel Sprint
5:58 #6 No Acceptance Criteria
7:19 #7 Burn-Down Chart Used To Blame
7:54 7 Ways To Love Scrum Again
8:16 #1 Remove PO From Daily Stand-Up
9:00 #2 Put Scrum Master In Their Place
9:49 #3 Buffer Estimates For Code Quality
11:03 #4 Don't Commit To Multiple Sprints
12:04 #5 Keep The Burn-Down Chart With Developers
13:00 #6 100% Acceptance Criteria
13:52 #7 Deliver Features That Delight
15:16 Episode Groove
Fire flame icon in thumbnail courtesy www.freeiconspng.com/img/696
Download a free software development career guide from my home page:
jaymeedwards.com

КОМЕНТАРІ: 2 300

@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

@archi-mendel Рік тому

This simply wasn't Scrum. I can call bicycle a Tesla electric car and expect to be driven around the block by the AI, but this wouldn't happened obviously. I would suggest every developer who is struggling with Scrum to read official Scrum guide. The vast majority of those struggling developers would immediately understand that their management has no clue on what Scrum is.

@bioshazard Рік тому

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

@archi-mendel Рік тому

@@bioshazard yep. I think this is very important to properly understand the concept before making any conclusions about it. We could simply state that SOLID, DRY, KISS and other concepts are stupid as the majority of people who mention these concepts are actually doing opposite to what these concepts are promoting. I've seen quite a lot of organisations which were stating that they follow these principles and had spaghetti-type code which was barely maintainable and totally unreadable. Does this mean the concepts are stupid? No, this just means that not always people actually do what they say they do.

@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 4 місяці тому

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 3 місяці тому

I've seen dozens of bosses like that.

@evgenii.panaite 2 місяці тому

Absolutely agreed. Any clues how to deal with them?

@InconspicuousChap 2 місяці тому

@@evgenii.panaite 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 2 місяці тому

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

@lancelotthefallen763 6 днів тому

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 10 місяців тому

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 5 місяців тому

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 4 місяці тому

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 3 місяці тому

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 3 місяці тому

@@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.

@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. 😂

@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

@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.

@natalieeuley1734 4 місяці тому

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 3 місяці тому

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.

@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. )

@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 5 місяців тому

Does it pay off?

@TheHeavenArt 4 місяці тому

Same thing happen to me :/

@StewartWild 4 місяці тому

My story is the same.

@Meeffoc Місяць тому

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

@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 10 місяців тому

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 5 місяців тому

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 5 місяців тому

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 4 місяці тому

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 3 місяці тому

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.

@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…

@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.

@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 5 місяців тому

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 5 місяців тому

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.

@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 6 місяців тому

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

@HealthyDev 6 місяців тому

@@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

@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.

@DanStrohschein 3 місяці тому

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 3 місяці тому

I couldn't agree more!

@_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

@mangowu9106 Рік тому

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

@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.

@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 2 місяці тому

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

@retroand 2 місяці тому

@@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.

@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.

@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.

@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 11 місяців тому

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.

@8020drummer 4 місяці тому

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 2 місяці тому

this is veterans affairs IT contracting to a T

@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"

@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.

@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.

@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 4 місяці тому

Wow.

@FHi349 4 місяці тому

Damn!

@PbPomper 4 місяці тому

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.

@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 7 місяців тому

wow i m not alone

@BarrySlisk 5 місяців тому

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

@errrzarrr 4 місяці тому

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

@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

@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?

@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 4 місяці тому

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.

@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.

@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.

@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 4 місяці тому

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

@timlind3129 Рік тому

Many good points, except for the story point rant. The one constant on a project is the number of hours in a day. Any other SP metric is just an abstraction of time. If a sprint is 2 weeks, there's a set number of hours in those two weeks. You can play games with story points all you want, but 2 weeks is 2 weeks and what you'll find is that those that use some abstraction are always converting back to hours somewhere in the process anyway. Complexity and the like are very closely tide to LOE. SPs can be good for fooling management though.

@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.

@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.

@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.

@DarkGuardsman Рік тому

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 Рік тому

@@DarkGuardsman 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.

@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.

@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.

@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.

@Sweenus987 Рік тому

My worst SCRUM experience is being expected to give a completion timeframe for something I've never done before and had no real understanding of at the time, got a really rough version of what was requested in a decent timeframe but it was messy and needed a lot more work

@VortechBand Рік тому

Management doesn't usually care about how long something takes, as long as they have some time estimates they can present to their managers for the manager's performance review and possible raise. So just split up your unknown epic into smaller stories ("Learn framework X", "Do a PoC with framework X", "Design new feature Y"), and then divide those stories further down to tasks such as "Read framework X documentation", "Discover framework X best practices", etc. as separate cards/tickets with ballpark estimates. That's what your manager can work with, and gives you buy-in for exploratory efforts.

@Sweenus987 Рік тому

@@VortechBand Thanks for the advice. Tbf it was my first professional experience so it was rather confusing to be expected to come out with a number. That said, given the unknowns, I don't understand why discreet time valuesneed to be given. All it ever did was generate pressure and stress which tired me out and caused me to perform worse overall anyway :/ Love programming but I'll always be cautious of management.

@m1dway Рік тому

Been in the same situation too... Some managers are built for micromanaging

@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".

@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.

@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)

@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!

@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 5 місяців тому

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 4 місяці тому

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?

@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!

@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 Рік тому

@@scottpageusmc 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 Рік тому

@@scottpageusmc 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.

@prontopuntor Рік тому

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

@BenScarboro Рік тому

Now add in SAFe...

@jamesfaucher4588 Рік тому

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 6 місяців тому

"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 5 місяців тому

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

@MachineYearning Рік тому

This is very quickly becoming my favorite channel on UKposts. 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!

@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

@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.

@SoundFriendly Рік тому

Being a software developer sucks indeed because management is often extremely stupid.

@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 5 місяців тому

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 4 місяці тому

@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 4 місяці тому

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 4 місяці тому

@@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.

@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.

@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 ?

@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!

@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.

@jzsfvss Рік тому

Scrum just validates micromanagers, which is why they love it. Real programmers are creatives, not factory line workers, and one with a whip will refuse to see that. Freedom is the nest of creativity. You've gotta let the energy flow freely and interact organically, but many managers will never get it. They are too afraid to.

@archi-mendel Рік тому

You're not talking about Scrum, you're talking about "scrum".

@KireFireLiar 6 місяців тому

Well said. Death to Taylorism!

@MichaelLazarski 5 місяців тому

micromanagers will micro manage you in anyway. happens on waterfall projects or what every you want.

@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.

@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

@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.

@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 :).

@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.

@sasukesarutobi3862 Рік тому

Great points as always, and it's great to see you back! One thing I'd mention about good acceptance criteria is also making sure that they don't devolve into "programming by remote control"; as you said elsewhere, implementation details shouldn't come from anyone but developers themselves, so if product owners are putting them in the acceptance criteria, then the criteria aren't helping the development team to build the most appropriate solution for the system and business problems.

@austin_thorne Рік тому

Just discovered your channel and absolutely love it! I didn’t realize how many of the scrum rules I’d been breaking in the past.

@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.

@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?

@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.

@ghostofrecon1 Рік тому

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

@TJDeez Рік тому

This was great man. This really clarified and validated a lot of the things that I disliked about the project I'm on. I have to figure out how I could make even 1 of these changes, can't hurt to try

@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".

@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.

@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.

@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 5 місяців тому

A metric without unit is meaningless.

@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.

@kentbull Рік тому

This is such a well done video. I’ve been on teams that got it right and teams that dismally failed on each of these points. I can attest to the truth in this video.

@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!

@philguitfiddle Рік тому

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

@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

@GregSweats Рік тому

Love your content, right ideas, sustainability! 18 year Web Dev vet here....22 if we consider the small business sites I did in Jr. High School. BLEW MY MIND when I walked away for a few minutes, came back, heard amazingly well produced music, and assumed this skipped to my next queued up videos on learning Reaper for Audio Engineering (Podcast / Tutorial Videos). 🙏👏👏

@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.

@renegadeprime3871 Рік тому

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!!!

@jamessauve2419 5 місяців тому

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.

@AntonioRodriguezSilver Рік тому

What an interesting video! I used to be an engineer and moved on to Product as a Product Manager. We've never had a formal Product Owner, and maybe my experience as part of the engineering team has made the way we do it different? I still attend the daily stand-ups. I am the guy who has always insisted that story points should not be related to time, but even our devs relate it to time and go for "uhh, 1 story point is half a day." Ok guys, I'm trying to keep you on Scrum, but you do you guys. I also had a chuckle when you mentioned that each use case should be a separate story. I have user stories cancelled all the time when they represent separate use cases because the developers feel that they are not necessary because we already had a user story for the overall feature and they didn't want to manage documenting separate user stories for separate use cases. I feel developers themselves can be their worst enemies in falling into a frustrating Scrum trap.

@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

@ShivanS Рік тому

The guitar pieces intersperced throughout the video make it so peaceful. Thank you for this video :)

@thibbard Рік тому

Nice to see you posting regular content again. The guitar at the end is a nice added touch.

@antoinedelequeuche4458 6 місяців тому

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 6 місяців тому

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

@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!

@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.

@10Kview Рік тому

Nice guitar interludes. Great content and the chat conversations are amazing. You have a good YT community.

@VitorCastelo 2 місяці тому

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.