(Kanban don‘t hurt me, don’t hurt me, no more...)
Chances are, that as a person working in IT, you’ve already come across the term “Scrum”. You’ve maybe even practiced it. Possibly liked it. But what does it really mean, this Scrum? What are the foundations, that hold up this neat framework? How did it all begin? Well, let’s find out…
Now here’s a little lesson in history
Scrum is not a fresh new questionable approach, that appeared just a few years ago. On the contrary, it is a solid methodology, tested by many years of usage in the real world. The first time scrum was mentioned in our context, it was in an article in 1986‘s issue of Harvard Business Review, where Hirotaka Takeuchi and Ikujiro Nonaka compared the united effort of a team to a rugby scrum formation. Moving back and forth together, to reach a common goal.
Inspired by this article, Jeff Sutherland with his colleagues implemented Scrum as a development process in 1993 at the Easel corporation.
Two years later, Sutherland and Ken Schwaber together published The SCRUM Development Process at OOPSLA Conference ‘95. From now on, the framework started to gain momentum and wider popularity.
With knowledge gained from practicing Scrum , Sutherland and Schwaber gathered again in 2001, with 15 esteemed colleagues, to write down the Agile manifesto - a list of preferences valued most in the agile culture, focused on the software development.
Agile manifesto then became adopted throughout the industry as well (just as the Scrum framework) and as they say: “...the rest is history“.
Where is it used?
Scrum can be used in a wide variety of projects, that benefit from the agile approach with its ability to quickly adapt to unforeseen changes. It fits very well with incremental and iterative initiatives.
And if you remember our motto “Flexible thinking – reliable delivery“ - that is essentially Scrum. Therefore, it works very well in our software development environment, where we seek to comply with the everchanging needs of our customers.
That’s all very well, but how does it work?
This article should be brief, right? So pretty much as the picture below describes. But the terminology may need some clarification, so here goes a basic explanation:
- Product Backlog is a prioritized list of items that, once completed, form our product.
- Sprint Planning is a ceremony, during which the Scrum team selects items they will work on during the next Sprint.
- Sprint Backlog is a list of items, selected for the Sprint.
- Daily Scrum is a ceremony, during which each member of the development team updates his/her colleagues on the work that was/will be done next.
- Sprint Review is an event, where the development team presents, what has been done during the last Sprint.
- Sprint Retrospective is an event for the team to share feedback on the last Sprint, ideally with action points for improvements as an outcome.
- Product Increment is a potentially shippable part of the desired product
Now let’s try and put it all into place
In Scrum, the Scrum team starts with a prioritized backlog of items to be done. During the Sprint Planning, the team selects items they will work on during the next Sprint. They select the items from the Product Backlog and create a Sprint Backlog. The team starts to work on the items and meets regularly at the Daily Scrum to discuss progress. When the Sprint ends, the team presents the work that was done to the stakeholders at the Sprint Review and provides a Product Increment. After this, the Scrum team holds a Sprint Retrospective, where they discuss the just finished Sprint, provide feedback and work on future improvements.
See? Not hard at all.
If you would like to find out more about our own implementation of Scrum, you can find the description of Scrum Moravia Flavor Scrum MF. And naturally, please keep reading this blog.