A couple of years ago, I wrote a series of posts about Scrum. Several years of experience later and due to the rise of containers and microservices I want to revisit my approach to Scrum in 2020 in this post and talk about what should be done differently.
What is Scrum?
Scrum is a framework that describes an agile approach on how to manage a project. It gives recommendations to teams on how to manage their work to achieve high team performance and support each other in the process. For more details about Scrum read my five-part series.
Most sprints are between two to four weeks. That’s already better than waterfall approaches but there are still many handovers between teams or departments. For example, in a project, I worked previously the work items were created by the Product Owner and then given to the developers. After a two week sprint, all finished work items went back to the Product Owner because he was also responsible for testing. After several days to several weeks the testing results came back to the developers and the code got either deployed to production or new work items were created.
When deploying to production, the code was handed over to the ops team which wasn’t involved in the development of the new features at all. Suddenly they had to keep code and features running which they didn’t know anything about.
If the testing found bugs, these bugs got reported back but since the next sprint already started, they were planed earliest in the sprint after. This means that developers have to touch the same feature they implemented weeks before again. Due to the long time between the implementation and the revisit, it takes some time to get into the code again. This loses a lot of time and therefore causes a lot of costs. In my eyes, this isn’t how you should do Scrum in 2020.
How to do Scrum in 2020
Scrum in 2020 should be done differently because we have so many great tools that support us to get features done faster. We have microservices, Docker and Kubernetes, CI/CD and, great DevOps tools like Azure DevOps or GitHub Actions. All these tools support developers to get features faster into production. A feature that is implemented but not in production is nothing but costs.
To do Scrum in 2020 right, I think that it needs a change of the mindset of organizations and also the adoption of the development process. Changing the development process is straight forward in theory. Have automated tests and use CI/CD. Changing the mindset of an organization or its customers is harder. To get features fast to production the testers need to be included in the development process and if someone else, for example, marketing has to approve the changes, they have to be also included in the development process and give their feedback fast (< 1 day).
I also think that the traditional stages of Test (also often called Q&A or Integration) and Production are outdated. With CI/CD you can deploy every pull request and once the pull request is approved, delete the container.
The goal should be to develop a feature in the morning and have it running in production in the afternoon. If it takes days or weeks until a finished feature runs in production, you are losing on the value the feature provides and increase the costs.
Conclusion
Scrum in 2020 should be all about getting features into production as fast as possible. If developers implement features and only deploy at the end of a sprint, the costs are higher than necessary an,d also the quality is not as high as possible. To do Scrum right, organizations have to adopt a modern mindset and, developers have to use modern DevOps tools.
Comments powered by Disqus.