Open Letter to all the People Being Forced to do Scrum

Tks Steve! I'm sharing your post to my colleagues. o/
From my point of view cross functional teams struggle with efficacy & efficiency. Devs want to code, designers want something else, data scientists something else and so on. Imagine in IoT environment where we have several different specialists with deep understanding of each area, efficacy & efficiency is a constant issue... let's keep learning and practicing.

Thanks for sharing.

I do know what this is like. I've had too many experiences where I efficiently created personal deliverables that had zero value on their own. It wasn't until I combined what I did with other that real value was created.

Good publication! I will share it with my colleagues in LI. You made a clear summary of what is a life cycle of the project under any methodology. What makes it important for an organization to adopt a Project Methodology is to achieve the passion, commitment and culture of "Continuous Improvement of the Process". Thank you for sharing this incredible publication.

The problem is that a lot of people forced to do scrum don't get the benefits you list because their organisation still imposes itself in those areas. Yes, that means the organisation is doing scrum wrong but I believe that's the source of a lot of the complaints.

Hi Steve,

Great perspective.

I think a sister-article would be interesting from the perspective of a company who wishes to support Scrum. I can immediately think of some important items which nearly mimic yours above:

1. Our company needs to get important work done, and the people closest to the delivery of that work will make most of the detailed decisions. Others will support those people by providing information, access, authority, and the minimum-necessary-bureaucracy.
2. To ensure the best return on the investments we make with our teams, we value quality over speed, user feedback over specialist's assumptions, customer collaboration over contract negotiation.
3. We don't really care a team's *way of working*, but we know it's risky to send a group of people on a months-long, large-batch, expedition to implement the contents of a business requirements document -- so we ask instead that they work in batches of work which can be fully integrated and released in periods not longer than a month or so.

et cetera.

Thank you for sharing, Steve.

Passion is such an important part of continuous improvement. Improvement is not always easy and passion helps you get over the rough patches.

I agree. I hope people in those circumstances will read this post and use it to trigger some discussion in their organization.

"I thought you wanted us to do Scrum, but it says here that if we're doing Scrum, there are benefits that we can expect".

Looking forward to your sister article :)

Haha, I meant "I think YOUR sister-article..."

Well... whether either of us act on it I'm sure it'd be helpful to some.

I notice that Sprints are implied, but not called out explicitly. I would say that Sprints are the defining characteristic of Scrum. Specifically, tour point #4 seems to offer more flexibility that I've seen in Scum implementations

During our meeting, my teammates and I need to create a plan to achieve the above work, but it only needs to have enough details to get started.

The way I have always seen the Scum guide interpreted is that the work items to be included in the Sprint must be broken down and estimated (so they can be compared to the teams velocity). Some smaller adjustments can be made during the Sprint. We may not complete everything in a Sprint. But starting a Sprint with the plan of adjusting content as we go, although sensible, reasonable, and intelligent, doesn't seem to be in keeping with the definition of Scrum.

I used to be a proponent of Srcum, but I no longer advocate it because:

1. The fixed duration time-box. I consider this advice to be outdated given that many teams are delivering more frequently than every 2-4 weeks, and I find variable cadence based on delivering as soon as possible once a valuable objective is met is preferable to waiting until the time-box ends.

2. I've not found full decomposition of 2-4 weeks worth of work to be practical. You can start with a plan, but even seemingly small, simple tasks, often carry large "unknown unknowns". A challenge I've heard referred to a "Scrum-er-fall"; and I agree with that characterization.

I do still see benefits in the other practices and continue to advocate and apply them. But Scrum without Sprints are extreme "Scrum-but" at best, so I wouldn't call it Scrum at all. I think Scrum was novel, almost revolutionary when it was first introduced. But, I consider doing Sprints today to be a regression from what I would consider modern practice. So I still battle against forced Scrum (I am among those forced to use Scrum at work), because while I recognize many benefits we've gained from it, I think it now keeps us tethered to an outdated practice.

Thanks for taking the time to leave a comment.

I generally agree with your two points.

I would encourage you to have another look at the current version of the Scrum Guide.

The Sprint cadence is for goal setting, gathering stakeholder feedback and looking for improvements, not a delivery cadance. Teams are free to deliver when every they have something of value.

The estimation and decomposition work that a team does in Sprint Planning can be really lightweight. Create a goal; highlight the PBI you think you need to complete the goal; agree that the work can likely be completed in your Sprint and then start working so you can start discovering what you don't yet know.

You could have a look at the work Scrum.org has been doing with members of the Kanban community to encourage Scrum teams to use the Sprint for what it's meant for and not to as mini-waterfall.

Ta.
Steve Porter

Thanks Steve!

Definitely going to share this with our ScrumMaster guild!

The current version of the Scrum Guide says the sames as previous: Sprints have "CONSISTENT" durations throughout a development effort. Unless i am not understanding as the Guide hopes, it means "fixed duration time-box" or not?

Yes, the duration of the time box is fixed, but what you do in the time box isn't.

The Sprint cadence is for goal setting, gathering stakeholder feedback and looking for improvements, not a delivery cadence. Teams are free to deliver when every they have something of value.

Thank you for clarifying it. Talking about Sprints, The Scrum Guide says "A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed". If we deliver many times during a sprint, how we inspect the Increment at the final of Sprint, because parts of it were delivered and maybe inspected previously to the Sprint Review?

@disqus_77dEaLQk6n:disqus, what is the point of having sprints at all in such case? Especially with fixed duration?
What is the point of having demo sessions once per sprint if the delivery is done continuously? It looks like first we provide something to customers and then, during demo, we realize that this is something wrong and we revert.

When the work you're doing is complex, there's some advantage to having some simplicity built into your process.

Having a set time on the calendar to review what's new and gather feedback may make it easier to get everyone together.

You could say the same thing about planning.

A regular cadence removes some complexity.

Thanks for your answer. I fully agree with the statement "consistency reduces complexity". But where we are with our pros and cons?

Pros:
- reducing some complexity by consistent schedule

Cons:
- more efforts spent on backlog refinement, planning and daily scrum (all team takes part instead of a smaller group who will really work on this story)
- planning and re-planning issues because of new inputs during the sprint (high-prio defects, urgent features, etc)
- low flexibility (as you need to wait until sprint ends to introduce new item, otherwise efforts for re-planning)
- irregular flow with peak load at the end of the sprint (not only for people, but for computing resources as well)
- longer feedback loop (while waiting for retrospective, something can slip out of the mind)

<neutral:>
- team building and motivation by tight deadlines (although usable in a short-term perspective, tight deadlines in time may result in burnout and demotivation)
- optimized development ("YAGNI" and no time for "gold-plating" might be useful, but has an ugly alternative of releasing unfinished work: not tested, designed poorly, with no documentation, etc)

Not so many "pros", don't you think so?

There are more cons in your list, but some of them can be mitigated and sometimes the pro is so awesome that it makes a list of smaller cons not as important.

and don't forget, the Sprint cadence just states that you must do the thing 'at least once a Sprint.' If a team needs to do it more often, they can. Including introducing new work. High priority work arises, then do itI I would hope that a team would consider the impact on the Sprint Goal before they start that work.

Team wants to hold a mid-Sprint retro, do it!, (actually, if we suddenly had to deal with unplanned high-priority work, I think a mid-Sprint retro to discuss where the work came from and why it couldn't wait would be a great idea!). :)

I think we may have a different view on what the Sprint constrains. You can release when ever you want, you can replan your work when ever you need to, you can retro when ever you want. Just make sure that at least once a month, you create a goal, you create a plan to deliver the goal, you meet near to end of the month to get feedback from your stakeholders and then get together as a team to see if there are things that we can do better. Other than that, you're pretty much free to do what makes sense.

Having a sprint review a few days after you’ve delivered seems to be ideal actually... gives the team some time to gather data/feedback on that delivered increment. Sprint review discussion would be around what was the actual customer outcome (and the data to support it), instead of hypothesizing what impact it may have if/when the increment is delivered (the less desirable but more common discussions in my experience). If there is no data yet and the new feature has been live for a few days already, that may also tell you something.

Sorry, just seeing this now.

The Scrum Team can decide what needs to be discussed in the Sprint Review. Maybe you don't need to talk about everything that was released because it was already discussed. Or maybe you do want to talk about it again because you've learned something new since the last time we've reviewed the work.

Yes, this does makes things a bit more complex, but it might be worth it if you're delivering value sooner.

Yes, exactly right!

As a Product Owner, I'd love to know that we released some new functionality and no one has used it. This will help us decide what to do next Sprint.