Problems with the Scrum process

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:

This is a great conversation:

cageface says:

But the author’s criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features they encourage developers to hack things together in the most expedient way possible and completely fail to capture the need to address cross cutting concerns, serious consideration of architecture, and refactoring.

This is how you can get two years into a project and have managers and clients that think that things are going well when the actual code is an increasingly unmaintainable rats’ nest. Good devs confronted with this kind of mess will eventually burn out on sticking their necks out defending necessary but opaque refactoring tasks and move on to greener pastures.

uklenny wrote:

When a startup is running to get MVP out to get customer feedback, it’s usually much more efficient to set the basic expectation that the first version of your product will get thrown away once you’ve learned all the important aspects of what you need to deliver. With that in mind – startup development is a completely different beast than when your product is established and you have paying customers with expectations of up-to-date documentation etc.

Some managers are do not have good people skills and manage by just holding developers to account based on the expectations set in their Scrum planning day. Discussions about whether refactoring should be done yet or not may not even be something they want to know/talk about and they rely on engineers to factor that into their sprint estimates.

Depending on whether the company is being driven by sales/demo opportunities, or feature roll-out timescales etc. then the call about whether to do something ‘quick’ or ‘right’ may drop either way.

For developers it’s important to understand the dynamics that are driving the business and what their role is (sometimes you have to ‘JFDI’). If you have a good engineering team with a strong leader then these things shouldn’t be that visible to anyone else. It’s also important to be able to meet the expectations you set. If you keep delivering late then you’ll also struggle to get people to let you do more than the minimum required at the time.

For the business as a whole it’s all about the big picture and understanding the decisions you make and what their impact (short and medium term) is.

maxxxxx says:

In my view the only way to handle this is to make constant refactoring part of the work without telling management. If you ask for permission for refactoring you will almost always get a “No”.

s_kilk replies:

This is how we ended up with the “Shadow Sprint” at a previous workplace. A whole bunch of utterly essential engineering work was left out of the sprint process, so many of us would just go ahead and do what needed to be done anyway while working on whatever tickets we’d picked up frome the “real” sprint.
Utterly dysfunctional of course, but if it’s do-or-die, I’d prefer to ‘do’.