Agile series - Scrum
Upcoming SlideShare
Loading in...5
×
 

Agile series - Scrum

on

  • 1,398 views

This presentation is part of the series of Agile presentations shared as part of the Agile training, workshops and coaching. Focus is on providing wholesome information about using Agile beyond the ...

This presentation is part of the series of Agile presentations shared as part of the Agile training, workshops and coaching. Focus is on providing wholesome information about using Agile beyond the skeleton frameworks.

Statistics

Views

Total Views
1,398
Views on SlideShare
1,398
Embed Views
0

Actions

Likes
2
Downloads
48
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

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

Agile series - Scrum Agile series - Scrum Presentation Transcript

  • Agile Series – Scrum Durgaprasad B. R Flow, Value, Feedback, Collaboration -
  • -
  • Scrum Product Owners Test Automation Lean Scrumban Scrum Master/ Project Manager Continuous Integration/ Deployment Web Application Development Lean Software Development Kanban XP/ Engineering Continuous Improvement Embedded Applications Agile HR Practices Agile Leadership Program Governance Coaching Legacy Systems Verification Projects Technical Support Agile Offshoring Agile Development Projects Sustenance Projects Practices -
  • Backlog 1. 2. 3. 4. Agile Manifesto and Principles Scrum Principles Starting Scrum Managing Scrum -
  • Scrum - Background Term coined by Hirotaka Takeuchi and Ikujiro Nonaka Scrum – was described by them as a new approach to software product development They studied companies like Fuji Films, Toyota, Xerox and 3M which were operating in tough markets. They call it the Rugby approach: as the whole process is done by a crossfunctional teams. The teams try to go the distance as a unit, passing the ball back and forth. Scrum – an event in Rugby, where likeminded people get together and discuss the ownership of the ball -
  • Scrum Scrum like Chess, has limited set of rules. With those rules, different situations arise and the team as a whole should use their collective intelligence to come up with the next best move ….. But, unlike Chess, there is no “Touch and Move” rule On a wrong move (feedback from customer/opponent in chess), you can immediately revert back the last move/few moves easily Scrum is so popular in Agile, that people interchangeably use Scrum for Agile -
  • What is Scrum ? Scrum is a Software Management Process not a Software Engineering Process -
  • What is Scrum ? • • Greatness of Scrum is its independence from Software Engineering Process Generally, XP engineering practices are popular with Scrum -
  • Scrum Overview Everything in scrum is within an iterative, incremental framework consisting of timeboxes called “Sprints’. Each sprint duration is fixed for a project(2 to 4 weeks). Everything is done by small cross functional team (8-9 members) who are responsible for managing themselves At the beginning of every sprint, this team commits to implement a set of high priority items from a prioritized list called „Product Backlog‟ to implement within a timebox During the sprint, everyday team briefly discusses the progress during Daily Scrum, and plans next steps to complete the work Team should deliver something “done” called increment, at the end of each iterations which is of value of customer At the end of the spring, the team does a Sprint review with the stakeholders to demonstrate the build and get valuable feedback. The team also does an Sprint Retrospective at the end of every sprint, to look at things to improve for the next sprint (continuous improvement) -
  • Scrum Master    Scrum Team Product Owner Responsible for Process Support the team Remove Impediments    (PO with help of other members creates the Product product backlog) Backlog Prioritization Voice of Customer Owns the Product Backlog   Cross Functional Deliver Each Sprint (Use burndown charts and dashboards to track progress) Refine Product Backlog (810% Sprint) Minimum Releasable Features Sprint Backlog Daily Scrum (15 min) - 3 Questions 2-4 weeks Sprint Sprint Potentially Retrospective Shippable Sprint Review (2-3 hr) Product (2-4 hr) - Continuously Increment Demo Improve Sprint Planning (2-4 hr)     Prioritization Task Breakdown Team Commitment Sprint Backlog Scrum Flow -
  • It takes an hour to learn and lifetime to master -
  • Backlog 1. 2. 3. 4. 5. Agile Manifesto and Principles Scrum Principles Starting Scrum Managing Scrum Continuous Improvement -
  • Scrum – Core Values • • • • • Commitment Focus Openness Respect Courage Note: Scrum core values sound a bit like US Army’s seven commandments: Loyalty, duty, respect, selfless service, honor, Integrity and personal courage. This may not be very surprising as two founders of scrum have military background: Jeff Sutherland was a fighter pilot and Ken Schwaber attended U.S. Merchant Marine Academy -
  • Backlog 1. 2. 3. 4. 5. Agile Manifesto and Principles Scrum Principles Starting Scrum  Roles  Ceremonies  Artifacts Managing Scrum Continuous Improvement -
  • Sprint Not more than 4 weeks. Smaller the better. Ideally 2 weeks Aim is to deliver a releasable software at the end of every sprint Sprint includes require gathering to user acceptance testing The teams are not interrupted during the sprint Sprint duration once fixed cannot be changed -
  • Scrum Framework Scrum Roles - Scrum Master - Product Owner - Team Member Ceremonies - Sprint Planning - Sprint Review - Sprint Retrospective - Daily Scrum Artifacts - Product Backlog - Sprint Backlog - Burndown charts - Increments Scrum Framework -
  • Scrum Roles Advocates three roles within the team - Scrum Master Product Owner - Team Member - -
  • Scrum Metaphors Classic Story of the Pig and Chicken Dear Pig. We should open a restaurant – “Ham and Eggs” No Sorry! I’d be committed and you’d be only involved!!! Pig roles are considered core team members. Performers. People who “do” work  The team, product owner and scrum master are pigs in the team A chicken is someone who has something to gain by the Pigs performance, but in the end, really do not contribute day to day to “getting things done” You cannot be a Pig and a Chicken at the same time. Especially Middle management. Note: Chicken and Pig story is an old story and good for small startup teams, which wants to keep management away. However, as teams grow, including management is very important. It may be time to get rid of this story !!!! -
  • Scrum Master • SM represents the management to the team • Helps the team to learn and apply Scrum • SM protects, guides, and serves the team while also activating as a change agent • Primary role of Scrum Master is of a coach and not a facilitator • Has no delivery responsibility, does not commit to date, budgets and profits etc. • Full time role and servant leader -
  • Scrum Master Servant Leader, team protector, trouble shooter, Scrum guide        Removes impediments Prevents interruptions Facilitate the team Support the process Manage management Continuous Improvement Self development and Team Development -
  • Scrum Master – Servant Leader 3 C’s of Servant Leader Character to influence others Courage to pursue a purpose Commitment to develop others -
  • Scrum Product Owner • The Product Owner is responsible for maximizing the value of the product • He / She is the navigator choosing features and providing feedback to deliver value • • • • Product owner is the single “wring-able neck” for the product. Responsible for ROI and answerable to the management and customer Represents customer / sponsor the development team Product owner can be a busy role in a complex product team and can take help from the team members for his activity (business analysts) Ensure that the PO’s are available. Non-availability has major impact on output -
  • Scrum Product Owner - Activities The first step in Scrum is to articulate the Product Vision – done by the Product owner. • This product vision will evolve into a list of features called Product Backlog, created and owned through out the project by the Product Owner. • Backlog grooming on an ongoing basis • • • • • • Define features based on the vision Prioritizing backlog items based on the business value/ROI Classify backlog items consists of Epics->Themes->Features->User Stories Define Release contents and release dates User stories should be right sized enough to be done within an iteration • Participate in daily scrum (optional), sprint planning, sprint reviews and retrospectives (optional) • Inspect the “incremental” delivery at the end of the sprint. Has authority to approve, ask for change or reject the deliverables • Provides product status updates to the customer and the management regularly -
  • Scrum Product Owner - Activities Product Owners activities during the sprint, would include • • • • • • Coordinating with the team and Scrum master on the product issues, Preparing the user stories for the next few sprints, maintaining backlog, Helping team with writing test cases, Working with the business to get feedback from the end user/customer • Authority to terminate sprint if the game plan has changed • Question the team if they are not following a plan or working on non-priority work items -
  • Scrum Product Owner - Profile • • Subject Matter Expert (Domain) Understand end user and champion for their cause • Understand business – ROI and priorities • Able communicator • Decision Maker – handles conflicting goals/situations in the best interest of the customer -
  • Scrum Product Owner – Who ? Ideally customer / end user can be a product owner, provided they can dedicate their time to the project If not, then, the team can identify proxy Product Owner someone who is mature, understands customer domain, and co-ordinate with the customer -
  • Scrum Product Owner – Who ? How do you handle a customer ? Treat your customer like a neighbor whom you can count on everyday rather than a intrusive relative who moves in for a while and then not to be seen for a year -
  • Scrum Project Team Amazon – 2 Pizza Rule “If your team can’t be fed on two pizzas, then cut people” • • The idea of a “two pizza team” was coined by Jeff Bezo, founder of Amazon.com Limit the task force to five to seven people (depending on their appetite  ) -
  • Scrum Project Team - Characteristics Like a player in a rugby/football team • Have positions and not roles • Generalization Specialists – if required should play in any position • Cross Functional – Don’t hold on to your position, help team win • Have Clear objectives – Know what winning means • Co-located (to the maximum extent possible) • Self Organizing – team organizes itself during the play • Empowered • Quality Driven • Mutually Accountable (no finger pointing) • Focused on value delivery (Goals) • Open honest (feedback, appreciation) • Have FUN !!! -
  • The team Small (5-9 persons), co-located, cross-functional, Self organized, full time      Define tasks Estimate effort Develop product Ensure quality Evolve processes -
  • Scrum Framework Scrum Roles - Scrum Master - Product Owner - Team Member Ceremonies - Sprint Planning - Sprint Review - Sprint Retrospective - Daily Scrum Artifacts - Product Backlog - Sprint Backlog - Burndown charts - Increments Scrum Framework -
  • Scrum Ceremonies Advocates four ceremonies in Scrum - Sprint Planning Sprint Review Sprint Retrospective Daily Scrum -
  • Scrum Master    Scrum Team Product Owner Responsible for Process Support the team Remove Impediments    (PO with help of other members creates the Product product backlog) Backlog Prioritization Voice of Customer Owns the Product Backlog   Cross Functional Deliver Each Sprint (Use burndown charts and dashboards to track progress) Refine Product Backlog (810% Sprint) Minimum Releasable Features Sprint Backlog Daily Scrum (15 min) - 3 Questions 2-4 weeks Sprint Sprint Potentially Retrospective Shippable Sprint Review (2-3 hr) Product (2-4 hr) - Continuously Increment Demo Improve Sprint Planning (2-4 hr)     Prioritization Task Breakdown Team Commitment Sprint Backlog Scrum Flow -
  • Ref: VersionOne Meeting Schedule Meeting Frequency Length Strategy Typically once a year 4-16 hours Release Planning 1st day of each release 4-8 hours Iteration (sprint) planning 1st day of each iteration 2-4 hours Iteration (sprint) review Last day of each iteration 1-2 hours Retrospective Last day of each iteration 1-2 hours Daily standup Each day at the same place and time 15 minutes -
  • strategy Purpose: • To define strategy, vision, goals of the program Agenda: • • Involve all stakeholders and list down their interests Question “Why” this is required -
  • Strategy Attendees Input Output Product Owners, Product and or Project Managers, Team Members, Key Stakeholders Market Reports Customer Feedback Management inputs Vision and strategy Key assumptions and issues Delivery dates Common Obstacles • Clear understanding of the market needs • Clear understanding of the market sizing • Stakeholder interests and commitment -
  • Ref: VersionOne Release Planning Purpose: • • • • To articulate themes, functional priorities and delivery dates are defined Allows for the communication of the entire scope of the release to project teams and stakeholders about high level plan Release backlog is identified and estimated at a high level Based on an initial estimate and / or velocity, a preliminary delivery plan is agreed upon Agenda: • • • • • • • • • • Review meeting agenda and guidelines PO reviews product vision, strategy and goals PO reviews key dates and milestones PO presents the first cut at the prioritized product backlog Team asks questions to understand user stories Team estimates user stories at a high level (i.e. story points, ideal days etc.) Team estimates its initial capacity and/or velocity per iteration Team finalizes its delivery objectives in the form of a release plan Meeting facilitator records and key decisions, assumptions, risks and/or issues Stakeholder consensus is achieved and a commitment to proceed is given -
  • Ref: VersionOne Release Planning Attendees Input Output Product Owners, Product and or Project Managers, Team Members, Key Stakeholders Vision and strategy Key assumptions and issues Delivery dates Release plan Backlog Key assumptions and issues Delivery dates Common Obstacles • Inability to negotiate time, scope and budget constraints • Lack of acceptance of team based estimation and planning • Lack of understanding that the plan is not frozen and will change -
  • Ref: VersionOne Sprint Planning Purpose: • • • To plan and agree on the stories or backlog items the team is confident about to complete within the sprint To identify the detailed tasks and tests for delivery and acceptance Sprint planning can have two parts • • • Agenda: • • • • • Part 1: Deciding sprint goal and deliverables Part 2 : Task planning Team first estimates the available time/capacity (excluding meeting time, leaves etc.) for the sprint and then self assigns the backlog items that can be completed within the sprint Review meeting agenda and guidelines Part 1 – Deciding Sprint goal and deliverables • • • • Review “Definition of Done” for all work items PO shares his goal and team clarifies their doubts Part 2 – Task Planning • • • • • • • • PO proposes the product backlog for review Team ideally defines the iteration goal or theme PO and team review and clarify each item Larger stories are broken down as needed Team selects the stories they can complete within the iteration Team estimates any resulting new stories Team breaks each story into tasks and clearly define acceptance criteria Team estimates each task (typically in hours) Team members sign up for tasks initially during the iteration Team may review the workload to make certain it is feasible and balanced Team plays an active role and PO supports the team - Product Owner agrees with the work that will be completed
  • Ref: VersionOne Sprint Planning Attendees Input Output Product Owners, Team Members, Scrum Master, and/or Project Master Prioritized product backlog, prior velocity, team member capacity and/or schedule tests Backlog Grooming Iteration goals, Sprint Backlog and acceptance tests, Task Breakdown, Prepare index cards and paste it on a kanban wall When: During Start of every Sprint Key Considerations • • • • Duration: ~2-4 hours The team always has the final say when it comes to estimating Every team member should have a vote and or voice Dependencies should be minimized, if not prevented entirely The team should consistently identify and impediments preventing them from completing their work that need to be addressed Common Obstacles • Driving into too much detail and designing each feature in full rather than identifying the task work necessary -
  • Ref: VersionOne Sprint Review Purpose: • • Conducted by the PO to ensure all acceptance criteria of the work completed have been met Following the review, the team then demonstrates completed functionality to showcase their work to stakeholders and/or customers Agenda: • • • • • • • Review meeting agenda and guidelines Team walks through completed functionality with PO Team identifies any incomplete stories The PO moves/or splits incomplete stories or backlog items back into product backlog PO closes out iteration and accepts appropriate functionality Team demonstrates working software to interested stakeholders Any open issues / impediments and action items are noted and assigned -
  • Ref: VersionOne Sprint Review Attendees Input Output Team Members, Scrum Members and/or Facilitator, Product Owner Accomplishments from the prior iteration, List of issues and impediments Increment Demo List of suggested changes Confirmation and closure of accepted User Stories Key Considerations • Demonstrate stories as they get completed. Insist on feedback and signoff. • Mid sprint review on completion may be an option to get early feedback and fix within the same review • PO is the most important participant of this meeting. Ensure that he is present. • Ensure that the feedback comes from PO. All other stakeholders can give their feedback to the PO and not to the team. -
  • Ref: VersionOne Daily Standup Purpose: • A standing meeting that facilitates team communication Agenda: The 3 questions which are typically addressed by each team member include:  What have you done since we last met?  What are you planning to do until we met again?  What, if any, impediments are you encountering that are preventing you from making forward progress? -
  • Ref: VersionOne Daily Standup Attendees Input Output Product Owners, Team Members, Scrum Master, and/or Project Manager, Interested stakeholder Individual team members state of work currently and completed Team communication and understanding of individual and iteration progress, task status, critical issues or impediments Key Considerations • Only people with work assigned in the iteration should speak • Topics outside the 3 questions should be addressed outside the meeting • The team should report progress to the team as opposed to one member or a ScrumMaster or manager • An unaddressed impediments and issues should be noted Common Obstacles • All team members are not present • Non-core members consume the meeting with discussion • Time is spent on general discussion or detailed tangents vs. targeted progress -
  • Ref: VersionOne Retrospective Purpose: • • • Provides team a dedicated opportunity to collectively evaluate their processes. A great opportunity for Continuous Improvement Goal is to inspect and adapt team practices and processes in an effort to identify and take actions on key issues that are impending the teams progress or health Agenda: • • • • • Review meeting agenda and guidelines Team reviews what went well during the last iteration Team reviews what did not go well or as planned during the last iteration & why Team identifies the most important items or issues to focus on next iteration Team notes any additional impediments preventing them from adopting and/or improving their process -
  • Ref: VersionOne Retrospectives Attendees Input Output Team Members Scrum Masters And/or Facilitators, Product Owner Details and accomplishments from the prior iterations, list of issues or impediments Prioritized impediments Changes as stories to Backlog Action plan for improvement with dates and Action item owners Escalations Key Considerations • Retrospectives are intended to focus on the process and not people • Avoid chickens, as team would want to critically look at improvements. Even Scrum Master can be optional. • Effective retrospective requires a feeling of safety. Any feel of punishment for raising uncomfortable issue may make the retrospectives ineffective. No Problem ….. is problem – Toyota Saying -
  • Scrum Framework Scrum Roles - Scrum Master - Product Owner - Team Member Ceremonies - Sprint Planning - Sprint Review - Sprint Retrospective - Daily Scrum Artifacts - Product Backlog - Sprint Backlog - Burndown charts - Increments Scrum Framework -
  • Scrum Artifacts Advocates four artifacts prescribed by Scrum - Product Backlog Sprint Backlog Burndown charts Increments -
  • Product Backlog – Heart of Scrum • • • • Scrum uses concept of product backlog to track requirements and issues The principle is to feed the project teams with small chunks of work which can be completed with a short interval of time Team is shielded from other complexities and allowed to focus on the work in hand The product backlog contains a list of prioritized user stories, feature requests, change requests, bugs and other requests from business -
  • Scrum Master    Scrum Team Product Owner Responsible for Process Support the team Remove Impediments    (PO with help of other members creates the Product product backlog) Backlog Prioritization Voice of Customer Owns the Product Backlog   Cross Functional Deliver Each Sprint (Use burndown charts and dashboards to track progress) Refine Product Backlog (810% Sprint) Minimum Releasable Features Sprint Backlog Daily Scrum (15 min) - 3 Questions 2-4 weeks Sprint Sprint Potentially Retrospective Shippable Sprint Review (2-3 hr) Product (2-4 hr) - Continuously Increment Demo Improve Sprint Planning (2-4 hr)     Prioritization Task Breakdown Team Commitment Sprint Backlog Scrum Flow -
  • Product Backlog • Product Backlog High • • Low • Agile teams implement work items which are of high priority in the product backlog Requirements may be added, removed or reprioritized any time by the product owner Requirements which are of high priority are detailed in their description and may be further broken down into user stories Product owner is responsible managing the backlog -
  • Product Backlog Release Plan Sprint Plan User Stories Features/User Stories Epics/Features Future releases The Product Planning Iceberg -
  • Product Backlog - Planning Release planning Features, epics Sprint planning Features, epics User stories, Tasks Product Backlog Release Backlog Sprint Backlog -
  • Product Backlog - Example Id Description Priority Size How to demo 1 Service Contract renewal notification High M Email notification to the Service administrator 2 weeks prior to expiry 2 Log “Field Change Requests” Calls Medium S Allow creation, modification and deletion of FCR calls with call type as “Field Change Request’ 3 Part Pickup reminder Medium M Email notification to the Service administrator for parts not picked up beyond 2 days of service call closure 4 ……. Low XL ….. 5 ….. Low L Comments ….. -
  • Sprint Backlog Sprint backlog contains a prioritized list of user stories and related work breakdown tasks to be implemented within an iteration • Each task item in the backlog contains • • Unique identifier • Task description • Task author, owner • Status • Effort remaining in hours • The data is updated in the backlog on a daily basis -
  • Sprint Burndown chart • • • Sprint burndown chart shows the work remaining in a sprint The project manager/scrum master is responsible for tracking this chart on a daily basis This chart helps to estimate the remaining effort involved in completing the iteration -
  • Sprint Burndown -
  • Backlog Agile Manifesto and Principles Scrum Principles Starting Scrum Managing Scrum 1. 2. 3. 4.          5. When to apply Scrum? Visual Process Control – Task Board, Information Radiators Shared workspaces Information flow (?) Other meetings – Discovery sessions, Release Planning Other Artifacts – User Stories, CFD Scaling Scrum Technical Debt Distributed Development Finally -
  • Backlog 1. 2. 3. 4. 5. Agile Manifesto and Principles Scrum Principles Starting Scrum Managing Scrum Finally -
  • Finally …. “Scrum can be used by a bunch of idiots, who don’t know software, tools, but using Scrum they can uniformly generate crap every increment…. Everyone knows at the end of every timebox, where you are …. Which is good” - Ken Schwaber -
  • Agile Fluency Levels Organization Culture shift Organization Structure shift Team Skills Shift Optimize for Systems Team Culture Shift Optimize Value Deliver Value Focus on Value Start Building Code • 2-6 months  • 45% of teams    See programs from business perspective  Redirect teams when needed © James Shore and Diana Larsen • 3-24 months • 35% of teams • 1-5 years • 5%- rare  Ship on market  Cadence  Capture value frequently Reveal obstructions early   Make excellent product decisions  Eliminate handoffs Speed decision making Cross-pollinate perspectives Stimulate innovation Optimize value stream -
  • Agile Fluency Levels Teams progress faster when they practice advanced techniques alongside basic ones Appropriate level of teams depend on organization • • Larger the organization lower the level. For large, bureaucratic organization, Level 2 is appropriate High levels have been achieved by smaller, nimbler organization • • Losing fluency: reasons are • New management/policy changes • • • Without organization support agile fails Attrition – assembly new teams for every project, rather than assigning projects to long-lasting teams -
  • Scrum Project Team “Scrum assumes you are all adults” Ken Schwaber (co-developed Scrum) -
  • Next step….. -
  • Scrum Product Owners Test Automation Lean Scrumban Scrum Master/ Project Manager Continuous Integration/ Deployment Web Application Development Lean Software Development Kanban XP/ Engineering Continuous Improvement Embedded Applications Agile HR Practices Agile Leadership Program Governance Coaching Legacy Systems Verification Projects Technical Support Agile Offshoring Agile Development Projects Sustenance Projects Practices -
  • Thank You Durgaprasad B. R prasadbr@hotmail.com Cell - +91 9845558474 -