One of the pillars of Agility is to iterate. What I like about it is that you can iterate about almost anything. Your thoughts, your practices. And why not over tools and frameworks that we talk about and sometimes use (and misuse), such as Scrum?
Scrum is pretty simple in its essence. So simple that one must pay attention not to get lost on accessory tools that the community built around it. All very nice and useful. All NOT a must-have, though. So, forget about poker planning, Scrum boards, Jira. Forget about how big should team be, how long should iterations be. Let’s revisit what Ken Schwaber and Jeff Sutherland shared as empiric knowledge that came to be named Scrum. The major reference for it till this day still is the scrum guide, no matter how many cute, funny or structured tools and communities appear enhancing the subject. This post, like many others, is just a helper on understanding what is defined as Scrum by its creators.
Scrum has:
- a Team (with Roles);
- some Events (sometimes called Ceremonies);
- a Backlog (Scope of work);
- and work a cycle called Sprint.
It is easy to remember those basic items when one thinks that a team must come together to deliver work periodically.
The Team
How big should the team be? How small? How varied? What skills should they posses? So many questions arise in the community, notably among novice adopters. Not to say they are not relevant, the answer lies in understanding what is a team from the perspective of Scrum. The team is composed by a group of doers, a cheerleader and a business-tuned worker. As simplistic as this might sound, that is my interpretation on the 3 roles found within a team, ideally all separate, but let us not get ahead of ourselves.
The Development Team
The doers, the worker, are called the Development Team. Those are the people who perform the actual work, the masters of the implementation of whatever is it that is needed. Those people are as generalists or as specialized as needed by a project or company and it is important to form a team having in mind they should be self-organized, independent, self-sufficient. Those people should have in their hand all, or almost all, power to deliver whatever is needed in their scope of work. When we think about software development, as a whole, the team should know or be in position to learn and use any technology in order to produce their software, API, application or whatever in the end of a cycle. These people are accountable by whatever the results may be. A big sense of ownership and accountability is required, so teams must be formed in an atmosphere that allows for this to happen.
The Scrum Master
The Cheerleader is the Scrum Master. I like this allegory because this is a very humane, fine tuned and very peculiar role. A cheerleader gives all her energy to the team. She devotes herself in trying to make the team raise to the challenge without being able to get in the field and play. The Scrum Master is observant of Scrum within the team and the organization. She is someone who makes sure Scrum is understood by the team members, practiced by the teams, by the managers. A great Scrum Master eventually gets useless as the team progresses into full self-management and Scrum knowledge. She will then work more on evangelizing other spheres of the company that might still pose challenges to the self-organized teams, coach the management layers, try and create a change-positive environment. In a much ideal scenario, she will then flee once “her work is done”. Now, in the reality, the challenges are way too many and the Scrum Master is more than just a Scrum warrior. This role belongs to someone who will spend her time helping the team to gain focus, taking in her hands activities that overwhelm the team, help the Product Owner in maximizing backlog value and find innovative ways for everybody to practice Agility. The Scrum Master (or group of Scrum Masters) is paramount in shaping the company’s outlook in Agility overall. She brings understanding to all levels of the organization and equalizes ways of work throughout the company, helps teams to increase their productivity, in short, she is a full change catalyst. It should be pretty clear that a Scrum Master is not an “Agile Project Manager”, whatever the latter might be. She is not someone preparing status reports, she is someone coaching or mentoring people and communicating with everybody. Being neither a manager nor acting on an interest of a project but on that of the team, this somewhat common definition could not be further from the true nature and value of a Scrum Master.
The Product Owner
The Business-oriented person of the team is the Product Owner (the PO). He is a champion of the market in which the product (or product-to-be) is inserted. He understands what brings high value, what is a good timeline for features, what is enough or too much as far as the deliverables go. He is also the person who decides when a deliverable is ready to go. With Scrum a team delivers on iterations. Without this important way of working a team cannot be called a scrum team. But when working iteratively a team always gets a chance to improve a feature. To add or remove something, including on the looks or the UX. The PO can then test his expectations either alone with his own knowledge or with Beta users, or just by accepting the feature so it makes it to the market timely and can gather quickly feedback of real users, pioneering in its sector, as it happens with many startups. A good PO works with his team in sharing what is the vision of the product, what is and what is not part of the scope. The PO should refine his understanding with the team regularly so everybody know what to implement and he produces a backlog that is accessible to everybody and that gets improved / detailed with the whole team. It is also the PO who sets the tone for the Sprints and decide, given the important feedback of the team, what are the features that should be worked on, as far as priorities go.
Those are the only roles recognized under Scrum, but they are all that is needed in this simple to grasp yet difficult to master framework.
Interested in learning more about Scrum?
If you are interested in learning more about Scrum, check out my e-book. Scrum is very simple, and you can learn how to use it in a day. If you never worked with agile before it most certainly introduces you to agility in a very practical way.
