1. End Game

2. Testing on Wednesday

3. How to Test Structured Unstructured Or some of both
Ask them to accomplish a specific task
Unstructured
Tell them what it does and let them play
Or some of both

4. What You Need to Prep Hardware Accounts and ids
Enough data to be interesting

5. Structure 4 rounds Team member running the test to rotate
Identify where you are to send testers

6. Sprint End

7. Why Saturday?
Stop working
Clean up
Prep for Monday

8. Final Presentations

9. Monday, December 12 noon-3 The Facts
Clients will be invited (can adjust time)
Pizza will be served
Only medical excuses accepted
The math:
3 hours = 180 minutes / 14 teams = 12.8 minutes
Bottom line: 10 MINUTES per team

10. Content: Focus on the INTERESTING NOT a checklist
PROJECT OVERVIEW
LESSONS LEARNED
DEMO
What you did
Why you did it
How you did it
Development
Process
Technologies
Do NOT spend a lot of time typing
Walk the audience through typical scenarios

11. Presentation Basics Speak loudly and clearly
Speak, don’t read: you ARE the experts
Look at the class, NOT the computer
Everyone MUST speak
Approximately even

12. NO presentation problems Make sure I know what you need!
Demo Basics
Set up and test demo
NO presentation problems
Make sure I know what you need!
IF you need to restart, do it BEFORE you present

14. Extreme Programming Kent Beck considered the inventor
Ideas developed in the early 90’s
First project at Daimler Chrysler in 1996

15. Extreme Programming Complete development process
First code drop 2-3 weeks after start (what is the start?)
Customer part of the development team
Iterative development to the max
Derive requirements with customer through hands-on experimentation
Agile methodology

16. XP Bills of Rights Developer has a right to
Clear requirements and priorities
Determine how long a requirement will take
Revise estimates
Always produce quality code

17. XP Bills of Rights Customer has a right to An overall plan
See progress in a running system
Change requirements and priorities
Be informed of changes to schedule and have input as to how to adapt
Cancel in the middle and still have something to show for the investment

18. XP Value System Communication Focus on people, not documentation
Simplicity
Of process and code
Feedback
Mechanism to make useful progress
Courage
To trust in people
(Bollinger: what you would like to know about software that your life depended on)

19. Extreme Programming Flowchart

20. User Stories Use cases Written by customer Used for planning
Developers estimate by story
Stories basis for iteration
Used to build acceptance tests
Remember that correctness equals meeting requirements

21. System Metaphor
Initial system design

22. Spikes Technology explorations Focus on high risk items
Typically considered throw-away code
If not, needs to be agreed to by the whole team

23. Release Planning Each iteration has its own plan
Function OR date (other is adjusted accordingly)
(Recall 4 variables: function, date, resources, quality)
Planning adapts as the project progresses
Measure project velocity
Number of user stories and tasks completed
Next iteration looks at planned vs. actual time
Allowed to plan last iteration’s number for this iteration

24. Iteration Scope: all parts of the system Recommendation: 3 weeks
Only add functions needed for current user stories
Recommendation: 3 weeks
Moving people around
Backup and training
Code is owned by the whole team
Pair programming
Re-factoring

25. Pair Programming Two people working at a single computer
Built-in backup and inspections
Collaboration builds better code
Mechanical model
One drives, the other talks
Keyboard slides between the two
Logical model
One tactical, the other strategic
Both think about the full spectrum but bring different perspectives

26. Pair Programming Experiments
Typical numbers show the total manpower consumed not very different
Numbers range, but no more than ¼ additional manpower
Implication: actual time is reduced
Improved satisfaction also improves productivity
Williams et al, “Strengthening the Case for Pair-Programming”

27. Refactoring Each iteration adds just the function needed
If you continue to add new functions every two weeks, code can get messy
Refactoring is the cleaning up of the code at the end of the iteration
Critical to maintaining quality code
(Also applies to the design)
Difference between refactoring & rewriting?

28. Feedback Loops

29. The Rules of Extreme Programming
Planning
Managing
Designing
Coding
Testing

30. When to Use XP Types of projects Team Automated testing High risk
Poorly understood requirements
Team
Small size: 2 to 12
Needs to include customer
Automated testing
Timing issue

31. What Makes a Project XP Paradigm Values Power sharing
see change as the norm, not the exception
optimize for change
Values
communication, simplicity, feedback, and courage
honor in actions
Power sharing
business makes business decisions
development makes technical decisions
Distributed responsibility and authority
people make commitments for which they are accountable
Optimizing process
aware of process and whether it is working
experiment to fix
acculturate new team members
Ward Cunningham, Ron Jeffries, Martin Fowler, Kent Beck

32. NOT everyone loves XP

33. SCRUM Origins: Jeff Sutherland Ken Schwaber Mike Beedle
Initial scrums at Easel Corp in 1993
IDX and 500+ people doing Scrum
Ken Schwaber
ADM
Scrum presented at OOPSLA 96 with Sutherland
Author of three books on Scrum
Mike Beedle
Scrum patterns in PLOPD4
Ken Schwaber and Mike Cohn
Co-founded Scrum Alliance in 2002, initially within the Agile Alliance
With acknowledgement to mike cohn from mountain goat software, llc

34. We’re losing the relay race
Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986.
“The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”
would be nice to include a quote from Wicked Problems here

35. Scrum in 100 words
Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).
The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.
Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

36. Scrum origins Jeff Sutherland Initial scrums at Easel Corp in 1993
Ken Schwaber
Scrum presented at OOPSLA 95 with Sutherland
Mike Beedle
Scrum patterns in PLOPD4
Ken Schwaber and Mike Cohn
Co-founded Scrum Alliance in 2002

37. Characteristics Self-organizing teams
Product progresses in a series of 2-week to month-long “sprints”
Requirements captured in “product backlog”
No specific engineering practices prescribed
Uses generative rules to create an agile environment for delivering projects

38. The Process ©

39. Sprints Scrum projects make progress in a series of “sprints”
Typical duration is 2–4 weeks or a calendar month at most
A constant duration leads to a better rhythm
Product is designed, coded, and tested during the sprint

40. Sequential vs. overlapping development
Requirements
Design
Code
Test
Rather than doing all of one thing at a time...
...Scrum teams do a little of everything all the time
Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

41. Unified (Software Development) Process
Iterations within phases
4 phases and core workflows for each
Inception
Elaboration
Construction
Transition
Requirements
Analysis
Design
Implementation
Test

42. No changes during a sprint
Plan sprint durations around how long you can commit to keeping change out of the sprint

43. Scrum framework Roles Ceremonies Artifacts Product owner ScrumMaster
Team
Roles
Sprint planning
Sprint review
Sprint retrospective
Daily scrum meeting
Ceremonies
Product backlog
Sprint backlog
Burndown charts
Artifacts

44. Product owner Define the features of the product
Decide on release date and content
Be responsible for the profitability of the product (ROI)
Prioritize features according to market value
Adjust features and priority every iteration, as needed 
Accept or reject work results

45. The ScrumMaster Represents management to the project
Responsible for enacting Scrum values and practices
Removes impediments
Ensure that the team is fully functional and productive
Enable close cooperation across all roles and functions
Shield the team from external interferences

46. The team Typically 5-9 people Cross-functional:
Programmers, testers, user experience designers, …
Members should be full-time
May be exceptions (e.g., database administrator)

47. Sprint planning meeting
Team capacity
Sprint prioritization
Analyze and evaluate product backlog
Select sprint goal
Sprint
goal
Product backlog
Business conditions
Sprint planning
Decide how to achieve sprint goal (design)
Create sprint backlog (tasks) from product backlog items (user stories / features)
Estimate sprint backlog in hours
Current product
Sprint
backlog
Technology

48. Sprint planning
Team selects items from product backlog they can commit to
Sprint backlog is created
Tasks are identified and each is estimated (1-16 hours)
Collaboratively, not done alone by the ScrumMaster
High-level design is considered
Code the middle tier (8 hours)
Code the user interface (4)
Write test fixtures (4)
Code the foo class (6)
Update performance tests (4)
As a vacation planner, I want to see photos of the hotels.

49. The daily scrum Daily 15-minutes Stand-up Not for problem solving
Whole world is invited
Only team members, Scrum Master, product owner talk
Helps avoid other unnecessary meetings

50. Everyone answers 3 questions
What did you do yesterday? 1
What will you do today? 2
Is anything in your way? 3
not status for the ScrumMaster
commitments in front of peers

51. The sprint review Team presents what it accomplished during the sprint
demo of new features or underlying architecture
Informal
2-hour prep time rule
No slides
Whole team participates
Invite the world

52. Sprint retrospective Periodically look at what is and is not working
Typically 15–30 minutes
Done after every sprint
Whole team participates
ScrumMaster
Product owner
Team
Possibly customers and others

53. Product backlog: User Stories
The requirements
A list of all desired work on the project
Ideally expressed such that each item has value to the users or customers of the product
Prioritized by the product owner
Reprioritized at the start of each sprint

54. Sprint Backlog: How
Breaks the user story down into tasks

55. Burn-Down Chart Tracks Remaining Effort

56. Scaling through the Scrum of scrums