BY Patkos Csaba
Scrum is one of the most heavily used agile techniques. It’s not about coding; instead, it focuses on organization and project management. If you have a few moments, let me tell you about the team I work with, and how we adopted Scrum techniques.
A Little History
Scrum’s roots actually extend beyond the Agile era.
Scrum’s roots actually extend beyond the Agile era. The first mention of this technique can be found in 1986, by Hirotaka Takeuchi and Ikujiro Nonaka, for commercial product development. The first official paper defining Scrum, written by Jeff Sutherland and Ken Schwaber, was presented in 1995.
Scrum’s popularity grew shortly after the 2001 publication of the Agile Manifesto, as well as the book Agile Software Development with Scrum, coauthored by Ken Schwaber and Mike Beedle.
A Few Facts
Scrum defines a set of recommendations, which teams are encouraged to follow. It also defines several actors – or roles, if you prefer that terminology – together with an iterative process of production and periodical planning. There are several tools, which accommodate the Scrum process. I will reference a few in this article, but the most powerful tools are the white board and sticky notes.
There is not, and never will be, a list of “Scrum Best Practices,” because team and project context trumps all other considerations. — Mike Cohn
Everything starts with the pig and the chicken. The chicken asks the pig if he is interested in jointly opening a restaurant. The chicken says they could call it, “Ham-and-Eggs.” The pig answers, “No thanks. I’d be committed, but you’d only be involved!“
That’s Scrum! It specifies a concrete set of roles, which are divided into two groups:
- Committed – those directly responsible for production and delivery of the final product. These roles include the team as a whole, its members, the scrum master, and the product owner.
- Involved – represents the other people interested in the project, but who aren’t taking an active or direct part in the production and delivery processes. These roles are typically stakeholders and managers.
This is How We Started
Everything depends on dedication and good will. If you want your team to be efficient, productive, and deliver on time, you need someone to embrace some form of Agile techniques. Scrum may or may not be ideal for you, but it is surely one of the best places to start. Find that someone on your team who is willing to help the others, or you, yourself, can take on the responsibility of introducing Scrum.
You may ask why you should care how another team, like mine, does Scrum. You should care because we all learn how to do Scrum better by hearing stories of how it has been done by others – especially those who are doing it well. – Mike Cohn
The talented team I work with already knew a lot about Agile. We switched from Waterfall development to a more agile process, and released quite frequently. We successfully managed to release every three to six months, having a decently low number of bugs after each release.
But, still, we were far from what we can achieve today. We missed the process, or rules, that would force us to change our perspective on the product and process. That was the moment when our team manager introduced us to Scrum, a term we, at that time, had never heard of.
This person took the role of the Scrum Master.