Cutting It Close

You are a seasoned developer within an Agile development team, actively engaged in the day-to-day coding and technical aspects of the project. The team has been following the Scrum framework, conducting regular sprint planning, daily scrums, and sprint reviews. You have been a key contributor to the project, consistently delivering high-quality code and innovative solutions. The team is gearing up to showcase their latest features and enhancements and the product demo to stakeholders is incorporated into the second half of your team’s sprint review.

Your team’s sprints have their concluding events on Wednesday mornings, generally a 1-hour window to push the update to production before the lunch break, then the sprint review with stakeholder demo. That generally offered the team some very fresh feedback to bring into sprint planning as they wrap up the day.

Generally, releases to production have been mostly smooth and take less time than the hour that’s set aside. Lately, however, updates to a complex feature have been feeling a bit rushed toward the end of the sprint. This has led to merge difficulties and errors to address on the spot during the deployment. A few times the automated tests post-deployment picked up a few escape bugs that needed to be addressed in the following sprint.

In short, your team’s “just in time” approach to rolling out the update the morning before the demo is starting to make the entire morning stressful and unpredictable. The team has sometimes had to bump a few scrum events and other times do a bit of multitasking during the retrospective. You’re sure some team members will always run things down to the last minute, but you’re also sure you’re not the only one feeling this unnecessary stress. You haven’t shared your feelings with the rest of the team just yet.

What is your decision?

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.