Start Scrum Now

Category: Education

Presentation Description

Using Scrum now for better way of doing things.


Presentation Transcript

Scrum Now! : 

Scrum Now! Short presentation for a long Journey.

About : 

About Dương Trọng Tấn Scrum Master, Agile Coach, Training Manager (Software Development), SE Instructor Works for FPT Education, Hanoi Scrum, & Vietnam Agile Community 2

Contents : 

Contents History of Scrum Agile vs. waterfall The Scrum framework Scrum Roles Scrum Master Product Owner Development Team Scrum Process and Sprint Done Definition Scrum Events Sprint Planning Meeting Product Backlog and Sprint Backlog Daily Scrum Tracking Progress Sprint Review Retrospectives Organization Issues Technical Practices 3

First Thing First : 

First Thing First “Agile development is no silver bullet, but it is useful. Organizationally, agile delivers value and reduces costs; technically, it highlights excellence and minimal bugs; personally, many find it their preferred way to work.” James Shore 4 “Scrum works for idiots” Ken Schwaber

Mastering Scrum Scheme : 

Mastering Scrum Scheme Image by Skip Angel, 5

Scrum : 

Scrum 6 Photo courtesy of

Methodology Trend : 

Methodology Trend 7 Source: Forrester Research

Scrum has been used for: : 

Scrum has been used for: Commercial software In-house development Contract development Fixed-price projects Financial applications ISO 9001-certified applications Embedded systems 24x7 systems with 99.999% uptime requirements the Joint Strike Fighter Video game development FDA-approved, life-critical systems Satellite-control software Websites Handheld software Mobile phones Network switching applications ISV applications Some of the largest applications in use Marketing Campaigns Academic Projects Agile Tour Event Management Source: Mountain Goat Software, Scrum Alliance 8

Scrum among methods : 

Scrum among methods 9 Source: VersionOne

What is Scrum? : 

What is Scrum? Scrum is an agile framework for developing complex products. Delivers the highest business value in the shortest time. Scalable to distributed, large and long projects Teams in Scrum are self-managed and cross-functional, and hyper-productive Empiricism Light weight Simple to understand But Extremely difficult to master 10

Scrum Benefits : 

Scrum Benefits Maximize values Increase development productivity Lower engineering costs Increase software quality Reduce risks of failed application Work-life balance 11

Waterfall vs. agile : 

Waterfall vs. agile 12

Review: Traditional Development Model (Waterfall-like) : 

Review: Traditional Development Model (Waterfall-like) 13 Requirement Design Code Test Release

The Agile Manifesto : 

The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 14 That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agile Manifesto : 

Principles behind the Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 15

Complexity in projects : 

Complexity in projects 16 Source: Ken Schwaber Scrum

Scrum framework : 

Scrum framework 17

[Đồ hình Scrum Framework] : 

[Đồ hình Scrum Framework] 18

Three legs of Scrum : 

Three legs of Scrum 19 The three legs of Scrum make an empirical process control mechanism

Three Roles of Scrum Team : 

Three Roles of Scrum Team 20

The Scrum Master : 

The Scrum Master 21

Scrum Master Responsibilities : 

Scrum Master Responsibilities 22

Scrum Master Service to the Product Owner : 

Scrum Master Service to the Product Owner Finding techniques for effective Product Backlog management; Clearly communicating vision, goals, and Product Backlog items to the Development Team; Teaching the Scrum Team to create clear and concise Product Backlog items; Understanding long-term product planning in an empirical environment; Understanding and practicing agility; and, Facilitating Scrum events as requested or needed. 23

Scrum Master Service to the Development Team : 

Scrum Master Service to the Development Team Coaching the Development Team in self-organization and cross-functionality; Teaching and leading the Development Team to create high-value products; Removing impediments to the Development Team’s progress; Facilitating Scrum events as requested or needed; and, Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood. 24

Scrum Master Service to the Organization : 

Scrum Master Service to the Organization Leading and coaching the organization in its Scrum adoption; Planning Scrum implementations within the organization; Helping employees and stakeholders understand and enact Scrum and empirical product development; Causing change that increases the productivity of the Scrum Team; and, Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. 25

Scrum Master, IS and NOT : 

Scrum Master, IS and NOT IS Servant leader Facilitator Change agent Fixer Sheepdog NOT Project Manager Have authority over the team Chief Architect 26

Day of a Scrum Master : 

Day of a Scrum Master Find what to improve: How is my Product Owner doing? How is my team doing? How are our engineering practices doing? How my organization doing? Who and what should be coached? 27 See the full checklist in Appendix

Questioning for “inspect & adapt” : 

Questioning for “inspect & adapt” I noticed <situation>, what shall we do? I observes <situation>, is that important? I fell <feeling>, do you share that? Shall we try to find out why <situation>? What do you think we should do? Who has any idea about <situation>? Is this useful? What have you decided? What should you do? Why-Why-Why-Why-Why? 28

Management Transformation : 

Management Transformation Traditional Managers tell people what to do and make sure they do it properly Managers maintain the right to authorize decision Managers limit the information or resources available to workers Scrum People decide what, and how to do Team makes decisions Information is transparent 29

The Product Owner : 

The Product Owner 30

The Product Owner : 

The Product Owner Define the Product Backlog item (features, patches, etc.) Decide on release date and content Order the Product Backlog items (PBI) to best achieve goals and mission Responsible for the profitability of the product (ROI) Maintain the visibility and content of the Project Backlog  Accept or reject work results Actively participate in development process Should have a vision for the product 31

Who could be Product Owner? : 

Who could be Product Owner? 32

The Development Team : 

The Development Team 33

The Development Team : 

Self-organizing defines tasks and assignments ideally, no titles but rarely a possibility Cross-functional no functional roles (tester, coder, architect, etc.) Responsible for delivery of potentially shippable product increments Optimal size: 7 (+\- 2) For maturity and productivity Membership should be permanent Members should be full-time Maintains the Sprint Backlog The Development Team 34

Enhances Teamwork : 

Enhances Teamwork 35 Team focus on shared-goals that add value not individual tasks Limit work-in-progress

Team organization compared : 

Team organization compared Self-organized Teams Customer-driven Multi-skilled workforce Few job descriptions Information widely shared Few levels of management Whole-business focus Shared goals Seemingly chaotic Purpose achievement emphasis High worker commitment Continuous Improvements Self-controlled Values/Principles based Functional Teams Management-driven Workforce of isolated specialists Many job descriptions Information limited Many levels of management Function/Department focus Segregated goals Seemingly organized Problem-solving emphasis High management commitment Incremental Improvements Management-controlled Policy/Procedure based 36

Decision making : 

Decision making How does the team decide? Team Consensus Voting Specialist decides Without an agreement on how to make decisions, team might have lots of problems. 37

The Scrum Process : 

The Scrum Process 38

Sprint : 

Sprint Scrum projects make progress in a series of short iterations called Sprints Duration: 1–4 weeks or a calendar month at most Each Sprint has a Sprint Goal A constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint 39

Risk is reduced to one Sprint : 

Risk is reduced to one Sprint 40 The same work, but organized differently and on fewer requirements. Waste becomes hugely visible and can be systematically removed. Time Thanks Ken for the slide

Sequential vs. overlapping development : 

Sequential vs. overlapping development Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Sequential development Scrum teams do a little of every thing all the time using one-piece flow mechanism 41

No change during a Sprint : 

No change during a Sprint Plan Sprint durations around how long you can commit to keeping change out of the Sprint Scrum Master – the sheepdog: “keep wolves away from sheep” Changes: Sprint Goal, team composition, quality goals, scope of features change DevTeam Inside change 42

Definition of DONE : 

Definition of DONE 43

Definition of “Done” : 

Definition of “Done” Team together with Product Owner define what does “done” mean, in what aspects and contexts. “Done” may be executable, “passed all tests”, “approved by senior engineers”, “reviewed by peers” or just nothing to do more with the item. “Done Definition” reflects the current technical capability of the team 44

“DONE” Evolution : 

“DONE” Evolution 45 Running code Unit testing Acceptance testing API docs Developers manuals Customer docs Performance test Marketing materials Pricing Update manufacturing process Etc. Running code Running code Unit testing Running code Unit testing Acceptance testing complexity years 1 10 0

Scrum Events : 

Scrum Events 46

Scrum Events : 

Scrum Events 47

Sprint Planning Meeting : 

Sprint Planning Meeting Scrum Team selects items from the Product Backlog they can commit for the Sprint Sprint backlog is created Tasks are identified and each is estimated (1-16 hours) Collaboratively, not done alone by the Scrum Master High-level design is considered Timebox: 8 hours As a vacation planner, I want to see photos of a hotel so that I can decide to book that hotel. 48

Sprint Planning Meeting : 

Sprint Planning Meeting 49

Just-In-Time Planning : 

Just-In-Time Planning Predictive Planning: All planning activities at the beginning Empirical Planning: Just-in-time planning and re-planning based on frequent inspection 50

Daily Scrum : 

Daily Scrum Held every day in 15 minutes for task synchronization & JIT planning An important “inspect & adapt” mechanism for self-organized team 3 questions: What has been accomplished since the last meeting? What will be done before the next meeting? What obstacles are in the way? Team members report to each other, NOT to Scrum Master Should be stand – up meeting 51

Tale: Chickens and Pigs : 

Tale: Chickens and Pigs 52 Only those committed should have any influence on a project. Scrum is a software engineering and management system Part of the rules of Scrum keep the chickens away from the pigs. A slide by Eric Hosick

Usefulness of Daily Scrum : 

Usefulness of Daily Scrum Inspect for adapting later: Do they manage themselves? Do they share their work? Do they report unclearly? Are the tasks too big? Does it take too long? Any impediment found? Any impediment resolved? Any improvement found? 53 Does the team find the daily scrum useful? Scrum Master

Daily Scrum Follow-up : 

Daily Scrum Follow-up Daily Scrum is not for problem solving, it reflects the “transparency” and “inspection” Follow-up the Daily Scrum make sure the team “adapts” to new situations Scrum Master helps the team removes impediments Update artifacts: Sprint Backlog Impediment Backlog Burndown charts Actions: meeting, training, discussion, review, etc. 54

Sprint Review : 

Sprint Review The Development Team presents “done” PBI to the Product Owner and stakeholders Time box: 4 hours Participants: Scrum Team (pig) + stakeholders(chicken) Features not “done” are not shown Feedback generated – Product Backlog maybe reprioritized It’s not a DEMO session Informal <30 minutes preparation Product Owner should use Acceptance Tests Scrum Master sets next Sprint Review 55

Acceptance Testing : 

Acceptance Testing Users approve the results of implementation Customers write the tests Tests are created for all critical business logics “Users attack the system in isolation” Tools: Framework for Integrated Test ( ) FitNesse ( ) 56

Acceptance test examples : 

Acceptance test examples 57 As a book buyer, I can search for books by entering values in any combination of author, title, and ISBN Use values for author and title that match at least one book Use values for author and title that match no book Try an ISBN search ATs As a book buyer, I can adjust the quantity of any item in my cart. Setting the quantity to 0 removes the item from the cart. ATs Put an out-of-stock into the cart. Put a book that hasn’t published yet into the cart. Put a book that is in stock into the cart Put a second copy of book into the cart

Sprint Retrospective : 

Sprint Retrospective Stop and look back, seek improvements and build learning organization Time box: 3 hours Participants: Scrum Master + Development Team Product Owner is optional Question: What went well and what can be improved? Scrum Master helps the team in discovery, not providing answers 58

Retrospective Guidelines : 

Retrospective Guidelines Check previous actions first. If not done, retrospect them Only select a couple of actions and really do them Focus on an constructive attitude “What can we do?” Plan for actions 59

What things should be checked? : 

What things should be checked? Actions Do we only have a few actions? Are they considered useful? Are they implemented? Is “done” extended? Updating our work agreements? Do we require tasks in the Sprint backlog? items in the Product backlog? 60 Content from Bas Vodde

Slide 61: 

61 Deming PDCA Circles for lean learning

Code of Conduct : 

Team Z ************* Time of Daily Scrum: 8:00 Penalty for being late: 1 $ Everyone integrates daily Refactoring if dirty code Ask if unsure Pair programming and TDD rules Strictly follow Code Standards Check DONE definition checklist before commit Code of Conduct 62 Signed

Other Events (non-Scrum) : 

Other Events (non-Scrum) Release Planning Product Backlog Refinement Workshop User Story Writing Workshop Refactoring Dojo Coding Dojo Code Review Workshop etc. 63

Scrum Artifacts : 

Scrum Artifacts 64

Typical Artifacts : 

Typical Artifacts Product Backlog Ordered list of desired project outcomes/features Sprint Backlog Set of work from the Product Backlog that the team agrees to complete in a Sprint, broken into tasks Burndown Chart at-a-glance look at the work remaining (can have two charts: one for the Sprint and one for the overall project) 65

Product Backlog : 

Product Backlog Requirements Items valued to users & customers Ordered and maintained by the Product Owner 66

Product Backlog example: a feature board : 

Product Backlog example: a feature board 67 Source:

Product Backlog Characteristics : 

Product Backlog Characteristics One list per product List features (functional & non-functional) Emergent, ordered, estimated More detail on higher order items Product Owner responsible for order Highly visibility Derived from Business Plan or Vision Statement Optional items: Risk, tests, dependency to other products, person who know best about items, etc. 68

Product Backlog Refinement : 

Product Backlog Refinement Split backlog items into Action and Waiting section in the Product Backlog Action items are ready for implementation Items in Waiting section can be re-prioritized and refined on the go 69 Action Items ------- ------- -------- WAITING Items -------------- -------------- -------------- -------------- --------------

Sprint Backlog : 

Sprint Backlog Plan and tracking tool for a Sprint Maintained by the Development Team 70 Task Board – effective Sprint Backlog

Task Board : 

Task Board 71 … Step 1 DONE Step 2 Step n … TO DO Queue In Process Queue In Process Queue In Process IN PROGRESS

Burndown Chart : 

Burndown Chart 72 Progress towards the Sprint goal The importance is how much work remains in the future, not how much effort spent in the past

Maintaining the Sprint Backlog and Burndown Chart : 

Maintaining the Sprint Backlog and Burndown Chart Developers volunteer for tasks No “assign” Tasks are estimated in hours (1-16) Estimated work remaining is update daily Any member can add, delete or change the product backlog Originator “role” vs. volunteer “role” If work is unclear, define a sprint backlog item with a larger amount of time and break it down later Re-paint the Burndown Chart daily 73

Sprint Backlog Estimates : 

Sprint Backlog Estimates Work remaining reporting during a Sprint updates the estimated number of hours required to complete a task Sprint Backlog is NOT a time-tracking tool Timesheet makes NO sense in Scrum Productivity is measured by meeting goals, it is results oriented, not effort driven. What is a productive hour? 74

Other artifacts and tools : 

Other artifacts and tools Release Burndown Chart Impediment Backlog Scrum Poker Cards Stopwatch (?) Traffic Light (?) What else? 75

The Organization : 

The Organization 76

The Organization : 

The Organization Scrum will be conflicting with lots of traditional organization roles and responsibilities Project Manager Functional department: QA, Test, Development, etc. Other roles will change This is a personal change in some persons future and career Where can CSD, agile coach, agile lead, Scrum Master be fit in your organization? 77

Common reasons for creating ScrumBut : 

Common reasons for creating ScrumBut Not understanding the purpose of Scrum Scrum is not a silver bullet Hiding organization problems or preventing change in organization Improvement based on practices and contexts (inspect-adapt) This is very common, but keep balance and spirit of Scrum 78

Starting with Scrum : 

Starting with Scrum Build a dedicated long-lived permanent cross-functional team Define “DONE” Make sure all work flows via the Product Owner Apply-by the book first Keep project managers out 79

Adopting Scrum in the Organization : 

Adopting Scrum in the Organization Gain the trust of the organization before they will be changing To change the organization, show the Hyper-Productivity Proof. “Make Scrum be a virus in the org” Always focus on changing and improving yourself instead of blaming the organization Thinking in “lean way” (lean thinking) 80

Scrum Obstacles : 

Scrum Obstacles According to Bas Vodde: The illusion of command and control The persistence of status-quo The mediocracy of ScrumBut The belief in magic The era of opacity The tyranny of the waterfall. 81

Causes of failure : 

Causes of failure Ineffective use of retrospective Inability in getting all people in planning meeting Failure to pay attention to the infrastructure required Bad Scrum Master Product Owner is consistently unavailable Failure to push testing forward Reverting to form Obtaining only "checkbook commitment" from executive management Teams lacking authority and decision making ability Not having onsite evangelist for remote location Cultures that do not support learning Denial is embraced instead of brutal truth 82 Jean Tabaka

The Scrum Iceberg : 

The Scrum Iceberg 83

Technical practices : 

Technical practices 84 [For further study]

User Stories : 

User Stories User stories are agile requirements Balance parties involved in development: customers, users & developers Expressed in user-oriented language and understandable by developers Driven by users and business, not system attributes 85

INVEST criteria for good stories : 

INVEST criteria for good stories 86 Independent Negotiable Valuable Estimatable Sized appropriately Testable

Gathering user stories : 

Gathering user stories 87

Story-writing Workshops : 

Story-writing Workshops Participants: developers, users, customer, others (pigs) Brainstorm to generate stories Goal is to write as many stories as possible Some will be “implementation ready” Others will be “epics” No ordering at this point Product Owners and stakeholders are involved, not there to be asked. 88

Pair Programming : 

Pair Programming A pair of developers shares a problem, a computer, a keyboard and a goal: solve the problem Utilize the R-mode activities Improve communication and effectiveness Improve software quality Widely ADOPTED, but CONTROVERSAL! 2 roles: Driver and Navigator The Driver doesn’t see the big picture The Driver should “step a way from the keyboard” The Navigator tends to use pattern-matching problem solving technique 89

Continuous Integration : 

Continuous Integration Continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently. Supported by a CI system with lots of automated tests, builds and other generated artifacts. Benefits: Increases transparency Increases cooperation and communication Enables people to work on same code 90

CI System : 

CI System 91

Incremental Design : 

Incremental Design Flexible complex design on paper|CASE tool Incremental Design (not simplistic) 92 Something unexpected always changes Something unexpected always changes More complexity than needed. Hard to maintain. Easier to adopt. ID is easier to change. Less complexity

Prototyping : 

Prototyping Early visibility of the prototype gives users an idea of what the final system looks like Encourages active participation among users and developers Increases system development speed 93

Test-Driven Development : 

Test-Driven Development You don’t start programming until you have designed your tests! Strategy Make it Fail No code without a failing test Make it Work As simply as possible Make it Better Refactor(code, design, test, documentation) Believe in testing 94

TDD Steps : 

95 TDD Steps Image by Excirial (

TDD Rationale : 

TDD Rationale 96

Red-Green-Blue model : 

Red-Green-Blue model 97

Acceptance TDD : 

Acceptance TDD A mechanism for acceptant test automation 3D strategy Discuss in requirement workshop To make tests library Develop in concurrence To create more Passed features Deliver for acceptance To meet done definition, accepted by users 98

Behavior-Driven Development (BDD) : 

Behavior-Driven Development (BDD) The development of software guided directly by described behavior and features (and mocking). Somewhat like ATDD, but different mindset Higher software quality, better self-organization 99

Refactoring : 

Refactoring You practice “code a bit, fix a little” => result in dirty code & bad design. Refactoring helps in restructure or design your code to make it better. what does “better” mean? Keep your code: Maintainability Extensibility High Cohesion Low Coupling 100

Refactoring Techniques : 

Refactoring Techniques For abstraction Encapsulate Field Generalize Type Replace type-checking code with State/Strategy Replace conditional with polymorphism For breaking code apart Extract Method, turn part of a larger method into a new method Extract Class For improving code standard Move Method or Move Field Rename Method or Rename Field Pull Up, move to a superclass Push Down, move to a subclass 101

Recap : 

Recap 102

Q&A : 

Q&A 103

References and Resources : 

References and Resources Jean Tabaka, Twelve ways agile adoption failed, Better Software, Nov. 2007, ( ) Mountain Goats, Scrum Overview, ( ) MoutainGoats, Planning Poker Estimating in details ( Scrum Alliance , Pete Deemer, Gabrielle Benefield, Craig Larman & Bas Vodde, Scrum Primer ver. 1.2 Bill Wake, INVEST in Good Stories, and SMART Tasks, A gallery of team rooms and charts, “Scrum from Student to Master” by Skip Angel 104

Scrum Community : 

Scrum Community Definitive Scrum, Training: Scrum Alliance: Agile Alliance: Hà Nội: Hồ Chí Minh City: 105

Appendix A: Scrum Master Checklist : 

Appendix A: Scrum Master Checklist 106 Download the file:

Appendix C: Scrum in one page : 

Appendix C: Scrum in one page 107

Appendix D: Scrum Quality Checklist : 

Appendix D: Scrum Quality Checklist Good Scrum Estimates are updated every day Everybody is there at Daily Scrum every day People offer to help others People ask for help People present the team with problems and solve them as a team There’s lots of talking and interaction Lots of silly bits introduced by the team Bad Scrum The Sprint requires a lot more work than was planned Team member reports the same item more than two days thi the same or greater estimates and nobody notices or cares No interaction outside of daily scrum Product Owner not available for consultation Distractions from outside the team Hidden of multiple backlogs Acceptance of the status quo Failure to produce PSSI every sprint 108 Thanks Alan Atlas

Appendix F: Distributed Scrum : 

Appendix F: Distributed Scrum Kind of distributed Scrum team: Isolated Scrums: Teams are isolated across geographies. Distributed Scrum of Scrums: Scrum teams are isolated across geographies and integrated by a Scrum of Totally Integrated Scrums: Scrum teams are cross-functional with members distributed across geographies. Difficult to shares values and goals 109

Books : 

Books 110

Slide 111: 


authorStream Live Help