Bibik How to Kill the Scrum Monster

Quick Start to Agile Scrum Methodology and the Scrum Master Role
1. Auflage 2018
ISBN: 978-1-4842-3691-8
Verlag: Apress
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Englisch, 81 Seiten

Implement Scrum or improve how Scrum works in your team or organization using this concise, sharp, and programmatic book. You will quickly learn what you need to know without getting confused with unnecessary details.What You'll Learn
Become familiar with Agile concepts and understand the path from Waterfall to the Agile Manifesto
Understand the most commonly used Agile methodology-Scrum-and how it relates to eXtreme Programming and Kanban as well as to Lean principles
Identify the challenges of the Scrum Master role and understand what this role is all about
Know the stages of Scrum team developmentEmbrace and solve conflicts in a Scrum teamWho This Book Is For
Anyone looking for a simple way to understand Scrum methodology


Ilya Bibik is an experienced Scrum Master with more than 16 years of experience in the software development industry, including seven years in the Scrum Master role. He has a master's degree in e-commerce and a bachelor's degree in software engineering, and a teaching diploma. His professional background also includes software development, software project management, software quality management, software security, school teaching, and military experience with electro-optical technologies.

During his career in the software industry, Ilya has used software development methodologies such as Scrum, Kanban, and Waterfall. He has also worked in business in the areas of retail, wholesale, fashion, e-commerce, e-learning, real estate, manufacturing, ISO-9000, and rental property management.

Autoren/Hrsg.

Bibik, Ilya

Inhaltsverzeichnis

1;Contents;4
2;About the Author;5
3;Acknowledgments;6
4;Introduction;7
5;Chapter 1:From Waterfallto Agile;8
6;Chapter 2: Overview of Agile Methodologies;14
6.1;eXtreme Programming;15
6.1.1;Risks and Mitigations;16
6.2;Kanban;16
6.2.1;Risks and Mitigations;18
6.3;Scrum;18
6.3.1;Risks and Mitigations;18
6.4;Hybrid of Different Methodologies;19
6.5;Lean;20
7;Chapter 3: Agile Scrum Deep Dive;21
7.1;The Scrum Team;22
7.2;How Scope is Divided;24
7.3;Sprint Cycle and Meetings;25
7.4;Planning Process;27
7.5;Definition of Done;28
7.6;Board;29
7.7;Team Rules;30
7.8;Blocks and Impediments;31
7.9;Velocity;31
7.10;Tools;33
7.11;Important to Always Keep in Mind;34
8;Chapter 4: Scrum Master: What It’s All About;36
8.1;Influence Without Authority;37
8.2;Scrum Master Admin Work Trap;37
8.3;Combining Other Roles with the Scrum Master Role;38
8.3.1;Scrum Master/Developer;38
8.3.2;Scrum Master/Quality;38
8.3.3;Scrum Master/Line Manager;38
8.3.4;Scrum Master/Product Owner/Business Analyst;39
8.4;Perceptions, Personalities, and Conditions;39
8.5;Commitment of Scrum Master to Additional Tasks;40
8.6;Scrum Master Technical Skills;40
8.7;Estimating and Monitoring Your Team;41
8.8;Accepting Change by the Team;41
8.9;Build Scrum Master Confidence;42
8.10;Scrum Master = Project Manager?;42
9;Chapter 5: Team Dynamics;44
9.1;Relationships Between Roles in the Team;46
9.1.1;Scrum Master–Product Owner;47
9.1.2;Architect–Product Owner/Architect–Scrum Master;47
9.1.3;Scrum Master–Quality Manager;47
9.1.4;Architect–Developers;47
9.1.5;Scrum Master–Developers;48
9.1.6;Product Owner–Team;48
9.1.7;Technical Writer–Team;48
9.2;External-to-Team Communications;49
9.2.1;Team–Line Manager;49
9.2.2;Team–Program;49
9.2.3;Team–Stakeholders;49
9.3;Conflict/Problems Resolutions;50
9.3.1;Scrum Master as Part of Conflict;54
9.3.2;Conflict Bottom Line;55
10;Chapter 6: Key Takeaways;56
11;Appendix A: Case Studies;58
11.1; Situation 1: A Team Member Is Taking Over Responsibilities of Another Role (Not in Order to Help);58
11.1.1;Background;58
11.1.2; Root Cause;59
11.1.3; Possible Solutions;59
11.1.4; Decision;59
11.2; Situation 2: Ineffective Meeting Planning;59
11.2.1;Background;59
11.2.2; Root Cause;60
11.2.3; Possible Solutions;60
11.2.4; Decision;60
11.3; Situation 3: Quality Expert Constantly Misses Deadlines;60
11.3.1;Background;60
11.3.2; Root Cause;61
11.3.3; Possible Solutions;61
11.3.4; Decision;61
11.4; Situation 4: Another Team Is Trying to Take Over;61
11.4.1;Background;61
11.4.2; Root Cause;62
11.4.3; Possible Solutions;62
11.4.4; Decision;62
11.5; Situation 5: Micromanaging Line Manager;62
11.5.1;Description;62
11.5.2; Root Cause;62
11.5.3; Possible Solutions;63
11.5.4; Decision;63
11.6; Situation 6: One of the Developers Rejects the ScMa;63
11.6.1;Description;63
11.6.2; Root Cause;63
11.6.3; Possible Solutions;64
11.6.4; Decision;64
11.7; Situation 7: PO Isolates Himself from the Team (PO Doesn’t Want to be Part of the Team);64
11.7.1;Description;64
11.7.2; Root Cause;64
11.7.3; Possible Solutions;65
11.7.4; Decision;65
11.8; Situation 8: Conflict Between Teams;65
11.8.1;Root Cause;65
11.8.2; Possible Solutions;65
11.8.3; Decision;66
11.9; Situation 9: Lack of Resources in the Team;66
11.9.1;Description;66
11.9.2; Root Cause;66
11.9.3; Possible Solutions;66
11.9.4; Decision;67
11.10; Situation 10: Lack of Senior Developers in the Teams;67
11.10.1;Description;67
11.10.2; Root Cause;67
11.10.3; Possible Solutions;67
11.10.4; Decision;68
11.11; Situation 11: Team Rejects Agile Scrum Methodology;68
11.11.1;Description;68
11.11.2; Root Cause;68
11.11.3; Possible Solutions;68
11.11.4; Decision;69
11.12; Situation 12: Team Wants to Have Longer Sprints of Four Weeks;69
11.12.1;Description;69
11.12.2; Root Cause;69
11.12.3; Possible Solutions;69
11.12.4; Decision;69
11.13; Situation 13: Developer in the Team Will Work on Other Developers Tasks Instead of His/Her Own;70
11.13.1;Description;70
11.13.2; Root Cause;70
11.13.3; Possible Solutions;70
11.13.4; Decision;70
11.14; Situation 14: PO Fails to Provide Requirements;70
11.14.1;Description;70
11.14.2; Root Cause;71
11.14.3; Possible Solutions;71
11.14.4; Decision;71
11.15; Situation 15: Requirements Change During Sprint;71
11.15.1;Description;71
11.15.2; Root Cause;71
11.15.3; Possible Solutions;72
11.15.4; Decision;72
11.16; Situation 16: External Stakeholders Try to Change Requirements Directly With Developers;72
11.16.1;Description;72
11.16.2; Root Cause;72
11.16.3; Possible Solutions;73
11.16.4; Decision;73
11.17; Situation 17: Not Able to Complete Quality DoD During the Sprint;73
11.17.1;Description;73
11.17.2; Root Cause;73
11.17.3; Possible Solutions;73
11.17.4; Decision;74
11.18; Situation 18: A Lot of Nonconstructive Feedback During Retrospective;74
11.18.1;Description;74
11.18.2; Root Cause;74
11.18.3; Possible Solutions;74
11.18.4; Decision;74
11.19; Situation 19: Lack of Participation During Retrospective;75
11.19.1;Description;75
11.19.2; Root Cause;75
11.19.3; Possible Solutions;75
11.19.4; Decision;75
11.20; Situation 20: Justified Negative Feedback from Stakeholders During Review;75
11.20.1;Description;75
11.20.2; Root Cause;76
11.20.3; Possible Solutions;76
11.20.4; Decision;76
11.21; Situation 21: Unjustified Negative Feedback from Stakeholders During Review;76
11.21.1;Description;76
11.21.2; Root Cause;76
11.21.3; Decision;77
11.22; Situation 22: Unrealistic Estimates During Planning;77
11.22.1;Description;77
11.22.2; Possible Solutions;78
11.22.3; Decision;78
11.23; Situation 23: Can’t Complete Sprint Commitments;78
11.23.1;Description;78
11.23.2; Root Cause;78
11.23.3; Possible Solutions;79
11.23.4; Decision;79
12;Index;80