At Neoteric, it is an unwritten rule that all of us share our knowledge with those who want to learn. That’s why we’re always happy to take part in initiatives related to promoting agile project management. This month, together with my friend Bartek, we gave a lecture and a short workshop about Scrum.
Who are we?
Project Management is our profession and passion. We are enthusiasts of agile methodologies and innovative technologies. Our day begins with conversations with Australia and Singapore and ends with calls with the United States and Canada (you can read about the challenges of managing projects in different time zones in my previous article). We manage projects related to the creation of web and mobile applications for clients from various parts of the world and with diverse business profiles.
What is Scrum and why is it so easy to fall in love with it?
Scrum is a framework. In the IT area, it is a well-known way of working. Scrum gives us some tips on how to manage projects.
According to the Scrum Guide: “Scrum is a framework for developing, delivering, and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.”
A very important part to understanding Scrum is getting to know the roles. The Scrum Team consists of Product Owner, Development Team, and Scrum Master.
It’s the only person responsible for managing Product Backlog, an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The concept of managing Product Backlog includes:
- organizing the order of elements of the Product Backlog in a way that best achieves the goals and missions set up,
- optimizing the value of work performed by the Development Team,
- ensuring that the Product Backlog is available, transparent and clear to everyone, and also describes what the Scrum Team will be dealing with in the next step,
- ensuring that the Development Team understands the elements of the Product Backlog in the required degree.
No more words needed.
The team consists of professionals who do the work of delivering the product. Speaking about “development”, I mean all the roles that are necessary to let the team show a working piece of the product at the end of the Sprint. In other words, whether you’re a programmer, tester or business analyst – in Scrum every person, regardless of the role, is called a developer.
Development Teams have the following characteristics:
- They are self-organizing. No one tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.
- Development Teams are cross-functional, with all the skills necessary to create a product Increment. A sample team can consist of several programmers, several testers, a system administrator and a UX designer. However, this does not mean (contrary to the commonly prevailing myth) that, for example, a tester must be able to program, and a UX designer has to be able to write automated tests. If the team as a whole has all the required competencies, it can produce functionalities independently and without unnecessary downtime.
The team works in iterations – Sprints (a time-box during which a potentially useful version of a working product is created). Sprints have consistent durations.
Sprints consist of some events:
- Sprint Planning. The plan is created with the collaborative work of the entire Scrum Team. Sprint Planning answers the following questions:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will we achieve the work needed to deliver the Increment?
- Daily Scrums. A Daily Scrum is a 15-minute time-boxed event for the Development Team. The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how the progress is trending toward completing the work in the Sprint Backlog.
- Sprint Review. A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate on what was done in the Sprint.
- Sprint Retrospective. A Sprint Retrospective is an opportunity for the Team to inspect itself, to think what went wrong and what went well during the Sprint and to create a plan for improvements.
After a short lecture, there was a practical workshop during which participants had the opportunity to use the knowledge from the theoretical part.
The participants were divided into two groups and they selected individual roles for themselves. They had to feel like employees of a small advertising agency who must provide a newly created shopping center with a catalog of products.
During the workshop, we checked how much the group managed to remember from the lecture. They needed to use their knowledge about who is responsible for what in Scrum and how important meetings are in practice.
During the sprints, random events occurred. We took scissors or glue away from the groups and we checked how they would react. We also tried to distract a team member from work in order to check whether the scrum master would react. Of course, the teams made minor mistakes, but that’s what it was all about because you learn the most from your mistakes.
After the workshop, we summarized their mistakes and what they did correctly. We also asked for their feedback, which is always important to us. We were extremely proud to hear that the workshop was very enjoyable, and it helped the participants understand the roles in Scrum and learn how important it is to schedule all the meetings properly.