I am lucky to work in an environment where I have the chance to adapt to changing requirements in short periods of time. As outlined in an earlier article this is part of working in an agile environment.
Getting more specific one agile methodology is scrum. I try to develop software according to this framework. I write “try” here as there are always things you can improve on.
Scrum has its roots in physical manufacturing. Ken Schwaber and Jeff Sutherland were the first to document the application of these ideas in software development - labeling it as scrum. What they say is that scrum is lightweight, simple to understand but difficult to master. Based on my own experience I totally agree with that.
Scrum is based on making experiences and take decisions on the basis of those experiences. The team wants to optimize predictability and control risk. That's why scrum is based on an iterative and incremental approach instead of making huge plans. In the end this comes down to the following three corner stones:
- transparency: those that are responsible for the outcome need to have detailed insights into the work, they also need to understand these insights, hence a common language is necessary,
- inspection: the applied process has to be inspected regularly to verify that the team is on the right path process wise,
- adaptation: if during inspection a deviation from the accepted standards was determined the process has to be adapted.
The last two points are ensured with the help of the events sprint planning, daily scrum, sprint review and sprint retrospective. These and the structure of the scrum team will be part of my next article.
Post image taken by me, published under CC BY-SA 4.0.