A one day Introduction. Tim Guay, PMP, CSM, PMI-ACP, CLSSS

Size: px

Start display at page:

Download "A one day Introduction. Tim Guay, PMP, CSM, PMI-ACP, CLSSS"

Jemimah Sanders
6 years ago
Views:

1 A one day Introduction Tim Guay, PMP, CSM, PMI-ACP, CLSSS 1

2 To give those who are not familiar with Agile a quick overview of key Agile and Scrum concepts. 2

3 1 Agile Overview 2 User Stories and Backlog 3 Scrum 4 Agile Development Best Practices 5 12 Agile Failure Modes 6 Scrum Simulation exercise 3

4 Goal: to illustrate the pitfalls of the Waterfall approach. No verbal communication allowed Divide into groups Roles are as follows: Project Manager Customer Business Analyst Plane Maker (the developer) Tester 4

5 1 The BA and Customer meet to discuss the requirements for the plane. The customer goes away. 2 The BA writes up a spec for a paper plane 3 The BA hands the spec to the PM. The BA then goes away. 4 The PM assigns the tasks to the folder and sets a time limit 5 The folder folds the plane per the spec. 6 The PM writes a status report 5

6 7 The tester tests the plane and pronounces it production ready 8 The PM writes another status report 6 The Customer checks the plane and tells everybody how close it was to what they envisaged 7 Debrief 6

7 Agile Overview 7

8 In your experience, what are the problems with the traditional waterfall method? 8

9 Process and document-centric Big Design Upfront Silos No ongoing user feedback loop The iron triangle Change is difficult 9

10 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 That is, while there is value in the items on the right, we value the items on the left more 10

11 1 Customer satisfaction by rapid delivery of useful software 2 Welcome changing requirements, even late in development 3 Working software is delivered frequently (weeks rather than months) 4 Working software is the principal measure of progress 5 Sustainable development, able to maintain a constant pace 6 Close, daily cooperation between business people and developers 11

12 7 Face-to-face conversation is the best form of communication (co-location) 8 Projects are built around motivated individuals, who should be trusted 9 Continuous attention to technical excellence and good design 10 Simplicity the art of maximizing the amount of work not done is essential 11 Self-organizing teams 12 Regular adaptation to changing circumstances 12

13 So what do you think the benefits of Agile would be? 13

14 Increased visibility Progress is measured by working software Information radiators give at-a-glance current status Increased adaptability & flexibility To market conditions To customer feedback To the unexpected 14

15 Business value Delivered sooner Greater actual business value is delivered Faster time to market Faster ROI Risk reduction Short delivery horizons, usually 2 to 4 week iterations (sprints in Scrum-speak) Risk-based prioritization Ability to rapidly course-correct Inherently less risky than Waterfall 15

16 Increased quality More disciplined software development process; TDD, CI, Refactoring Active and regular customer involvement Regular customer feedback Retrospectives Improved moral & productivity Empowered and self-organizing teams Sustainable pace More focused on delivering value Better relationship with the customers 16

17 Knowing what you now know about Agile principles, do the paper plane exercise again Debrief afterwards and pick one member to share your experiences with the class. 17

18 User Stories and Backlog 18

19 Describes in a structured narrative form a user interaction with the system User could be a person or another system Can also be the system itself for a nonfunctional story Should fit on an index card with the acceptance criteria written on the back 19

20 User Story Format As a <user role> I want to <goal> sp that I can <reason> Acceptance Criteria (Can be more than one) Given <initial context>, when/where <event or condition>, then <expected outcome> 20

21 Good user stories meet the INVEST criteria Independent Negotiable Valuable Estimable Small Testable 21

22 Popular Agile estimating technique is Planning Poker, which estimates the size of a story in story points Story points are an abstract measure of size Uses Fibonacci numbers (1,3,5,8,13 ) Use cards or app. 22

23 For each user story to be estimated Each participant secretly picks a size Everybody reveals the size they picked Folks picking the high and low estimates explain their rational to the team Another round of size picking occurs Keep repeating until a consensus is reached 23

An Epic is a high-level requirement or cluster of related stories Example would be: As a user I want to deposit checks via my smart phone This is too big to be a

24 An Epic is a high-level requirement or cluster of related stories Example would be: As a user I want to deposit checks via my smart phone This is too big to be a user story and needs to be deconstructed into a set of user stories. EXERCISE: Break up the example into its component user stories, then size. Remember INVEST 24

25 Informed by the product vision Contains user stories (the requirements) Product Owner works with the customers to create and prioritize the backlog Prioritize using MoSCoW Don t forget the non functional requirements 25

26 Should allocate about 5% of sprint time to backlog grooming (4 hrs in a two-week iteration or sprint) Activities include Adding new stories and epics Breaking down epics into stories Estimating effort and refining existing stories Streamlines sprint planning 26

27 Velocity is the total number of story points a team completes in a sprint The average velocity is used by the team to determine how many story points to take on in a sprint 27

28 Velocity is tracked during the sprint using a burndown chart 28

29 Scrum 29

30 An iterative framework for doing software projects Most common Agile methodology In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum methodology The book Agile Software Development with Scrum was published in 2001 Does not cover the whole software development lifecycle 30

31 Focus Courage Openness Commitment Respect So how do you think these values would be manifested? 31

32 Scum has three roles Product Owner Responsible for what work will be done and the order of priority for that work Maintains the product backlog The single neck to choke ScrumMaster Facilitates the Scrum process Removes impediments Servant leader Team Member Everybody else assigned to the team Self organizing, dedicated, and empowered All skills needed should be represented on the team Specialized generalists 32

33 A product owner creates a prioritized wish list called a product backlog. During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces. The team has a certain amount of time, a sprint, to complete its work Meets each day to assess its progress (daily Scrum). Along the way, the ScrumMaster keeps the team focused on its goal. At the end of the sprint, the work should be potentially shippable The sprint ends with a sprint review and retrospective. As the next sprint begins, the team chooses another chunk of the product backlog and begins working again. Rinse and repeat 33

Technically not part of the Scrum Lifecycle, but all Scrum projects need to start with product visioning Will result in a one-page description of the product Answers the following questions; Who is

34 Technically not part of the Scrum Lifecycle, but all Scrum projects need to start with product visioning Will result in a one-page description of the product Answers the following questions; Who is going to buy the product? Who is the target customer? Which customer needs will the product address? Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product? How does the product compare against existing products, both from competitors and the same company? What are the product s unique selling points? What is the target timeframe and budget to develop and launch the product? 34

35 AKA Iteration A fixed period of time in which the team commits to delivering an agreed-upon set of user stories that meets the agreedupon definition of done Period can be anywhere from 1 to 4 weeks, commonly 2 weeks Length cannot be changed during the course of the project 35

36 Starts with a sprint planning session Has a short daily stand-up meeting known as the daily scrum Ends with a demonstration of the completed stories to the customers, followed by a team-only retrospective Goal is to produce new software that is potentially shippable, though not feasible to roll into production every few weeks 36

37 In Scrum as well as in other Agile methodologies, sprints and meetings are timeboxed. This means a set time for the sprint or meeting is agreed-upon and the sprint or meeting ends at the end of the timebox, regardless of any outstanding work or discussion remaining PERIOD!!! 37

38 In Scrum meetings are know as rituals The rituals that are part of the formal Scrum framework are: Sprint planning The daily scrum Sprint demo Sprint retrospective 38

Kicks off the new sprint The product manager and the team negotiate which the stories will be included in the sprint Team members should bring up dependencies or nonfunctional requirements that need

39 Kicks off the new sprint The product manager and the team negotiate which the stories will be included in the sprint Team members should bring up dependencies or nonfunctional requirements that need addressing Team members should ask for clarification or greater detail as needed If the stories are not already estimated, the team will do so using planning poker or other agreed-upon estimating technique Team will commit to delivering the agreed-upon stories, which now form the sprint backlog Individual team members will volunteer to take on each story 39

Once the Sprint is underway, the Product Owner or other management CANNOT make any changes to the agreed-upon sprint backlog unless they abort the

40 Once the Sprint is underway, the Product Owner or other management CANNOT make any changes to the agreed-upon sprint backlog unless they abort the sprint However, the team can request a change Any story not meeting the definition of done by the end of the sprint goes back into the product backlog 40

41 If the team is responsible for production maintenance, then time for maintenance stories should be set aside If the time isn t fully used, the team can pull the next story from the product backlog and work on it 41

42 Daily standup team meeting Same time, same place Attendance mandatory by team members Timeboxed to 15 minutes Each team member answers three questions: What did I do yesterday What will I do today What is blocking me 42

43 Facilitated by ScrumMaster Non-team members may attend as observers but must take a vow of silence Having management around could result in self-censorship Issues cannot be discussed during the daily scrum and must be taken off-line 43

44 Someone takes the role of ScumMaster Someone else the role of a Manager observing the daily scrum. Facilitator will brief you prior to the exercise The rest are team members and take a card to act out the dysfunctional behavior Have the Daily Scrum 44

45 How did that feel? How would you deal with these issues? 45

46 The team demos the completed stories Key customers, the team, and any other interested party attends Timeboxed at 2 or 4 hours Facilitated by the Product Owner One team member drives the software Q & A encouraged No Powerpoints! 46

47 Agenda The work the team committed to delivering The work they completed Key decisions that were made during the iteration/sprint Project metrics Demo of the work itself Priority review (for the next iteration/sprint) 47

48 For the team only!!! DO NOT SKIP! Facilitated by the ScrumMaster Be respectful, no blame gaming Agenda What worked and we should keep doing What did not work and we should stop doing What should we start doing that we are not doing now 48

49 Agile Development Best Practices 49

50 Restructuring to improve: Readability Reduce complexity Maintainability Extensibility Internal Architecture Eliminate duplicate code Etc. 50

51 Drawn from extreme Programming Write unit test first before coding a user story Process is: Red Run test code breaks Green Write just enough code to pass the test Refactor Refactor code to optimize it Tests are automated 51

52 Drawn from extreme Programming Automated build process that is merges the various checked in developer working code several times a day Used in conjunction with TDD and automated testing Goal is that any build could be rolled into production 52

53 Common code ownership Any developer can work on any part of the code Requires strict coding standards Pair Programming Two developers work on the same computer The pilot does the coding The navigator reviews the code as it is being typed in and focuses on the strategic 53

54 12 Agile Failure Modes 54

55 1. Checkbook commitment doesn t support organizational change management. CEOs create within the company their own personal family dysfunction. 2. Culture doesn t support change. Reward plan, and a static and prescriptive standard of work. Try to keep cross-organizational uniformity and use PMO as enforcers. 3. Do not have retrospectives, or they are bad. Actions which come out get ignored or written off. 4. In a race to finish features, the infrastructure gets worse and architecture becomes unstable. Distributed teams make this worse. 55

56 5. Lack of collaboration in planning. Like having the whole team for release planning 6. None or too many Product Owners. Both cases look the same. Agile is yet another hat to wear and the person is already too busy. They check out and ask the team to just do Agile. Can t get past the this sucks phase of adoption if the business is not bought in. 7. Bad Scrum Master which uses a command and control style with the team to look faster, yet in reality slows things down. Low morale lowers IQ. Take decisions away and it actually makes people stupider 8. No on-site evangelist. If the teams are distributed, need one at every site. Can t reap the benefits of Agile or offshore without an on-site coach at each location 56

57 9. No solid team. Disempowered and won t/ can t self-organize. Not dedicated to the project 10. Tsunami of technical debt. Too busy chopping wood to sharpen the axe 11. Traditional performance appraisals. Individual heroics rewarded, glad you re not a team player! 12. Revert to traditional. Change is hard. Hit the threshold where this sucks. Revert back to old ways of doing business 57

58 Goal is to create an earth tourist guidebook for alien tourists Start with a 20 minute sprint planning session Then a sprint with 2 x 30 minute days, each with a daily stand-up Followed by a 20 minute sprint review and a 20 minute retrospective See hand out for user stories 58

Agile Essentials Track: Business Services

Agile Essentials Track: Business Services Presenter: Mark Thomas Synopsis Are you a victim of building the wrong solutions slowly? If so, you re not alone, and considering an Agile approach may be the