Implementing Scrum at 2359 Media
As a team lead at 2359 Media now and having managed numerous development projects, the importance of having a lightweight, iterative and incremental framework for managing complex work has never been clearer. There are plenty of tools out in the market and many of them can be rather complicated, which is why I eventually decided on implementing Scrum for my team.
Furthermore, companies that have adopted the Scrum framework report the following benefits:
- Increased ability to manage changing priorities
- Better visibility into projects
- More alignment between business and IT
- Faster time to market
- Being able to complete complex projects that previously could not be done
What is Scrum?
Firstly, Scrum is a project management tool and not a methodology. It is a tool for transparency as it requires team members to be honest with one another to surface issues or impediments. It will be a big change for many teams to run things more efficiently moving forward.
To achieve this, there are five values that underpin Scrum. They are Courage, Focus, Commitment, Respect and Openness. These values are important in maximizing the benefits of Scrum as they shape how teams behave, plan and execute their tasks at various stages of the Scrum.
What is in a Scrum Team?
The Scrum Team consists of the Scrum Master, the Product Owner, the Development Team, designers, QA and any other supporters.
The role of the Scrum Master is to remove impediments. If there are blockages or problems coming up, the Scrum Master’s job is to get things out the way and to get the project up and running. The Scrum Master is the middleman between the Product Owner and the Development team.
In addition, the Scrum Master leads change, to help everyone improve and succeed. He or she teaches and coaches Scrum theory, practices, values. Facilitates Scrum events, and referees Scrum rules. Coaches the inspect and adapt of Product and Process. Encourages transparency and honesty. Helps remove impediments. Protects from distractions. Leads by serving, not by directing.
On the other hand, the Product Owner (usually the client) is responsible for maximizing the value of the Product. To do so, the Product Owner has to have a deep understanding of the needs of the customers/users, and the goals of the business. The Product Owner also articulates a clear vision for the Product, and owns the Product Backlog — a prioritized list of everything needed in (or for) the Product. He or she is responsible for deciding the tradeoffs between Scope (features), Schedule, Cost, and Quality.
Finally, the Development Team is responsible for producing the Product. Together they self-organize and manage their work on the product in each sprint. As a cross-functional team, they have all the skills needed to produce a “done” product in each sprint. The recommended size of a development team is 3 to 9 people. For larger Products, multiple small teams work in parallel.
What does the Scrum process look like?
A sprint consists of three parts: the planning stage, producing stage and the inspection stage. The bulk of the sprint would be spent on producing, taking around 4 work days, while the planning and inspection would take half a work day respectively.
In the Planning stage, the sprint planning is done between the Scrum Master and Product Owner and Development Team.
In the Production stage, the Scrum Master and the Development Team works together on daily scrums to deliver the release quickly and efficiently.
In the Inspection stage, the Scrum Master carries out a sprint review with the Development Team and Product Owner, as well as any other stakeholders involved in the Product. The Scrum Master may also carry out a sprint retrospective with just the Product Owner and Development Team instead.
The sprint goal consists of a product backlog, which as noted above, is a prioritized list of items needed in the product such as features, user stories, technical work, fixes, changes, improvements and knowledge acquisition. The team works towards building a Minimum Viable Product (MVP), which is the smallest collection of Product Backlog Items needed to have a usable version of the Product. There is also a Scope Buffer in the Product Backlog that consists of items that can be removed or replaced if delays or urgent features appear.
The Scrum Team creates the definition of “Done” before the first sprint begins. “Done” items are fully tested, defect-free and documented. Items should have also passed automated unit and functional tests.
Dos and Don’ts of Scrum
In the case of a project delay, there are certain “dos” and “don’ts” of Scrum.
Some of the things a Product Owner could do are:
- Increase schedule, by adding more Sprints (which increases Cost).
- Reduce scope, by descoping low-priority Product Backlog items.
- Reduce scope, by delaying low-priority Product Backlog items to a later release.
- Reduce scope, by simplifying low priority Product Backlog items.
- Work with Scrum Master and Management to reduce impediments.
However, Product Owners may intuitively add more developers to the project, increasing cost and reducing velocity for a period of time, or even permanently. Doing so might only add pressure on the developers which would reduce quality and cause burnout, reducing velocity as well.
What happens in a large project?
In applying Scrum to a large project, there will be multiple teams working in parallel with a Chief Product Owner that the Product Owners report to and a Chief Scrum Master that the Scrum Masters report to. The Scrum Masters facilitate direct communication and coordination between development teams. For instance, instead of having a single group of 35 developers working on a large project, they will be broken into smaller teams of 5 with a Product Owner and Scrum Master in each one of them.
There will also be a scrum of scrums where representatives meet on a regular basis (2–3x per week) for high-level coordination, resolving dependencies, and surfacing cross-team issues or concerns.
Concluding Thoughts
While I started off the article highlighting the benefits of using Scrum, it is important to recognize that it is not a silver bullet, and the key to success is proper implementation. Personally, Scrum has helped my team and clients be more aware of the product’s progress and where we stand in our daily scrum.
In addition, the Scrum process needs to be contextualized to different organizations and needs. For instance, while a week may be the most common sprint length, teams should adjust to their own needs — in my teams, we switched to two weeks because we felt that suited us better.
Stories can absolutely be stretched over more than one sprint. That’s just a reflection of not all tickets fitting neatly into a sprint, and is not uncommon. And lastly, continuous delivery is also not a feature of Scrum — both are independent of one another.
Nonetheless, teams that use Scrum discover how to react more quickly and respond more accurately to the inevitable change that comes their way. And by staying focused, collaborating, and communicating, teams can accomplish what truly needs to be done — together.
This article was written by one of our Team Leads, Elroy Chew, after sharing with the 2359 Media team on how to implement Scrum across the organization to enhance service delivery.
