5 ms·

There are a lot of reasons for spillover in my experience. They’re all interrelated. First and foremost is that most product/project managers, engineering mana

There are a lot of reasons for spillover in my experience. They’re all interrelated. First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. They may love the glory of leading or assisting a team of software engineers to build great products, but I’ve seen maybe 1 or 2 who are actually qualified to be the agile/process guy/gal. Additionally, they’re frequently counter-incentivized to be meeting jockeys, PowerPoint creators, and “culture people” who simply do not do the job as it’s meant to be done. As soon as ^^ happens, sprints are destined to fail, because the work of sizing tickets falls squarely onto engineers who would probably rather be writing code than talking about it, so they make informal agreements about value of a story point being a day’s work or not blocking tickets that don’t have defined success criteria, or what have you. As such, tickets are not properly vetted and grow to be massive, amorphous chunks of work that either allow devs to hide from the (painful/annoying) process of Scrum and just do their thing. The last (and worst) of the reasons spillover happens is that people are burnt out, unmotivated, or unrewarded by the process. If the “customer” (also a massive rats nest of a concept in Agile) isn’t at the demo and actively interested in the product being developed, any amount of “points” will feel arbitrary and useless. There’s no faster way to lose interest in Scrum than canceling a demo and having your developers lose faith that completing that ticket actually matters to someone.

rgblambda 3y ago
> First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. In my experience this rings true. Whenever I see a ticket with no description or acceptance criteria, a ticket that's blocked by another ticket in the middle of the backlog, or a ticket that's being repeatedly rewritten mid sprint to include work that's already in the To Do column or at the top of the backlog, I feel like walking up to the Scrum Master and going "What would you say... you do here?". Bring this stuff up at retro and blame gets redirected and watered down. The action becomes "we as a team" need to get better at doing the Scrum Master's job. But like you say, they're very fond of big picture stuff like PowerPoints and meetings about doing agile better.
- zerbinxx 3y ago
  Yeah. “We succeed and fail together” - unfortunately, unless this is true from a management and reward perspective, it can never be true at a team level. Additionally anything raised in a retro that contradicts a management edict will never see the light of day. If your PM is appraised by Power Point quality or number of sprint points while engineers are managed by some other criteria, success and failure become asymmetrical and incentives clash.
lamontcg 3y ago
Or spillover happens because the map isn't the terrain and no plan survives contact with the first brittle edge condition in the existing codebase.
- zerbinxx 3y ago
  Sure. To me that sounds related to the “lack of backlog refinement” and “no AC” parts of this. If there’s no text on a ticket, there’s not even a map! Good luck with the territory, in that case.
  - lamontcg 3y ago
    That isn't really backlog refinement though. That is when you start actually doing the task and you realize that plan A and plan B of how to implement the fix or whatever can't work, and fixing it will necessarily be much more time intensive and some sort of plan C or plan D. Often this happens when you go to start changing code and you see how badly the tests blow up on you or something like that.

rgblambda 3y ago

> First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. In my experience this rings true. Whenever I see a ticket with no description or acceptance criteria, a ticket that's blocked by another ticket in the middle of the backlog, or a ticket that's being repeatedly rewritten mid sprint to include work that's already in the To Do column or at the top of the backlog, I feel like walking up to the Scrum Master and going "What would you say... you do here?". Bring this stuff up at retro and blame gets redirected and watered down. The action becomes "we as a team" need to get better at doing the Scrum Master's job. But like you say, they're very fond of big picture stuff like PowerPoints and meetings about doing agile better.

zerbinxx 3y ago
Yeah. “We succeed and fail together” - unfortunately, unless this is true from a management and reward perspective, it can never be true at a team level. Additionally anything raised in a retro that contradicts a management edict will never see the light of day. If your PM is appraised by Power Point quality or number of sprint points while engineers are managed by some other criteria, success and failure become asymmetrical and incentives clash.

lamontcg 3y ago

Or spillover happens because the map isn't the terrain and no plan survives contact with the first brittle edge condition in the existing codebase.

zerbinxx 3y ago
Sure. To me that sounds related to the “lack of backlog refinement” and “no AC” parts of this. If there’s no text on a ticket, there’s not even a map! Good luck with the territory, in that case.
- lamontcg 3y ago
  That isn't really backlog refinement though. That is when you start actually doing the task and you realize that plan A and plan B of how to implement the fix or whatever can't work, and fixing it will necessarily be much more time intensive and some sort of plan C or plan D. Often this happens when you go to start changing code and you see how badly the tests blow up on you or something like that.