As everyone who’s looked even superficially into Scrum knows, there is a focus on creating a “potentially shippable increment of functionality”… but many projects or teams rarely actually ship incrementally or iteratively. In those cases, it’s sometimes hard to persuade teams of the importance of getting work “done” inside the timeboxed sprint because there may be another 10 sprints coming up before anything actually gets shipped.
For example, if you are approaching the last two or three days of a sprint and one of the developers informs the team at the standup that he’s finished all their work and that they want to pull another story into the sprint.
However, there’s no chance that this story can be developed *and* tested within the remaining days in the sprint, you don’t have the resources to do this, but they are a developer and they want to develop! They do not want to help out with testing, or help another developer finish their stories and they don’t see why it’s so important that things get tested in the same sprint as they are developed – after all this project isn’t going to ship until September, and all these stories still need to be developed.
Only when it comes towards the last couple of sprints of the project and the impending release to end users does the sharpness and focus really kick in, rather than having a constant focus and pace over the duration of the project.
This is a challenge, how do you as a scrum master persuade the team of the importance of driving work to a completed state within the timebox, when from their perspective, it may not matter – there’s always another sprint? It was observed that the rollover of work between sprints becomes habit forming if the boundaries of each sprint are regularly breached.
In this session, we started off discussing this and unanimously agreed that releasing frequently to your customer is a very good thing and should be encouraged wherever possible, however as discussed in the very first session in April, that some businesses are just not able to handle regular releases through a range of factors.
A lot of the discussion centered around the importance of commitment – to the goals of the sprint and to the team and to the product owner and customer.It was felt that without such commitment, any team is potentially just paying lip service to agility.
Two key messages came out of the discussions :
i) Always ship in some way. Even if the organization can’t ship working software to the end user every sprint, look for another form of shipping… create a UAT environment and deploy the output of each sprint to that environment and have acceptance testing take place each sprint. The act of shipping even internally will reinforce the habit of producing “complete” functionality
ii) Treat internal users and stakeholders with the same respect you would treat real customers. If the team takes internal stakeholders seriously then the focus on delivering to them will provide the required focus to get people to drive work to completion.