One of the best advices of this post is: “Technical debt may be necessary, but it had also better be clean”

I had another related discussion with Dan Khan (http://www.abetterstartup.com/2010/05/bootstrapping-versus-best-practice-in-lean-startups/), regarding Kent Beck’s revision of Agile Manifesto for startups, and his vision on the importance of fully understanding technical debt under such circumstances.

About the pitfalls of Scrum and programming practices, Folwer also mentioned this on his FlaccidScrum article (http://martinfowler.com/bliki/FlaccidScrum.html).

Just some things I thought was missing in this discussion.

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.

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

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.

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.

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?

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.

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

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…

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’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…

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.

“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.”

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.