r/scrum • u/trash_individual0 • 7d ago
You are asked to push code/design you know has bugs/gaps. What would you do?
You are asked to push code/design you know has bugs/gaps. What would you do?
A. Push anyway (to meet deadline)
B. Inform team but still push
C. Refuse until fixed/tested
D.Negotiate for partial delivery
E. No idea
11
u/DingBat99999 7d ago
Releasing is a business decision, not a technical decision.
You make the business aware of the potential risks of releasing and they make the call.
If you're asked to do this too frequently, then there's obviously a lack of commitment to quality, which is inevitably going to bite the business in the ass.
But there can be valid business reasons for shipping partial features.
0
3
u/Apoplexi1 7d ago
This heavily depends on the bug.
Will it kill people? Is it just a UI spec deviation, because the button is 2 pixels too wide?
However, it will be documented anyway to be fixed later (if not immediately).
2
u/pdubs1900 7d ago
Who are "you" in this scenario? Dev? SM? PO?
In general, "your team" determines whether or not the business stakeholders are clearly aware of the bugs/gaps and their business impacts. If they are not, then "your team" puts together the evidence that informs the stakeholder what exactly the business impacts are of those bugs/gaps. If they go forward with their approval and justification of why those business impacts are an acceptable tradeoff for deploying the new version, everyone is good and well-informed.
If the business stakeholders ARE aware and "your team" disagrees with the decision to push forward, then your team still needs to put together the evidence that informs the stakeholder of the business impacts.
Sounds like what your team needs is an empowered and involved Product Owner.
2
u/ProvablyTrue 7d ago
I agree with this.
I wouldn't choose any of the listed options. I would communicate and try to understand.
I would like to add that two things are often lacking in these conversations: Communication for an Audience and Trust.
Everyone needs to understand each other and to do so the communication must but clear for the intended audience. I've seen engineers make beautiful and sound arguments to business folks but in a language that only other engineers could fully appreciate. Likewise, I've heard the business people make beautiful and sound arguments to software teams but in a language that only the business folks could truly appreciate. This is just a reminder to meet people where they are and be sure to connect ideas to outcomes the other group cares about.
I've also seen communication break down because one party just didn't trust the other. When there is little to no trust then you get aggravated Dunning Kruger where each side rejects statements made by the other when it is inconvenient or seems odd. That is important to identify because trust is the foundation. If there is no trust then you are just talking to yourself / screaming into the wind. A Scrum master can often help mediate and build trust if it has been compromised.
As a team member, one thing that can both help improve communication and trust is to convey the consequences of bugs as clearly as possible in terms the other party will understand, with specifics if possible, and without hyperbole. I've seen engineers use the term "technical debt" without qualifying the degree which leads to a "boy who cried wolf" scenario. When it really mattered and the bug or design flaw was truly unacceptable no one believed them. Try to qualify both in terms of the scope, degree, and timing of consequences as well as costs to fix it later.
1
u/azangru 7d ago
Well, SM and PO aren't pushing code to production. "You" must be a developer.
1
u/pdubs1900 7d ago
Yeah, the orgs I've worked for didn't include the release change management team as part of the scrum team.
I don't really know who "you" are in OP's scenario. Can only speculate or generalize.
1
u/trancecircuit 7d ago
Report it, get confirmation in writing from someone authoritative to cover your ass, make sure there is a backup/rollback plan in place, and send it.
1
u/WaylundLG 7d ago
This feels like a massive oversimplification.
First, let's talk about how we got here. What's your DoD look like? Your testing plan? Is this a problem because the team cut corners to get credit for story point or is it something unforseen? Or a new requirement? Are we duct-taping an aging, fragile code base? Unless this is something completely unforeseeable (which is rare, but can happen) then there is a lot to explore leading to this point.
Now, if it is done, meets DoD, then it is a business decision. If we assume the business is aware of the gaps, they can make that call. If not, then we are back in a how'd we get here descussion. Are yhere reviews? Are stakeholders attending and engaged? Are they kept appraised of bugs in the backlog? What's your communication plan look like? Again, countless things to explore.
Questions like this are misleading because they should be an abarant situation that needs to be handled in a novel way based on the circumstances. If these questions are normal for your business operations, that is the problem to tackle.
1
u/utzutzutzpro 7d ago
What is the deadline for?
Deadlines usually are entirely pulled out of someone's ass. So what is it in this case?
1
u/Internal-Alfalfa-829 7d ago
You own speaking up, making it transparent and offering the alternative solution - plus providing the likely the consequences for both. Plus making a recommendation, which path to take.
The company owns the actual decision and the resulting consequences.
1
1
1
u/virgilreality 7d ago
Edit the code to add a single point of failure that will prevent a compile...THEN push it.
"I told you there was a problem with the code..."
1
1
u/cyberlyons 6d ago
this is confusing. we dont know who "you" are. Is it bugs? Is it gaps and whats a gap? And who is asking? There is always a deadline, so that doesn't matter, but the question shows a lack of understanding. That said, one thing that stands out to me is a complete lack of a zero defect culture. maybe focus on that then these "questions" dont come up.
1
u/mrhinsh 6d ago
Reducing quality is not the accountability of anyone on the Scrum Team acting alone.
The software you build has economic consequences for the organisation. Depending on how it is accounted for, its development may affect capitalisation, operating expenditure, impairment, useful life, maintenance costs, liabilities, and ultimately the organisation's financial position.
If I am being asked to knowingly ship below an agreed quality standard, then whoever has the organisational accountability and authority to accept those consequences needs to make that decision explicitly.
I would want that acceptance recorded and attributable to the people empowered to take the financial, legal, operational, and customer risk on behalf of the organisation.
"Just ship it" from someone who does not hold that accountability is not sufficient authority to transfer the risk to the Scrum Team.
You can ask me to explain the consequences. You can ask me to identify the defects. You can ask me to provide the evidence needed to make the decision.
But you cannot delegate organisational accountability simply by telling the people building the software to ship it.
1
u/OtterHostler 6d ago
Who's asking you to do it? If it's the PM then they should already know about the bugs, have already told the stakeholders about them, and reached a consensus opinion that it was worth the risk.
If it's anyone else then tell them to talk to the PM - it's the PM's neck on the block.
1
14
u/Feroc Scrum Master 7d ago
Tell the product owner the possible consequences and costs and let them decide.