Scrum is not about engineering practices

To be fair to Martin Fowler, he does not suggest that SCRUM is the cause of these problems.

In reality, SCRUM is a symptom of the problems in these environments. not the cause. A team chooses a lightweight project management framework (SCRUM) and applies engineering practices equally lightly. The underlying cause is simply a lack of professionalism. SCRUM is chosen as it is seen as easier than other project management methodologies.

I am a big fan of SCRUM but like any tool, it is only as good as the people using it.

@Dave: You’re parially right. But he beginns his post with

“They adopt the Scrum practices, and maybe even the principles
After a while progress is slow because the code base is a mess ”

and suggest the code mess has something to do with Scrum – I’m contrary to your opinion on this one. I fear he picks Scrum because of the momentum to gain more readers (The title of the post is “FlaccidScrum” – so the post IS about Scrum specifically):

“I’ve mentioned Scrum because when we see this problem, Scrum seems to be particularly common as the nominative process the team is following.”

I agree, Martin Fowler does heavily infer that SCRUM is the cause of the problem and that is unfair to SCRUM and does SCRUM a big disservice.

I guess I am trying to read between the lines of his post and recognise that poor performing teams may choose to use SCRUM over other methodologies but that it is laziness that pushes these teams towards SCRUM. SCRUM is relatively easy to implement and light in process, therefore it is easy to say you are using SCRUM (and therefore a methodology) even if you miss the main spirit of SCRUM.

Unfortunately most people will simple pick out the words “SCRUM” and “mess” in his posting and complete their conclusions there which is a shame.

Well said! In my mind, scrum is a tool and a piece of the process – but the entire process. The team still needs to self-organize and determine the other necessary tools and processes to put in place to make a project successful.

I’ve heard over and over that “scrum doesn’t work with X kind of project” or “in Y environment”. I think that’s kind of the easy way out…

Great points. Technical debt is a great way to look at a lot of this, and it’s a term that managers can get down with.

Your conclusion reminds me of this part of “Clean Code”:

The managers and marketers look to us for the information they need to make promises and commitments; and even when they don’t look to us, we should not be shy about telling them what we think. The users look to us to validate the way the requirements will fit into the system. The project managers look to us to help work out the schedule. We are deeply complicit in the planning of the project and share a great deal of the responsibility for any failures; especially if those failures have to do with bad code!

“But wait!” you say. “If I don’t do what my manager says, I’ll be fired.” Probably not. Most managers want the truth, even when they don’t act like it. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion.

To drive this point home, what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time?[2] Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.

[2] When hand-washing was first recommended to physicians by Ignaz Semmelweis in 1847, it was rejected on the basis that doctors were too busy and wouldn’t have time to wash their hands between patient visits.

I disagree with the statement that “Developers define what stories they work on in each sprint”, because defining the priority of the stories to be implemented in an iteration should be the responsibility of the customer (or product owner) and not the developer. Once said, the developer does have the responsibility of realistically estimating how long it takes.

Unfortunately, management concerns are independent of harsh technical realities as they have to take into consideration the needs of customers and competing offers. So their demands for faster delivery dates may be justified – but management controls resourcing, so they can influence the actual real time it takes to deliver a software product in this way.

The truth is that we have learn to produce better software faster (or we don’t eat). If scrum helps us do that, it is useful, if not, there are plenty of other software processes…

@Chris: I might have – subconsciously – taken the idea from Clean Code which I have read some time ago, no that you quote the paragraph again.

@Dennis: Sorry, define was the wrong word, select would have been better. I might have thought of defining the tasks for each story, what they need to technically do.

“Technical dept is not professional”
HIDING technical debt is not professional.

In the past tech debt charts I have used have had things like “build times above 7 mins”… ie: things we have identified and will address. We communicate to the steakholders why we will include ‘non-story card’ cards into the iteration.

I feel your anti Martin Fowler sentiment in this case is ill-founded, and seems based on emotion. Contrary to your beleifs: Martin makes no claim that SCRUM is a engineering practice.

Who is hiding technical dept? Developers when professionals don’t create technical dept.

You’re hiding costs if you have small stories without technical improvements/refactoring/maintenence. You’re lying because the story points/costs you tell the product owner are wrong. Then you tell them you need to do technical stories for things you forgot?

“Martin makes no claim that SCRUM is a engineering practice.”

Huh?

“Then you tell them you need to do technical stories for things you forgot?”

Thats exactly correct, things that were retrospectively poorly designed or poorly implemented, or might be semi-awesome but could do with improvement from a ‘technical’ perspective.

Rather then having devs squeeze in work to improve the 2 year old build script, put it on the wall and let the stakeholders know it needs working on, be professional, be honest.

Usually teams that track tech debt, are also pro-active in preventing tech debt.

“Rather then having devs squeeze in work to improve the 2 year old build script, [...]”

Why improve? Why not constantly refactor the build script? Just as you do with code?

“Usually teams that track tech debt, are also pro-active in preventing tech debt.”

Yes might be.

Stephan,

I also think that Fowler do not infer that Scrum is the root of problem. He is heavily talking about the lack of “technical practices”:

“What’s happened is that they haven’t paid enough attention to the internal quality of their software. If you make that mistake you’ll soon find your productivity dragged down because it’s much harder to add new features than you’d like.”

From a philosophical point of view:

“Scrum is not about engineering practices, it’s about management.”

Scrum is not about management, it’s about delivering value to customer – aka working software.

Kind Regards

It’s hard to be precise in 140 characters. The problem isn’t Scrum itself. It explicitly says it’s a management process and doesn’t cover the sphere of dev processes. As such, it has been applied to non-development projects. I once heard that a news radio station in the U.S. used Scrum to manage their daily tasks covering the news. Great!

However, the reality I see in industry is the mistaken notion that just adding Scrum solves your problems, until the unsolved engineering problems overwhelm the project. My complaint is really with many leaders in the Scrum community who should strongly emphasize the need to fill in these missing pieces. I’m fine if they choose not to address dev practices. Ultimately, Scrum won’t be a success if there are too many project failures, even if Scrum is not the reason for the failure.

Also, in my experience, most teams don’t manage their technical debt unless they use the XP developer practices. Therefore, when we mentor teams on agile practices these days, we always adapt to their environment a combination of Scrum, Lean, and XP management practices combined with XP developer practices.