We Are Agile Using Scrum-But
The effects of omitting key Scrum framework elements
20 November 2017
Many software development teams worldwide have changed their way of working to follow the Scrum framework. As part of this change, some teams follow only parts of the framework and omit some key elements. Whenever a prescribed role or ceremony is omitted, it likely impacts the quality or the outcome of the team’s work.
We are Agile and using Scrum! But …
Based on my experience, here is a list of the usual omissions — and reasons why I think they should not be omitted. I’m sure that you have experienced some other omissions, so feel free to leave a comment about your experience.
No full-time ScrumMaster
Some teams operate without a dedicated person in the role of a ScrumMaster. In such cases, one of the Scrum Team members doubles up as a developer, tester, or business analyst and ScrumMaster. This person is usually stretched between these two responsibilities and faces challenges in trying to fulfill each role to the team’s expectation and satisfaction.
The Scrum Team should have a dedicated ScrumMaster. The number of concurrent teams that a ScrumMaster can work with can range from one to three, based on the team size, nature of work, and comfort with the Scrum framework. A great ScrumMaster will help the team become highly efficient as a collaborative unit that works cohesively toward the product vision.
No product owner
Some teams have a proxy product owner or are missing one completely. A proxy product owner is one who is not actively performing the role of a product owner (PO) for the team and is only available occasionally to answer questions about the product. Another setup in which the proxy product owner is useful is when the work is done by a business analyst on the team, in consultation with a group of product experts, and one of them is the designated PO for the team depending on the feature being worked on. In both setups, the team suffers. The number of communication loops that are added severely limits the team’s ability to create working, tested software in every sprint that the PO can review and accept. Because multiple people provide input to the team, the chances of some of them not getting their “wishes” fulfilled are very high. This could result in stories not being accepted or changes coming in all the time.
A dedicated and empowered PO who is readily available to the team enables them to become productive; frequent feedback from the PO ensures that their working, tested software will meet the customer’s needs and has higher chances of getting accepted.
No timeboxed iterations
Some teams feel the urge to extend their sprint end dates whenever their user stories are not done. At other times, they end their sprints when the work they had planned gets blocked or they finish the work early. Sprints that have durations all over the place take away a very important attribute of a Scrum Team: predictability.
Teams that follow timeboxed iterations can use their velocity and capacity trends from previous iterations to forecast when their remaining work can be done. This forecasting enables their organizations to line up releases and set expectations with their customers. By removing this predictability, organizations are either unable to forecast release dates to their customers or stick to predefined dates that their teams may or may not realistically achieve.
Teams must keep their iterations timeboxed, which enables them to make every effort to meet their commitments. They can leverage the outcomes of such sprints to forecast and seek help based on challenges they foresee.
Don’t follow all ceremonies and activities
Some teams are comfortable following only some of the Scrum ceremonies and choose to avoid other ceremonies.
I’ve observed that the sprint retrospective is the ceremony that gets neglected the most, followed by the sprint review and showcase or demo. The retrospective is a difficult ceremony to conduct meaningfully. The teams that have challenges meeting their sprint commitments are those most likely to avoid the retrospective meeting, thereby losing out on the golden opportunity to identify improvements and seek help. Some teams express that they don’t have any problems, hence they don’t need to retrospect. In cases when this is true, the retrospective meeting could be done at a different frequency or in a technique that expressly helps the team recognize their achievements and move on.
The other ceremony that is neglected is the sprint review. In cases in which the PO is not actively involved, these reviews are conducted for the sake of compliance, and the team sleepwalks through user stories (some that may not even be done!). The ability of the PO to review their work throughout the sprint is overlooked, and the chance to provide feedback is completely missed. These teams will often near their product releases with several surprises and challenges. Teams that have an accessible PO can work with the individual to get work to the Done state throughout the sprints. Because of the PO’s availability, the product increment can be showcased to a wider set of stakeholders to apprise them of the progress made and also seek their feedback.
The daily stand-up (DSU) meeting — though usually conducted — gets abused because of the format and content. Team members often ramble about work done and issues faced. This ceremony meanders into issue resolution sessions in which the team spends upwards of 30 minutes (sometimes an hour or more!). Focusing on work accomplished and presenting impediments — but staying away, at this point, from resolving them — will keep the DSU brief, focused, and meaningful.
No backlog of prioritized items
During a sprint, Scrum Teams commit to a set of user stories from a prioritized product backlog for development. Whenever they are impeded, they should have the ability to work with the PO and select some other user story from their product backlog to develop. When the PO does not have a backlog that the teams can dip into in such cases, the team’s ability to use their capacity is constrained. Productivity takes a hit, and teams spend time doing less important work.
POs must constantly create user stories, review them with their development teams, and get them ready for future sprints. Some teams set a target to have two or three sprints’ worth of work ready in their backlog so that they are never starved. The development activity keeps churning out the most important features in every sprint. Teams that don’t have a prioritized and ready product backlog will also be disconnected from the product vision; team members are confused about the next set of features they will work on. This distraction generates several other side effects, such as misalignment, lack of interest, missed product vision, etc.
A healthy backlog ensures that a team is always aligned with the product vision. By being involved in the backlog refinement activities, the team will be aligned to the most important set of features and will actively engage in the success of the product.
No dedicated team members
Some organizations are unable to assign dedicated members to teams. By design, members are expected to either work with multiple teams simultaneously or keep changing teams after every sprint. Such splitting of time or random rotation of team members prevents the formation of a team and keeps members guessing about what they are expected to focus on next.
Teams that work well together can expect better outcomes and overcome challenges more easily as compared to a unit of discreet and disoriented members. Teams whose members are working across multiple teams often leave other team members struggling to cope with the unavailability of the “shared” capacity when they are needed. This will dampen interest in the work and at times even impact the quality of the output.
Scrum Team members are expected to collaborate, help each other, and have the backs of others on the team. Because of these attributes, they are often able to overcome roadblocks that would normally stop ordinary teams in their tracks, and they achieve their goals.
Don’t deliver Done stories in every sprint
When teams don’t have dedicated members, a well-defined and prioritized backlog, and a loose implementation of the framework, they struggle to create working, tested software at every iteration. The Definition of Ready and Definition of Done should normally guide the team in getting their user stories done according to their own agreements. At such times, teams struggle to gain the PO’s acceptance of the product increment they have developed (their interpretation of it!).
A combination of dedicated team members, a healthy backlog, and adherence to the Scrum framework will increase the chances of a team delivering working, tested software each sprint and getting them accepted each sprint. Working agreements that make sense and a Definition of Ready and Definition of Done that matter are often at the foundation of successful teams.
What is your experience? I’d love to hear the challenges you’ve faced and how they’ve impacted your teams.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.7 (9 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.