A brief introduction to agile software development

1. Agile Methods A brief guide to agile software development Duong Trong Tan tandt@fpt.edu.vn HCM city, 9- 2011

2. Objectives Software Engineering history & agile What is agile development? The Agile Manifesto The diversity of methods Scrum XP RAD TDD Crystal Kanban Agile mashup The cooperative game A brief introduction to Agile Software Development 2

3. Agile Basics “Agile projects succeed when the team gets the spirit of agility.” – Ron Jeffries A brief introduction to Agile Software Development 3 Image courtesy of Pollyanna Pixton

4. A brief introduction to Agile Software Development 4 Continuous improvement Hyper productive Kaizen Agile Small teams Buzzwords Incremental Lean Changes Earned Value Based Iterative Rapid Adaptive

5. History A brief introduction to Agile Software Development 5 SE Scrum Weinberg: psychology of computer program Declaration of Independence deMarco: Peopleware XP 2005 2011 2001 1970 1980 1995 1990 AgileAlliance.org 1968 Gilb: Principles of Software Engineering Royce: managing the development of large software systems PMI developed agile certifications RAD DSDM

6. A brief introduction to Agile Software Development 6 So, what are software projects?

7. Partiesand Concerns Users? Customers? BO? Developers? A brief introduction to Agile Software Development 7

8. A brief introduction to Agile Software Development 8 What is agile development?

9. 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 A brief introduction to Agile Software Development 9 That is, while there is value in the items on the right, we value the items on the left more. AgileAlliance.org

10. The Twelve Principles of Agile Software 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. A brief introduction to Agile Software Development 10 AgileAlliance.org

11. Home ground comparison A brief introduction to Agile Software Development 11

12. The diversity of methods A brief introduction to Agile Software Development 12

13. Rapid Application Development One of the earliest method A strategy instead of comprehensive process Utilizing of Prototyping “VB – Access Method” Still useful, esp. prototyping technique A brief introduction to Agile Software Development 13

14. Prototyping Early visibility of the prototype gives users an idea of what the final system looks like Encourages active participation among users and producer Increases system development speed (in RAD) Steps: Identify basic requirements Develop Initial Prototype Review Revise and Enhance the Prototype 14 A brief introduction to Agile Software Development

15. Scrum A hyper-productive development model A brief introduction to Agile Software Development 15

16. Scrum One of the most successful agile methods because of its hyper-productivity It is management – oriented Somewhat CMM Level 3 equivalence Widely used in various types of projects Google AdWorlds project 3M Universities RnD projects In VN: LogiGear, KPM, FSOFT, FAT, etc. A brief introduction to Agile Software Development 16

17. Scrum Framework A brief introduction to Agile Software Development 17 Scrum Team Rules Rules Scrum Transparency Inspection Adaption Artifacts Scrum Events Rules

18. A brief introduction to Agile Software Development 18 Image courtesy of ScrumAlliance

19. Scrum Roles Scrum Master Product Owner Development Team Other parties (all kinds of ‘chicken’) A brief introduction to Agile Software Development 19

20. Transition of roles Project Manager Tester Developer System Designer QA Graphic Designer A brief introduction to Agile Software Development 20 Cross-functional Scrum Team

22. Managers maintain the right to authorize decision

23. Managers limit the information or resources available to workers

24. People decide what, and how to do

25. Team makes decisions

26. Information is transparentTO A brief introduction to Agile Software Development

27. Transition of organization Self-directed Team Multi-functional Team A brief introduction to Agile Software Development 22 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 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

28. Development Team Team is cross-functional and consists of 5-9 people There are no set project roles within the team Team defines tasks and assignments Team is self-organizing and self-managing Maintains the Sprint Backlog Conducts the Sprint Review A brief introduction to Agile Software Development 23

29. ScrumMaster Holds Daily Scrum meeting Assures every people related to the project follow the Scrum rules Removes obstacles Shields the team from external interference: “Keep Chickens away from Pigs” Conducts Sprint Retrospective at the end of a Sprint Is a facilitator, not a manager A brief introduction to Agile Software Development 24

30. Product Owner (PO) Accountable for product success Defines all product features Responsible for ordering product features Maintains the Product Backlog Insures team working on highest valued features A brief introduction to Agile Software Development 25

31. Product Backlog List of all desired product features List can contain bugs, and non-functional items Product Owner responsible for ordering the items Items can be added by anyone at anytime Each item should have a business value assigned Maintained by the Product Owner A brief introduction to Agile Software Development 26

32. Examples of Product Backlog A brief introduction to Agile Software Development 27

33. A Sprint Time box: 2-4 weeks (why?) An iteration for building a piece of increment (potentially shippable) of the whole system It’s the working time, not planning or asking what to do. The team manages itself during a Sprint The team commits to Product Backlog during the Sprint planning meeting The Sprint Backlog is updated during a Sprint A brief introduction to Agile Software Development 28

34. Sprint Backlog A brief introduction to Agile Software Development 29 Each item is prioritized and estimated

36. What will you do?

37. What is impeding you?3. A Sprint (2-4 weeks) 4. Sprint Review Meeting 1. Sprint Planning Meeting 5. Sprint Retrospective Meeting

38. Sprint Planning Meeting Time box: 8 hours Product backlog prepared prior to meeting First Half Team selects items committing to complete Additional discussion of Product Backlog occurs during actual Sprint Second Half Occurs after first half done – PO available for questions Team solely responsible for deciding how to build Tasks created / assigned – Sprint Backlog produced A brief introduction to Agile Software Development 31

39. Scrum Daily Meeting Held every day during a Sprint The most important inspection event in Scrum Timebox:15 minutes Team members talk to the whole Development Team, not Scrum Master Asks 3 questions during meeting “What have you done since last daily scrum?” “What will you do before the next daily scrum?” “What obstacles are impeding your work?” Opportunity for team members to synchronize their work It helps removing burdens between members A brief introduction to Agile Software Development 32

40. Sprint Review Time box: 4 hours Team presents “done” code to PO and stakeholders Functionality not “done” is not shown Feedback generated – Product Backlog maybe reprioritized ScrumMaster sets next Sprint Review A brief introduction to Agile Software Development 33

41. Sprint Retrospective Time box: 3 hours Participants ScrumMaster Scrum Team. Product Owner is optional Questions What went well and what can be improved? ScurmMaster helps the team in discovery – not provide answers A brief introduction to Agile Software Development 34

42. Sprint Backlog A kind o f To-do list for a Sprint Created by the Scrum Team (can be originated by one member, responsibility belongs to another) Product Owner has defined as highest priority Used for synchronizing works between team members A brief introduction to Agile Software Development 35

43. Sprint Backlog examples A brief introduction to Agile Software Development 36 “digital” Sprint Backlog “analog” Sprint Backlog >>

44. The Burn-down Chart A brief introduction to Agile Software Development 37 Burndown Chart shows the Sprint trend, the performanceelocity of the team through Sprints

45. Potentially Shippable Product Selected items are fully implemented, tested and ready for use Small but complete, “it will be bigger” Scrum Team needs to 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. A brief introduction to Agile Software Development 38

46. Distributed Scrum 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. A brief introduction to Agile Software Development 39 Sutherland et al.

47. Top Distributed Scrum Issues Difficult leveraging available resources, best practices are often deemed proprietary, are time consuming and difficult to maintain Difficulty synchronizing work between distributed sites Lack of effective communication mechanisms Conflicting behaviors, processes, and technologies Incompatible data formats, schemas, and standards Ensuring electronic transmission confidentiality and privacy Difficult to share values [Bas Vodde] A brief introduction to Agile Software Development 40 Sutherland et al.

48. eXtreme Programming From hacking code to a real process A brief introduction to Agile Software Development 41

49. eXtreme Programming Project A brief introduction to Agile Software Development 42

50. XP Values Simplicity encourages starting with the simplest solution Communication favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback Feedback From the system, customer and from the team, to avoid optimism Courage design and code for today and not for tomorrow Respect respect for others as well as self-respect A brief introduction to Agile Software Development 43

51. A brief introduction to Agile Software Development 44

52. XP Roles The Customer Sets project goals and makes business decisions The Developer Turn customer stories into working code The Tracker Keeps track of any metrics used by team The Coach Guides and mentors the team A brief introduction to Agile Software Development 45

53. Test Driven Development Tests created before coding Focus on quality Not a complete development strategy Derived version: Behavior-Driven Development (BDD) A brief introduction to Agile Software Development 46

54. TDD Rationale A brief introduction to Agile Software Development 47

55. TDD Strategy 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 A brief introduction to Agile Software Development 48

56. Acceptance TDD 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 49 A brief introduction to Agile Software Development

57. 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 50 A brief introduction to Agile Software Development

58. CI System 51 A brief introduction to Agile Software Development

60. Something unexpected always changesMore complexity than needed. Hard to maintain. Easier to adopt. ID is easier to change. Less complexity A brief introduction to Agile Software Development

61. Pair Programming A pair of developers shares a problem, a computer, a keyboard and a goal: solve the problem PP was defined in XP Utilize the R-mode activities Improve communication and effectiveness Improve software quality Widely ADOPTED, but CONTROVERSAL! 2 roles: Driverand 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 53 A brief introduction to Agile Software Development

62. 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 in mind: Maintainability Extensibility High Cohesion Low Coupling 54 A brief introduction to Agile Software Development

63. Crystal Clear “A human-Powered methodology for small team” A brief introduction to Agile Software Development 55

64. Crystal Clear Practices Frequent Delivery Reflective Improvement Osmotic Communication Personal Safety Focus Easy Access to Expert Users Automated Tests Configuration Management Frequent Integration A brief introduction to Agile Software Development 56

65. Crystal Clear “The team can reduce intermediate work products as it produces running code more frequently, as it uses richer communication channels between people.” - Alistair Cockburn A brief introduction to Agile Software Development 57

66. Crystal Clear Every product is slightly different and evolves over time, so the methodology, the set of conventions the team adopts, must be tuned and evolve. - Alistair Cockburn A brief introduction to Agile Software Development 58

67. Crystal Clear Roles Sponsor Allocates money for the project Expert User Lead Designer Lead Technical person, mentors less experienced team members Designer-Programmer Each person designs and programs A brief introduction to Agile Software Development 59

68. Kanban Kanban literally means “visual card,” “signboard,” or “billboard.” Toyota originally used Kanban cards to limit the amount of inventory tied up in “Work In Progress” on a manufacturing floor A brief introduction to Agile Software Development 60 … Step 1 Done Step 2 Step n In Process In Process In Process Queue Queue Queue … Work Items

69. A brief introduction to Agile Software Development 61 Why use Kanban in Software Development?

71. Smaller development items are often too small to be valuable and difficult to identify

72. Quality of requirements suffers as analysts rush to prepare for upcoming cycles

73. Quality of current development suffers when busy analysts are unable to inspect software or answer questions during development

74. Quality often suffers as testers race to complete work late in the development time-box A brief introduction to Agile Software Development 62

75. The time-boxed iteration drama A brief introduction to Agile Software Development 63

76. A brief introduction to Agile Software Development 64 Using a Kanban approach in software drops time-boxed iterations in favor of focusing on continuous flow.

77. Kanban queue A brief introduction to Agile Software Development 65 … Done Step 2 Step n Work Items Step 1 In Process In Process In Process Queue Queue Queue …

78. Kanban queues (cont’d) Large enough to keep the team busy Small enough to avoid premature prioritisation Ideally should be FIFO A brief introduction to Agile Software Development 66

79. Kanban - Work In Progress Reduce multi-tasking Maximize throughput Enhances teamwork A brief introduction to Agile Software Development 67

80. The multitasking issues Facts: 20% time lost to context switching per ‘task Sequential yields results sooner A brief introduction to Agile Software Development 68 A A A B B B C C C A B C Chart courtesy of Yahoo!

81. Throughput A brief introduction to Agile Software Development 69 Organizational overhead goes up as work in progress increases Total Cycle Time = Number of Things in Process Average Completion Rate to improve cycle time Improve Average Completion Rate Reduce Number of Things in Process

83. Kanban Example 1 A brief introduction to Agile Software Development 71 Image courtesy to Jeff Patton

84. Kanban Example 2 A brief introduction to Agile Software Development 72

85. Kanban Example 3 A brief introduction to Agile Software Development 73

86. Agile Mashup It follows the Agile Manifesto and keeps the sprit of agility It utilizes practices from several methods, for example: Use sprint backlog and user stories with TDD and standup meeting with a kanban liked dashboard. Use stand up meeting in daily Scrum Use Burn down chart in Kanban A brief introduction to Agile Software Development 74

87. A brief introduction to Agile Software Development 75 Agile Software Development - a cooperative game. Alistair Cockburn

88. 76 Paper Face-to-face communication is better 2 people at whiteboard 2 people on phone Communication Effectiveness Videotape 2 people on email Richness of communication channel A brief introduction to Agile Software Development Slide courtesy to Cockburn. A.

89. References and Further Readings Agile Software Development: The Cooperative Game, 2ndEdn. By Alistair Cockburn. Scrum Guide 2010 by Ken Schwaber and Jeff Sutherland Agile Project Management with Scrum by Ken Schwaber Agile Java Crafting Code with Test-Driven Development By Jeff Langr Test-Driven Development in Microsoft .NET by James W. Newkirk and Alexei A. Vorontsov Extreme Programming Explained by Kent Beck XP introduction, http://www.extremeprogramming.org/ http://xprogramming.com/ http://www.agilealliance.org/ Kanban Oversimplified http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html Ken Schwaber & Jeff Sutherland, Scrum Guide, Scrum.org Pete Deemer, Gabrielle Benefield, Craig Larman & Bas Vodde, Scrum Primer, GoodAgile.com HanoiScrum.net AgileVietnam.org ScrumAlliance.org AgileAlliance.org A brief introduction to Agile Software Development 77

90. Q&A A brief introduction to Agile Software Development 78

91. A brief introduction to Agile Software Development 79 Thank you! Let’s Go Agile! Sunday October 23rd 2011 FPT University, Innovation Building, Quang Trung Software City, District 12, HCMC, Vietnam