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?

  • 2
    I see a huge misunderstanding in your question about scrum: The scrum master is already a member of the team, most likely this person is a developer who is working on some of the stories. This isn't a management role, necessarily.
    – jmort253
    Mar 11, 2014 at 2:32

7 Answers 7


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.

  • 3
    In order to make this already-great answer a perfect answer, I'd also add a third misunderstanding, that the Scrum Master is somehow not technical. The Scrum Master should be someone who is already part of the team. It's not a separate title in the organization.
    – jmort253
    Mar 11, 2014 at 2:31
  • @Dave Hillier: Thanks for your response. I do agree with your point that scrum masters should only direct the team to achieve DOD as set by the developers. This question just struck me from my personal experience, as our scrum master keeps chasing developers to get our code checked in soon (whether or not the code is reusable). Its only when the code review response demands refactoring, that we start rewriting those bits and end up wasting more time during the sprint which could have been clearly avoided if the scrum master had let us work at our own pace. Developers should be trusted as well. Mar 12, 2014 at 9:36
  • @Dave Hillier: I really appreciate your response. I would have voted your answer up only if I had above 15 reputation. Mar 12, 2014 at 9:37
  • @ComputerScientist a Scrum Master encouraging you to check in regularly is fine as that is a good practice. As for refactoring, I suspect you're making it too big. See refactoring.com. Refactorings should be small and committed frequently. Mar 12, 2014 at 13:52
  • @Dave Hillier: Well, probably. Although its something experienced by many developers I have seen. In the end they just complain that they wanted to write a reusable code, but couldn't due to time constraints and pressure. Mar 12, 2014 at 14:29

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.

  • We don't really struggle to meet commitments, its just that some developers work overtime, even from home (which I personally don't mind but some do) to ensure both code quality and time constraints are met. Some eventually tend to overlook code quality and just aim to get through all committed user stories ASAP. Now from my personal observation so far, I think a reason behind this can partially be attributed to the scrum master as well as they are always chasing us to pace through the sprint. Your justification makes sense too. Mar 12, 2014 at 16:07
  • 1
    The sprint commitment should be achievable without needing to work overtime or sacrificing code quality. By doing overtime and cutting quality you get into a negative loop; your velocity goes up because you're working later and reducing quality which means you commit for more in the next iteration then need to work more hours and reduce quality to hit the next sprint goal...
    – Ben
    Mar 12, 2014 at 19:19
  • That made perfect sense to me! However, the business requirements need to be considered too, and committing to lesser features might not really go down well with the higher management. But this is too specific to my scenario. I think I got some understanding about how developers and scrum masters need to fit well together in a sprint and achieve the commitments. Thanks @Ben. Mar 12, 2014 at 21:15

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

  • That is EXACTLY what I was trying to say as well! I believe the role of a scrum master is only to coach the developers and motivate them to do better. Chasing them to finish tasks is totally wrong. I think now I better understand the roles of a scrum master and what is being done right/wrong in my case. Thanks. Mar 12, 2014 at 16:16

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.

  • I am not sure if developers are expected to commit to user stories for a sprint after considering the technical aspects. But for all I know, we don't really consider them because the scrum master does not let us do so. He wants us to commit to user stories from customer's perspective. Is that how it should be? Or is the scrum master doing it wrong? Also, the rephrased question probably expresses my question better and fits the Stack Exchange Q&A format. Mar 12, 2014 at 16:11
  • Scrum Teams must be allowed to consider non-functional done criteria in their ability to commit to a story. Team story point estimates should provide room for completion of done criteria since they impact the complexity of delivering a story to a customer. Done criteria should be a built-in commitment (even if not documented in the user story) and your scrum master should be able to communicate the business value of team done criteria to all stakeholders on the project.
    – WBW
    Mar 24, 2015 at 19:12
  • 1
    PS sounds like your scrum master may not understand the value of done criteria. It may be worth approaching him/her and asking her to explain why teams have done criteria to the team and have a conversation with them on things like unit tests, automated integration tests, code reviews, etc...
    – WBW
    Mar 24, 2015 at 19:19

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.

  • There's a great difference between additional features possibly coming in the future, and making the actual implementation reusable and maintainable. The last also takes time, expect at least triple time for unit test covered "clean code", compared to spaghetti code hacks which work in one first test case. On the feature side, KISS and YAGNI may be ok, but on the quality side, working with quick hacks only leaves bad software and frustrated developers.
    – Erik Hart
    Mar 27, 2016 at 11:04

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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.