The Secret of Scrum Nobody Talks About

[@perfectionbox]

After 35 years, the two most productive, on-time, on-budget, error-free projects I worked on were the ones that didn't use Agile. Stressing people is the golden ticket to destroying productivity.

[@perfectionbox]

@Shawn No, not waterfall either. We did some upfront planning but did the rest as we went along, without sprints nor standups. Estimates were never taken literally. We simply trusted that each person knew what they were doing. We took bugs seriously because they were stains on our honor, and we celebrated the fixes and improvements. We refactored and rearchitected instead of worrying if it would set us back, because we knew technical debt was worse.

[@softwareminimalist]

@@perfectionbox So how was this not agile?

[@perfectionbox]

@@softwareminimalist It might have appeared semi-Agile to outsiders but a) nobody consciously planned to use Agile, and b) whatever Agile-ish ideas might have been in use, there was no management corruption of them e.g. scrums, standups, jira, etc. I guess the closest we came could be called "a gentleman's Kanban"

[@softwareminimalist]

@@perfectionbox A rose by any other name would a smell as sweet.

[@SpeedfreakUK]

@@perfectionbox sounds like your main advantage was that you just didn’t have to work with that many people and balance their priorities against yours.

[@bigneiltoo]

The standup meeting: a daily exercise in public shaming, boredom and having to justify your own existence.

[@stevemc81]

Don't forget zoning out until you hear your name with a question inflection, time to gamble ... It's the right response yes or no?

[@PieceChestnut]

The only way to improve a bad daily meeting looking your mentioning is to take the lead, get together with the team, and ask to everyone "what is our goal and how far from it are we? What need to happen to get there?". Get rid of the 3 questions format.

[@Uri18]

Speak to your scrum master about this. Let them know. And if a PM is showing up at the meeting and causing this dynamic, tell the scrum master to keep him away from the daily. The daily is for The Team, the people who code and test the product.

[@BillClinton228]

Yep, Scrum is actually whatever management wants it to be and in most companies that means whipping the peasants to work harder. I used to work for a company where I was the only developer and I had 6 managers including a project manager that was mostly ignored 80% of the time - so no documents were every written, no protocols were ever followed and there was never any clarity on what the product needed to deliver. People just walked into my office and asked for a feature and I had to build it yesterday.... when I brought this issue up with executives I was told "thats just how things work around here"... so I quit.

[@bigneiltoo]

@@BillClinton228 - The All Purpose Scrum response: "It still doesn't work, but I optimized it. So, it (doesn't work)... much faster".

[@crimsonalucard]

Just stumbled on this channel. This is really different from the developer stuff posted by young people all over youtube. Real seasoned advice just not as trendy with the music and visuals.

[@TDECali707]

I agree.

[@NPC-rq9tp]

Yea fuck hippies

[@johnyepthomi892]

I hate the intro music and shitty branding in most videos.

[@dima8833]

Awesome video! You are absolutely right! I think the reason why this problem is not common knowledge and not discussed at every Scrum meetup ever (it's the biggest problem there is for this framework) is that Scrum is not really Agile. It even says so in the documentation - Scrum only works in all it's entirety. Any change is not a "real Scrum". Huh? What happened to "Individuals and interactions over processes and tools"? It's not really good with "Responding to change over following a plan" either. For me, Scrum is an amazing framework to start the conversation and begin mental shift to truly Agile process - adapting to change and failing fast. It only works if there somebody driving this mentally. It's always a choice. Thank you again for your video, I was smiling and nodding pretty often - clear, simple, fast and on point. Awesome!

[@HealthyDev]

Thanks for your feedback, I’m glad to hear more people than just me are experiencing this. 👍

[@HealthyDev]

At 4:00 I misspoke - Scrum is 23 years old (as of this video). My enthusiasm got the best of me ;).

[@girlmadeofwires]

And now it's 25 years old at the time of me watching it, so I didn't raise an eyebrow at all

[@HealthyDev]

@@girlmadeofwires In the words of Dana Carvey as the Church Lady "How Conveeeeeenient!" 😉

[@LA-so4qz]

As a coach, I appreciate the thoughts you shared (though careful with user stories, they are actually XP framework, not Scrum and Scrum teams shouldn't be held to writing user stories if the tool doesn't work for them and help them produce value ;). You nailed it on the head when you said people are wrong. I've worked at several different companies since getting into the Agile career track that have used Scrum as another project management process to hold teams accountable to management and leadership, which is not the frameworks intent. A lot of companies operate in the cargo cult Agile (including a lot of coaches and scrum masters that don't really understand Agile). What it comes down to is a change in mindset and putting the customer first instead of focusing on the tools (examples being companies thinking because they use Jira that makes them Agile, or because they have a daily stand-up it makes them Agile but really is just another status update to make developers suffer or to say you have a cross functional team because you have both developers and testers but what's really happening is developers throwing work over the wall at the end of a sprint to testers). I could go on quite the rant...I find it disheartening that so many engineers have been put through the ringer when it comes to Agile or Scrum and get a bad taste in their mouth because of it. Because when properly implemented, Scrum can help empower teams to figure out the right processes and tools in place that help them produce the right value to their customers. But whether you are a manager, a stakeholder, a coach/scrum master, etc. you need to learn when to get out of the way of the team so they can get work done and get quick feedback from customers. Beating them over the head with essentially a rule book because so-and-so said we are agile isn't going to make things better - it's going to dishearten people and you miss the why behind Agile (not to mention not all companies should be Agile, it's often just a trendy thing to do). Again, great video and appreciate your perspective!

[@HealthyDev]

Thanks for sharing all that. I can’t find a single thing I disagree with. Exactly my experience.

[@dickdereus2507]

Totally agree - sometimes it just ridiculous how scrum gets evangelized in a company while the horrible results are in plain site. Same with agile by the way. Sometimes I'll ask an agile coach about the 4 'values' of the Agile Manifesto (people over process etc) and they will have NO clue what I'm talking about. The next candidate for great-ideas-to-be-hijacked-by-managers is the concept of DevOps (already is). 'We'll now just let the developers do all the Ops work as well - save a bundle of money'

[@HealthyDev]

Hey Dick, thanks for your comments. It’s definitely frustrating. The challenge for me has always been: “how do I help people who are supposed to know more about something, or are in a position of authority over me, to be open to the possibility that they have something to learn?” Ultimately it’s hard, and takes an incredible amount of patience and letting go. It’s a career long struggle for me, especially considering I and others I may be leading are subjected to whatever dangers arise from misapplied agile principles. If you haven’t seen it already, I wonder how you feel about the video I did on DevOps. I share your sentiment about it’s potential for abuse. I’m hoping as the industry continues to mature more people are able to help companies get the benefits of DevOps without buying the fake news about it out there. kzbin.info/www/bejne/fnTKYXR8rbt_j5I

[@Diogo7442]

I truly believe a scrum master should have experience in the field they are working in If they work in IT they should have knowledge and have worked as a dev 100%. Something I am noticing is that scrum is not being used right in a lot of companies.... I have seen people trying to use scrum and Agile but instead have misshapen it in such away that it becomes a Frankenstein version of waterfall.

[@bigneiltoo]

I'm in DevOps hell now. We used to have this guy called the System Administrator. They were the midpoint between Computer Science and Electrical Engineer. It was a different job and I would get a coffee and they would Plug-n-Pray and set jumpers and (imagine) I wasn't on the clock in some Scrum master book that puts all of that lost time on me.

[@flamehiro]

@@Diogo7442 100% they should be seasoned dev originally

[@monad_tcp]

at least with devops you get to play with the hardware of the things

[@flemme4580]

Well, if you look at the terminology used by Scrum you will see that it is intended to appeal to managers. "Sprint" is not a leisurely walk but you have to run. And of course the word Scrum itself is also very suggestive. Oh, and it needs a master. Scrum is not misunderstood - it is a (rather heavy) process which does not care whether the software is built in an agile way or not.

[@bz7901]

Why is it that developers' time is pointed and scrutinized, but never business analysts, pms, or anyone else?

[@cryptodeveloper]

This is my situation right now. I'm so fucking pissed off

[@HealthyDev]

Immature leadership think non-development activities can’t be estimated because they are input to developers, therefore developers have everything they need to estimate. Big disconnect and oversimplification.

[@cptbenjaminwillard]

Good video! Totally agree vwith your assessment. Small anecdote: at a previous company, people were hard to be convinced to put any structure into their work. They wanted to show up in the morning and then decide what to work on. After some small trials we eventually agreed to adopt only the feedback loop: every 2 weeks we organised a retrospective and built on that. It actually worked wonders. Some structure evolved from that and lo and behold, even planning emerged from those meetings.

[@kourosh234]

So true. The bottom line is: 1- find out what's wrong asap 2- adapt in addition: 3- do what you can asap (agility) 4- have fun creating software. 5- do not criticize. compliment 6- leave if you feel always stressed

[@HealthyDev]

Can’t disagree, all good tips!

[@ryanehrler]

Spot on. Like usual. Biggest problem I've had is management either not understanding or not willing to learn the basic spirit and value of scrum. They think they are smarter than everyone else and say things like, "We have our own flavor of scrum" or "We kinda do scrum". Which usually really means "We don't want to hire Business Analysts or Scrum Masters". They also usually don't have any real retrospective, no continuous delivery, and no customer feedback. That company burned so much money, and unfortunately they didn't even know.

[@HealthyDev]

Yeah I’ve kind of given up on expecting managers to figure this out on their own. I guess I decided it’s up to me to teach them what’s different about software development. Thanks for your feedback! I can definitely relate.

[@mildsauce5019]

This is gutsy and feels rather cathartic. Thank you for doing these sets of videos!

[@perfectionbox]

Hey, let's run a marathon by sprinting over and over. Yeah, that'll work. 🙄

[@Uri18]

Too literal. We call it a sprint. But it's just a timebox

[@perfectionbox]

Uriel A. Fernandez Agile says "people over processes" but the average shop rams sprints, standups, and JIRA down everyone's throats and God help you if you try to do things even a tiny bit differently

[@kaworunagisa4009]

Weeellll... I worked in a company with 2 month long 6 day work week "sprints". Needless to say, I quit after 8 months.

[@TheSilverGlow]

It works fantastically...perhaps you are doing it wrong?

[@StarryNightSky587]

so lucky to always have worked in teams that actually get the freedom to implement their own flavor of scrum, appropriate for the team and product dont forget, it is a framework ;)

[@HealthyDev]

That is truly being agile - congratulations!! 🎉

[@stevengregor9544]

Great video Jayme. Makes me think of a few patterns I often see consulting on projects: * clients who think because they're using Jira and have a daily stand up meeting, they are "doing Agile" * projects that after many months of development effort, don't seem to have an immediate audience that actually care about the deliverable, and prove difficult to gather feedback when you expected your client to get excited about their new platform/product

[@HealthyDev]

Steven Gregor thanks for your feedback! That makes a lot of sense. The intense scrutiny during design and then “set it and forget it” attitude during execution just doesn’t seem to work well in our industry. I’m glad you liked the video!!

[@lukecapizano3832]

It seems a little contradictory to assume that "doing agile" requires a formal process. :) As long as there is room for feedback and adaptation in the development cycle, does it really matter?

[@HealthyDev]

I totally agree! Putting these ideas out there is a bit of a balancing act between practical advice and being flexible. The best teams I've been on find the "process" that's best for them (it's all about profit and value right?). I thought this video might help the many people out there still working at companies that have some sort of process (scrum being the most popular) to think about whether they are adapting. Appreciate your feedback!

[@stevengregor9544]

That is basically the point I was making... a fair amount of teams out there think they are being Agile simply because they perform a few of the rituals, when infact the project is still being managed as waterfall by statically marching to some previously agreed upon deliverables. A misalignment I try to raise whenever it makes sense ( :

[@HealthyDev]

Steven Gregor got you. Good for you for having the courage to bring it up sometimes. I struggle too with how hard to push a client to think about it. Sometimes they are open, sometimes it’s like talking to a brick wall! I hope by making these and future videos I can help you and others have some content to share with clients when it’s the right situation. Sometimes hearing more than one voice in agreement (even if the other voice is just me in a video lol) is the “social proof” needed to get them thinking outside the box!

[@dustinking2965]

Scrum suddenly being imposed from above seems to be a sign that things are about to go south. I think it may be suitable for a small number of situations where the work units are very small and predictable, but when working on complex software systems it just seems to be a pain.

[@John_Fx]

Very astute observations. Another unspoken reason management likes scrum is that it at least simulates the ability to quantify software development projects in a metrics driven way.

[@HealthyDev]

Can’t disagree!

[@PeterGfader]

RE: METRICS. >> Scrum simulates the ability to quantify software development projects in a metrics driven way I agree. And therefore there are no metrics in the Scrum Guide. You as a Product Owner need to find the metrics that are important in your organisation. Examples: Bug Trends, Used Features, Time Saved by people, Earnings via Product,... I think productivity of DevTeams is impossible to measure. Don't even try. Yes, Velocity is not productivity.

[@ornicarornicar9070]

Story points are not days of work, but you need to do 10 every two weeks...

[@errrzarrr]

- Is about flexibility and improvement. Not speed. Ah! There's a reason they have and like these words so much: sprint and velocity. In my experience (real life experience) Agile isn't flexible at all. They won't trade or adapt their meetings at all. The developers team have to adapt around it, not the other way around

[@picleus]

My "Scrum" project has been going on for years without releasing to anyone outside of a couple business stakeholders who are barely interested in it. Our managers are on our case now about how the team is not agile enough and we're basically doing waterfall... but instead of cutting new scope or focusing on getting to a deployable state, their number one concern is getting more accurate (hourly) time estimates. I'm too young to have done waterfall, but it sure seems appealing to be able to commit to either a deadline or a list of features.

[@randomizednamme]

Seems very accurate. I started in the industry almost a year ago and was definitely taken advantage of in this respect. I would compromise all the time to hit sprint goals or sit in an hour retro on why we didn’t finish everything in the sprint as if it were that simple (maybe because you drove us to include too much? Another topic). It was really discouraging because there were times where I felt we wrote good software but all that mattered was a good looking burn down chart. It drove me to just not caring anymore.

[@HealthyDev]

Sorry to hear ;( I like the phrase “success theatre” to describe this. Focus on making everything look good regardless of the truth. It takes courage and subtlety to fight against it, but I’ve helped companies stop doing it sometimes. But it’s definitely not easy. I hope your future teams are better!!

[@DryPsylocibin]

@@HealthyDev "Success theatre". That is perfect. A very apt term to have in my vocabulary. I've seen situations where this concept was at play on multiple levels. The upper management would be preoccupied with putting up a good facade for the customers. The middle management with making everything seem on track and under control towards their superiors. And the developers who had become too fearful for being upfront about difficulties and complexity spiraling out of control would maintain that a sprint could be successfully finished three quarters of the way in when in reality it would take a miracle. Eventually no-one came out a winner.

[@HealthyDev]

@@DryPsylocibin thanks lol, full transparency I heard that term from someone else - I wish I could remember who at this point. The moment I heard it I was like "aha! That's exactly what I've been experiencing!" :)

[@Dasein23]

If you are “being driven” to put work in a sprint, you are not doing scrum. The dev team chooses how much work to pull into a sprint. The scrum guide is EXPLICITLY clear on this.

[@donbriggs9128]

@@Dasein23 Another important point is, who guestimates the tasks. All developers work at different rates so they should also be able to adjust the time to complete based on their own experience level, which in turn creates a more realistic burn down. Slightly off topic, but, I worked at a place a couple of years ago where the CTO would timebox the complete project (because of promises he had made) but we found that there was no way on earth it would ever happen. A number of us left the company in the end because of the constant favouritism and bullying.

[@Dowlphin]

Is "scrumbag" a word heard among software devs?

[@psaunder1975]

It is now! :-D

[@thx5001]

I found your videos a week ago. They are great. So here's the problem: The business cannot unlearn waterfall, i.e. get all the requirements documented (and locked down!), get all the designs done (and locked down!), get all the requirements turned into stories (1:1), estimated (and locked down!)..."ok now YOU developers can start building the software, that WE'VE designed, in sprints, then it will go to the test team, etc.". Sprint Reviews are about checking overall progress, that is checked weekly anyway. So where do I, the Scrum Master, go from here?

[@luafalcao2984]

Martin Fowler, the Great Father, said once ""However, like any popular technique, agile software development has suffered from semantic diffusion, so much of what we see under the name of agile doesn't bear much resemblance to what the early pioneers were doing. So I think it's important to revisit the essential elements of agile thinking."

[@HealthyDev]

I don't always agree with Fowler but I do more often than not. This is one of those cases where I do! Great quote. Thanks for sharing!!

[@andersbodin1551]

The secret to not get burned out by estimates and burn down charts is to emotionally check out, and no longer give a fuck about the success of your projects. Just focus on your free-time, and family life.

[@caroldanvers265]

Our team has just started doing scrum and Agile and I immediately knew this was to put pressure on their workers. Agile is really stressing me out because some of my validations is always breaking. Sometimes I'm worried about how Agile is a way to micro manage their employees to squeeze the most work out of them and if we slow down then we may find ourselves out of work. I feel like I'm hating scrum and Agile everyday.

[@commentersname8576]

You are spot on. it is a way to terrorize those they can terrorize.

[@JohnLewis-old]

This is awesome content and I love that you articulate what a lot of management lost on the road to Agile.

[@HealthyDev]

Thanks John, appreciate it! 🙌

[@grueti21]

From 2006 to 2010 i was in an apprenticeship for softwaredevelopment. I never heard of scrum until 3 years ago.

[@bigneiltoo]

I've found that the new thing is: companies want to get new employees into Agile as soon as possible - even though their computer is not set up yet. So you have one person putting in an IT request to get your VPN working while another person is humping your leg every day and saying "are you done yet? Are you done yet?" Then, the very first day you can possibly actually start to work, you're so late that it's a crisis and you're on probation with some bean counter. It used to be the learning curve and honeymoon phase. Now, it's militant, rigid Agile, which amounts to a form of hazing new employees.

[@mcscubin8935]

I'd like to know where this happens so I can avoid it.

[@imrannazir6931]

I'm going through this right now. Second week in, learning the code myself, learning what user stories are, coming up with solutions in an unfamiliar repo and they want to start the sprint in a few days time. I'm the only developer in my area, something I only discovered on the day I started. I'm considering looking elsewhere.

[@bigneiltoo]

@@imrannazir6931 - The game goes like this: your coworkers will interchange intrinsic knowledge (like you were asked on your interview) with insider knowledge (like the network path they chose). Then they will harp on your as much as possible so you feel like you've made a bunch of stupid mistakes when all you really did was ask what network path they chose. It's like companies want to reverse engineer everyone into crisis mode by design.

[@oleksandrhr3949]

Millions of thanks for this video!

[@HealthyDev]

You’re very welcome. Thanks for watching!

[@tonysmith7836]

Spot on!

[@deandalby1]

I have been saying this for years, I have had a few good scrum projects but most of them the business use it as leverage to squeeze whatever they want in a sprint... even if it is a day before the sprint is due to be released. Very often the mechanisms in scrum designed to protect the developer are ignored to have more throughput.

[@jeskedolmans5583]

As a new scrum master, I've been thinking of getting some scrum-related quotes up on the walls for everyone to see (new quote every week?). This one is going up there!

[@bjbegui]

Hit the nail on the head...

[@TimRubel]

I understand this is a 2-year-old video however, I need to say you nailed it.

[@HealthyDev]

Thanks for the feedback. Glad you can relate!

[@rmcgraw7943]

Most companies use SCRUM to establish a baseline velocity for each developer so they can pressure them to continue to constantly make their highest velocity each sprint, and it’s very obvious that is what they are doing. It’s supposed to be about communication and collaboration to get ideas and requirements nailed down correctly, knowing they will be different from each point of view; however, that is not how most companies use it. Usually the product owner hardly ever shows up, in my experience, and he’s supposed to be KEY to the entire process; sadly, often the team manager ends up doing that job, and that is completely opposite of empowering development teams (a key aspect of SCRUM teams). Companies use it to measure project progress in a quantitative way (it’s all numbers), which is what waterfall never provided. In waterfall, you rarely saw anything until the entire product was done, so it’s either success or failure at the end, with little, if any, chance to modified what “you thought” the product was meant to be. SCRUM was not created to provide a way to monitor team members; however, that is one of the benefits (iterative reviews via demos after each sprint), but that IS NOT what it was made for.

[@Dasein23]

Well said. I place most of the blame for this sad state of affairs on Mike Cohan’s influential and highly destructive book, “Agile Estimating and Planning”.

[@sheriffderek]

I like your points. I think a lot of the problems can be alleviated by product designers and content strategies - and all the more specific roles besides general developers / instead of using to tight of a scrum model. If people are working in a truly agile process - you don't need all this structure - and it's just built into how you do your job. I think standup is helpful / but a lot of the other parts just feel like unrealistic guesses for middle management and the CMO to pretend they are working.

[@HealthyDev]

Thanks for the feedback. Yeah I agree on the “you don’t need all this process” to a point. There are definitely many situations where a process isn’t buying the team anything but they just keep doing it because the scrum guide, a conference speaker, or some article says it’s necessary. I guess the main point I was going for here was in the spirit of continuous improvement, knowing we’ll never be perfect, the rhythm of evaluating how things are going with sprints can be helpful with the right team and situation - or a tool of oppression and abuse in others!

[@ian1352]

In my experience waterfall also sought feedback and adaptation. On the other hand change can become a managerial obsession when a company adopts agile or scrum practices. Teams and individuals get pressured to find something, anything, to change every couple of weeks. Teams who have worked together for many years and honed the way they work over that time quickly become angry and frustrated at this constant outside pressure which invariably results in direct interference if they don't make sure they're seen to toe the line by pretending they're finding things to change.

[@HealthyDev]

Good points to bring up. I agree and have seen the same dysfunction when continuous improvement is seen as a requirement instead of a goal to pursue when real opportunity arises. I guess in this video I was speaking more to teams that have a harder time being able to embrace change. But that doesn’t make your point any less relevant. Thank you!

[@JamesWilsonBluespark]

Great stroke of luck that only days after I finally decided to unsub from the drivel from Tech Lead, I stumble across such wholesome goodness like Healthy Software Developer. Thanks @Jayme for what you're doing here. Wishing you the best on your way towards growing your subscriber base! Cheers.

[@HealthyDev]

You're welcome James, welcome to the channel. 👍

[@josda1000]

You had this absolutely right. I just wouldve made that line "It's not about getting work done, it's about getting work right." But yes, solid video. I work in an environment where we work wayyyyy too much, even on weekends to get a sprint 100%. We should just be planning properly instead of "we have all this we got to get done, plus what we didnt get done last sprint" we as a team don't have a say as to what we take into a sprint.

[@ThePandafriend]

How can it be scrum if the team doesn't do the planning?

[@josda1000]

@@ThePandafriend exactly.

[@pixelmasque]

great videos!

[@hstanekovic]

One of the most important things with the Agile programming is that you work in iterations that have fixed time length but do not have fixed scope. Thus, you must prioritize work and do only what you can reasonably do in the fixed amount of time. Then, you show it to the client and ideally your client knows that other things will be finished in the next iterations, according to priorities that were agreed together. If you just fix the time intervals and do not loose scope of iterations then ... you are screwed :) For me, this is the essence of Agile methodologies.

[@HealthyDev]

Great point. Fixed timeline + fixed scope = fake agile. Unfortunately it’s all too common these days...

[@DobesVandermeer]

Imagine that, "agile" development is about agility...

[@chordsbyriku]

I find that many projects think they are using scrum when adding daily standups and sprints to a waterfall project. In my experience they fail. The best project I have worked on so far used scrum with almost all the steps sprint planning, standups, retrospectives and so on. Did we deliver all of the features we planned in the beginning. No of course not, we were agile. We did however deliver all the necessary features on time and budget and everybody was happy.

[@HealthyDev]

Now that you know the secret of Scrum, how are you helping others stop being abused so they can adapt? Leave me your thoughts below! Skip to points in the video: 0:00 Introduction 1:26 Scrum Rituals from a Developer Perspective 1:34 Ritual #1: The Daily Standup Meeting 1:45 Ritual #2: User Stories 1:54 Ritual #3: Estimation 2:10 Ritual #4: The Backlog 2:22 Ritual #5: The Burn-Down Chart 2:39 Why Bother With Using Scrum? 2:43 Project Need #1: Have a Vision 3:04 Project Need #2: Gather Requirements 3:11 Project Need #3: Design & Build 3:24 Project Need #4: Testing 3:38 Project Need #5: Releasing 3:52 What's The Missing From Most Scrum Projects? 4:04 What's The Value of Proper Scrum? 6:08 Why Is Your Team Keeping The Secret?

[@jacekjacenty]

You are expressing some radical thoughts here.

[@HealthyDev]

The only way I can see helping others be more healthy is by getting them to talk about things like this. I know not everyone will agree, but hopefully it sparks more debate around using Scrum as a tool for control! As always, thank you for your feedback Jacek!

[@Martennl]

I will use your thoughts (and perhaps share the video) during a course on project management on a technical university. Thanks Jayme!

[@stevemc81]

I think the problem is empowerment, often the response at a retro is ... That's how the management or the architects told us we have to do it, and the Dev teams have no means to push back at all

[@HealthyDev]

@@stevemc81 isn't it frustrating how the whole reason devs push back is to help the project be successful? I've started using positioning statements at the beginning of any time I do this now because otherwise the negative stereotypes for developers in our industry seem to have planted this seed "when a developer disagrees, they are being difficult or incompetent". It's a real problem for sure...

[@TheWiseRabbit]

This is a good video. I like.

[@mehdi5738]

I think scrum is just a fashion which is used by managers who have no idea of software development. I think a team can do good software without scrum and another team can do bad software with scrum. It actually depends on the people involved, the structure and the motivation and also the freedom granted to developers to make their own decisions, and not treating them like children unable to organise their work

[@HealthyDev]

Couldn't agree more with the statement that it depends on the people involved. I still think scrum is a great process when used by the dev team. There used to be a suggestion that developers would rotate who was the scrum master. I think it worked great back then. Once separate managers, who've never written code got involved, thinks kind of went downhill. :(

[@dkktse]

I do daily standup, and what I found with new teams is that they would just look at it as a daily status meeting, reporting to me. As mentioned in the video, the daily standup is most useful to bring any issues, questions, wrong direction to the forefront so we can get on the same page with the issue and find solutions quickly. In essence, the team talk to each other at the scrum, not report to me In the event the requirement, design, solution is well thought through, "waterfall anyone"? if the team member says I have no issue, then you leave them alone to keep working, and the standup is really quick As we all know one of the pitfall of waterfall is you really cannot think of everything up front, and you need to know when you should stop thinking and documenting and start developing to flush out the "real issues" In summary, scrum is not the place for status reporting, or policing the team, but a forum for the team to be open and honest about issues, questions, gaps in the design, etc.

[@tetraquark2402]

Turns development into a sweat shop and drains the fun of it

[@axelvanhooren6325]

Thanks! I am not an Agile fan, but I liked the video coz it contains truth (no BS). However, stakeholders are often wrong because identifying, udnerstanding information problems and conceiving information solutions is not the role of the business. They have to do business, not informatics. The discipline of Analysis (SA, BA, FA, PA, ...) has been invented exactly to identify information opportunities, to study how information is used and can be used in environments, how to solve these issues ... This discipline is not about to find out what people want (and think they need), but what is necessary. But this professional discipline has largely been underestimated, undervalued and badly applied. It is so easy to be the bridge and to do what the business wants.. Now, we pay the price.

[@HealthyDev]

Can’t say I disagree. Thanks for sharing. I agree, unfortunately there are many businesses that seem happy to have people less qualified to do research and make decisions be the ones who do.

[@jimeiden2360]

Doing traditional software development with a daily scrum, doesn’t make it agile.

[@Dasein23]

Very very true. Pretty much all of the scrum “horror stories” I see here in the comments are descriptions of classic Waterfall / command and control environments, not scrum.

[@errrzarrr]

Sounds like a cult to me. It's so perfect and good and pristine, is just people that are so dumb to get it well

[@jimeiden2360]

@@errrzarrr Leave it to Corp America to take a good a idea and mold into something to be used as a bludgeon thinking it is a panacea. Until the next fad comes along. I remember the days of Reengineering was the fad. Companies used that as an excuse for layoffs.

[@Lektuerekurs]

@@jimeiden2360 Greetings from across the pond -> can you imagine us Germans? "Ze daily hass to be exacktly 15 minutes long. Not fourteen, not sixxteen. Fiffteen minutes, you understand?!"

[@mikewright2858]

Scrum is for micromanagement of poorly-performing, remote teams.

[@donbriggs9128]

If you have a poorly performing remote team, that is what needs to be addressed. Fully remote teams are hard enough to manage at the best of times, but if the team performs badly, maybe they either need help and training (which means they should not be remote) or they are just useless and should be let go or promoted out of harms way.

[@donbriggs9128]

@a 2345193 Then either you do not understand it, or you have knowledge of companies who abuse it.

[@donbriggs9128]

@a 2345193 Obviously you are an angry person who did not fully understand what I said. What do I know about it? I am a Scrum master and have been working within Scrum teams for 13 years. Like I said *"or you have knowledge of companies who abuse it"* PS. Gay means Happy.

[@donbriggs9128]

@a 2345193 I do.

[@donbriggs9128]

@a 2345193 You are correct, I have no idea who you are, but that does not mean I am wrong. You have just admitted to being angry. You have just admitted to having knowledge of companies who abuse it. And that is all I said. I'm sorry if scrum has not worked for you, but you would be hard pushed to find a company these days who do not use it at all.

[@xmeda]

Secret is that Agile aim is to have equivallent teams where one team can replace other team. The key is to have overview for leaders. They want to know who spent what time on what task, so they can compare which team delivers, which not, which is cheap, which is expensive. And remember, that it is not only software development tool. Many companies are using agile while they are not working software at all.

[@HealthyDev]

Thanks for your insights, I think unfortunately much of what you say is true. Too many companies are setup to make leaders feel in control, at the expense of really making money by letting more people influence products.

[@redhotbits]

@@HealthyDev yes scrum is about controlling developers and be able to exchange them easily as they go away

[@cryptodeveloper]

whats the point of agile when there's no software development being done in the company?

[@xmeda]

@@cryptodeveloper Ask Honeywell leaders from India :))) They forced HW development teams to use it. It makes little sense with 3 month PI cycles and 2-3 week sprints, but the do not care at all.

[@cryptodeveloper]

@@xmeda I can only imagine the stupidity. I'm working at a well known software company and we have a 3 month PI as well. It's used as a tool by middle and upper management to abuse us developers.

[@kaiyafireforge6175]

I really appreciate this reminder. I’m curious what your thoughts are (I’ll scroll through your videos in case you’ve answered this already) regarding estimating. I find that the developers I work with refuse to guess-timate and never commit to a baselined target end date (even knowing that company culture accepts that the date could change with justification).

[@iambrandon7280]

I think SCRUM has become an effective micromanaging tool.

[@HealthyDev]

At some companies, I totally agree. The bummer is it’s a great process with the right team and mindset. Unfortunately I run across more people with a bad experience with it than good these days. I make these videos partially to try and help people see why it is a problem when used to micromanage, as you say - and do my best to share the good things about it (though I can get frustrated at times!). Thanks for the feedback!

[@cryptodeveloper]

@@HealthyDev "it’s a great process with the right team and mindset." This is what every scrum enthusiast tells me. I have 9 years of industry experience and the only time I have seen Agile working perfectly was when Product and Business Analysts were highly skilled and developers had full control over the dev environment to do whatever they wanted. So the developers always had a clear picture of the requirements and also had full control on what needed to be done.

[@HealthyDev]

@@cryptodeveloper you just described a successful project with the right team and mindset! Congratulations - some people *never* experience this over their career!

[@carlosalas2935]

Amazing video, thanks! 😄

[@HealthyDev]

Glad it helped, thank you!

[@delulu6969]

I'm learning about programming through paid online courses and books. I've read Jeff Sutherland's 'Scrum.' It sounds good and humane. He stated that people are bad at estimation just like you've said. He also suggested a 3-6 months period to get to know the real capacity of the team members before coming to an estimate. Again, just like you've said. I'm not a developer by trade but getting to know the industry's real culture makes me think should I make the career change?

[@HealthyDev]

Only you can answer that. If you like overcoming interesting problems on a team, it’s a very rewarding career. But if you like to work alone, or want a straightforward process for working that’s repeatable and predictable software development definitely isn’t it! Take my opinion with a grain of salt, as always ☺️

[@guntcheck]

People being bad at estimation is another scrum myth. Qualified engineers are actually quite good at it. The problem is that the field is full of pseudo engineers.

[@BittermanAndy]

@@guntcheck How do you figure that qualified engineers are good at estimating? I see two cases for estimating: (1) Done this before. Can give you what we did last time. Time estimate: zero. (2) Never done this before. Going to be completely new. Could be any number of surprises or idiosyncrasies or unexpected events. Time estimate: no idea, beyond the most vague "days/weeks/months" outline. In case (2), meaningful estimates seem to me (and this has remained true throughout my 18 year career) to be next to impossible to provide. And I am definitely not a "pseudo engineer", that just sounds like something to say to sound elitist.

[@guntcheck]

@@BittermanAndy The sum total empirical evidence proving that qualified engineers are bad at estimation(estimation is actually a science): *crickets*

[@BittermanAndy]

No, sum total evidence is 50+ years of software projects being universally badly estimated (of which I have 19 years of direct observation of my own). The onus is rather on you to prove it can be done, since it's your claim and it runs counter to people's experience. The good news is, if you can do it you'll revolutionise the industry. The bad news is, it's easier for you to make a shitty "crickets" dig while completely ignoring the points I'd made, so I guess the industry is safe from being revolutionised for the time being. I mean have you even READ Mythical Man Month or No Silver Bullet? Try to make sure you're up to date with 25+-year-old literature before making wild claims unsupported by evidence.

[@lambmaster]

Your videos are having the opposite effect on me! Whenever I watch them, I get a little more depressed...

[@HealthyDev]

Doh! Sorry I only expose the problems so we can find better ways to cope with them by hopefully dealing with reality. I don’t mean to sound negative but yes I’ve had that effect on some people. Hang in there!!

[@PaliVCiernom]

Another falacy of scrum, is the idea of retrospective meetings. It assumes that people are capable of discussing their own shortcomings, or what their colleagues are doing wrong. And while many people are capable of doing that, so far I have never seen team where ALL people were truly ok with this.

[@krccmsitp2884]

Retrospectives shouldn't be about the individuals at all, it shouldn't be a blame game. The goal is to improve your process, your way of working as a team.

[@towhee7472]

My manager is awesome, we use scrum and it works just fine! No pressure games, no bullshit.

[@MrEdot]

yeah, totally agree. it is being abused by a lot of people. in my experience, mostly people in management talks a lot. they just keep talking all the day, and giving some silly solution like, if its gonna rain, you should prepare an umbrella. it looks like no one knows that we should prepare an umbrella, when its gonna rain. they wont jump to the real problem and solve it. no, they cant. and yeah, they will do everything to make you work overtime. at the end, top performers will leave the team.

[@TheSilverGlow]

I love agile-scrum. In my 45 years of development, I know no better way. Those who criticize scrum are not using it correctly. Scrum, when used correctly, is FANTASTIC for developers, product owners, QA, documentors, architects, everyone...often, those who hate scrum really hate that they cannot "hide" behind disheaveled, disarrayed projects any more...scrum, when done right makes everyone accountable, gives every one a voice. On the flip side, what I hate about it sometimes, is when all team voices are given the same weight about topics they know little or nothing of, or have never worked in. For example, I've seen QA people given the same decision making weight over architecture, coding, etc...and to be fair, I've seen developers lord it over QA processes. I think scrum works best when there is a "separation of concerns" mentality when deciding things as a group. I think more weight should be given to QA for QA topics, developers for developer topics...of course everyone has an opinion, a vote, but scrum teams must be very careful how much weight is given to each vote for a given situation.

[@GaticusHax]

I'm not sure I'd call it a secret. I think managers get that it's an iterative process. The big issue I have found is that the scrum/agile process is usually implemented badly, as some hybrid of waterfall, mainly because budgets and contracts have to be decided up front. Managers and sales don't understand how to work with iterative estimates or burndown charts and they want to micromanage. I believe the real secret of scrum that most developers don't seem to pay attention to, is scrumming the scrum. Scrum/agile is not supposed to be a rigid methodology like waterfall. It is meant to be flexible and adaptable for your project needs, so it is wise to do a post-mortem at the end of every sprint and adapt the project methodology to address performance and quality.

[@HealthyDev]

I couldn't agree more. You obviously have experienced a lot of the things I have.

[@stevemc81]

Those three questions, I presume are the ones relating to the spring goal ... In over ten years of two week sprints at numerous organizations, I think we've had a sprint goal maybe 6 times ... And when you do ask, well the goal is to do all these stories!

[@ian1352]

Honestly the goal is a bizarre concept. Every team I've ever worked with has tried to have a sprint goal and eventually stopped bothering, because it has never served any purpose other than ticking a box. Maybe for less experienced people it serves some purpose?

[@wealcome_company]

Great video! I had the same feeling so I’m sharing it ;)

[@HealthyDev]

Glad you enjoyed it, thanks. 🙏

[@SimGunther]

The only constants are change and the team's plan in a system that's all about change

[@geelee1977]

It is important to remember, that software engineering is an applied SCIENCE. We should care about, and follow, the science. There is no empirical evidence to support the claims made by Scrum "supporters". Only confirmation bias, and anecdotes. *This is the REAL secret of Scrum that nobody talks about* The number one way to deliver on time, with good quality, is experienced and skilled software engineers. No amount of process will compensate for this. This is inconvenient for companies. It puts power into the hands of their workers. Experienced and skilled software engineers, cost more. Agile is merely a management strategy, to remove the power and get by with marginal engineers.

[@dsinghr]

Love waterfall

[@HealthyDev]

🙃🤣

[@pero777100]

Software developer(s) should be confident enough to offer and deliver high quality project or software product to the customer or end user. Developers should use they prior experience and knowledge to predict what customer would like to have, what would not like to have, what should not be implemented maybe because of laws or safety issues (even though customer requires it), what must be implemented again maybe because of laws, safety (even though customer doesn't requires it) ... etc. It is better to say to the customer: "Can you give us 1/2/4/20/40... (depending on project complexity, customer type, developers knowledge and experience... etc) weeks and then we can provide you initial offer."

[@RA-eg8tw]

Hey, just a question I had in my mind. Could someone with a criminal record get into consultancy and to which extent would it affect them in this career path?

[@HealthyDev]

I don’t think anyone can answer that question with any degree of confidence. It depends completely on the nature of the crime and the preconceptions someone considering you has about your ethics and that particular crime.

[@RA-eg8tw]

@@HealthyDev But in your experience, have u ever had to worked with or for vulnerable people regularly to which having a criminal record would have prevented you from doing so.

[@HealthyDev]

@@RA-eg8tw I'm not sure I understand what you mean by vulnerable people.

[@RA-eg8tw]

​@@HealthyDev I meant that having a criminal records would forbid you from working in fields that worked with children.

[@HealthyDev]

@@RA-eg8tw ah okay. I'm really not qualified to answer that, I'm sorry.

[@youngthinker1]

The funniest responses come when I suggest archiving, managing, and tracking customer's requirements. Something along the lines of, sign this, so we can build an application to meet these agreed on parameters, and where the application will go in the future. Can be changed of course, but just something written down. Some reason, this causes everyone to run for the hills and start yelling at me.

[@HealthyDev]

I've been there... Yeah unfortunately this situation is getting more common. A company wants the team to hit deadlines, but doesn't want to do the work it takes to nail down requirements. I talked about this in another video on the channel you may relate to, "Can User Stories Make Software Projects Late?": kzbin.info/www/bejne/hJLZnYOll82dbaM

[@ian1352]

We started doing that after running into a customer that insisted we had not built what they requested. We had, exactly, but had no proof.

[@djfouse]

I think it comes down to education of the organization, and initially coaching from a Scrum coach until your Scrum Master is able to coach and mentor the team. The three pillars of Scrum are transparency, inspection, and adaptation. Scrum provides opportunity to inspect and adapt. The team has to remember that and to take advantage of it. This means the team should be using the Sprint Reviews to get feedback from the stakeholders, and Sprint Retrospectives for the team to inspect and adapt to improve the relationships of the team and ability to release business value by way of software. As the Scrum Guide states Scrum is difficult to master. Teams should be constantly reviewing the Scrum Guide, and at a minimum is the team executing the roles, events, and artifacts of Scrum and how well they are doing it by way of Sprint Retrospectives. Finally, the big questions... is the organization empowering the teams, and is leadership supporting the teams by practicing Scrum itself so that the teams can optimize value without distractions?

[@HealthyDev]

Yes that’s how it should all go by the book - no dispute there. This video is more about the current abuses - and how most companies are missing the point altogether. 😕

[@markw.schumann297]

OMG yes: "People Are Wrong." 💯🎯

[@jimmiller9330]

Imagine having a contractor build your new house using Agile. Where’s the blueprint? Oh, halfway through laying the plumbing and pouring the concrete, you want to change the location of a toilet. Oh, let’s just adapt.

[@HealthyDev]

Exactly. Software has properties of construction completely different than physical goods.

[@guntcheck]

There isn't a shred of data to support the claims of scrum. Actually the data points at scrum being a flawed process. Software engineering, is the same as all engineering, you need to design up front if you don't want a crap product. Scrum doesn't delete established engineering principals.

[@HealthyDev]

@@guntcheck I understand you're frustrated with scrum, but it serves a valuable purpose. We can't afford to plan and design products up front anymore - it's too expensive, and by the time the product is delivered it isn't competitive. The market pressures are too strong. Here's another video to give you some more to chew on (and disagree with possibly, which is fine) with respect to this. "Spot a Fake Agile Team in Under 7 Minutes!": kzbin.info/www/bejne/fmeqlX5jmaibqrs

[@guntcheck]

@@HealthyDev I never said I was frustrated with SCRUM. You said that, and you keep saying that. Classic red herring. A strawman you can win. If you were well versed with the costs of poor quality, or with real software engineering, you'd know that you can't afford not to design up front. Say it with me, there is no substitute for good engineering practices. I said that there is no empirical evidence that SCRUM works, and there isn't. All software of consequence, AI on missile guidance systems, software in MRI machines, you will NOT see SCRUM used. You'll see it designed all up front, the way all engineering in all other disciplines is done. You clearly aren't a real software engineer that has worked on meaty projects. Scrum is used for low skilled engineers, called developers , on software of little consequence, like web sites. So you're wrong, and brainwashed, and biased and spreading misinformation.

[@HealthyDev]

@@guntcheck you caught me, I'm a complete imposter who knows nothing about software development. I'm not a real engineer, I love scrum, I have low skill, and I'm a moron. Now that we've cleared that up, I'll continue discussing software development with my other brainwashed brethren here since we've got nothing to teach you and you've got it all figured out. Congratulations on your superiority!

[@Farren246]

Holy crap, you've got a title scrawl now!

[@HealthyDev]

Hahaha! Yeah I'm trying out some new things with this video. I made it quite a bit shorter and tried to focus the points more. Put the title thing together with a weird little beat I made in Ableton Live. And trying to use some different annotations to add weight to the arguments. It's a little experiment, as I continue to try and be "agile" with my channel. I'll have to see how it goes :). Thank you for watching!

[@Farren246]

Tbh I'm just surprised you still have new content; you're firing out things so quickly that I figured you'd need to stop and think of new topics by now... I'm guessing that you're working through a list which you prepared before opening the channel? Also, would you consider adding a forum to your website? I know that the ultimate goal is to drive business to you, but I still think that some method of communication just about the site/content would be good (beyond just email and KZbin comments).

[@HealthyDev]

Hey Thanks Matt. I do have a list of topics, but it seems like every time I do a new video, 5 more pop out in my mind! My entire website really needs a reboot at some point. Your suggestion of a forum is a really good one. I still do consulting for companies for income, but right now this content is more for individuals and so it's a little separate from that (at least how I'm thinking about it). If I'm able to grow a large enough audience, maybe I can find ways to help people in a way that would make money from it. But the purpose of the channel for me at this time is just to connect with others out there who need this information - and try and exchange ideas so we can all enjoy our careers more! Thanks for your advice, I really appreciate it. The software development community can be really hard to connect with, because I think so many people have given up on thinking conditions can improve.

[@gummydogs]

+1 for the new intro and format tweaks. I'm also impressed by your breakneck pace of releasing videos, almost as frequent as a daily vlogger (don't burn out!). Hope your channel takes off soon because the content is really refreshing. Other CS career youtubers have nowhere near as much experience, and forums like reddit are just full of students giving "advice" to other students..

[@HealthyDev]

thanks gummy! I am trying to do 6 videos a week through April for now. I may cut down to 3 videos a week then, but it depends on how things go. I appreciate your support!

[@shiftswim]

Disagree. The purpose of SPRINTS is to incorporate feedback and adapt. The purpose of scrum is to enable the team to work without interruption all day while still having a feedback loop for management and an opportunity to identify impediments.

[@HealthyDev]

+SHIFT interesting. So identifying impediments and knowing what to do based on feedback is something only management can do? 🤷‍♂️

[@iltc9734]

The solution is fairly straight forward but a paradigm shift. You need to free yourself by registering a business name, printing some business cards and becoming your own boss, starting at the one person level then growing. You knowledge, capability, and macro-view is well and truly ready, and the small handful of disadvantages are nothing compared to the deep feeling of calm you will get. If the ship you are on is being steered by a half wit, then take command of the vessel, grab the wheel and tell the engine room what you need. Go forth young man ! You will succeed. it has been foreseen. You are the anointed one. :) seriously... do it. get rid of your frustrations.

[@RA-eg8tw]

Hey, I'm currently applying to a company for an internship that uses scrum. Is there anything I should be aware of most when I first enter the work environment if I get accepted. Also anything I can put in my CV that might impress the recruiter?

[@HealthyDev]

Hey Raiyan I talk about things to look out for in many other videos. As far as what to put in your CV, that depends a lot on your experience, what you’re applying for, and the way you want to market yourself. If you need help and have a budget for it, I offer career coaching for developers on my website.

[@zvuk]

Ye, agile scrum is for young students that learn a lot from mistake. More senior developers are not fit for that, for them, it only shines unnecessary light on every mistake they might do. You cannot have a "bad day at work" when using scrum. Everybody's work is visible.

[@cassiodias1965]

Go to 4:05

[@anagris9281]

As a Scrum Master and Product Owner, I feel sometimes like humans are just not ready for an idea like Scrum. People refuse to take feedback and change. Just look at how countries handled Corona Virus. Feedback was there for other countries, with DATA, and some countries just chose to keep producing, refusing to adapt. I am struggling to believe Scrum is actually implementable in today's work. I know I sound pessimistic, but that is what I have seen.

[@errrzarrr]

People not ready... For Scrum people Is always somebody else fault

[@klapyahandzup]

I swear, that's Roy from IT Crowd!

[@micwin2]

I object in respect of the purpose of scrum. the purpose of scrum is to leverage the pressure on individual developers away, to the whole team instead:the team decides what tasks in the sprint logs will be done in which order, and the team as a whole commits to achieve either the time box or the feature box. it's all about to stop managers to go to individual devs to yell at them, do bribing or intimidating to get some 'favors ' and let them yell at the whole team instead (well, let's try them!).

[@IT-Entrepreneur]

Can you do a video about following: "How to get motivated again as a Softwaredeveloper"? I mean... I did chose this job and had a very long way to get where i am now. I am a leading develeoper and i loved programming in the past. But since a year now i am just prokrastinating an cannot motivate me anymore to start. When i just started and i am in my tunnel then its awsome... But man... I can not motivate me to start anything anymore... Its always the same shit. Day in, day out.

[@Oswee]

What will happen if you will not put that pressure on the team?

[@HealthyDev]

I’ll refer you to one of my other videos for my thoughts on this, great question: Creative Software Development - Explosive Growth by Letting Go: kzbin.info/www/bejne/m2WbfIOvodyUeJY

[@1MinuteFlipDoc]

Consultants sales pitch to CEO. More work with less people.

[@klauswiedenmann6119]

Thanks for this video. Because you are telling in a fiew minutes many things are really going wrong. Scrum isn't for me really agile, because the processes are handled like a religion and the scrum master is your priest. And yes. There is no adapting - only in a view cases. But it's more pressing the developers to work faster, to do a complete sprint with many features, testing and developement in 2 weeks, instead of four weeks. And in many companies they using the scrum tickets or user stories like micro management, so you even need a toilet ticket for 15 minutes exit in your processes. So it's all about to control us developers. But many people like it or just saying they like it or they arn't the developer, because there are meetings with more managers then developer.

[@HealthyDev]

Klaus Wiedenmann thanks for sharing. Is it really getting where people have tickets for going to the bathroom??? 🤣 LOL gosh I hope you’re kidding.

[@klauswiedenmann6119]

@@HealthyDev yes I was kidding. But it feels like if you have micromanagement and people start to make alibi tickets.

[@HealthyDev]

Yeah it’s definitely a process that can be abused as a horrible method of micromanagement. I only hope over time and with more education we can turn that trend around. I’ve been on great scrum teams - and ones that were miserable. This has only been my experience, but it seems people who crave control are more to blame than scrum itself when it trends towards the latter.

[@esantanche]

I guess you know Allen Holub. Like you, he can see that Scrum is, in most cases, a problem, not a solution. To me, Scrum is how companies doing software shoot themselves in the foot.

[@HealthyDev]

Yeah Allen is definitely one of many people who have some interesting views on where all of this is going. I haven’t given up on scrum being useful in the right contexts, but there are definitely many forces with motives that conflict with its original purpose making it easy to get wrong. In command and control organizations where hierarchy determines who sets working methods it’s hard for middle managers to give up the control they expect to let it be done right. Hopefully some of my other videos about process, and resources from other influencers in our space can help warn tomorrow’s managers of the dangers!

[@ian1352]

@@HealthyDev The new control, in my experience, is forcing people to follow Scrum to the letter. If it isn't working then the team must be doing it wrong rather than that it simply isn't working for them.

[@HealthyDev]

@@ian1352 if by new you mean common over the past decade, I'll agree with you there :). Any process can be dysfunctional in the wrong hands in my experience!

[@danieljoaquinsegoviacorona1734]

If scrum purpose is to highlight mistakes in the development process, then, what are retrospectives about or for in this case?

[@HealthyDev]

To take action on what needs improvement.

[@lulubee4826]

Yes scrum is A huge misunderstanding and bizarre “lost in translation “ from those who want to embrace the “theory’s “ into wrong horrible practices

[@andreashurling6995]

Could you write your experiences in a book please? I have already experienced the topics that you deal with in various projects to a greater or lesser extent. At the end of your videos, I really feel a little better ...

[@andreashurling6995]

All the current books are about the techniques and methods in Scrum or agile work. Nobody writes about the soft factors and how they affect the developers. I am currently experiencing that DevOps puts even more pressure into my daily work.

[@HealthyDev]

Hey Andreas if I find the time, I do plan to. I’ve had this request from many other people too!

[@JorgeEscobarMX]

Totally agree, but since it's not my call to stop the abuse, why bother.

[@pero777100]

User stories: "As a user I want ..., so that ...." are just advisory statements. They cannot be treated as requrements to be implemented "as a must", only like guidelines. Developers/Architects should say at the end what should and what should not be implemented. Of course that user stories can be useful, but there are lot of other things like laws, regulations, safety, performance,... Sometimes developers can say - "no this user story must not be implemented because of this and that..." Or "This requrement must be implemented even though user did not requested it and there is no user story, because of safety or law or performance issues."

[@ornicarornicar9070]

I live in France and, as far as I can tell, scrum is napoleonian administration with English words in it. (Which is probably not what it was meant to be)

[@RU-qv3jl]

I agree with most of what you said. There are a few inaccuracies though. I suspect you put them in for simplicity and because it is common practice. I just wanted to mention it though. Both estimation and user stories are from XP. Yes many scrum teams use them too, but they are not part of scrum. I don’t want to get religious and preachy though. The point of agile is to learn and adapt and you hit that nail on the head. I just wish many more people got that message. It is so damn frustrating to deal with agile coaches that are total sh*t and just push method(ology) over mindset change and learning. We’ve got one now who just create our “Agile standards”. Most of it is about estimating and how a 13 is too big. Then once estimated you should split and estimate again. Then you get to split PBIs into tasks and, you guessed it, estimate those in hours. Then you get to look at the cost of the team and break down the story points into dollar value (Not even delivered because our teams haven’t even learnt to deliver before the end of the bloody project yet). Then we can bash the poor developers over the head with how few hours they are effectively work, how bad their estimated are and how much their shoddy work costs… I hate what agile has become. It has become nothing but a straight jacket to control and manipulate developers into more work with less creativity. Work through a mile long backlog in 2 week “Sprints” (More like a marathon of sprints with no rest to release, reflect and learn). With all that said. It would be great if you released more videos. Your content is great and sorely needed.

[@orlovskyconsulting]

About estimate i say to my clients: here you have 3 scenarios 1: product delivered on time with xxx rate and definetly overbudget 2: product delivered on time and on the budget ,but with less features 3: product never delivered i work already with another client , your team is disband and you go bankrupt.

[@lodragan]

A variation on the old, you can have it 1) On time. 2) On Budget. 3) High Quality. Pick two.

[@timp2315]

I have this problem all the time. Problem is you can't even explain PO's ScrumMaster what scrum is because they just think your lazy for pushing back. Intelligent Software Engineers should never had agree to this systematic exploitation.

[@gkri8390]

I said no to more than 1 user story in a sprint and scrum master doesnt like that.

[@timp2315]

@@gkri8390 exactly its like an indirect pressure to fill up that damn velocity chart.

[@Knuckles2761]

4:05 - video starts, water before that

[@jeddak]

Scrum is about quality, not accelerated development. Management thinks it's about the latter, and through abusing Scrum, they burn out developers.

[@orlovskyconsulting]

Team decide how many stories they can physically do, if managers push team to deliver scrum master should say: look pal you can fire me, but my team would only adhere to principles of scrum, which if team say 20 stories can be delivered we as team can deliver only 20 stories and nothing more then 20.

[@BittermanAndy]

That's great if all stories are the same and nothing unexpected ever happens. Otherwise, if it ever gets towards the end of a sprint and it looks like you're only getting 15 stories (or story points) done, oh boy... "got to keep our velocity up! Got to stick to what we committed! Oh yeah we don't use the word 'committed' any more, we use 'forecast', well we still need to achieve what we forecast we would! We wouldn't want to FAIL A SPRINT after all!" And so on and so on, pressurising the team to try to achieve more, more, more in a sprint because people who don't understand software development love metrics and Scrum provides all the metrics they could ever want to use as a stick to beat people with.

[@orlovskyconsulting]

@@BittermanAndy The job of scrum master be reasonable to both parties , but i repeat protect the team, if a scrum master doesnt have much experience he or she would be persuade to push the team to limits. I dont see big problems if team promise to deliver n amount of stories , but in reality deliver n- x (x means deprecated stories), the whole reason for scrum to be adoptable and deliver value and really working software each time, if in your case you would not able to do that , that only means that forces outside of your control pushed you into such state, my advise speak to each team member on 1to1 base and try to understand reasoning of each of the team member , then look again at the deliverables and previous iterations, then you would have complete picture. After that you have many options like push back the product owner and demand more devs or better environment for work, in the end its all about taking responsibilities a responsible scrum master respected by the team and the product owner and overall management and even company owner, this means step out of comfort zone and know how to fight and when to take those fights.

[@orlovskyconsulting]

@@BittermanAndy In very rare cases a cleaning spring must be taken, if the velocity is damaged and all parties agree that now some cleaning must be done, then here we go .