Scrum is a Methodological Framework that has been on the rise these last few years and is now an integral part of the IT landscape. Widely distributed and implemented in companies and IT departments, this framework has become familiar to many IT project actors.
However, beyond some well-known agility aspects and artifacts, its flawless application can still be subject to a number of pitfalls. For instance, the terms of its implementation and its general understanding, or the different roles stakeholders may have.
The true difficulty comes from the underestimation of the organizational changes and state of mind that it implies. These are often much deeper than those imagined or anticipated.
THE VALUES AGILITY IMPLIES
We can identify 4 fundamental values in the Agile Manifesto:
Individuals and interractions over processes and Tools;
Working software over comprehensive documentation;
Customer collaboration lover contract negotiation;
Responding to change over following a plan.
Scrum is currently the most popular agile implementation technique and one of the most adapted agile methodological frameworks for software development. (Although we often talk about agile methodology, this term is wrongfully employed, in the sense that a methodology suggests clear guidelines, which is in no way the case here.)
THE DIFFERENT ROLES
Scrum define 3 roles:
- The product owner (PO): decides what needs to be developed. He establishes and prioritizes the Product Backlog (list which contains the description of all customer needs, product features, as well as tasks which need to be completed in order to achieve full product development). The product owner works with stakeholders and takes into account end user “inputs”.
- The development team: as indicated by its name, implements the PO’s (product owner’s) requested developments. Whatever position they might have in the team (developer, business analyst (BA), tester, architect…) members of the team are called « developers » because they all contribute to the development of the product.
- The scrum master: is the Scrum methodological framework guarantor. He plays the role of an advisor and is perceived as the agile team coach. He also has a facilitative role in trying to remove any obstacles that may be encountered during the project. He is responsible for putting everything in place, in order to help the team achieve its goals.
The Scrum team works through series of sprints, limited in time (generally between 2 weeks and a month).
Before each sprint is held the 1st ceremony called the « Sprint Planning », where the development team and the PO meet. The PO introduces the Product Backlog to the team. Backlog user stories have already been prioritized by the PO and quantified in terms of workload by the development team who chose a certain number of items from the said backlog. The development team must respect the prioritization given by the PO when choosing user stories. These items form the sprint backlog that must be delivered at the end of the iteration by the development team.
During this sprint, a « Stand up Meeting » or « Daily Scrum Meeting » is held everyday. Each development team member is asked to answer 3 ritual questions:
- What did I work on yesterday?
- What will I spend my day on today?
- What are the difficulties I have encountered and the blocking points that occurred?
At the end of the sprint, the job is packaged for release.
The Sprint ends with 2 final ceremonies:
– The Sprint Review takes place with all concerned parties to demonstrate the work that has been done. This ceremony gives stakeholders the opportunity to see what has been accomplished and give feedback to the development teams.
– The Retrospective is a general overview feedback on what worked well, what problems have be been encountered, how they were solved and what can be improved. The objective of the retrospective is to make the next sprint even more efficient.
To sum it up, Scrum presents a relatively simple, framed approach to software development. However behind this apparent simplicity, the perfect implementation of Scrum remains delicate and can lead to errors that we will be addressing later on in this article.
Now that you’ve learned about agility, we’ll discuss in the next episodes the difficulties of applying Scrum and more generally agility. We will also try to suggest different solutions and recommendations to correct them.