Development Team: Can we start the Sprint on Tuesday?
Me (Scrum Master): Yeah! Why Not? But Why? What value do you think you will get if you start the Sprint on Tuesday?
The answer could have been a simple “Yes”. Sprint can be started on any day of the week and may not specifically be a Monday or Tuesday. Just that we need to follow a consistent duration of the Sprint length. And the succeeding Sprint must start immediately after the completion of the previous Sprint. There is no “pause” or “overlap” between two Sprints.
Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. — The Scrum Guide.
This question kept me thinking — “Or is it because of manic Mondays that the Development Team would like to start the Sprint from Tuesday, but Tuesdays may be more depressing”.
According to a study conducted by the London School of Economics in 2010, “Tuesdays are far more depressing as the weekend is not yet in sight”
However, I still wanted to ask that fundamental question of value.
“What value you think you will get if you start the Sprint on Tuesday?”
Development Team: We will get two additional “unofficial” days to resolve any build and release issues that may surface when we are getting the increment ready to be released.
Me: Unofficial? What does that mean?
The Development Team explained me how?
The Development Team gets two weekends. They have the flexibility to convert the second weekend of the two-week Sprint into a “working weekend” and resolve any build and release issues they might face. They also mentioned that these two additional days are unofficial. The Development Team does not count these two days in the length of the Sprint.
Me: Really! How does it work? How do you make it “unofficial”?
Development Team: Till the time we deliver, it should be Ok with all. Do you agree? But let us still explain it to you…
This is what the Development Team had to say:
The Development Team will assign a Build owner on Friday of the second week. The Build owner will first merge the code of all the developers and start the manual build.
- If the build fails, the Build owner will try to resolve the code build issues during the day. The Build owner will reach out to other members of the Development Team to help solve the build issues. If the build issues do not get addressed during the day Friday, the Build owner will carry them forward to Saturday.
- This Build owner will start fixing the build issues on Saturday. If the Build owner is not able to resolve the build issues, he will call (though phone) the code owner for help and resolve the issues. This process continues until the build is successful.
- The Development Team does not hold Daily Scrum on any of these days of the “unofficial working weekend” — Saturday and Sunday.
- It could be that not all team members are bothered on Saturday and Sunday, and only some of the Development Team members are involved. Others do not even come to know of any of these problems.
- Only the Build owner comes to the office.
- The Build owner or any other team member will not fill any timecards/workday during Saturday and Sunday. Their people managers do not come to know as the Development Team members do not make any timecard entry and no one has to approve it.
- The Development Team will not count these two days in the Sprint.
- The Build owner will rotate every Sprint so that one person does not have to work on a weekend throughout the entire project.
Me: It does not sound so happy. Have you been following it in the previous projects too?
Development Team: Yes, it always works. No one bothers as we have the increment ready in running condition on Monday.
Me: Would you like to change it? Can we do something to avoid this situation?
Development Team: Everyone is happy! The code works fine on Monday. But certainly we can try to improve it. We have to trade this improvement with business features that are in the pipeline to be delivered in some of the early Sprints.
“Can we do something to avoid this situation?”
The Development Team was ready to discuss the ideas and approach to resolve this issue. After a brainstorming session, the Development Team decided to implement the following:
- Improve the coding standards and code review guidelines.
- Implementation of the automated build process.
- Enhance Definition of Done to include code quality measurements.
- Implement an automated release process, if possible.
To improve coding standards and code review guidelines, the Development Team decided to enhance the organization’s coding standards and code review guidelines. They also marked some of the coding guidelines as “Not Applicable” as they were irrelevant given the current project.
For implementing an automated build process, the team suggested that it may take 1 -2 Sprints to streamline the process thoroughly. During these Sprints, they will have to go a little light on delivering the business features. The Development Team suggested picking up a few simple business features for the first two Sprints.
For code quality measurements, the Development team suggested implementing SonarQube. Not all the Development Team members were aware of this code quality measurement tool. The ones who knew offered to help and train in its use. For the readers of this blog, below is the brief description of SonarQube:
“SonarQube (formerly Sonar) is an open-source platform developed by SonarSource for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities on 20+ programming languages. SonarQube offers reports on duplicated code, coding standards, unit tests, code coverage, code complexity, comments, bugs, and security vulnerabilities.” — https://en.wikipedia.org/wiki/SonarQube
A sample SonarQube report looks like this –
The Development Team was enthusiastic about implementing the improvements as mentioned above in this blog. They monitored the progress of these improvements during the Daily Scrum and resolved any impediments they encountered. The Development Team settled on manual release and did not automate the release process.
The above scenario is also a real-life example of how the Scrum Team lived the Scrum Values of Commitment, Courage, Focus, Openness, and Respect.
The Development Team was committed and stayed focussed on achieving the Sprint Goal, though they found other “unofficial” ways to resolve their build and release issues. They were open to addressing this challenge and respected the thoughts and opinions of other team members to gather improvement ideas. It took courage to implement all these new improvements without knowing if these will pay-off.
The Development Team started the two-week Sprint on Tuesday. It ended on Monday of the second week and started the next Sprint the next day on Tuesday without worrying about manic Monday, terrifying Tuesday, or an “unofficial” working weekend.
In conclusion, there could be many theories about choosing the start day of the Sprint. The Scrum Team can follow what they feel is most suitable for them to deliver the done increments Sprint over Sprint. The Sprints can also start from mid-day, like Wednesday afternoon, there are no rules or restrictions. Take the opinion of all the stakeholders and give it a try. Scrum framework provides opportunities to inspect and adapt in a transparent manner.
“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk” — The Scrum Guide, 2017