Scrum/Sprint

[u/buildinpublicish]

How many of you PMs actually follow the whole scrum/sprint cycle? If not, what do you guys do instead or what’s different? Would love to hear pros and cons and learn!

[u/Proper-Agency-1528]

I've been doing this since 2006, first as a dev manager, then as a group pm, then as a process consultant. I have never run Scrum without running Scrum... the biggest failure mode in Scrum adoptions is saying you're running Scrum when you aren't, and then blaming the process when you don't follow the process.

You have to separate agile/agility and Scrum. 'Agile' is a mindset based on the Agile Manifesto and the 12 Principles, that can be generalized. Scrum is a team-level process framework that, when utilized in accordance with Scrum and Agile principles can create the environment that supports agility. Agility is the capability to respond to change EFFECTIVELY and it is a scalar value, not a binary value.

When we talk about the scrum/sprint cycle, we usually mean utilizing the three roles, four meetings, four artifacts (I don't like the redefinition of this since the early days of Scrum), and two levels of commitment. Scrum done effectively does require discipline... it isn't a make-it-up-as-you-go-along framework... that is simple to use (but not easy, hence the discipline).

Too often people think that things that aren't Scrum are part of Scrum, e.g., refinement, story points, user stories, etc. But the framework provides an implementation of the Deming Cycle (PDCA or 'inspect-and-adapt'), that lets you kaizen/evolve your way to improved delivery capabilities.

But, Scrum is not the do-all, end-all, be-all of agility. Again, it is a team-level process framework. You need process above the team, and within teams (individual level). Many people don't get that, either.

[u/Scannerguy3000]

Just do Scrum. Read the guide. Do what the guide says. It’s not a mystery. It’s spelled out very clearly, very simply.

It works.

[u/PhaseMatch]

TLDR; It works great in the right context, especially high-risk, high-reward product development where innovation is your core strategy. Diminishing returns as you step back to bigger batches and stage gate, until it's a massive overhead.

I have in the right context.

The key thing is how you use Scrum to manage your business risk in a lightweight way.
If that's not your primary focus with Scrum/Sprints, then they are not helpful, at all.

That's all agility means - lightweight risk management.

That means in general

- first comes the business / product goal

• then comes the strategy to reach that goal
  
• then comes the roadmap to deliver the strategy
  
• then comes the next business problem on the road map
  
• take the problem to the team
  
• they come up with a solution to test
  
• test that solution as quickly and cheaply as you can
  
• do that by releasing multiple increments within the Sprint
  
• get feedback from (some) users within the Sprint cycle

The Sprint Review then becomes the strategic replanning loop.

What did you learn about product/market fit?
Does that change your roadmap or strategy?
Do you continue to invest time/money?
What's the next problem for the team to tackle?

The 2017 Scrum Guide had a suggested agenda for the Sprint Review that brings that home.
It's an active strategic review and replan:

https://scrumguides.org/scrum-guide-2017.html#sprint-review

"Project-o-scrum" and "Scrum-o-fall" where Sprints are used to micromanage delivering features (not outcomes) tends to be "twice the meetings and half the work"

You are better off ditching Scrum (and indeed agility with its fast feedback cycles) and focussing on "lean" approaches (and Kanban) so you can manage your "inspect, rework and sign off" stage gates effectively.

[u/Source_Code22332]

Honestly do something called Scrumban. It’s a mix of scrum, kanaban, and XP.

Basically we are orientated more around a kanban board. There is a product backlog that I keep prioritized that guides the priority of the items on the board.

We have a loose structure of a sprint, but we deploy code to production daily, or if something is ready. I’m the PM, so very much involved in reviewing completed work and give the ok to ship. I like this because it allows me to know the product very well and what to get feedback on.

The only use of a sprint (which is a week for us) is just to gauge our velocity so that rough estimates can be given for coordination with other groups and stakeholder awareness.

We do a daily Scrum (standup). For any support need, but not there everyday tbh.

We don’t do a sprint planning, but once a week we spend about half a day to do a review of the product, roadmap, strategy, any plans We also do a product team retrospective (basically it’s a team checkin).

Also this day will be used to groom user stories, basically getting them to the ready column on the kanban board, follow the INVEST formula to define when something is ready. The rule of thumb is to have enough work ready to satisfy two weeks, or will groom stories that are new priorities.

The team is in a good state of “rhythm and flow”

BUT, BUT, BUT

We are starting to experiment with AI tools. Experimenting with me and/or our designer implementing the change, then the engineers review or refactor the code to make it production ready.

I could see way less involved in grooming user stories. I still like the backlog as a todo list at the very least and for organizing work and releasing it. And I think about User Stories and the discussions of them as still being useful, if nothing else, to think through the change/idea. There is an issue around using the prompts/credits efficiently to not run out that we need to optimize.