Your SlideShare is downloading. ×
0
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Agile & Scrum Training in Irvine - April 29th
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile & Scrum Training in Irvine - April 29th

964

Published on

Agile & Scrum Training . Foundations and values

Agile & Scrum Training . Foundations and values

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
964
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
65
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  1. Copyright Conscires 2011INTRO TO AGILEPresenters:Bachan AnandDave Cornelius, MBA, PMP
  2. AGENDA SCRUM Framework SCRUM Roles Copyright Conscires 2011 Planning & Estimation Team Engagement SCRUM Simulations SCRUM Myths Class Retrospective 2
  3. AGILE MANIFESTO Individuals and interactions over processes and tools Working software/product over comprehensive Copyright Conscires 2011 documentation Customer collaboration over contract negotiation Responding to change over following a plan 3
  4. AGILE 12 PRINCIPLES Highest priority is to satisfy the customer through early and continuous delivery Copyright Conscires 2011 of valuable software Welcome changing requirements Deliver working software (Product) frequently Business people and developers must work together daily throughout the project Build projects around motivated individuals Most efficient and effective method of conveying information is face-to-face conversation 4
  5. AGILE 12 PRINCIPLES Working software (product) is the primary measure of progress Agile processes promote sustainable development (maintain a Copyright Conscires 2011 constant pace indefinitely) Continuous attention to technical excellence and good design enhances agility Simplicity (art of maximizing amount of work not done) is essential Best architectures, requirements, and designs emerge from self-organizing teams At regular intervals, team reflects on how to become more effective, then tunes and adjusts http://agilemanifesto.org/principles.html 5
  6. AGILE LEAN ROOTS Eliminate Waste – Anything that does not add value Build Quality In – Quality if a primary focus Copyright Conscires 2011 Deliver fast – Just as it’s defined Defer Commitment – Learning before commitment Respect People – Give space for others to grow Improve the System – The system is the entire process Create Knowledge – Sharable and Usable Focus on the customer - Needs Continuous improvement - Daily 6 Kaizen - Change for better processes, led by the people
  7. SCRUM FOUNDATION VALUES Empiricism  Detailed up-front planning and defined processes are replaced by just-in-time Inspect and Adapt cycles Copyright Conscires 2011 Self-Organization  Small teams manage their own workload and organize themselves around clear goals and constraints Prioritization  Do the next right thing Rhythm  Allows teams to avoid daily noise and focus on delivery Collaboration  Leaders and customers work with the Team, rather than directing them 7
  8. SCRUM VALUES Transparency  Everything about a project is visible to everyone Copyright Conscires 2011 Commitment  Be willing to commit to a goal Courage  Have the courage to commit, to act, to be open and to expect respect Focus  Focus all of your efforts and skills on doing the work that you have committed to doing Respect  Respect and trust the different people who comprise a team 8
  9. Copyright Conscires 2011 9SCRUM FRAMEWORK
  10. SCRUM AND WATERFALL DIFFERENCESSCRUM Traditional (Waterfall)Plan what you expect to happen with Plan what you expect to happendetail appropriate to the horizon Copyright Conscires 2011Control happens through inspection Enforce what happens is the same asand adaption what is planned •Reviews and Retrospectives •Directive management •Self-organizing Teams •ControlUse Agile Practices to manage change Use change control to manage change •Continuous feedback loop •Change Control Board •Iterative and incremental •Defect Management development •Prioritized backlogs 10
  11. SCRUM ROLES DETAILS Product Owner  Maximize the value of the work done by prioritizing the features by market value Copyright Conscires 2011 SCRUM Master  Manages the SCRUM framework Team  Self-organizing empowered individuals motivated by business goals Other Stakeholders  Anyone who needs something from the team or the team something from 11
  12. SCRUM ROLES DETAILS – PRODUCT OWNER Thought Leader and Visionary Drivesthe Product Vision (for example, Copyright Conscires 2011 with Story Mapping) Prioritizes the User Stories Maintains the Product Backlog with the team Acceptsthe Working Product (on behalf of the customer) 12
  13. SCRUM ROLES DETAILS – SCRUM MASTER Servant Leader Facilitates the Process Copyright Conscires 2011 Supports the Team Removes Organizational Impediments Socializes Scrum to Management Enable close collaboration across all roles and functions 13
  14. SCRUM ROLES DETAILS – SCRUM TEAM Cross-Functional 5-8 Members Copyright Conscires 2011 Self-Organizing Focused on meeting Commitments 14
  15. Copyright Conscires 2011 15ROLES RELATIONSHIP
  16. MANAGEMENT ROLES (SERVANT LEADERSHIP) Is a servant first and ensures other people – i.e. followers or stakeholders – highest priority needs are being served Empowers others and supports an environment of trust Copyright Conscires 2011 Has empathy and sensitivity to the needs and interest of all stakeholders Is open to the voice of others by supporting discussions that includes those without a voice Accept risks; takes the risk of failure along with the chance of success, while trusting others My cup is always full – my focus is now; I’ve learned from yesterday and I’m planning for tomorrow 16
  17. PRE-SCRUM PLANNING Pre-SCRUM is where projects are approved, budgets and resources assigned Project Portfolio’s are expensive Copyright Conscires 2011 They are risky  Do we have the right people with the right experience and skills?  Can we afford the project?  What are the objectives of the project? Clear goals.  Lack of commitment  Can we verify the promise was met? The business want value and a return on investment 17
  18. PRE-SCRUM PLANNING Reject Copyright Conscires 2011 Active Pre-Portfolio Post-Portfolio Portfolio Success or Failure Projects Projects Projects Being formulated Approved Executed Evaluated 18 Pending Kick-off M & E Pending approval Executing
  19. PRODUCT VISION & ROLE ENGAGEMENT A goal to aspire to Can be summarized in a short statement of intent Copyright Conscires 2011 Communicate it to the team Common format:  For: (Our Target Customer)  Who: (Statement of need)  The: (Product/Product name) is a (Product/Product category)  That: (Product/Product key benefit, compelling reason to buy and/or use)  Unlike: (Primary competitive alternative)  Our Product: (Final statement of primary differentiation) 19
  20. RELATIVE ESTIMATION Humans are better at relative estimates than absolute estimates Many heads are better than one Copyright Conscires 2011 Estimates are made by those who perform the work Estimate size/complexity – Derive duration The goal is to get useful estimates with minimal effort Estimates are not commitments Planning Poker is the common method for estimation 20
  21. RELATIVE ESTIMATION Story Points:  Commonly used in Agile estimation Copyright Conscires 2011  No real-world dimensions  Compare one story to another  Based on effort, complexity, risk  Precision is not critical 21
  22. PRODUCT BACKLOG A living list of requirements captured in the form of User Stories Represents the WHAT of the system Copyright Conscires 2011 Prioritization with respect to business value is essential! Each story has estimated Story Points, which represent relative size, and is determined by those actually doing the work Higher priority items are decomposed and lower priority items are left as larger stories (epics) 22
  23. USER STORIES Product requirements formulated as one or more sentences in the everyday or business language of the user Copyright Conscires 2011  As a <user>, I would like <function> so that I get <value> Each User Story has an associated Acceptance Criteria that is used to determine if the Story is completed 23
  24. SPRINT BACKLOG List of stories, broken down into tasks, that is committed for any particular Sprint Owned and managed by the Team Copyright Conscires 2011 Any team member can add, delete or change the sprint backlog with additional tasks 24
  25. USER STORIES Independent  Not overlap in concept and be able to schedule and implement them in any order Copyright Conscires 2011 Negotiable  Not an explicit contract for features; rather, details will be co-created by Product Owner and Team Valuable  Add business value Estimated  Just enough to help the Product Owner rank and schedule the storys implementation Sized Appropriately  Need to be small, such as a few person-days Testable 25  A characteristic of good requirements
  26. SPRINT PLANNING Sprint Planning meeting held at beginning of each Sprint Time and Resources are fixed in any given Sprint Copyright Conscires 2011 Goal is to have prioritized Sprint Backlog, broken down into tasks, that the Team can commit to During planning, Team commits to scope that can be completed in the Sprint, taking into account the definition of Done Story points may be refined 26
  27. TASK BOARD Active visual indicator of flow of work Should be visible to team Copyright Conscires 2011 members at all times Should be kept current Encourages self- organization, and collaboration 27
  28. DOD - (DEFINITION OF DONE) Team creates its own definition of Done in the interest of creating quality software Definition can evolve over sprints Copyright Conscires 2011 Example checklist (not exhaustive):  Unit tests pass (ideally automated)  Customer Acceptance tests pass  User docs written  UI design approved by PO  Integrated into existing system  Regression test/s pass (ideally automated)  Deployed on staging server  Performance tests pass 28
  29. SPRINT BURN-DOWN Shows daily progress in the Sprint Copyright Conscires 2011 X-axis is the number of days in the Sprint Y-axis is the number of remaining stories 29
  30. RELEASE BURN-DOWN Shows progress across Sprints X-axis is the Copyright Conscires 2011 number of Sprints Y-axis is the total number of stories 30
  31. DAILY STANDUP MEETINGS Meetings held in same location, same time, every day Copyright Conscires 2011 Time-boxed at 15 minutes Encourages self-organization, rhythm, and collaboration Not a status meeting Each Team member speaks to:  What did I accomplish in the last 24 hours  What do I plan to accomplish in the next 24 hours  Any impediments getting in the way of my work 31
  32. SPRINT REVIEW Occurs at the end of each Sprint Inspect and Adapt the product (Empiricism) Copyright Conscires 2011 The team meets with the Product Owner (and Stakeholders) to demonstrate the working software from the Sprint This is a hands-on software demo (not a PowerPoint) that usually requires some prep beforehand 32
  33. RETROSPECTIVES Occurs at the end of each Sprint Inspect and Adapt the process (Empiricism) Copyright Conscires 2011 Team and ScrumMaster meet to reflect on what went well and what can be improved Tone of the meeting is that everyone did their best and now look to how can we improve Retrospectives must conclude with team commitments to action 33
  34. SCRUM RELEASE - VELOCITY Total number of story points completed by a team in a Sprint Can be used by the team as a reference during Sprint Copyright Conscires 2011 Planning Used by Product Owner to plan out the releases 34
  35. SCRUM RELEASE PLANNING Product Owner, in conjunction with the team, formulates Release Plans by applying the team Velocity to the Product Backlog Copyright Conscires 2011 Release Plans are revisited after every Sprint Two ways to approach  Fix scope and determine how many sprints are needed  Fix time and determine how much scope can be completed 35
  36. LET’S DO SCRUM SIMULATION! Copyright Conscires 2011 36
  37. SCRUM MYTHS SCRUM Myths:  No quality/no testing Copyright Conscires 2011  People burnout because of short and frequent delivery cycles (sprints)  No culture change is needed  Will make a better team  SCRUM is the only Agile method  Solution to all 37
  38. SCRUM MYTHS SCRUM Myths:  A silver bullet Copyright Conscires 2011  Management believes it will solve all problems  Easy to implement  Will replace waterfall method  Cowboy coding  No documentation  Simple but not easy 38
  39. SCRUM MYTHS SCRUM:  Exposes issues sooner Copyright Conscires 2011  Increases visibility, leading to faster issue resolution  Facilitates complete feedback & continuous improvements  Allows people to fail and learn from failure  Moves away from the blame culture  Embraces small incremental changes 39
  40. Copyright Conscires 2011 40CLASS WRAP-UP
  41. TAKE AWAY Scrum is a lightweight framework with a simple set of rules, built on foundations and values Copyright Conscires 2011 Scrum enables teams to discover their true potential and deliver quality software that adds business value 41
  42. APPENDIX - ROLES Product Owner  Thought Leader and Visionary, who drives the Product Vision, maintains the Product Backlog, Copyright Conscires 2011 prioritizes the User Stories, and accepts the Working Software (on behalf of the customer) ScrumMaster  Servant Leader, who facilitates the process, supports the Team, removes organizational impediments, and socializes Scrum to Management Team  Cross-Functional group of 5-8 Members that is self- organizing and focused on meeting Commitments 42
  43. APPENDIX – ARTIFACTS Product Backlog  A living list of requirements captured in the form of User Stories, prioritized according to business value Copyright Conscires 2011 Sprint Backlog  List of stories, broken down into tasks, that is committed for any particular Sprint; owned and managed by the Team Taskboard  Active visual indicator of flow of work Sprint Burndown Chart  Shows daily progress in the Sprint Release Burndown Chart  Shows progress across Sprints 43
  44. APPENDIX - CEREMONIES Sprint Planning  Held at beginning of each Sprint, with the goal to have prioritized Sprint Backlog, broken down into tasks, that Copyright Conscires 2011 the Team can commit to Daily Standup  Meetings held in same location, same time, every day, with the goal of ensuring that team members are in synch (not a status meeting) Sprint Review  Occurs at the end of each Sprint, with the goal of inspecting and adapting the Product Retrospective  Occurs at the end of each Sprint, with the goal of 44 inspecting and adapting the process
  45. Copyright Conscires 2011 45KEEP SHARING

×