In a scrum development environment, management keeps adding stories in the sprint

Question

In a company, they have been trying to implement scrum for something less than a year, and they have made some good progress. However, in the last 4-5 months and prior to the release of the software, management and PO have been adding things in the sprint all the time, therefore altering the priority and focus of the sprint. At the end of the sprints, things are half done, or not started at all, and some are done. This seems ok though, as they will be delivered in the next sprint, or the sprint after. The PO and management know that they shouldn't be doing this, however time is very limited to go live with the new product and if there is no business, there is no team, and therefore, no scrum. The morning scrums are are report to the manager of what is going on, and a ping pong of suggestions for possible solutions. The manager insists that this is the right forum to coordinate the team.

On the other hand, the manager has advised that he wants to keep the scrum values, and progress scrum in the team, it's just that right now, time is of the essence and things have to be delivered as soon as possible before the deadline. The Scrum Master, seeing the problem, he understands that priorities will keep coming up, sprints will keep re-shifting, and has given up trying to change this; he also understands that certain pieces of the software have to come on an urgent basis in order to be delivered. Additionally, "last moment additions", albeit essential, are added in the sprint or backlog, that need to be done tomorrow (sometimes the latter are, objectively speaking, non-negotiable, as they have to be delivered for the software to work).

To top all these, the company has issues in its infrastructure, such as environments not working, and development getting halted about 20% of the time due to external dependencies.

The company has client commitments which it is trying to meet. Therefore, on one hand they want to do scrum, on the other it just seems like a waterfall methodology labelled as "scrum".

Is there hope in this company in terms of appreciating what needs to be done in order to start implementing scrum? How can they stop adding things in the sprint backlog, and focus on actually delivering whole sprints instead of having half-done stories at the end?

Answer 1

First off, whenever something is added into the Sprint, ask the PO which story/stories should be removed. This is not optional. (Unless you find that you actually underestimated for that Sprint and actually have room to add stuff. This shouldn't happen often, however.) If you estimated being able to complete 10 story points, and you therefore took on 10 story points, and then managers want to add another 3 story points, you are not magically going to become able to complete 13 story points. Three points must be taken out, thereby maintaining the sprint's estimate. Not only does this combat the problem of having many 'half-completed' stories at the end of a sprint (assuming the original estimate was appropriate), it also has the added benefit of making some of the costs of these 'last-minute additions' clearly visible.

"I want story G."

"Okay, would you like us to remove story A, or stories B and C, to make room for it?"

"No, you can't remove either of them."

"Okay, we cannot complete story G, then. Please pick two to keep: either A, B and C, or G."

"Fine. Remove A, then."

(Time lapse)

"Why isn't story A completed?!"

"Well, we have this email here that explains it..."

While it might seem like you're completing things faster, that's not really the case. Either you try to complete all stories and get nothing done sprint 1 and everything done sprint 2, or you complete stories B, C, and G done in sprint 1, then finish story A in sprint 2. That's an advantage of Scrum vs. Waterfall - you get something earlier.

To top all these, the company has issues in its infrastructure, such as environments not working, and development getting halted about 20% of the time due to external dependencies.

Not really that unheard of, and not fundamentally incompatible with Scrum. Just treat it as having a lower focus factor; that is, it means your team is able to commit to a lower number of story points per sprint (compared to how many they could commit to without these issues).

The company has client commitments which it is trying to meet. Therefore, on one hand they want to do scrum, on the other it just seems like a waterfall methodology labelled as "scrum".

Like I explained above, taking on more work that you cannot actually complete might make it look like your Team is going faster, but it isn't actually going faster. Following Scrum shouldn't keep you from fulfilling client commitments.

Is there hope in this company in terms of appreciating what needs to be done in order to start implementing scrum?

Yes. Adding Scrum to a Waterfall workshop is often as agonizingly slow as it is eventually-rewarding. Keep at it.

How can they stop adding things in the sprint backlog, and focus on actually delivering whole sprints instead of having half-done stories at the end?

Hopefully, once the costs of doing this become visible, management will stop. Or else the need to do it might go away, once things settle down a bit. If neither of these happen and your project really is something that is so volatile that you cannot handle planning with two-week sprints, consider the possibility that Scrum actually won't fit. You don't have to stick with Waterfall, though - consider a different agile methodology, such as Kanban.