1. Agile In Practice Benjamin Booth Spring 2010

2. 2 Proprietary 2 Author/Blogger benjaminbooth.com

3. 3 Proprietary 3 5 Programmer/Architect

4.  1970 – Winston Royce – first to describe Waterfall model  Restrict change to improve predictions  Drive with the plan  Communicate with documents  Programmers are interchangeable 4 4

5. Waterfall Is Expensive! 51% of all IT projects are either over time, over budget, and/or lacking critical features and requirements

6.  Space shuttle flight control system  Requirements are well defined  Unlimited resources  Useful for < 5% of all software projects 6 6

7.  The site shall have a ‘nice looking’ menu page for an existing restaurant’s seven year old website. (Nice looking is defined by the customer.)  The system shall have the ability to edit the menu online. Current menus are stored in a MS Word document.  The site shall have a ‘Suggestion’ capability. Users can use a form to submit suggestions which get stored and also emailed to the owner. 7 7

8.  People (users) are the focus  Measure success with working software  Expect and embrace change  Use small, skilled, motivated teams agilemanifesto.org 8 8

9.  Japanese origin  Whole team  1995 OOPSLA, by Jeff Sutherland and Ken Schwaber  Skeleton of practices and roles 9 9

10. 10 Proprietary SCRUM Workflow

11.  “A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved."  Product Owner: Manages the backlog  A team member who is the voice of the customer  Scrum Master: Coach the process  Team Member: Write code  Everyone else is a “chicken” E 11

12.  Backlog  Sprint Burn Down  Sprint Backlog  Past Backlogs 12

13.  Store Backlogs electronically  Use physical Task Boards 13

14. 14 Proprietary Backlog Sprint Backlog Taskboard Sprint Burn Down Artifacts

15. 15 Proprietary Backlog Sprint Backlog Taskboard Sprint Burn Down Artifacts

16. 16 Proprietary Artifacts Backlog Sprint Backlog Taskboard Sprint Burn Down

17. 17 Proprietary Artifacts Backlog Sprint Backlog Taskboard Sprint Burn Down

18. What type of documentation would we use for requirements in scrum?

19.  Create min/max scale. Ex: 1 - 100  Id your easiest, medium, and hardest stories.  Easiest = 1 point  Medium = 50 points  Hardest = 100 points 19

20.  Keep old Sprint Backlogs & Burndowns  Keep old tasks  Use for velocity calculations  Helps identify trends 20

21. Each developer has a set of cards with estimation values A user story is presented Each developer picks the card representing the number of story points the user story should take Everyone then shows their cards Discussion happens until agreement on a number Repeat for each user story Schedule a sprint with the required number of story points based on your team’s velocity 21 Planning Poker

22.  easily navigate to the menu from the home page so that I can make a phone order (delivery)  be able to make suggestions for improvements to my overall dining experience 22

23.  create, update and delete menu items so that it stays interesting and keeps people coming back  generate a PDF of the menu so that I can give it to the printer for creating ‘real’ menus  get customer feedback emailed to me so I can quickly respond to problems and also pass on compliments to the staff 23

24.  Access to real customers  Proxy customer/user?  Large, distributed teams  Scrum of scrums?  Highly collaborative tools?  Industry misperceptions  Engage and educate  Command-and-control culture  Find a new job  Start your own company 24

25.  Waterfall or nothing still predominant  Agile is highly adaptive, people centric  SCRUM is an effective Agile process skeleton  If your process isn’t working adapt it 25

26.  Introduce incrementally  Business strategy and architecture a must  Get everyone speaking the same language 26

27.  Allocate QA time explicitly  Keep PM simple but do it  Keep improving your process 27

28. Q&A

29.  http://en.wikipedia.org/wiki/Agile_software_development http://en.wikipedia.org/wiki/Agile_software_development  http://www.waterfall2006.com/ http://www.waterfall2006.com  http://www.agileManifesto.org/ http://www.agileManifesto.org  http://www.codinghorror.com/blog/archives/000588.html http://www.codinghorror.com/blog/archives/000588.html  http://www.drdobbsonline.net/architect/207100381 http://www.drdobbsonline.net/architect/207100381  http://en.wikipedia.org/wiki/Scrum_%28management%29 http://en.wikipedia.org/wiki/Scrum_%28management%29  http://spectrum.ieee.org/sep05/1685/failt1 http://spectrum.ieee.org/sep05/1685/failt1 29