If you compare agile methods, Kanban would be the least prescriptive of them. Kanban is just next to “do whatever” – with the only constraints being Visualize your workflow and Limit Your WIP. Scrum on the other hand has a few more rules, still leaving it relatively lightweight:
XP and certainly RUP is more heavyweight when it comes to rules to follow. Regarding engineering practices, neither Scrum nor Kanban prescribe any that must be used. XP on the other hand prescribes practices such as test-driven development, pair programming, shared code and continuous integration. It’s quite common to adapt XP-practices (engineering practices prescribed in XP) in both Scrum and Kanban – but which ones should you choose?
As always it helps to see what others have done and are doing. In an award winning white paper from 2011 called “Scrum + Engineering Practices: Experiences of Three Microsoft Teams” we get to see which nine practices the Microsoft Engineering Excellence group suggests and the experiences of three separate Scrum-based teams at Microsoft. The nine practices used was:
- Planning poker
- Continuous integration
- Unit Test-Driven development
- Quality gates (aka “Done Criteria”)
- Source control
- Code coverage
- Static analysis tools
- Peer review
- XML documentation
Most of these are also practices in XP, but I feel one practice in particular is missing here: Pair Programming. This is a practice which often is used, however maybe not as a default. Maybe pair programming is used for certain stories where only one member of the team has the knowledge of how to solve the story. Using pair programming can be a good practice in such cases to make teams more robust.
Common for all of the practices is focus on the quality of the product. Of course there are downsides with some of the practices. TDD drives the development time up. However, the increase in quality with a lower defect rate certainly makes up for this. Continuous Integration could be problematic when it comes to build and test runs not always being successful due to bad merges, build system problems or source control integration problems. But also here the constant focus on quality makes up for the “downside”.
All the teams in the Microsoft study saw its productivity temporarily drop for three iterations when starting to use Scrum and these nine practices. From the fourth sprint on they experienced significant improvement in productivity without any increase in defects. Also the team that to a lesser degree followed the nine practices had by far the highest defect density.
Although all these practices were seen as beneficial for the teams in the study it is not necessarily so for your team. There isn’t a common recipe for success, which is exactly why the percentage of failed agile projects is as high as 49% according to Jim Johnson at the Standish Group. The number is 86% for waterfall projects, so agile is doing a lot better than waterfall. Still, 49% is a lot, so there is a lot of bad agile out there. And, as mentioned, some of the reason for this is that there isn’t a single recipe for success. Indeed there are a lot of things you really should do to be successful, but at some point you need to make some choices for your team with respect to what will work and what will not work – both when it comes to using Scrum, Kanban or other agile methods and when it comes to engineering practices.