At the recent Jazoon conference in Zurich, Ken Schwaber talked about the lack of technical practices in Scrum projects that lead to technical debt. However, the end of the talk made me thinks that this topic could have been chosen only to promote its Scrum.org certification courses.
Ken Schwaber started by saying that we often consider only the costs of the development phase, but not the costs of the total life cycle of the software. Therefore, we ignore the impact of short-term decisions on long term return on investment (ROI). The ROI can be measured with several aspects like the valuable functionality included or the absence of low value features.
Figure 1. Ken Schwaber at Jazoon
He discussed after this the meaning of quality for the developer
* I can understand the software
* I can change the code without side effect
* I can check if things work after a change
This lead to an exercise where he asked the audience to agree on a definition of “done”, using the context of multiple teams developing common software. He then asked if the agreed definition included:
* performance testing
* stability testing
* integration with other teams
* user acceptance testing
* code reviews
His point was that you should have a clear definition of done that include everything needed to deliver software to the user, otherwise you will have the same “death march” at the end of agile projects during the “stabilization” phase than in waterfall projects. He remembered an early embarrassing personal experience where his definition of “done” as a developer was different from the definition from the user and he had to explain what was needed to achieve it. When you have a gap between the team sprint results and what you really need to be “done”, you will create at every sprint an increasing backlog of work that will have to be cleared before delivery of the application.
Figure 2. Number of defects for two different sprint strategies
In the above picture, you see the evolution of the number of defects for the same team. In the first release, integration testing was not included in sprints. The number of defects strongly grows at the end of the project. For the second release, they included integration testing in every sprint activity. The number of defects was kept under control and the software was completed before the deadline.
“Not having enough time” is the excuse often presented by teams for not including needed activities in their sprints. However, these are things that will have to be done later at a higher cost. Additionally, as you are accumulating bad code, you create a technical debt that lowers your velocity. Ken Schwaber defines Scrum as a light framework without technical practices. This was done intentionally because people should know better what they needed to do. To his surprise, the holes were not filled well. He cited a survey conducted by Jeff Sutherland finding that more than 50% of “scrum” teams were not using the iterative/incremental practice. This is what Martin Fowler calls “Flaccid Scrum”.
Ken Schwaber used the last 10 minutes of his (reduced) speech to present, I will rather say advertise, the new certifications (Professional Scrum Developer) proposed by Scrum.org. He mentioned several courses offered by a local partner. This sadly makes me think that money could have been a major reason for him to split from the Scrum Alliance.