Signs that your scrum adoption is failing
Upcoming SlideShare
Loading in...5
×
 

Signs that your scrum adoption is failing

on

  • 291 views

 

Statistics

Views

Total Views
291
Views on SlideShare
290
Embed Views
1

Actions

Likes
1
Downloads
5
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Signs that your scrum adoption is failing Signs that your scrum adoption is failing Presentation Transcript

  • Anand Kumar Keshavan Software Product Development Specialist
  •  Scrum Master stopped being an individual contributor  Scrum Master assigns and tracks tasks of development team Scrum Master is NOT a Project Manger  Authority over the Scrum process vs. Team members  Ensuring team members are not blocked vs.. Checking up to see whether they are screwing up! Role is:  to ensure that Scrum meetings are conducted efficiently- within 15 minutes  to make sure that issues/impediments raised during meeting are resolved offline.  Work with Product Owner to ensure readiness of Product Backlog for next Sprint.  Ensuring that team members do not over or under commit.
  •  Do not happen at the same time everyday  Do not happen everyday– weekly meetings or meetings every alternate day.  Last more than 15 minutes  Discussions tend to deviate from the core- what I was working on yesterday, What I will do today and any possible impediments. For example, extensive analysis of the way a feature should be implemented, arguments on architectural issues…
  •  Team members do not update their tasks on a daily basis  Scrum master updates it for team members!!  Burn down chart remains “flat” for most part of the sprint and drops suddenly towards the end.
  •  Works overtime- 12-14 hours a day or more- especially during the last week of a sprint.  Members do not participate in sprint planning meetings, sprint demos or sprint retrospectives  As a whole does not complete the items planned in a sprint on a regular basis. Strong indication that the Scrum Master or another stakeholder is forcing the team to take up more than it can chew.  Team members do not strongly insist on including refactoring items in sprints- points to increasing technical debt and/or team fatigue.
  •  Odd sprint lengths- weekly sprints or 4 monthly sprint--  Product owner, Executive management attends daily stand-ups  Strong indication of scope been changed during sprints  Undermining the role of the scrum master.  Product being released after every sprint  Short sprint planning meetings- indicating that Product Owner/ Scrum master are allocating backlog items to team members  No sprint demo  Short or irregular retrospective meetings
  •  Executive management uses Sprint data for appraisals of team members  Collection and analysis of stupid metrics like tasks committed vs.. delivered for individuals and team  Strong aversion to rework by team members- indicates a culture of “getting it right the first time”- antithesis to agile principle.  External monitoring of the Scrum process, minutes of stand-up meetings, daily status reports, audits of artifacts, approval trails etc.- strong indication that an organization is not culturally ready for Agile adoption.
  • “Scrum is:  Light weight  Simple to understand But difficult to master!!” ( Scrum Guide) ( Sort of like Chess or Programming)