Lack of change control is thrashing my team
Posted by baezizbae@reddit | ExperiencedDevs | View on Reddit | 20 comments
How would you respond to a refusal to do any kind of retrospective or analysis on getting better at gathering requirements and acceptance criteria before starting work, when opposing and influential voices in the company are saying “scope changes happen all the time and there’s nothing we can do about it”?
This is the challenge I’m facing at the moment and I’ve had no luck trying to make the counter argument that acknowledges project requirements and acceptance criteria might sometimes change and evolve, but it’s not an excuse to avoid putting any effort whatsoever into crafting a process that allows for more thorough exploration and collaboration with stakeholders up front to minimize the pain and thrash that comes from last minute/unexpected work order changes.
I was accused of complaining without offering help by said influential voices, when instead what I’ve frequently argued for is taking an retroactive approach to figuring out what broke down in our requirements gathering process and where, understanding how it happened, and offering specific ways we can improve towards making the whole process better so that when we have to change an entire work order, we can address it without having to delay or derail other priorities (which is the very problem that spawned the whole discussion).
Thoughts on this?
Electrical-Mark-9708@reddit
It sounds like your team is having several classic problems at once my guess is that stories are not well written leading to rework or confusion and miss deliverables, but I’m also guessing that you’re winding up doing work late at night and on the weekends to make last minute “tweaks” that are a result of poor planning or scope changes.
It might help to remind your technical manager, that scope needs to be locked for sprints. That doesn’t mean you can’t change things within a sprint just that you have to take out an equivalent amount of work when you add work to a sprint.
Once your sprint is set, assuming you have something like a one or two week increment the agreement with product is that they can bring in work but only if they take out an equivalent amount of work this encourages them to get better at planning upfront.
As an IC you probably have a pretty predictable load that you can handle in any given increment. If your manager is OK with your load, then you need to remind them that they can’t simply just add more to it. Neither can they wait until the end of the project and then start screaming up and down due to poor planning that you now need to double your load. The whole point of tracking metrics is to avoid this sort of nonsense.
You can say this fairly diplomatically because you’re not accusing anyone or even complaining you’re just factually stating what your what you’re expected and predictable workload should be and that will encourage them to do a better job of articulating the work that needs to be done
No-Extent8143@reddit
In a similar boat myself. In my case it's a culture of "not my problem" when something goes wrong in Production. And I'm very sad to say I have given up. I can't see any way to change a culture when I'm the only one asking questions like "why no one is doing anything about this P1 alert?". Changing culture without a big churn is almost impossible IMO.
pl487@reddit
Framing it as a retrospective on past failures is inherently confrontational.
Propose the changes you want to see. If they are rejected, argue that they would have prevented problem X. If they are still rejected, let it go.
baezizbae@reddit (OP)
The challenge here is I’ve done literally all of the things you’re recommending right here, including just letting it go after things fell on seemingly deaf ears, so I decided to put my nose down to the work and let management decide what to do, if anything, only to get called out and asked why I wasn’t taking more ownership of helping improve the process.
So I tried once more to offer workable ideas and solutions we could try, pointed to specific examples where I thought it might have helped, and only then I was immediately accused of complaining. Pointing to the specific example of one project where things went completely off the rails and over a cliff was also shut down.
chrisza4@reddit
For this comment I suspect it is rhythm issue. I’m not sure if it is the case.
Normally when management decide to “improve process” they will have limited time to present senior leadership a plan. Let say they told ceo that I will take a week to come up with improvement . They will ask you about the improvement and if you don’t give them your plan in this window, they will call you out for not taking ownership.
But then once this window pass and they presented improvement plan to their ceo already, your suggestion will break their plan and will be counted as “complaining”. They will be like “why don’t you speak at the time. Now we are committed and can’t change.”
I am not sure if that is the case for you. It sucks if your management fail to communicate this but it can happen.
prescod@reddit
If it is true that scope change is sometimes inevitable then it is also true that a scope change does not mean that “something broke down in the requirements gathering process.”
IMO, Figuring out requirements as you go along is fine as long as there are no hard deadlines. And hard deadlines such even if you have strict scope in place.
Big_You_7959@reddit
Sounds like somewhere i used to work. If i were you, I'd be looking for a new job or take an upcoming project, and go we are trying this my way, "i want to do x, y, z - like it or lump it"
Only so much one can do to try and change working practices - that if the higher up won't change ( fear of change ?, the "we've always done it this way and it's gotten us this far, why change now?" approach)
templar4522@reddit
You either threaten to leave, if you think it is going to be effective, or you just leave. No point in compromising your mental health for these people. Find a better job.
Xaxathylox@reddit
Stop trying to take responsability for their incompetence. If there is no acceptance criteria, then you can't fail. Let it bomb in production a few times, and decline to be available during weekends. They will either fire you, or they will learn to communicate better. Either way, its a win.
mechkbfan@reddit
Overall agree except the "fire you" part lol
Sometimes you just need to let it go, stick to the 9-5, and let others learn the hard way.
As long as keep a clear papertrail of communication of issues to the right people in a constructive way then anytime someone tries to throw you or the team under the bus to upper management, then be ready to print those bad boys off to highlight the trend.
Yes I've done that before and it was glorious.
Also, I've been in similar position where people are too busy with their day to day jobs to do requirements properly. Annoyed me for first 6 months because there was so much waste, but over time I realised that if they let something drop in their day to day job, it'd cost them $100k+. While if I'm delayed a week, it costs them <$10k. Very different orders of magnitude of cost to business and I appreciate now why I'm the bottom of the ladder.
originalchronoguy@reddit
The title is not correct, that is not change control. Change Control has to do with the process of release. In your example, scope creep/requirement changes are a small part of it.
But, what you are writing about is different and scope creep is normal part of agile. There are some checks and balances to minimize that scope creep in iterative chunks.
Acceptance criteria should acknowledge the work is iterative and able to change and that is tracked.
Let me give you an example where someone like you slows down the process.
There is some web portal. It is a project with a lot of screens. One screen for managing users. Another for jobs/projects. Someone like you would demand everything is written out so there is no ambiguity.
Where as, I would dictate. Sprint 1. Build the shell. Let see how it looks. Throw in some mocks to make sure design is OK with w. Sprint 2. Show the list of projects. Lets not worry about filters or pagination. Just show how data visually looks. Sprint 3. Add filters/search,etc
That is iterative. I've had people that demanded all the screens done, all the functional things done. As things can change. After Sprint 2, you realize. they wanted to change the filter from left column to top row. But that is just a change that can happen at the end.
At each step, each sprint, things are closed off. The project isn't finish but major chunks are wrapped up. A blank shell with empty layout is still a win. It shows progress. Acceptance criteria acknowledge that phase is done and changes may happen.
My analogy to the above scenario is we are building a house. Lets worry about the roof, the walls, and foundation. Next Sprint, lets worry about the electrical for all the rooms. Last Sprint, each room can worry about the placement of their windows. Otherwise, you fall into the law of triviality: https://en.wikipedia.org/wiki/Law_of_triviality
moving-chicane@reddit
I foresee delivery problems, a ton of tech debt, and engineering leadership replaced in some years.
Your situation sounds like lack of seniority and experience with people who are saying it can’t be done better. What they are saying is they never been part of doing it differently, so they wouldn’t know.
How are you planning your work? Do you have acceptance criteria? Is your Jira filled with one-liners that are difficult to estimate? Is engineering in general fine with it?
endurbro420@reddit
I see your company does “agile” the same way my previous employer did.
How long has this been going on? Have any major projects been delayed due to said issues?
In my experience that is what it takes for them to begin to see the error of their ways. It is also totally possible that even when faced with setbacks they will just descope things to hit the target and never learn their lesson.
The worst part about these type of companies is it always feels like everything is on fire as nobody knows what to actually do.
drumDev29@reddit
They will just blame devs for delays and take zero responsibility
baezizbae@reddit (OP)
Hello!
I don’t know how long it’s been occurring in total, but definitely as long as I’ve been here (coming up on a year and a few weeks now), it was one of the first things I picked up on during my probation phase.
Yes there have been. And it was much as you described, things were descoped, priorities got changed, a couple customers expressed displeasure but soaked up the delays because there would be no way to extricate from the project without significantly more cost to start over with a different partner.
Biz leaders who have the decision making power over exactly this problem admit there are serious deficiencies in what we more doing, but like I mentioned in the op, actively shut down any attempt to prop things up so we’re better set up for repeated success.
endurbro420@reddit
Yep that sounds exactly like my last company. Big org wide retros regarding why the big project got delayed and was pruned of so many features. They say “we will do it differently next time” and then next time rolls around and it is the exact same situation.
I had done what you did and said many times “this isn’t how agile actually works” just to be told to not be negative.
The company I was at never changed and by all reports from people still there, it is still a dumpster fire.
My advice would be to make note of all the stuff you see that is lacking and then you can point back to it when stuff is delayed and on fire. Otherwise management thinks you are just saying “I told you so”.
MiserieMiserie@reddit
What actions have you taken so far? Have you tried to define the requirements or propose a concrete approach? If you're confident that your way is the right one, then show it.
I once worked with someone who constantly complained about how the process needed to change. He talked about big, ideal solutions—but whenever we asked him to take the first step or map out a plan, he backed off. It was always someone else’s responsibility—usually "higher-ups"—to overhaul everything at once.
Here’s the thing: if you want change, be the change. Clearly document your vision, outline the ideal process, in detail and identify the first actionable step you can take. Then bring it to your manager. Make it easy for others to say yes.
rdem341@reddit
Some thoughts
1) look into some concepts from DDD, might be helpful here. Specifically, I am thinking about bounded context, ubiquitous language and models.
Having sessions with stakeholders to build some of these upfront helps minimize unclear requirements.
2) Understand and explain that problems caught early are cheaper to fix. It's easier and cheaper to clear up requirements early in the project. It's cheaper to fix them now then later.
3) Up front analysis and effort is not waterfall. It's still possible to be iterative and agile, as discoveries come through.
Ideally, there are less and less major changes necessary late in the project because of upfront analysis.
It can be really difficult to convince upper management/executive to change their minds and bias. I think it will be helpful to create some slide decks to explain your perspective and use data and examples to highlight your points.
goatanuss@reddit
There are teams that allow for scope to drastically change and do it well. You just need to change the amount of engineers on the project if it can be parallelized or change the timelines.
If the scope doubles so should the timeline. Reasonable people will be fine with this.
smutje187@reddit
Openly communicate that when requirements change commitments are meaningless and quality will deteriorate or deadlines will be missed.
Agile doesn’t mean no planning, it just means shorter cycles cause 30+ years of experience have shown that longer commitments are meaningless anyway.
If your managers are fine with random deadlines and delivery by accident - it’s a question whether you’re fine with that - if they prefer quality maybe argue from that position. Alternatively bring up the topic of Definition of Ready - what constitutes that a Story can be worked on.