Are efforts to improve quality an impediment to achieving schedule in Scrum?

Question

Let me begin by highlighting couple of roles of a Scrum Master as quoted by the Scrum Alliance:

The ScrumMaster also works with the development team to find and implement the technical practices needed to get to Done at the end of each sprint.

Another responsibility of the ScrumMaster as quoted there include removing impediments to the team’s progress. These impediments may be external to the team (such as a lack of support from another team) or internal (such as the product owner not knowing how to properly prepare the product backlog). That said, the ScrumMaster fosters self-organization, meaning that the team itself should remove issues wherever possible.

Some other responsibilities mentioned include helping a PO creating and maintaining Product Backlogs, facilitating meetings, and making sure Scrum process is strictly followed.

I work in an Agile environment with 6 Scrum teams, as a developer in one of the teams. We follow Scrum professionally and as expected, the scrum master chases developers to get all user stories finished by the end of the sprint, as we commit the delivery right during sprint planning (without really touching on the technical aspects). Now obviously, the scrum master is not expected to know anything about code or how time consuming/difficult a user story is; all he wants is the user stories finished.

Now let's consider what Robert Martin has to say in his book Clean Code:

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.

Alright, so here goes my descriptive question: We all know writing clean and maintainable code could be time consuming depending on the task (for example architectural work usually require lots of time and efforts). Now, if writing clean code and maintaining them is an important aspect in software development, why does Scrum assign Scrum Masters (who don't have any programming knowledge) the role of getting developers to quickly achieve 'Definition of Done' before the end of sprint? A lot of times due to this, most developers end up not bothering much about writing reusable quality code and just write a slew of code just so that the feature is implemented. Rather than protecting developers from impediments, wouldn't it be appropriate to conclude that a scrum master is an impediment towards writing clean code?

Now someone could argue saying that scrum masters are supposed to do this so that the developers stick to their commitments and get the features delivered. But I think we have already touched on the point that scrum masters basically foster self-organization, and that the team itself should remove issues wherever possible. Its quite obvious that if the team doesn't deliver the features as committed, then they shall ultimately bear the brunt from the higher management, the thought of which should automatically drive the developers to work towards their commitments whilst not hindering them from writing good code.

My point is not against having scrum masters, I definitely agree with all other responsibilities of a Scrum Master other than racing developers to get the tasks done.

Am I justified in expecting the Scrum Master to allow me needed time to write reusable code?

Answer 1

This question seems to be from two mis-understandings about Scrum.

I don't really see how it follows that Scrum Masters cause a reduction in quality by keeping focus on the definition of done. The Scrum Master does not write the definition of done, the team does. The Scrum Master helps the team enforce the standards of quality that the team has decided upon.

The quote from Clean Code does not apply. Most managers might obsess about schedules, but Scrum Masters do not. They work with a different variable, they keep the scheduled fixed and instead adjust the scope of the project. A Scrum Master will drop user stories to keep the deadline the same.

However, that being said, I think that Scrum takes an overly simplistic view to team structure. You need to build your teams with the right balance of experience and skills so that they can self-organise. Ideally, when a team has a gap, they can recognise it and ask for more support in that area. You can't just put random people together and hope for the best.

Edit: As Jmort253 mentions, you have also assumed that a Scrum Master is non technical. This doesn't have to be the true, but in any case Scrum Master should limit the amount of directing and decision making that they do and instead make sure that they facilitate the team to make [technical] decisions.

Answer 2

Bear in mind that your Scrum Master is asking you to meet a commitment you, as a team, made at the start of your sprint.

If your team is consistently struggling to meet commitment without sacrificing code quality, I'd suggest you discuss this in your next retrospective.

Reasons I've seen for this:

• Team feels under pressure to give unrealistic estimates due to deadlines.
• Team hasn't considered technical design at all prior to estimation.
• Some thing happened to cause the teams velocity to drop (e.g. changes in team members) but it's not being taken into account for planning.
• Sprints are too long (it's easier to plan more accurately over a shorter span).
• Stories are too big (so hard to estimate).

Those are just speculation though. Ultimately, you won't know the root cause unless you all sit down and discuss it.

Also, if you discover a story is much more complicated than at first thought at some point during dev, make sure you're raising that at standups as early as possible. Keep a record of stories where this happens and looks for trends. Perhaps particular systems are hard to deal with or some bits of gnarly code with poor test coverage are tripping you up.

Answer 3

@Ben and @Dave Hillier have provided great answers and I won't repeat their excellent advice but I would like to add this:

The Scrum Master is not responsible for "racing developers". If you have a Scrum Master who "chases developers to get all user stories finished by the end of the sprint", I'd say they're doing it wrong.

The Scrum Master does not drive, command, direct or tell the Development Team what to do. Instead, they have a supporting role. They coach, mentor, teach or advise as the circumstances dictate.

On the question of Clean Code, I would expect a good Scrum Master to defer to the Development Team and the Definition of Done.

On the question of meeting the forecast that the Development Team made in Sprint Planning, I would expect the Development Team to strive to meet their forecast and I would expect the Scrum Master to help them meet that forecast in any way he or she can.

Answer 4

I'm not "into" scrum, but I think we can rephrase this as a general project management question:

Are efforts to improve quality an impediment to achieveing schedule?

The answer is clearly "no".

From what little I know about scrum, @Ben's answer is paramount - the team agrees to and commits to a definition of "done" that includes quality, schedule, cost, and any other relevant factors.

Answer 5

Your question about reusable code has been addressed by Agile and Scrum

I extracted a question from your post so that it conforms to the Stack Exchange Q&A format.

Am I justified in expecting the Scrum Master to allow me needed time to write reusable code?

The answer is an emphatic "NO".

XP is the source of many of the engineering practices widely practiced in the agile community - Test Driven Development (TDD), Continuous integration, Pair Programming/Code Review among others.

Here is what XP has to say about writing extra code that may be needed later:

Keep the system uncluttered with extra stuff you guess will be used later. Only 10% of that extra stuff will ever get used, so you are wasting 90% of your time. We are all tempted to add functionality now rather than later because we see exactly how to add it or because it would make the system so much better. It seems like it would be faster to add it now. But we need to constantly remind our selves that we are not going to actually need it. Extra functionality will always slow us down and squander our resources.

Here is a more detailed write-up, with examples, about the YAGNI (You Arent Gonna Need It) principle.

One of the 12 Principles behind the Agile Manifesto is:

Simplicity--the art of maximizing the amount of work not done--is essential.

Answer 6

There are some underlying misunderstandings in your question:

"why does Scrum assign Scrum Masters (who don't have any programming knowledge) the role of getting developers to quickly achieve 'Definition of Done' before the end of sprint?"

The above is not a scrum master's role. The scrum master works with the team to get them to establish and adhere to a definition of done. The team estimates work and should communicate an estimate and commitment that allows them to achieve their done criteria.

The scrum master facilitates the negotiation between the team and the PO/PM to ensure the team commits to a reasonable amount of work where they can achieve their definition of done. This is most commonly done during planning with the use of story point estimates and team velocity.

There is no "quickly" in achieving done criteria. In fact, a good scrum master should advocate for the team to decrease iteration commitments if they are constantly pressured by management to over-commit and "quickly" meet their done criteria.

The scrum master is a servant leader role focused on maturing delivery teams, not software projects.

This means that, if you, as a developer think they are only serving the management/customer timelines and not looking out for the ability of the team to write quality code, it might be time to look for a new scrum master or have an R&R discussion.

Answer 7

Why aren't "clean" and "maintainable" part of your Definition of Done?

The relevant metric could be something like "code has been reviewed for maintainability & any issues raised by the review (that don't expand functional scope) have been addressed."