Get certified - Transform your world of work today

Close

Signs of a Waterfalling ScrumMaster

5 February 2016

Alhad Akole
Zensar Technologies Ltd


Based on my Agile coaching experience and observations, below are some typical ScrumMaster behaviors that cause Agile projects to revert to the Waterfall model or go into Scrum-But mode.
 

Release planning

  • Assuming or formulating a story point (SP) and task effort equation
  • Not resolving dependencies among cross-functional teams
  • Not ROAMing (i.e., Resolved, Owned, Accepted, Mitigated) risks
  • Committing to more than the release-level capacity
  • Not welcoming innovations; no space or time for innovations or alternate solutions to problems
  • Not having a full understanding of the big picture — domain-wise and process-wise (applies to cases in which the client organizations are big)
  • Not planning for automation
  • Not planning for or encouraging continuous integration (CI) or continuous delivery (CD)


Sprint planning

  • Assigning SPs to user stories, or trying to challenge a team member's SPs
  • Committing user stories on behalf of the team, without looking at the end goal of the release or sprint
  • Committing user stories in a sprint when they are actually part of a release
  • Supporting user stories that are big enough to fill the sprint length
  • Breaking down user stories into software development life cycle phases; leaving the product owner (PO) to figure out what he or she will get when the user story is marked "done"
  • Assigning user stories and tasks to team members
  • Not planning the cross-skilling
  • Consistently making excuses to increase the sprint length rather than ensuring that user stories are short enough to develop in two to three days; using eXtreme programming (XP) practices to support shorter sprint lengths
  • Planning stories in such a way that development is completed in one sprint and quality assurance (QA) happens in the next sprint
  • Receiving user story acceptance criteria after three to four sprints
  • Not planning for the infrastructure (software, licenses, Microsoft® Visual SourceSafe repository, CI and CD frameworks) needed in advance, which is typically considered in Sprint 0
  • Not planning for the removal of technical debt
  • Taking the hardening sprints to fix all defects (i.e., allowing defects to exists in the system until such sprints are taken) rather than for code maintainability or optimization of the code
  • Considering user stories, which do not meet the Definition of Ready criteria, for the sprint planning meeting


Sprint execution

  • Not educating the team on XP practices
  • Nonexistent impediment backlog
  • Not looking at user stories
  • Allowing changes to happen during sprint
  • Not collaborating with the PO or external members
  • Not tracking the daily team allocation/loading to balance out the unplanned leaves or absences
  • Not making the Definition of Done (DoD) or exit agreement for each stage visible to team members
  • Not citing the team working on tasks (related to sprint) in the Application Life Cycle Management (ALM) tool
  • Testing only after development is complete
  • Not exploring the option to automate


Daily Scrum call

  • Driving the Scrum call; if the ScrumMaster is not one time, the daily call doesn't happen
  • Speaking on behalf of team members
  • Talking too much or monopolizing the discussion
  • Allowing discussions to drift away
  • Asking for status from team members
  • Not restricting the call to 15 minutes
  • Consistently tardy for the call
  • Holding the Daily Scrum at a new location every day
  • Not using Big Visible Information Radiators to show the team's progress
  • Treating task-level planned estimates as efforts (to do + actual)


Sprint review (demonstration)

  • Allowing user stories that do not meet DoD to enter the review meeting
  • Allowing reviews between developer and PO to occur in isolation
  • Not tracking or adding review comments in the product backlog


Sprint retrospective

  • Always following a monotonous format for the sprint retrospective; innovation games are not used
  • Collecting points upfront from the team and putting them in front of the team in one go; restricting the thinking process
  • Hiding the shortcomings of the teams or processes
  • Never working on "improvement" points identified in the retrospectives; not developing and tracking an action plan
  • Not performing a root cause analysis of defects during the retrospective meeting


Use of ALM tools

  • Using only one screen from all available screens for all Scrum ceremonies
  • Not knowing how to create different reports or charts apart from the burn-down chart
  • Not knowing how to handle incomplete user stories
  • Not effectively using the ALM tool for the team's benefit
  • Not educating the team on how to effectively use reports generated from the ALM tool
  • Not using the discussion or team collaboration features of the ALM tool; heavy dependency on emails
  • Rather than blocking the user stories, reducing the capacity of the team if dependent systems, such as dBase or Access, are not available; trying to catch a moving target


Other areas

  • Even though teams are colocated, housing development and QA teams in separate places
  • Drafting internal execution plan only when user stories are made available to QA for testing
  • Not scheduling all required Scrum ceremonies well in advance and inviting required stakeholders
  • Combining retrospectives and Daily Scrum calls
  • Assigning deadlines to teams and Agile coach in order to turn the teams into Agile (say, in the next 15 days)
  • Asking the team to prepare all required documents (Microsoft® PowerPoint presentations, Excel spreadsheets) for all ceremonies
  • Not considering the soft skills or career aspirations of team members
  • Always looking for the Responsibility Assignment (RACI) matrix and drawing lines for tasks (in some cases, going beyond the dotted lines helps the team to deliver faster)
  • For distributed teams, missing the connection to outside Scrum ceremonies with team members
  • Not listening to the Agile coach; rather, the ScrumMaster is doing things on his or her own that are wrong in principle

 

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.



Article Rating

Current rating: 4 (5 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe