Your Project Is FAKE Agile, What Now?

[@HealthyDev]

Are you driving yourself nuts trying to force a software company to be agile? I hope this episode offers some alternatives to consider if you want to prioritize your health and sanity.

[@nicholaspreston9586]

I've driven myself nuts trying to force companies to give a shit about code quality and to get away from terrible OOP practices, whether they're Agile or not! I'm grateful for your videos because instead of bitching about the industry, you actually provide reasonable solutions you yourself tried. Thanks for making these videos. I'd have quit software altogether if not for advice from devs like you, Nick Chapsas, and Primagen, etc.

[@HealthyDev]

@@nicholaspreston9586 glad to hear it helps some. Letting go of the expectation that people will care about things that matter sometimes is hard. Sounds like you’re making some great strides in finding peace.

[@nicholaspreston9586]

@@HealthyDev Thanks to your videos, I suspect I'm on the right track. I'm a real hardass when it comes to reducing code complexity (see: React and everything about it). Communicating why simplicity shields us from bad decisions is difficult. I need to learn to let go. It's not just Agile or management. It's we the coders too. I'm a big believer in thinking transactionally and coding with functions, no matter the language. The reason is, it's universal, easy to test, and can cater to other near-universal standars like SQL and HTML, with everyone being on the same page and having the same goal, saving a bunch of time. I'm a C# coder and I literally have 20+ small nuget packages in the cloud, each one having a few major functions and one responsibility and that's it. No more than that, or spaghetti will happen. It took some work to set it all up, but I'm happily recycling my code. Every function I write is a "Lego". I wish others would see how simple software could be if we just chunked things up and reused configurable functions (any language). Someday....

[@HealthyDev]

"It's not just Agile or management. It's we the coders too" this is a profound statement and most people don't have the humility to admit it. When I started realizing some of the stereotypes and attitudes I adopted from the development community were actually limiting my career, was when I started really heading to the next level.

[@nicholaspreston9586]

​@@HealthyDev "...It's we the coders too" Yeah, I'm starting to recognize my own bad habits. Like not prioritizing the critical path in my own projects has had me question whether some code I've written for companies has been truly helpful or not. Never know with contracts b/c they're so short. Of course, most projects fail, so I'm not too worried. However, it's my job to be a help and not a hurt. So i have to keep myself focused on the task at hand, no matter how mundane it is and no matter how badly I want to automate it. If it's not in my lane or critical path, I should defer it. I've found that coding things for myself help me practice critical path thinking. For example, I wrote a Linux daemon that controls an API for the Todoist (todo) phone app. The app is missing some key features, so I leveraged the API crud to make new ones like automatically planning my entire week out. I also added a 'bump' feature that will push due dates for my task. Those are the two new features, and I'm working on a third that helps with completing overdue tasks (and ensuring I get all the karma points in the app). Why it's missing from Todoist, I don't know. Having this auto scheduling daemon takes an immense amount of self-pressure and anxiety off of me, because I know I'll have a custom tailored schedule any day of the year from now on. And in the process, I learned YAGNI and kept my code focused on 3 features. Sure, it's not an AWS architecture or some trendy AI shiny, but it's keeping me sane on multiple levels and helping me self-teach something I've lacked much of my career. So, I can blame whoever I want in my career, but I have myself first to blame, if I'm being a good engineer. And no one will do it for me anyways. "Be the change..." as people say.

[@XeonProductions]

Every project i've ever worked on in the past 10 years has devolved into Agilefall as I call it. It's some amalgamation of agile and waterfall.

[@DuRoehre90210]

True. Either this or some kind of Canban. Then they keep trying to enforce the "legal canban rules" until they realize that rules like "only one Ticket assigned to a person at a time" is braindead, and stop enforcing them.

[@jonnybmc]

Ditto. Back here we call it 'watergile'

[@alexfrank5331]

Agilefall.... headless chicken trying to swim up the waterfall.

[@rileyalbiston6188]

Wagile. Waterfall with sprints.

[@ddanielsandberg]

Waterscrum is where it's at! :)

[@amazotron3471]

I call it Fragile. Management hears "we don't have to do anything, its all up to the devs - yipee". Keep dates, keep requirements, its all in stone.

[@TheRobinrosenberg]

I did a presentation with that title, mostly based on experience. :) it has agile in the title. I've worked in agile team once, miss it :(

[@theo-dr2dz]

Yes, it's a good deal. Kick all responsibility and work downstairs and keep the power, the salary and the prestige. No wonder agile is so popular nowadays.

[@JasonRobards2]

"Fragile"... that's an easy word for non technicals to grasp

[@dragonfalcon8474]

After seeing the chaos of executives wanting waterfall and devs trying to do agile, and the fake garbage it creates. I think you are 100% on the money with this video.

[@herp_derpingson]

1. I tried forcing change, but I realized that doing it without any formal authority is near impossible or extremely stressful, just puts a target on your back. People at the top themselves were full of ego and didn't want to agile themselves or even care about their own product. 3 and 4. Writing things down help to a certain degree, but your boss can simply say, "Yeah, I changed my mind, what are you gonna do about it?" 5 and 6. Those who promise and those who deliver are never the same people. You can estimate whatever you want, but the contract has been signed even before you were hired/onboarded. These are valid coping strategies, but the underlying problem is just supply demand. I have come to the realization that there are no good or bad jobs. It just population pressure. Real agile/fake agile none of that matters if your boundaries are being respected.

[@TastyGarlicBread]

As a Senior PM who is about to be promoted to Group PM, this is a much needed reality check. I, too, work in a "fake agile" company, that has all the scrum ceremonies, employs all the "agile" people, but has 0 room for adoption of agile proper and pushes milestones and project-based work top-down. I am now more and more convinced that, unless the people at the top change their minds, no amount of good intentions and planning will work a few tiers down, and I just bite the bullet until the next opportunity arises...

[@_ncko]

This is kind of what I think as well. I suspect it goes even higher than the execs actually. I think Agile processes focus on achieving outcomes and view learning as a step in that direction. So for a truly Agile team, learning (about the customer) is progress. However, CEOs need to impress investors to convince them that they are making progress. Investors are not going to be impressed by lessons learned, they want to see output. This need to impress investors with outputs turns into top-down orders for specific features or projects. Which ultimately shoots the company in the foot because the ideal is to learn the most you can with the least amount of code/infrastructure/etc to produce/maintain. Outputs create overhead and complication so it is best to make sure they are worth the effort-which requires learning! lol. As a software engineer, I've just decided to accept that this is the way the industry works and it is why we get paid well. My skillset is in dealing with codebases that have a lot of technical debt for companies that run this way. I feel like a doctor who works with patients that refuse to take care of themselves, and instead would rather pay me a bunch of money to administer increasingly dangerous medications just so they can survive another day.

[@HealthyDev]

THANK YOU for sharing this. I keep trying to tell this to everyone. See? Even the product managers are frustrated when the company can't be agile. It's not usually their fault. We're all on the same side everyone.

[@TerribleTom113]

I saw that ALL THE TIME in the military. As a young TL, we were always told we were supposed to be adaptable, responsive and take initiative to solve problems, but the reality was that we were forced to sit around doing nothing until other orders came down from the top and then you had to follow them to the T, and meet every deadline without fail (or else.) All the agile type talk was just empty rhetoric.

[@HealthyDev]

@@TerribleTom113 wow seriously? I actually thought the military would be one of the few organizations that would have to mean what they say behind this one. Surprising!

[@TerribleTom113]

@@HealthyDev I'll put it this way: The large majority of what civilians think the military is like (myself included prior to enlisting) is b.s. It's why I didn’t re-up after my first contract. The reality is nothing at all like what they tell you in the recruiting office. Maybe it's more "agile" up in the SOF units, but even that doesn't seem to be the case from the SOF guys I knew. I can't speak to that level from experience, though.

[@xlerb2286]

Just my bad luck perhaps but I've never been on a project that _wasn't_ fake agile. Worse one was where they split up a 2 year waterfall development cycle into 2 week chunks and called it agile. We had a series of sprints doing nothing but generating requirements, then another set of sprints doing design docs, etc. That worked about as well as you'd think. But with the exception of that one company slicing waterfall into sprints I've liked the companies I've been at and it was worth putting up with fake agile. The paycheck spends the same either way. My recommendation is to not spend much time trying to fix a company. If they're willing to listen and change fine, otherwise just decide if that's the place you want to stay at, and if so live with it and shut up. They won't change and you'll just stress yourself.

[@amkessel2014]

I don't think it's just your bad luck. I've worked at over a dozen companies, several of them startups, which you'd think might be more flexible than older companies, and I have also NEVER been on a true Agile project. I also totally agree about not spending too much time trying to fix company. Maybe there are some out there who would find the fight rewarding, but many engineers I know, myself included, just want to develop, and the process, whatever it is, is just there to be endured.

[@l1belula]

haha I myself got tasked with splitting a UI/styling update project into fake sprints. Then after the "estimates" were "locked in", I got hit with the actual designs.

[@chikechinukwue2906]

And you think that at the end of 2 years you would have had better outcomes from your product than delivering value every 2 weeks? Good luck with that!

[@xlerb2286]

@@chikechinukwue2906 Well, that particular product would have been hard to do in 2 week chunks. It had over 200 devs working in 3 locations around the world and integrated with a ton of other technologies that were under active development at the same time and we were feeding them requirements for changes we needed. Our product itself was itself split into 3 tightly coupled layers. A typical sale took 10 months on average, took over a year to fully deploy including significant 3rd party modification for their particular business needs, and the total sale price started in the million dollar range for the bare bones basics and went up from there. You don't really make that up as you go. But trying to pretend you were just cost us time we didn't have. :) I do NOT like working on big projects like that, not my cup of tea.

[@user-jj6vd8yz5d]

​@@l1belulathanks for the info

[@inthecaddy]

Every project we have is fake agile. Every time I try to redirect back to actual agile processes it gets hijacked and turned back in to fake. I keep pushing for standups. They turned in to status meetings, then turned in to planning and grooming every meeting. I keep trying to get them back on track and it never fails. This video could not have come at a better time for me. Thanks,

[@etienneb.6956]

Exercise actually saved my career. Can't agree more.

[@TheFocusedCoder]

This hits a cord. I've never been on "agile" project. It's a myth to me at this point lol

[@HealthyDev]

I have several times, it's fricking incredible. Unfortunately it's like an albino - incredibly rare.

[@Jacob011]

I'm working at such company. Simply put Agile™ is not agile. And the creator of agile hates what it has become.

[@groovediggr8777]

nailed it. and this may be the biggest issue. Some of the more common Agile frameworks and consultancies out there (I'm looking at you, SaFE) are reinforcing the mgmt kneejerk reaction for fixed date/fixed scope/long term commitments.

[@heidebaer41]

@@groovediggr8777 Fixed dates and scopes aren't bad, but it is disgusting that people claim to be agile when they have those. If you don't have the cajones to go full agile, then don't lie to your devs.

[@MrSofazocker]

When sprints become deadlines, and estimates don't makes sense anymore, you have failed agile... but that's were most are unfortunately

[@monterreymxisfun3627]

You have some control over the tasks you do in a project. In a dysfunctional environment, low visibility can be a good strategy. Finesse yourself into tasks that give you satisfaction.

[@benjaminthorp2208]

Main takeaway - let go! Easier said than done but I’m committed to not letting this industry continue to destroy my well-being. Also beautiful guitar work!

[@HealthyDev]

Thank you sir!

[@username7763]

At this point id rather find a company that doesn't use agile. At least no pretending anymore .

[@wertigon]

"SCRUM Master" on a SAFe team here, I view my role more as a tech lead / coach protecting the other team members from the rest of the organization and coaching to make them a better developer while doing some minor code jobs on the side, usually refactors and code reviews.

[@AcidGubba]

Do you see your role? What does your company think your role should be? Teachlead sounds good, but the added value isn't really there. I think the people who do it don't really know what their job is. I've often seen a techlead think they're doing a lot of development themselves. Basically, they don't understand what their title stands for and thought it sounded important. What do you think the job of a techlead is?

[@wertigon]

@@AcidGubba The job as a tech lead is to guide the development. If this place was the military I am basically a platoon leader. I don't do a lot of fighting, even though I would if I had to. Instead I climb to the top of a hill and help the team decide on a strategy going forward, using my perspective to avoid the worst traps laid out. It's more of a management role but without the power to hire or fire people.

[@AcidGubba]

@@wertigon But do you see yourself there personally or does the company see you there?

[@wertigon]

@@AcidGubba It is how I view myself. The corp more or less sees me as that guy who presents reports every other week about progress. As long as the features get delivered they don't really care if I have to sacrifice firstborn babies to get the features we commit to get resolved... Or they wouldn't, but that kind of stuff tends to give bad PR. :)

[@JM-jc8ew]

I've come across a lot of devs who hate Agile/Scrum/SAFe but they really haven't experienced the real thing.

[@HealthyDev]

Similar experience. I only came to the realization about 5 years ago, that more people have never experienced true agility on a project than those who actually have. A sad statement for adoption in general.

[@JeffreyParrishJcap]

This sounds like exactly what I needed to hear right now, I am on a 9 month contract with a company that thinks they know better than everyone else (huge old company) and they have a lot of strange ideas that I have to work through. I tend to take too much responsibility and that cripples me here because I don't feel like I can take full responsibility for the whole project when I am the lead developer. This helped me think that I can take my other frontend developers and advocate for tooling and services that will help them work faster - and that gives me hope that I can leave an impact even if the contract goes nowhere.

[@HealthyDev]

Great attitude despite adversity!

[@videotime706]

I think a lot of “fake agile” stuff comes from thinking that you ever “become agile”-there’s no rule set or procedure that you just put in place, it is always a process of continuous improvement! Things like SAFe have really poisoned the water as far as the term “agile”. Famously, the Agile Manifesto doesn’t mention anything that people commonly associate with the term!

[@KA-wf6rg]

I just left a company where everything you said was the reality. I kept banging my head against my desk, wondering in bewilderment why we threw around the term Agile, or advertised it in our *job descriptions*, but the company had literally no understanding of what it meant. So I tried, at first gently, to provide some comments to help get people thinking in the right direction. And I knew it wasn't a pipe dream I was trying to sell, because I came from a company previously that was fairly Agile. Over time, I realized I was just being ignored. Then when I tried to voice a little more in larger meetings, not combatively but just trying to get people thinking, several times I was shot down by the "Director" of Engineering. Words like "everybody can't just do what they want" or "cowboy coding", etc, etc were used. So I came to the realization that they didn't get, and they didnt *want* to get it. I wish this video was available when I was in the thick of that. Looking back, I could have saved myself some stress and not tried so hard to change things, at least while I looked to work somewhere else. I can be guilty of being an idealist at times, but I'm learning that reality is in fact real, and sometimes it's best to just accept it, try to make a difference where I can, but don't try to change the world.

[@gtrider316]

I really like the new logo and matching background behind you. The complementary colors are very satisfying.

[@Erik_The_Viking]

BTW - love the new branding for the channel! Great advice - especially with buffering deadlines. OMG this saved my rear so many times. Let's be honest - s*** happens. Agilefall is the reality for most companies, and typically dysfunctional. Makes me really appreciate waterfall more.

[@dragonfalcon8474]

I have been on teams that do Agile correctly and ones that do it incorrectly. Agile is great for software development on a small to medium scale. One issue I have seen is that as agile scales through a large corporation it just means do things faster, ignore documentation, and tactical tornado everything with zero accountability. In particular, the C-suite and higher level managers want metrics and reports, and 3-7 year plans fully laid out, and Agile does not fit into that well. So now we are stuck with waterfall that uses agile terminology buzzwords.

[@HealthyDev]

Yeah absolutely. Agile is not appropriate in companies that want long term forecasts.

[@ImperiumLibertas]

​@@HealthyDev the desire for long term forecasts is the root of the problem imo. Instead of setting goals and milestones realizing that they will change moment by moment they try to predict what the company will need in that 3-5 year period and pretend to know how to measure the work and how to measure it before it even exists. At my waterfall company every sprint is a 5 point ticket plus a 3 point ticket. It just doesn't mean anything. Totally meaningless estimates.

[@ImperiumLibertas]

I think milestones can be used to progress and outcomes at a regular interval and can if implemented properly be used to hold people accountable.

[@robertbeckman2054]

It’s me again, 18 years software developer burnout accidental Debby-downer. I worked at 8 companies, one twice, and not a single one did agile even close to right-whatever that actually means I’m not sure anymore. They all claimed to, except one company that was me and three others taking Russian software and converting it to VB6 -talk about Hell. I enjoy your videos, as I dealt with most of what bad stuff you’ve described over all the videos of yours that I’ve watched. Cheers.

[@xlerb2286]

Boy, we've had about identical careers (except for me it was taking Danish C/C++ software and converting it to C#) except I've been at it ~30 years. I also haven't seen agile done close to right even once. Current company is the best but when time gets tight out come the old habits and we're all about being date driven. It's all a S.E.P. to me now though, retiring in 3 weeks. I'll miss many people, but I won't miss agile.

[@galier2]

Since we're "agile" our progress in the backend froze to a halt. The front end thrives, but the backend does not evolve anymore. I have now more than 4 years of bug fixes, code reformattings, optimizations, and new features sleeping in my repository. Before we did all these agile ceremonials it was easy for me to bring changes into the code base. Now, it gets always pushed back as there is no place anymore for the slightest (perceived) risk (there's not more risk than before, it's just that because of all the formality, risks are perceived by the rest of team when they are not in a position to assess it realistically).

[@marcotroster8247]

I'd encourage you to have 1 or 2 really bad projects. After that you can always convince yourself that you endured much worse situations and still delivered value.

[@odaselementales]

I feel so seen and validated. I jest, but it's funny because it's true. I feel like you've just told me "yes, you're being gaslighted and yes, after years of frustration, you have stumbled on the right way of doing things in a dysfunctional project without driving yourself crazy and I do the same things."

[@HealthyDev]

Glad to hear! That’s exactly what I’m hoping to help people like you experience. Hang in there.

[@Elemblue2]

Ive always been resistant to gas-lighting, to my own detriment, because I don't buy in under social pressure. Thank you for putting words to what I have been feeling around the edges of.

[@ianm1837]

I just come for the chill vibes and the guitar interludes

[@dinckelman]

One of the jobs I've had forced me to get SAFe Agile certification, which they at least paid for. And then promptly ignored every principle described in the certification. It was a complete shitshow

[@HealthyDev]

Ugh, that sucks. My wife was considering becoming a scrum master at one point. In the certification training she took (in person, with one of the biggest names in the business) the attendants were arguing with the trainer about how their management would never support the principles he taught. That showed her enough to help make the decision not to pursue it anymore.

[@_ncko]

It is so good to finally see this kind of content somewhere. So much content in the the software development space is focused on working with an ideal. I've always wanted to see content on how to work in the real world. In the real world, most companies may use agile terminology but they aren't really agile. This is awesome advice. Our industry needs more books and popular content like this.

[@HealthyDev]

Thank you!

[@devinosborne3396]

Pretty sure this is the best video you’ve made. You explained the problem so clearly in so few words. And all the best examples. 100% relate

[@leonelmateus]

great topic! didn't realize this antipattern was so common. the lingo is being thrown around but it is NOT agile. its used as a selling point only, not in execution. last project idiot pm kept slinging agile around.. it got cancelled. hope you are well! thanks.

[@HellsJayBells]

This speaks to me so much. I've discovered that I've already taken on a lot of this advice. What was new was 6. Define Your Own Success really helped. I am a tech lead for a very small team, genuinely feel that the success of the product is resting wholly on my shoulders. I'm going to focus on taking the step back and defining success for me, regardless of how the project ends up. It'll take a bit of time, but I really like that reframing.

[@HealthyDev]

Glad it helps. Took me over a decade to start learning that one...

[@MrShikaga]

The first thing you have to learn is that you cannot be Agile if your customer isn’t Agile. If your customer wants to know how much their software is going to cost and when it will arrive, you cannot be agile, no matter what you do. And if you work in a consultancy, which many of us do, then that will be 90% of customers. There are very few customers out there who are going to get sign off for a project without such assurances. Agile only works for product companies, or if your customer is internal (an engineering team in a bank for example) but if you are charging someone to deliver software, you are going to struggle to convince your customer to embrace Agile. Just stick to Waterfall.

[@HealthyDev]

Agreed. I practiced education selling with agile. I talked about this in one of the first videos I did on the channel about MVPs. A customer has to be taught the benefits of agility and why other companies vying for their bid don’t care about their business success, just getting the deal. Without that conversation, no client will go for agile development.

[@MrShikaga]

@@HealthyDev Yep. Unfortunately though, very often it's simply not possible. It's not that the customer doesn't understand, it is that the decision maker works within a larger organisation with a defined procurement process that is inflexible. I worked selling a lot solution projects to banks, and the department we would sell to would have to put together a piece of paperwork to send to the accounting department saying exactly how much it would cost and when the payment needed to be made. There was no way to explain "Well, we don't know, just pay us $X per month and we will keep going as long as is valuable". Often it was worse than that, the bank would have Request For Quote documents, hundreds or even thousands of excel lines long, we would need to fill them out with estimates for each feature and then our quote would be compared with all the other ones by the procurement department, not even the department who would use the software. These are procurement processes designed to buy paper and pens in bulk applied to software, because back in the 60s the bank would just give the contract to whoever some executive went to school with. And it resulted in misery for all parties involved.

[@HealthyDev]

@@MrShikaga for sure. I wouldn't want to work with a bank and try to do agile projects. As you said, procurement departments are a disaster and need to be overridden by the CFO. Much harder sell.

[@evgenykopunov5459]

It's all well and good, and I love how one of the main points is exercise. But now you need to switch between guitar and exercise in the intermissions to practice what you preach :) :) :)

[@HealthyDev]

Lol! I don’t think anyone wants to watch me work out 😂

[@Joe-ku1ko]

Pro tip: if you are upset that your leadership refuses to take your suggestions, you should be heavily considering this guidance in this video, and if you refuse to consider, then know you are just as closed-minded as the people at your job. Its a lot easier to change yourself than to change the system.

[@donm7928]

hey Jayme! just wanted to say that I love the new logo and channel name! It somehow inspired me to change and get better with my journey as an IT worker.

[@TheRobinrosenberg]

I agree. You may be able to improve, but don't stress over it. Talk to those who want to listen only.

[@HealthyDev]

Wise words. Took me WAY too long to learn that.

[@kensearle4892]

Thank you for the video! In current PMP training, they cover Waterfall, Agile, and Hybrid, as I think they are realizing many companies are using a hybrid/customized approach. As a Lead Software Engineer... I see mostly Hybrids so I am learning how to recognize what they have quicker and adjust my plan to work with it. I agree, having acceptance criteria on all user stories is key. I agree, treat changes as new incoming work. Don't pay for other people changing their minds. Have a process for change requests. I like a Backlog so I can ask the PO/PM to prioritize change requests among other incoming work. Yes, definitely build in buffer time. The lesser known the work, the greater the buffer. Know your boss. If missing a deadline is the worst, buffer so you can address unexpected issues and still complete on time. Stay ahead, not be late. Know your boss. If they contribute to scope creep without re-prioritizing other work, increase some buffer time to reduce the stress point. Know your boss: If they do not want to or don't have the authority to change a PM process, you likely won't. Know your boss: Will they support your suggestions? Start with ideas you know they will like and support. I did all these backwards at some point so trying to save others some stress.

[@dElectroBuddha]

These are gold !!!

[@TimeFliesWithRum]

I needed this video right now, thanks a lot. I work as a senior tech lead for a fake agile client project. We are in the last third of the project time, and the project itself is an absolute bomb. Destroyed by a lot of things that you mention in this video. I have found that i have taken it personally, and i have been trying very hard to tell myself that the things i CAN control, i and my team members have done very well. It is the things i CANNOT control that has wrecked the project.

[@HealthyDev]

Hang in there. Glad to hear it sounds like you've shifted your mindset a bit to not stress out over what you can't control.

[@NattyNarwhaal]

Buffer 100%, deliver at 75%, chill for the rest of the time.

[@dElectroBuddha]

Channel content is great, but comment section is among the best I've seen!

[@HealthyDev]

Yeah the community is pretty amazing (most of the time, few trolls lol).

[@gammalgris2497]

If possible try to be agile within your team. You'll still have to adhere to the formal processes when dealing with other departments and the management.

[@markmbarrios]

The 1 on 1 talk I needed. This is such a reality check. Thank you for raising this.

[@aasoftware]

You have built something wonderful in here. Congratulations! And thank you for continuing this work. I remember stumbling upon your older videos a year or two ago, and being touched by them. Now things are on a much higher level, much more professional and impactful. And I love how you integrated guitar playing in the pauses. I have always tried to make music for itself, never thought of using it within another work path. Great idea!

[@HealthyDev]

Thank you! Welcome back to the channel :)

[@TedSeeber]

I just lost a job on a project that is fake agile. For 7 years before, I was on a team that was real agile. Same company. Scotty school of engineering is good- but cannot be counted on

[@travisabrahamson8864]

The way you started you toed the line of "resignation", I thought you might cross it but you didn't. I am a firm believer that developers are the advocates for the code, let the scrum master be the advocate for the process and let the Project Owner be the advocate for the client. But I agree, the team should set its goals for a project and individually we should set our goals that align with the idea that even against the odds we are not going to resign that the project's outcome can only be failure. We may not complete it 100%, but even getting some part completed that meets a client need can be a success.

[@megd9849]

Two questions: 1) Your first recommendation was not to force everyone to admit that you're on a fake agile project. Item #3, however, was to become a requirements lawyer because in waterfall, you have crystal clear requirements all scoped out. How do I hold my boundaries when management is exerting pressure on me to be flexible in my requirements and deliverables but concrete in my deadlines WITHOUT drawing attention to the fact that we're not doing agile? Maybe just avoid using words like 'agile' and 'waterfall' entirely? Aka, 'I can only work with fuzzy AC if you give me fuzzy deadlines.' 2) What do you do if everyone else on the team lets the managers change AC two or three times a sprint, including the Tech Lead? When I'm the only one trying to hold tight ones around last minute shifting AC, or AC that's built on verbal requirements and not written down / impossible to keep track of, I feel like I'm almost doing something morally wrong by not going along with it (intellectually I know this is not true - I'm saying the amount of anxiety it induces is overwhelming). It also makes me feel like the weakest link, and I'm afraid of looking lazy and stubborn next to my less boundaried peers, who are often reeling from months of unemployment and are just grateful to have any job at all, so they're not interested in making waves.

[@HealthyDev]

#1 I think you answered your own question. The quote you gave is hilarious, and true. #2 This is general dysfunction since it's fake agile. In scrum you can't just willy nilly change AC mid sprint without adding the new criteria to future sprints and canceling current work. It doesn't work that way. A change goes in the next sprint, always. It sounds like you won't have much luck getting support on that since it sounds like systematically across all those roles they abuse it.

[@tomgeorgestory]

We had a great learning session on this new way of working. As a developer, I could REALLY see benefits to working in agile. Give the team trust to get the work done. Make sure there is a proper backlog, do the sprint planning, size the stories, get proper stories, and so on. What I find instead is that we are just using tickets to track work. Manager assigns the work like before, decides who gets which tickets, how many points each ticket should be, etc. "Agilefall" is worse than waterfall because it has the phony illusion that you get some say in the process but it's really just more of the same crammed into a two week "sprint." And then it's "Well we really shouldn't be carrying over the tickets from sprint to sprint." Not "Hey, maybe we should create the tickets such that they are 2 week pieces of work as a part of the larger project... you know... like agile is supposed to be. LOL, sad for sure... it's basically, it's a scam at my workplace.

[@SambuddhaBisi]

Man those guitar interludes warrant a sub on their own

[@johnprice6805]

I exclusively work on fake agile projects.

[@HealthyDev]

Haha! I can see this on a resume: "Certified in fake agile"

[@tursilion]

when you hear such a statement, just assume agile == null and so nulls out the entire statement. Does wonders for your peace of mind. ;)

[@saltedskin]

Thank you about talking about those challenging topics. In my history the projects not calling themselves "agile" where the projects that were most agile. In job offers "agile" is a red flag for me.

[@deafmettle]

I love this. I have spent alot of my career banging my head against a brick wall around best practice in Digital and engineering industries to the point of burnout. What never ceases to amaze me is the length upper management go to sell the mangled approach they want to take in the name of some form of best practice but that will always underachieve on the benefits they expect from it. And when it goes wrong you are doing it wrong rather than the approach was wrong from the outset. I've given up now for my own health and I coach my peers to stop trying to control stuff they can't control because in the long term it will destroy you. Best practice is a myth. Everyone says they are doing it - no-one actually does it properly. One thing I do today which does help is journal what I am doing and what the outcome was and I actively drive lessons learned sessions. The journalling is cathartic and helps me see both my successes and failures. Lessons learned are rarely heeded but I am content I have made my point and after that if the company ignores it and they fail again then it's on them and not me - and I gladly remind them of it.

[@PoppySeed84]

How do u feel about scrum masters having zero technical skills or knowledge? Ive only had one good scrum master. And while he didnt program or have a degree in computer science (i think he had a degree in film history), he still found it interesting. He used the software we built. He tested it. He would even go thru the build process on his own computer. It was awesome. He actually knew what we were working on every sprint. And if conversations needed to get technical, he understood why. He gained our trust. He was amazing... every other scrum master ive had has been an "agile guru" with zero technical skills or knowledge. They generally just dont care about whats actually being built. They dont use the software. They dont find it interesting. They avoid any technical details like the plague. Every conversation that starts to become technical gets derailed into an agile process discussion. Its horrible. Thats my problem with corporate agile. We're surrounded by people that just want to appeal to their superiors by delivering a nice burn up chart. The actual software? Nah, that shit doesnt matter.

[@username7763]

Scrum master is a bs job. Might be good people who happen to have the title but the job itself is less than worthless.

[@PoppySeed84]

Ive heard multiple scrum masters and POs at my company refer to the devs as "kids" and they're the "parents" that keep things on track. That's what corporate agile has introduced whether it was meant to or not. A whole industry filled with people who look at technical details as the kid stuff... I'm sure at at great technical companies, this is different. But at ur average mid sized city enterprise, that's what it's become.

[@username7763]

@@PoppySeed84 some developers are immature children. But this should not be accepted. Our field needs more responsible developers.

[@HealthyDev]

@PoppySeed84 yeah that reminds me of a prior episode I did, "Why Do Managers Treat Programmers Like Children?": kzbin.info/www/bejne/h6HCqoCXmb5jfKM

[@arioamin]

My first real job was at a true agile company, any job or projects I've been part of since have sadly been some form of ungodly mix between methodologies

[@adamcarroll3498]

What you said about "estimating to an ideal scenario" and removing buffer time really hit a nerve, that's exactly what happened to me recently, and it fell apart anyway. It's a very dirty tactic by software managers, and I'm the lead on my team. It didn't matter 😏

[@HealthyDev]

I’m sorry. I think many managers aren’t trying to play dirty tricks with doing this. They just don’t understand why it’s not a good practice.

[@adamcarroll3498]

@@HealthyDev thank you for that. Yeah you're probably right, but needless to say we don't live in an ideal world! Good luck with the channel rebranding! Regards from South Africa 🌍

[@lardus8614]

I was at a company where "fake agile" was the norm. I said as much, when I asked me to explain what I meant, I just told them "you use the name of agile as an excuse not to plan and not to think". They wanted you to "act agile" without the benefits of being agile...

[@mat4246]

#5 any recommendations how to deal with managers that require explanations of estimates and will pull in engineers from other teams to estimate the same thing if they think my/our estimate is too high?

[@HealthyDev]

Let the other engineers do it if they have a different estimate. No two developers write code the same way. You can't estimate for another person, unless you have their brain.

[@mat4246]

@@HealthyDev Thanks! I forgot to include a very important detail: it's still my team that will do the project :) it simply becomes a matter of who can provide a smaller estimate for my team's project and somewhat justify it

[@ChristianConrad]

@@mat4246 "No, we don't think we can do it in that time. If they think we can, they're wrong: They're not us, so they don't know. If they think _they_ can, then let _them_ do it. Maybe they can, we don't know: We're not them."

[@Mauzao]

Sadly too often I've experienced that some devs within a team break the united front that should be presented by the dev team. Once a manager/PO/lead wants some new feature for an unchanged deadline, some devs just don't see that as problematic. This leaves the other developers in the worst spot possible: either say no and be the bad guy or go along and have lots of stress.

[@PhilDietz]

"You'll have to get Director and VP approval for me to add/change this new feature to this." [5 mins later] Email: Please add this feature to your story this sprint. Signed Director.

[@garrettweaver3824]

Management saying “give us the ideal case estimate and we’ll buffer” is from a management technique called critical chain. This is an implementation of Theory of Constraints by Eliyahu Goldratt, who realized that every management layer adds their own “buffer” on top of estimates, which causes project timelines to be massive. Ironically, what TOC tells us is that multiple management layers lead to inefficiency on projects and therefore a reasonable recommendation would be to flatten the management hierarchy. Instead Goldratt recommends removing everyone’s safety buffer, at all levels, and put all of them into a global project buffer at the end of a timeline. This means that every task is estimated at 50% confidence and therefore, by design, half of all tasks will be late. Although regression towards the mean will mean that the project will be fine, it also means that up to half of all developers will get reprimanded for poor performance.

[@witblitsfpv1265]

Very true words! Most companies are sold Agile as a recipe for success. Waterfall is the blacksheep and Agile somehow guarantees success. In the end, from a business point of view they do need some sort of timeline/realistic cost, almost as if Agile is incompatible with the business world. Excercise, that's an excellent point. The pain of fake Agile pales in comparison to 150 situps at 06h00 in the morning. It works!

[@kostasalexopoulos5836]

I wasn't aware of the term back then, but I practiced requirements lawyering at my first job. It was a chaotic place that pretty much intentionally avoided any form of organization, aside from the founder being involved in everything (not a startup). I started doing it because iterating over the same stuff again and again was too frustrating (and boring). I started noticing inconsistencies between different features, and I would point them out and request clarifications, until I felt that the feature was ready for development. In a sense, it was a way of me to avoid responsibility for the feature failing to be delivered in time or producing undesired side effects. In the end, it was a habit I needed to break when I moved to a healthier place, I was being too argumentative and subconsciously expected negative outcomes from other people when I had no reason to do so.

[@stephanf17]

Best advice I've heard in years.

[@jinto_reedwine]

I have never worked on an agile project. It was either explicitly waterfall or agilefall. Personally, I never felt that was the reason things got heated between management and developers. At least on the projects I worked on, failing to manage expectations was the biggest problem. A lot of your points are really good, including the one about exercise, and I wish i had your channel much earlier in my career! I do feel there was a negative undertone to video implying that, if you aren't on an agile project you necessarily must be feeling bad about it, or that the project is likely going to struggle. Is that really the case? It never bothered me, but it is all I have ever known 😅

[@PaulSebastianM]

Thank you for this advice. It's really eye opening for me.

[@HealthyDev]

You’re very welcome! ❤

[@dreboyle167]

The challenge is two competing sets of needs. The business needs predictability, and the product wants responsiveness. Couple this with running multiple projects and you see how we get there. This isn’t failure to deliver hire agile, it’s necessary pragmatism. The business can’t get the minutia of detail it wants, nor can the devs and product folk get free rein (budgets exist) so what we end up with is neither, and that makes no one feel great.

[@alexfrank5331]

I have 15 years of doing all types of "Agile" project. 100% endorse everything this guy says. Especially point #3. I had to figure that out myself. It's a very powerful realization that lead to WAY better results and the upper manage really only care about the results.

[@lorakkaibab]

"Hey, that's not actually how a user story is supposed to work in Agile," I said to the BA. "You don't really understand story points. Let me teach you what they really are." "STOP TRYING TO FIX THE BROKEN SYSTEM" - this was the most important thing I heard last time. Thank you very much, it is very eye-opening!

[@J0HN3]

I think a lot of this comes down to TRUST amongst engineers and management. Execution leads to wins. Wins leads to trust. Trust leads to autonomy.

[@starliteinn5397]

I don't understand how the mindset of 1 and 2 - live with the broken system, don't try to change it, and let it all pass over you while you wait for the next job - jives with 3 and 4, about actually demanding changes.

[@HealthyDev]

Ah good question. I'm suggesting you accept that the project isn't agile. In that if everything is focused on deadlines and predictability (not getting feedback and being flexible) you try to not force it. When in that situation, I suggest points 3 and 4 which are about protecting yourself in that broken environment. Charging for changes and protecting your reputation are unnecessary on a truly agile project since there's more flexibility and trust. Does that help a bit?

[@What_do_I_Think]

You are frustrated about Agile and you are doing scrum? Find the mistake: Agile is not scrum and scrum is not agile. That is the first mistake those companies make: implement scrum(bag).

[@Rosaluna-NYC]

Thanks for the great video! 👍👍 I'm also stuck in this fake agile situation where management thinks adding more and more tasks without prioritizing, but expecting everything be worked on with high prio is "agile"... Drives me nuts... Therefore I might share this video with my colleagues to explain further.🤗

[@henningtorsteinsen2169]

It’s interesting how many of these advice aligns with stoicism.

[@bkr_418]

I work in FinTech, where they actually are proud of doing Agilewaterfall It’s a mess. Thank you for your video, it was what I needed. I’m a junior finishing up uni, and you’re the mentor I wish I had at my job 👍

[@AdamWeigert]

Could have used advice like this 6+ years ago😅

[@jmguillemette]

Wonderful episode and very true recomendations. Keep it up!

[@felipemalmeida]

I should've seen this video early last year

[@JimAllen-Persona]

I’ve never worked on an Agile development team but it brings back memories of Ishikawa diagrams. ITIL- the equivalent in my world - is a great idea and ties perfectly into Agile but rarely does IT management have the gonads to tell user management or customers that the fix is not making this release.

[@thisoldproperty]

I work for government. So every single buzz word gets adulterated to where it's not even useful to use the word any longer.

[@CaleMcCollough]

I love Jamie. He's always go such good advice. I've always viewed Agile as hitting deadlines myself. I'm embarrassed. I thought the story points was just to get stuff done on time.

[@melissam6037]

Fake agile has me lolz 😂😂😂😂 it’s too real

[@keim3548]

*"charge for changes"* - while I agree don't just absorb it, the agile way is you trade off the scope, not change time or budget. You don't push out deliverable dates - that delays value delivery. You don't charge extra money for changes - that discourages positive changes. Throwing away code that is already written is frustrating but it's not the worst thing that could happen. The worst thing that could happen is the customer and management feel so pressured to not make changes they build upon obsolete requirements. This incentivizes reality distortion fields and all sorts of other nonsense. And the developers are left to take pride only in their craftsmanship rather than in their business impact. Also, estimates should never be done without incorporating an expected amount of changes. I realize how difficult this is to fit scope into a sellable pricetag and dev teams feel the pressure from sales to squish the estimates to fit, so that's why it's so important to have an agile contract structure, and that means buy in from the sponsors, not just words in a document.

[@amiv220]

The 1st and 2nd advice are the best ones. Just stop caring too much about such things 😌

[@nostalgian4113]

As a developer/ systems analyst / UI UX designer/ QA tester working under a project manager with industrial project management background, i struggle but managed the requirements phase, my issue is UAT. He blames does not give UAT feedback on time or rejects a release for months because of UI edits. He reports to stakeholders, i reported to my manager who reports to stakeholders and he causes more conflicts between us two unprompted. Anyhow, i can’t force him to do UAT on time and i communicated this and i asked for QA person specifically for this, is there something else i can do?

[@christianbaer2897]

First indicator would be "We are doing Scrum". Sorry, but Scrum is not agile development and people who say so, have not read the Manifesto for Agile Development or the Scrum Guide (or neither...). Scrum is a rigid process, that has to be followed and cannot be changed (read the guide, it says so there) and this is the complete opposite of "[We] value: Individuals and interactions over processes and tools"

[@HealthyDev]

Agreed. Scrum is the Kleenex of agile processes. People tend to use them interchangeably. I use scrum in examples on some of my episodes because people can relate.

[@MrShikaga]

I disagree. Different teams benefit from different methodologies. At the last place I was at, pretty much all the teams used Kanban, but it was up to teams to decide for themselves what they wanted to use. One of the teams though had been struggling, had lost some strong team members recently and were struggling to figure out a process that would work best for them. In the end, during one of their Retros they said “Why not let’s try Scrum?”. After a couple of months, things were going much smoother. They preferred the more structured format of Scrum and delivered more with less stress. Now if you were to join that team, they would tell you “We are doing Scrum”. This doesn’t mean they aren’t Agile, it just describes the SDLC and methodologies they were following. They still value individuals over process, and if Scrum ever isn’t working for them, they can change it however they want, there isn’t an Agile Police who are going to come and arrest you if you change some of the ceremonies around. The point is that the team is in charge of their processes and tools, not that some tools or processes “aren’t agile”

[@christianbaer2897]

​@@MrShikaga I never said, that Scrum cannot work for some teams. I simply said, it is not an agile practice. The reasoning behind that: Scrum as a process is immutable and creates a role, that is accountable for adhering to the process. In other words: When the team decides to ditch Scrum, that person failed in their role. Tell me how that is "valuing individuals more than processes". You are right, there is not an "Agile Police", but there is a Scrum Police (and you call him 'Master'). The Scrum Guide very clearly states, that you can alter your process, but then it is not Scrum anymore and that the Scrum Master is "accountable for establishing Scrum as defined in the Scrum Guide". Accountable! So, according to the Scrum Guide, the moment the team decides, they want to deviate from the Scrum Guide, it would be the job of the Scrum Master to prevent that, as they have to be "enabling the Scrum Team to improve its practices, within the Scrum framework." So... The Scrum framework is immutable, the Scrum Master is accountable for everybody sticking to Scrum with all of its events and artefacts, but still everybody should value individuals and their communication more than the process and tools. This is a contradiction and it is coming directly from the Scrum Guide. I am not making this up.

[@MrShikaga]

⁠@@christianbaer2897Thanks for your reply. I think we are in agreement, I just wanted to make it clear that “We are doing scrum” is not an indicator that a team isn’t agile, as the indicator of agile isn’t the process they use, but the ability to choose for themselves. I will admit I have never met any ScrumMasters you describe. I have worked with a few scrummasters over the years and they have all been very sensible and pragmatic people who cared more about delivering quality software than following strict guidelines. I have certainly never met a scrum master who thought it was their job to prevent a team from changing their process. Perhaps they were more agile coaches than scrummasters. That said, very few teams who say “we are doing scrum” have scrum master. Typically they simply mean that they plan and commit to work in a 1,2 or 3 week blocks where the backlog isn’t expected to change, along with all the normal ceremonies of standup, retro, planning etc as opposed to something like Kanban which is obviously much more fluid

[@lucky6666]

I keep telling them to manage for this ideal (getting stuff done) and they keep saying they're agile. That not me driving myself crazy, that's them lying constantly about everything and driving me crazy.

[@MatthewSextonUSMC]

Watching your videos and doing my cardio! 💪

[@HealthyDev]

Nice! Hahaha I love it.

[@CoxJul]

Alastair Cockburn is wondering whether to call it 'packaged Agile' vs 'true agile'; I call it 'commodity agile' vs 'agility'.

[@bitman6043]

There's no fixing company like that. Change the job

[@jasonwitt95]

Thank You! I have been saying this for years. I'm glad I'm not the only one who see this too. At least I know I'm not insane now

[@HealthyDev]

No, you most certainly are not!

[@keim3548]

**buffer your estimates** - I'll be sure to watch your video on estimates, but agile does put emphasis on getting more accurate estimates. Where I see a lot of teams falling down is once they learn to buffer their estimate to protect themselves, they end up grossly overestimating and then they never have a feedback loop to get more accurate next time, because as long as the deal is signed nobody is penalizing overstimation. And in this case, an often otherwise quite good dev will take the extra time to address other technical debt, or look ahead to other backlog items that haven't even been selected for scope, and either start working on those things (including coding!), or gold plating the scope in the current iteration. Where this really goes wrong is that when the agile team tries to look back at their team throughput for a sprint and use it for the next sprint, it's hopelessly muddied by this other stuff.

[@philipoakley5498]

Adding buffers: You should also do it because your ability to estimate is also 'crap'. You have already forgotten to include all those minor diversions and time eater activities and extra coordination meetings that are part of your time estimate, never mind the extra 50% that you could reasonably say was 'managements'. So you extra 40%, plus their 40% (that they'll forget to include) is actually an x2 factor!. And don't for get that in retrospect that 40% extra was identical to just a 30% less than actual. Definitely worth timing those proper 'end to end' times for the tasks, especially the follow up activities eating into the next task when you already thought you'd completed the previous task. PS. It's not just software that has this problem. It ubiquitous. We have a false belief in our own 'goodness'. [to fellow readers] Have a read up on Human error and cognitive biases and remember it's you (&me) that they are talking about!

[@gullijons9135]

I needed this talk 10 years ago!

[@VagrantCode]

In other words, touch grass

[@HealthyDev]

I literally took my sandals off and went walking in the yard after I read this :)

[@bkr_418]

😂

[@AcidGubba]

It sounds stupid now, but I only develop in a mixture of agile development and waterfall. I think you can actually meet realistic timelines that way. Completely agile would of course be great, but then you don't really get a product that meets all the requirements in time. I don't think much of Scrum - I did it for 6 months in a company and it was a total waste of time. And the allocation of tasks in general also exposed weaker developers in the group. Which I personally saw as pretty toxic - it never affected me personally, but that was one of the reasons why I quit.

[@gentlemanbirdlake]

A strategy: Treat this as an indisputable fact: All story points are always 7. no more no less. From the simplest to the most complicated, 7. Always and only 7 agiles. 7. No point playing the numbers game if it means nothing.

[@letopizdetz]

I haven't seen an "Agile" company so far. It's just mini waterfall with multiple short deadlines each month.

[@gr77552]

Could you make a video about why people who deal with the cloud as IT professionals burn out super fast?