Skip to main content

Open Letter to all the People Being Forced to do Scrum

July 14, 2019

I've been thinking about the people who complain about being forced to do Scrum.

I agree that forcing self-organizing teams to do something seems counterproductive.  However, even in that scenario, there are only a few hard and fast Scrum rules. Anything else I'm being made to do is not Scrum's fault: 

  1. My teammates and I have to meet once a month to come up with a goal we can accomplish together in the next month. To help make sure the work we're doing has value to the organization I work for, someone on the team is going to help decide what work to achieve that goal would be most valuable.
  2. We need to make the work that my teammates and I pull from available to the people in the organization for whom we work, however, someone on the team has the final say about what's in the list. 
  3. The items in the above list need to include the order in which we think the work is going to be started, a description, an estimate, and some indicator of value. Those four properties can change whenever we discover something new. 
  4. 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. 
  5. My teammates and I have to meet once a day to talk about how we're going to work together on our plan. 
  6. We need to keep our plan up to date. 
  7. The work my teammates and I do needs to meet a predefined level of quality. The organization I work for may set a baseline, but if that doesn't exist, we can choose that predefined level of quality. At the bare minimum, what we've produced during the month must be usable.
  8. My teammates and I have to meet once a month to get feedback on the work we did from the people who care about what we're building. At this point, our work needs to be in a state where it meets the predefined level of quality and is usable. 
  9. My team has to pause once a month to talk about how we can improve how we work together. We have to come up with one improvement for the next month. 

So yeah, that's a bunch of stuff I'm forced to do, but it doesn't feel so bad when I consider the autonomy and organizational support that comes with Scrum:

  1. Other than the rules I've listed, no one from outside my team gets to decide how we're going to work together.
  2. I have input on the goal our team is trying to accomplish, and I have the final say on whether I think the goal do-able or not. 
  3. My team get to decide how we estimate our work and only the people doing the work on my team decides what those estimates are.
  4. No one from outside my team gets to decide what we work on and the people doing the work on my team get to choose how much work we think we can accomplish.
  5. No one tells us how to run our daily meeting, where or when to hold it and who gets to participate.
  6. The organization I work for ensures that my teammates and I get a minimum of 20 hours a month to plan our work, review the work and discuss how we want to improve. We could use less if we don't need that time. We could do more if we decide there's value in it.
  7. The organization needs to support someone on the team whose job it is to help us understand these rules and to get the most benefit from following them.

Forcing a team to do Scrum isn't the best approach, but if you are in that situation, understand the value it delivers, and appreciate the autonomy that comes with it. 

P.S.If you think I missed anything in my lists, please add a comment, and I'll be happy to update it.

Ta.
Steve Porter


What did you think about this post?

Comments (22)


Luis Carlos Guimarães
10:28 am July 15, 2019

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.


Steve Porter
08:57 pm July 15, 2019

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.


Greg Garcia
04:19 pm July 16, 2019

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.


crThanatos
04:42 pm July 16, 2019

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.


David Sabine
07:47 pm July 16, 2019

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.


Steve Porter
08:16 pm July 16, 2019

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


Steve Porter
08:17 pm July 16, 2019

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".


Steve Porter
08:18 pm July 16, 2019

Looking forward to your sister article :)


David Sabine
02:29 pm July 17, 2019

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.


Daniel
11:21 pm July 17, 2019

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.


Steve Porter
07:15 am July 18, 2019

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


Daniel
02:58 pm July 18, 2019

Thanks Steve!

Definitely going to share this with our ScrumMaster guild!


guino3
06:25 am December 1, 2019

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?


Steve Porter
11:09 pm December 1, 2019

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.


guino3
10:05 am December 2, 2019

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?


Sergii Sichynskyi
04:45 pm December 17, 2019

@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.


Steve Porter
05:20 pm December 17, 2019

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.


Sergii Sichynskyi
02:43 pm December 19, 2019

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?


Steve Porter
03:51 pm December 19, 2019

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.


Nicholas Clark
06:40 pm January 3, 2020

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.


Steve Porter
09:21 pm January 3, 2020

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.


Steve Porter
09:22 pm January 3, 2020

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.