Robert Kneschke - stock.adobe.co
Are you really doing Scrum? Follow these guidelines to be sure
Let's examine how the proper implementation of Scrum elements like timeboxing, the product owner and Scrum Master ensure a team will actually benefit from the Agile framework.
While a team may think it is following Scrum guidelines and best practices, that might not be the case. Sometimes old development practices die hard. In other instances, teams may say or think they're doing Scrum, but are only going through the motions.
When a team implements Scrum correctly, the framework delivers valuable benefits. Scrum provides an empirical foundation for teams, which enables them to more frequently deliver higher-value products. When a mature, properly structured Scrum team follows the framework, the team can reap the benefits of Scrum.
It's one thing to implement Scrum. But to optimize development through the framework, a dev team will need to adopt several key Scrum guidelines. Here are some ways an IT organization can tell if they are really doing Scrum.
You diligently apply timeboxing
Timeboxing sets a fixed amount of time for an activity, and it's a practice a team should apply to all elements of the Scrum framework.
It's necessary to structure work in sprints that have a well-defined interval of one to four weeks, depending on the tasks at hand. Each sprint should also contain goals that ideally no team member would alter during the predetermined interval.
Once the sprint concludes, the team will then hold a review with stakeholders in a one- to four-hour timebox based on the sprint interval. The review allows the group to collectively inspect the results and ensures that the stakeholders can offer feedback on product development progress during each sprint interval.
Additionally, the team should hold an internal team retrospective in a one- to four-hour timebox at the conclusion of each sprint. This end-of-sprint sprint meeting allows the team to assess performance against goals and look for areas of improvement based on their success and failure.
If you set timeboxes for all meetings, the team members will know how much time they need to set aside each day. When meetings have clearly defined topics and a fixed duration, they'll be more productive and allow the team to get back to work faster. Timeboxed events maintain the process schedule and can ultimately lead to a viable product at the end of the sprint.
Your team meets daily
During a sprint, teams should meet every day. This practice provides the opportunity for a quick update on task performance, and team members can discuss dependencies, highlight any problems and track progress toward the sprint goal.
When issues arise at the daily Scrum meeting, team members should continue the conversation offline to work through problems and keep the project's timeline intact.
You organize your team for Scrum
Scrum teams are structured to facilitate agility and communications. Each Scrum team consists of a:
- product owner
- Scrum Master
- development team
The product owner is responsible for ensuring product delivery and organizing the Scrum team's work schedule. This person also creates and manages the how the team prioritizes the product backlog.
The Scrum Master oversees the establishment and execution of the Scrum. This team member helps everyone -- including management -- understand Scrum theory and apply that practice within the organization. Members of the Scrum team are the ones who create the actual product each sprint. These developers work with the Scrum Master and product owner to move work from the backlog into the sprint based on the priorities laid out in the Scrum agenda. Typically, the Scrum team is comprised of 10 or fewer people, but this number is flexible based on the scope of the project.
You select one product owner, one Scrum Master
If a team truly wants to follow Scrum, it needs to define certain roles. That mean only one person should be the product owner, and a different sole individual should be the Scrum Master. When someone wears multiple hats, the team is not following the framework.
Team size needs to be constrained, too. Generally, smaller, well-defined teams can function better. The larger the team, the more likely it is that communication and productivity will suffer.
You treat Scrum as prescriptive
Scrum helps teams establish a solid foundation upon which to develop. If a team is new to Agile, Scrum can be an ideal framework to ensure flexible development with a base structure. The practice can be fine-tuned to fit and evolve with the team's competence and performance. It ensures that work within each sprint is fixed and allowing for the team to adjust intervals as necessary based on sprint priorities. Therefore, it's a good choice for development teams but isn't necessarily ideal for the responsiveness of operations teams.
For teams that need to constantly re-prioritize work daily, other Agile methodologies -- such as Kanban -- may be a better fit. Otherwise, if a team is really doing Scrum, it can follow these principles and ensure cleaner development.
