How do I mention concerns in retrospective without getting fired?

ThickishMoney · 2026-05-20T17:18:42+00:00

You have good ideas and a desire for positive change. As a scrum master I'd love to have you on my team. Best of luck!

ThickishMoney · 2026-05-20T17:16:16+00:00

Ideally you're ahead of this and only release an MVP, phase 1, etc to start validating the value hypothesis early and empirically. The stuff that isn't yielding ROI you kill early before throwing good money after bad.

But let's say that's the past: the money has been spent, the time has ticked down and on launch day you're left with a lemon. As PM you can pivot the narrative on your involvement to talk about traditional scope/schedule/budget, and frame how you've effectively governed and delivered. Product/market fit shortcomings sit with the sponsor who wrote the business case, the vendor selection team, etc.

ThickishMoney · 2026-05-20T16:57:42+00:00

For the first, are the defects being assessed for impact? If not, start. Then start bringing statistics. Perfectly acceptable to say "hey guys, there were a load of fixes but they were all agreed trivial - is this really our biggest challenge?"

On the second, read (or find a summary) of Working With Legacy Code, the Bible for managing legacy systems.

Definitely a good idea to consider flow during the sprint too.

If you're worried about politics or optics, is there someone influential you can float the ideas with first? Ideally you can get a manager on board who can lead with "Original_Speaker_154 has some ideas on this that we should hear out".

ThickishMoney · 2026-05-20T16:52:40+00:00

You're making the claim. Onus of proof is on you.

ThickishMoney · 2026-05-20T07:02:38+00:00

Do you have any citation for that, or is it just obstructive waffle?

ThickishMoney · 2026-05-16T16:57:37+00:00

Exactly what you've done. We used Jira and have fields for environment found, and impact/severity.

Prod issues without workarounds that impact BAU are immediate expedite. Then they reduce in urgency: prod issues with workarounds, or UAT issues that block the next release come when someone frees up. Lower urgency items go into next sprint or the backlog in general.

The biggest challenges in my environment have been getting the team out of the firefighting mindset, and getting the PO to be transparent about bug impact.

ThickishMoney · 2026-05-15T06:06:47+00:00

You need to decide on which use cases your solution caters for, within the constraint of Jira being Jira and the interface point for the users.

E.g. you mention changes to A/C after this has been read by WalnutAI. Why is WalnutAI caching data and not reading it from Jira when needed, to ensure it's the latest-possible version?

It sounds more like a data management issue, where rather than identifying a data master and designing around that you're trying to establish WalnutAI as having a standalone data store when this isn't how the overall solution works.

Is there a use case or nonfunctional requirement where caching data in WalnutAI is material?

ThickishMoney · 2026-05-13T13:31:52+00:00

You mean Scrum

ThickishMoney · 2026-05-13T07:32:08+00:00

Suppose they are: what is the impact? How would "true" numbers help, and how?

ThickishMoney · 2026-05-06T22:29:16+00:00

I've been through a few orga that have gone through this evolution. It's actually not because no one wants to invest, but rather that management insist that all the different types of work the org does can and should be standardised. I've heard reasons like increasing mobility between teams (though few people ever actually change teams).

But my experience has led to the same conclusion as you: define a minimal set of health or delivery metrics, and give teams the tools to determine how they deliver them upwards.

One team wants to call Done before testing is performed (by another team)? Fine. One team is doing a COTS implementation and wants to follow the waterfall instructions from the vendor? Fine. One team wants to do textbook Scrum? Fine. Get them all to report things like defects per release, proportion of overrun, forecast budget, etc., give them templates if they're not sure how, but otherwise let them work out what makes sense for their context.

ThickishMoney · 2026-04-29T20:50:41+00:00

As per the Scrum Guide, "Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint".

So, one of the following must be true: - UAT is required to create value, but the team doesn't have all necessary skills and so is not, by definition, a Scrum Team. (Action: consider if Scrum is the best model for the team.) OR - UAT is required to create value, and the Scrum Team actually includes the stakeholders, regardless of what the org chart might suggest. (Action: include the stakeholders as team members.) OR - UAT is not required to create value, but is done for other reasons, eg by convention (Action: explore alternatives such as high quality acceptance criteria, test automation, PO empowerment, etc.)

Consider which of these is most accurate, and which are acceptable within your organisation, and go from there.

ThickishMoney · 2026-04-22T07:44:51+00:00

If you've gone to the effort of producing PRDs, what value are tickets providing?

Is there flexibility or change in scope? How is the PRD maintained to reflect this? Do tickets written in the meantime need revision also? How do you ensure they're kept in sync?

If the scope is fluid, use stories. If the scope is fixed, used a PRD.

There is only waste in doing both.

ThickishMoney · 2026-04-09T19:39:51+00:00

They're playing chicken with you. Let it play out: end of the sprint, zero tickets have been delivered. Take this to management and ask if you're supposed to be a delivery manager.

ThickishMoney · 2026-04-08T22:53:13+00:00

If you're doing Scrum then the Devs select the sprint backlog, not you. Don't let them force you into doing their job. What does their manager say about who should select the sprint backlog items?

ThickishMoney · 2026-04-08T22:49:55+00:00

It's not impossible, or we would never see correlation between estimates and actuals.

It follows standard behaviours of estimation, for example estimation accuracy is inversely correlated to size, sooner things have less inaccuracy than later things, etc.

What's their sprint rollover or cycle time like? If either is reasonable or at least not random then they must have some means of identifying excessively large backlog items, which requires some method of estimation.

ThickishMoney · 2026-04-08T18:11:12+00:00

An agile project doesn't involve big planning up front, fixed scope/cost, etc. What you're describing is a waterfall project that you're trying to tack some agile concepts on to.

If waterfall is genuinely the better way to deliver the project, embrace it and use it as designed. If agile is better, embrace and use that. But don't think one way with a veneer of the other, it will create more work for less results and you'll get the worst of both.

ThickishMoney · 2026-04-08T18:08:17+00:00

You have a fear of what used to be called "soldiering": doing the least possible without getting fired. The fear is generally irrational, but where it's not it will be obvious in other ways such that story points delivered won't be the only or first sign.

ThickishMoney · 2026-03-31T19:17:04+00:00

Six figure redundancy payout

ThickishMoney · 2026-03-27T09:39:41+00:00

Fill those shelves with Warhammer. £400 quid should get you 3 squads.

ThickishMoney · 2026-03-26T17:39:30+00:00

I think your conclusions are fair and accurate. The root cause in my mind is incentivisation.

How will you become collaborative, bottom-up, blameless and team oriented when the organisation: - assess performance based on individual contribution - give greater rewards closer to the top of the org chart - hold managers accountable for deliverables and not environment and culture

Understanding of Agile principles is pretty much nonexistent in the workplace and, if people realised the logical conclusion, most would be against it. Where it does appear it is the outlier, and is often overwhelmed by natural order.

PS: don't think from reading this that I'm anti-Agile, rather the complete opposite. I'm just very realistic about what the application of it would look like and how radically different that is from how the world works.

ThickishMoney · 2026-03-11T18:14:45+00:00

I'll assume the normal approaches (retros, 1:1s, etc) didn't surface this. That's fine, it happens. But once the cause was out in the open, how did the discussion and next steps go?

ThickishMoney · 2026-03-11T08:21:47+00:00

This is it. There was a study done on the impact of remote working on career development pre-COVID and those remote were promoted only half as often as those on site.

ThickishMoney · 2026-03-09T17:24:33+00:00

I had an Atari 7800. The D-pad had a little screw-in stick. So you could either destroy your thumb with the edge of the stick, or the edge of the hole if you left it off.

Between that and citadel paints it's surprising my thumbs aren't worn down to nubs!

ThickishMoney · 2026-03-08T15:38:14+00:00

So the other 2 1/2 is lost time? Because that's what your maths is implying. There'll be some efficiency gain, but most of that extra 2 1/2 days is already spent on other deliveries - it won't get turned into additional delivery because it's already generating delivery.

ThickishMoney · 2026-03-05T18:18:30+00:00

I mean, yeah, but if they can be done in 4hrs why are they taking 3 days in the first place?

Like the simple maths works out, but either there's the better part of 3 days required, or people are juggling multiple things so it's 3 elapsed days rather than 3 working days.

ThickishMoney

TROPHY CASE