Your Project Is FAKE Agile, What Now?
Vložit
- čas přidán 2. 06. 2024
- It's finally sinking in. Your software project is FAKE agile. Is there anything you can really do about it?
The sad reality is that more companies have fake agile software development processes than those that are authentic. You can fight tooth and nail to try and change the system, or you can accept when there's nothing you can do.
Being a truly agile software company is not usually something any individual programmer or manager can change. It has to start from the top. If the company doesn't do agile budgeting and have a culture of adapting to feedback, they are a typical feature factory focused on output over outcomes.
In this episode, I offer some practical ways to let to of your frustration and do the best job you can given the circumstances. If you're the type of software engineer, manager, or any other tech job role that considers themselves a change agent - you may be challenged by this one.
But this episode isn't for everyone. It's for those of us who are experiencing mental health issues, burnout, and anger over our software project being fake agile. I hope it offers some relief.
Join this channel to get access to perks:
/ @healthydev
Support me on Patreon:
thrivingtechnologist.com/patreon
TechRolepedia, a wiki about the top 25 roles in tech:
thrivingtechnologist.com/tech...
The Healthy Software Development career guide:
thrivingtechnologist.com/guide
Learn about one-on-one career coaching with me:
thrivingtechnologist.com/coac...
RELATED EPISODES
Spot a Fake Agile Team in Under 7 Minutes!
• Spot A Fake Agile Team...
An Agile Budget Keeps You From Being a Code Monkey
• An Agile Budget Keeps ...
Is Your "Agile" Backlog Really a Waterfall Project?
• Is Your "Agile" Backlo...
Can User Stories Make Software Projects Late?
• Can User Stories Make ...
Are Programmers Really To Blame For Bad Estimates?
• Are Programmers Really...
CHAPTER MARKERS
0:00 Introduction
1:30 How to Cope With FAKE Agile Development
3:25 1. Stop Forcing Change
5:10 2. Exercise
7:25 3. Become a Requirements Lawyer
10:33 4. Charge for Changes
13:12 5. Protect Your Reputation
15:12 6. Define Your Own Success
21:54 Episode Groove
#agile #programming #career - Věda a technologie
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.
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.
@@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.
@@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....
"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.
@@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.
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.
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.
Ditto. Back here we call it 'watergile'
Agilefall.... headless chicken trying to swim up the waterfall.
Wagile. Waterfall with sprints.
Waterscrum is where it's at! :)
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.
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.
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.
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.
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.
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 :(
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.
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.
Exercise actually saved my career. Can't agree more.
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,
This hits a cord. I've never been on "agile" project. It's a myth to me at this point lol
I have several times, it's fricking incredible. Unfortunately it's like an albino - incredibly rare.
"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.
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...
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.
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.
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.
@@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!
@@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.
I'm working at such company. Simply put Agile™ is not agile. And the creator of agile hates what it has become.
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.
@@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.
When sprints become deadlines, and estimates don't makes sense anymore, you have failed agile... but that's were most are unfortunately
At this point id rather find a company that doesn't use agile. At least no pretending anymore .
I just come for the chill vibes and the guitar interludes
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.
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.
Great attitude despite adversity!
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.
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!
Thank you sir!
I really like the new logo and matching background behind you. The complementary colors are very satisfying.
I've come across a lot of devs who hate Agile/Scrum/SAFe but they really haven't experienced the real thing.
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.
That's much like saying: "oh, but people have never experienced *real* communism".
I do prefer the duck test: if most instantiations of Agile fail, then there's probably a fundamental flaw in the system itself. And it is this: it's sold as pragmatism, but taught in a completely dogmatic way. It attracts, and creates, dogmatists. It's bound to fail.
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!
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
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.
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.
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.
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.
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.
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
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.
Yeah absolutely. Agile is not appropriate in companies that want long term forecasts.
@@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.
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.
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.
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!
Thank you! Welcome back to the channel :)
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.
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.
Thank you!
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.
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.
I agree. You may be able to improve, but don't stress over it. Talk to those who want to listen only.
Wise words. Took me WAY too long to learn that.
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.
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.
Glad it helps. Took me over a decade to start learning that one...
The 1 on 1 talk I needed. This is such a reality check. Thank you for raising this.
Wonderful episode and very true recomendations. Keep it up!
Channel content is great, but comment section is among the best I've seen!
Yeah the community is pretty amazing (most of the time, few trolls lol).
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 :) :) :)
Lol! I don’t think anyone wants to watch me work out 😂
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.🤗
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.
These are gold !!!
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."
Glad to hear! That’s exactly what I’m hoping to help people like you experience. Hang in there.
Thank you for this advice. It's really eye opening for me.
You’re very welcome! ❤
"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!
Thriving Technologist, You're the best! I subscribed because I love your content!
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.
Man those guitar interludes warrant a sub on their own
This was great. Spot on and great recommendations.
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.
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.
Buffer 100%, deliver at 75%, chill for the rest of the time.
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.
I exclusively work on fake agile projects.
Haha! I can see this on a resume:
"Certified in fake agile"
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 😅
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 👍
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.
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.
@@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.
@@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.
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.
Watching your videos and doing my cardio! 💪
Nice! Hahaha I love it.
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.
#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.
Really great video for you new channel
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
#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?
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.
@@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
@@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."
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.
when you hear such a statement, just assume agile == null and so nulls out the entire statement. Does wonders for your peace of mind. ;)
Best advice I've heard in years.
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.
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.
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.
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
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).
I needed this talk 10 years ago!
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 😏
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.
@@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 🌍
Could have used advice like this 6+ years ago😅
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.
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.
Scrum master is a bs job. Might be good people who happen to have the title but the job itself is less than worthless.
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.
@@PoppySeed84 some developers are immature children. But this should not be accepted. Our field needs more responsible developers.
@PoppySeed84 yeah that reminds me of a prior episode I did, "Why Do Managers Treat Programmers Like Children?": czcams.com/video/Qp_yMadY0FA/video.html
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!
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.
"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.
amazing video! thank you
Happy you enjoyed it. Thanks for the feedback!
Great video man
The 1st and 2nd advice are the best ones. Just stop caring too much about such things 😌
In other words, touch grass
I literally took my sandals off and went walking in the yard after I read this :)
😂
It’s interesting how many of these advice aligns with stoicism.
p.s. Do you have a video of yours that you like to point to that explains what agile really is (or should be)?
*"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.
I wish I found this channel 15 years ago.
It didn't exist then! :) Welcome to the channel, hehe.
There's no fixing company like that. Change the job
I should've seen this video early last year
Could you make a video about why people who deal with the cloud as IT professionals burn out super fast?
**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.
Excellent guidance and much needed for me. God sent video this is for me
A lot of big companies do something like Scaled Agile which isn't Agile at all.
"You don't really need to write requirements - just a high level user story and then start building it". That's in opposition to agile practices on many levels. The main concept it violates is progressive elaboration. You do **need to elaborate in sufficient detail** at the "last responsible moment". This is in a big contrast to the old ways of waterfall where I would literally have to write over one hundred pages of functional requirements for a dev team of 8 to consume and sign off on.
Software projects are just hard to get right, and there is no methodology that can magically change that. Waterfall was really hard to get right too! All those detailed requirements documents? Mostly garbage. I've been lucky enough to work on some really good projects, and with some really good customers, but there's still no getting away from the fact that it's just hard to get right, and most companies just aren't very good at it. I often say we're like medieval cathedral builders - we have these amazing visions, but we don't yet have the techniques to deliver them reliably, so we keep building stuff that falls down. Maybe we'll figure it out in another couple of hundred years...
I worked at a company that constantly bragged about being "agile". The clown who was the product owner also installed himself as the scrum master and eliminated retrospectives because he was too fragile to handle any feedback from the team. PATHETIC.
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.
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.
Love the new logo; still getting used to the new name. But speaking to this piece, it makes me sad. The reality is that nearly all businesses are trying to deliver rapidly, so the excuse that we have time pressures for delivery shouldn't mean we give up on agile principles.
I understand. I'm not actually advocating giving up on agile principles. I'm advocating trying to force agility on executive management that don't support it (fake agile).
I hate the name "Agile". Often it's just a buzzword management uses to believe that we can build stuff as fast as possible but they have no idea what Agile really is.
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!