The relentless pace of scrum
Teams working under a scrum model very often talk about the relentless pace of scrum. There seems to be a constant pressure on getting new work done. So much so, that a lot of teams feel that there is no time allowed for personal development/technology investigations or even refactoring of the systems the team is responsible for.
Typically, teams in scrum, get a group of stories from the customer. The team is then expected to execute on these stories, getting them completely developed and tested prior to the end of the iteration.
What gets lost, often times, is the realization that the teams are not responsible for delivering stories. The teams are responsible for delivering a system. The outcome of a particular sprint/iteration is not a group of completed stories, but rather a high-quality system. Once that paradigm shift happens, then it makes it very easy for teams to find time to accomplish some of the things that they previously thought they were unable to do because of scrum.
Teams have a fair understanding of the amount of technical debt that they are accruing interest on. It is perfectly within that team’s right to take on fewer stories so that they can address the technical debt.
It is important that teams realize that they control their own velocity. The teams dictate the amount of work that they will take on for a given iteration. Teams should certainly be allowed to take on a little less new work to address some technical debt.
We, as agile development managers, need to encourage teams to deliver effective systems. It is not conducive to measure teams on velocity alone.
Hi,
Great posting. However, I’d like to point out that the team should not just be “accepting” stories from the customer that “they” require be completed by the end of a Sprint.
If the team (including the Product Owner) has the conversation(s) that talk about the technical debt being built up — in terms of what impact is has on the business — I have found this is a useful discussion.
Remember that this is about delivering working software at the end of each iteration!
Thanks for the info.
- mike vizdos
http://www.implementingscrum.com
http://www.michaelvizdos.com
Mike,
You’re absolutely right… However, many times its a very difficult proposition to have a product owner choose to eliminate technical debt over a new feature.
There’s significant relationship building that has to happen there to help the product owner know that it’s not just “gold plating”.
Matt,
Good point.
I’d still submit one of the ways to build the relationship — in order to get rid of the “gold plating” perception — is to include the product owner as a member of the team and have the developers look at things from a business (read: non-technical) position.
If the product owner can see that this technical-bla-bla thing will cost X dollars in support costs (that the product owner may have to pay for out of their own budget), maybe this is a good conversation that helps eliminate the perception of the “gold plating.”
One of the things I like about Scrum is it puts stuff like this in the face of the organization; and how the team (and the organization) handles these type of discussions can change for the better. Or not (smile).
- mike vizdos
http://www.michaelvizdos.com
http://www.implementingscrum.com
Amen, my brother.
The team dictates the pace and owns the product it creates. If quality of the codebase is important to the team, they have the power to address it by factoring that into estimates and stories pulled from the backlog.
If team training is a priority, there are a number of ways to address it, but it certeinly does not need to be under the table.
Nice post.