Good concepts – Scrum or no Scrum

From one stable state to another Scrum strongly recommends creating a “potentially shippable product” at the end of each sprint. In my Scrum training & coaching experience, I have come across many questions & doubts about its practicality. It is often argued that when we are not going to put the next increment in production, does it make sense to aim for it. After giving this due thought, I have come to the conclusion that the answer can be found at the systems level.

What Scrum is trying to ensure is that the software system moves from a stable state at the beginning of a sprint to another stable state at the end of the sprint. Anything that is started but not finished is a potential threat to the system stability. Hence it advocates breaking more complex product backlog items into smaller user stories so that they can be started and finished in one sprint.

This is a good approach but may not always be practically possible in each and every case. There are a number of interrelated activities and simple cause-effect relationship may not give us a clue to the impact of incompletion of a given factor on the overall system. It is better to be aware of such incompletions and raise them during the daily standup meetings. It also helps to discuss major incompletions and their effect on the system during the sprint-end retrospective meeting. Both these actions will help increase the sensitivity of the team members towards the risk involved.

A common problem faced by the teams relates to sequencing of development and testing. Normally, testing only follows development. However, practices like test driven development (TDD) and behavior driven development (BDD) where failing tests precede coding and amount of code written is kept to the minimum to pass the failing tests. This approach avoids the temptation to cover lot of functionality in one go and the resultant risks of introducing additional bugs. Another practice strongly favored by agile is one of refactoring. Here again, need based separation of concerns helps in doing it in small chunks. Lastly, it helps to have a much better understanding, collaboration and shorter iterations of coding & testing.

There is an important concept of technical debt in Scrum, which simply means “The difference between what was delivered and what should have been delivered”. Whatever is left out in one sprint, generally due to pressures of completing the sprint on time, results in cutting corners on quality. These left overs come back to haunt later, quite often with far more serious consequences. When applied at systems level, a systems debt would cover not only the gap in delivery but also the other aspects like readiness of the team to tackle the demand & challenges of the work involved, absence of good practices and so on. The team needs to consider, plan & work on all such areas.

Though most of these concepts have been explicitly covered in Scrum, there is no reason why the software teams not following Scrum cannot apply some of these in their work. Actually, a team involved in any kind of work and not just software development can benefit from using just two concepts; keeping incompletions to the minimum and being more sensitive to the importance of system stability. Any work makes a system temporarily unstable. It is therefore important to identify future events where systems stability is externally important and work towards achieving it. It is important for the team to observe, discuss and learn from instances that lead to system instability and make this an enjoyable activity.