Here are the slides from online Intro to Agile

1. Copyright Conscires 2011 1 Intro to Agile & Scrum Presenter: BachanAnand T: @bachananand E: bachan.anand@conscires.com

2. Agenda 2 Intro to Agile & Scrum Scrum Framework Scrum Roles Planning & Estimation Team Engagement Q&A - Class feedback Copyright Conscires 2011 2

3. Agile Manifesto 3 Individuals and interactions over processes and tools Working software/product over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Copyright Conscires 2011 3

4. Class Agenda - Taskboard 4

5. Agile 12 Principles 5 Highest priority is to satisfy the customerthrough early and continuous deliveryof 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 Copyright Conscires 2011 5

6. Agile 12 Principles 6 Working software (product) is the primary measure of progress Agile processes promote sustainable development (maintain a 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 Copyright Conscires 2011 6

7. Scrum Foundation 7 Empiricism Detailed up-front planning and defined processes are replaced by just-in-time Inspect and Adapt cycles 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 Copyright Conscires 2011 7

8. Scrum Values 8 Transparency Everything about a project is visible to everyone 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 Copyright Conscires 2011 8

9. Scrum Framework 9 Copyright Conscires 2011 9

10. Scrum and Waterfall Differences 10 Copyright Conscires 2011 10

11. Scrum Roles 11 Product Owner Maximize the value of the work done by prioritizing the features by market value 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 Copyright Conscires 2011 11

12. Scrum Roles Details – Product Owner 12 Thought Leader and Visionary Drives the Product Vision (for example, with Story Mapping) Prioritizes the User Stories Maintains the Product Backlog with the team Accepts the Working Product (on behalf of the customer) Copyright Conscires 2011 12

13. Scrum Roles Details – Scrum Master 13 Servant Leader Facilitates the Process Supports the Team Removes Organizational Impediments Socializes Scrum to Management Enable close collaboration across all roles and functions Copyright Conscires 2011 13

14. Scrum Roles Details – Scrum Team 14 Cross-Functional 5-8 Members Self-Organizing Focused on meeting Commitments Copyright Conscires 2011 14

15. Roles Relationship 15 Copyright Conscires 2011 15

16. Management Roles (Servant Leadership) 16 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 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 Copyright Conscires 2011 16

17. Scrum roles vrs tradition roles 17

18. Pre-Scrum Planning 18 Pre-Scrum is where projects are approved, budgets and resources assigned Project Portfolio’s are expensive 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 Copyright Conscires 2011 18

20. Evaluated

22. Pending Kick-off

24. M & E 19

25. 20

26. Product Vision & Role Engagement 21 A goal to aspire to Can be summarized in a short statement of intent 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) Copyright Conscires 2011 21

27. Product Backlog 22 A living list of requirements captured in the form of User Stories Represents the WHAT of the system 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) Copyright Conscires 2011 22

28. Relative Estimation 23 Humans are better at relative estimates than absolute estimates Many heads are better than one 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 Copyright Conscires 2011 23

29. Fruit Salad – Relative estimation 24

30. Relative Estimation 25 Story Points: Commonly used in Agile estimation No real-world dimensions Compare one story to another Based on effort, complexity, risk Precision is not critical Copyright Conscires 2011 25

31. Scrum Release - Velocity 26 Total number of story points completed by a team in a Sprint Can be used by the team as a reference during Sprint Planning Used by Product Owner to plan out the releases Copyright Conscires 2011 26

32. Scrum Release Planning 27 Product Owner, in conjunction with the team, formulates Release Plans by applying the team Velocity to the Product Backlog 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 Copyright Conscires 2011 27

33. User Stories 28 Product requirements formulated as one or more sentences in the everyday or business language of the user 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 Copyright Conscires 2011 28

34. Sprint Backlog 29 List of stories, broken down into tasks, that is committed for any particular Sprint Owned and managed by the Team Any team member can add, delete or change the sprint backlog with additional tasks Copyright Conscires 2011 29

35. User Stories 30 Independent Not overlap in concept and be able to schedule and implement them in any order 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 story's implementation Sized Appropriately Need to be small, such as a few person-days Testable A characteristic of good requirements Copyright Conscires 2011 30

36. Task Board 31 Active visual indicator of flow of work Should be visible to team members at all times Should be kept current Encourages self-organization, and collaboration Copyright Conscires 2011 31

37. DOD - (Definition of Done) 32 Team creates its own definition of Done in the interest of creating quality software Definition can evolve over sprints 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 Copyright Conscires 2011 32

38. Definition of Done 33

39. Sprint Burn-down 34 Shows daily progress in the Sprint X-axis is the number of days in the Sprint Y-axis is the number of remaining stories Copyright Conscires 2011 34

40. Release Burn-down 35 Shows progress across Sprints X-axis is the number of Sprints Y-axis is the total number of stories Copyright Conscires 2011 35

41. Daily Standup Meetings 36 Meetings held in same location, same time, every day 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 Copyright Conscires 2011 36

42. Sprint Planning 37 Sprint Planning meeting held at beginning of each Sprint Time and Resources are fixed in any given Sprint 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 Copyright Conscires 2011 37

43. Sprint Review 38 Occurs at the end of each Sprint Inspect and Adapt the product (Empiricism) 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 Copyright Conscires 2011 38

44. Retrospectives 39 Occurs at the end of each Sprint Inspect and Adapt the process (Empiricism) 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 Copyright Conscires 2011 39

45. Scrum Myths 40 Scrum Myths: No quality/no testing 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 Copyright Conscires 2011 40

46. Class Retrospective 41

47. Scrum Myths 42 Scrum Myths: A silver bullet Management believes it will solve all problems Easy to implement Cowboy coding No documentation Copyright Conscires 2011 42

49. Exposes issues sooner

50. Increases visibility, leading to faster issue resolution

51. Facilitates complete feedback & continuous improvements

52. Allows people to fail and learn from failure

53. Moves away from the blame culture

54. Embraces small incremental changes

55. Simple but not easyCopyright Conscires 2011 43

57. Scrum enables teams to discover their true potential and deliver quality software that adds business valueCopyright Conscires 2011 44

58. Appendix - Roles 45 Product Owner Thought Leader and Visionary, who drives the Product Vision, maintains the Product Backlog, 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 Copyright Conscires 2011 45

59. Appendix – Artifacts 46 Product Backlog A living list of requirements captured in the form of User Stories, prioritized according to business value 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 Copyright Conscires 2011 46

60. Appendix - Ceremonies 47 Sprint Planning Held at beginning of each Sprint, with the goal to have prioritized Sprint Backlog, broken down into tasks, that 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 inspecting and adapting the process Copyright Conscires 2011 47