4. Processes
Theory + Experiments + Practices
Expericence
(good practices & bad ones)
Theory to utilize & promote
good practices
(PROCESS)
4
5. Processes - Software Development
2003
Water f
all
2004
2005
CMMi
UML
2006
TL9000
2007
2008
XP
TDD
Scrum
Unified Process
(RUP)
Continuous Integration
5
Lean
Kanban
Prince2
13. Scrum benefits - project
Ability to Change
Risk
Business Value
Visibility
13
14. Scrum benefits - company
Use Scrum?
- Google
- Facebook
- Amazon
- Twitter
- IBM
- DropBox
- Salesforce - Intel
- Yahoo
- Nokia
- Microsoft - GE
- Time Warner
- Lockheed Martin
- Electronic Arts
- …
14
15. Scrum benefits - case study
2006: Sentinel project awarded to Lockheed Martin, 4
phases, $450m, 6 years .
2010, after four+ years, $421 spent and 1st phase and part
of 2nd done. Mitre estimates another $351m and 6 years
to complete.
FBI stops contract and brings in house.
Scrum studio in Hoover building basement, reduce staff
from 400 to 40.
Project done in 1 year for $30m.
(source: www.justice.gov Inspector General reports)
15
19. Scrum roles - Pig & Chicken
Pigs: who are committed to building software regularly and frequently.
(e.g. the Scrum team)
Chicken: who involved but not a pig. Usually they are informed of the
progress. (e.g. stakeholders, managers)
19
20. Scrum roles - Scrum master
+ Scrum Master :
- Primary job is to remove impediments to the ability of the
team to deliver the sprint goal.
- Not necessarily the leader of the team (as the team is selforganizing) but acts as a buffer between the team and
any distracting influences.
- Understands the benefits of the Scrum process to ensure
that Scrum practices are used as intended.
20
21. Scrum roles - The Team
+ Product Owner:
- Customer representative
- Prioritizes product requirements
+ The Team:
- Includes others in Scrum team, who have the
responsibility to deliver the product.
- Usually 5-9 people with cross-functional skills.
- Self-organizing
21
24. Scrum artifacts - taskboard
User stories (with tasks) visible on a physical board.
24
25. Scrum artifacts - burndown chart
Burn chart is a graphical representation of work left to do
versus time.
+ tracking the team’s progress & predicting when tasks will be completed
+ how many story points the team can earn – the velocity . It helps
predict delivery times based on number of story points.
25
29. Scrum - daily standup
Attendees: Anyone can attend, but only the pigs (Scrum
team) may speak.
29
30. Scrum - daily meeting
Time: short (usually 5-15 minutes)!
It should start at the same time every working day (practically 15-45 mins
after start working time).
Venue: near the collaboration space,
i.e. near the Scrum taskboard enough to see the characters there.
Agenda: Everybody tells others about his tasks, in 3
points:
+ What has he done since the previous stand-up ? (DONE’s yesterday)
+ What is he planning to do today ? (DO’s today)
+ Is there any obstacle preventing him/her from doing what he/she has
planned ? (any IMPEDIMENT)
30
32. Scrum - planning meeting
(time-boxed: 8 hours)
At the beginning of any Sprint (iteration 1-4 weeks), two half:
* BackLog selection (WHAT to do)
+ Some of Product Backlog (user stories) will be chosen to
be Sprint Backlog.
+ Business value : is set by the Product Owner (client representative).
-> represents PRIORITY: how Important the story is to the client.
+ Development ef for t : is set by the Team.
-> represents COMPLEXITY: how Hard to implement the story according to the
average developer’s experience.
User Story: As a [USER] , I want [Feature X] so that [Y satisfied]
32
33. Scrum - planning tasks
* Task estimation (HOW to do)
+ each user story is broken down into concrete tasks, and for each task every
group “votes” a number as “the estimated points” for the task.
+ Planning poker cards : for displaying the “voted/estimated”
points. One task point is implicitly considered 1 man hour, for simplicity. (note: some
may use 1 man day for 1 story point).
33
34. Scrum - planning estimation
* Task estimation (HOW to do)
+ If
the points from the groups for the task are unanimous, or similarly
(highest number is not higher than 1.5 the lowest number), the “final estimated
points” is determined and marked into the task.
+ If
the points of the group are not similarly (see above), the groups of highest
number and lowest number will, in turn, tell the team why they think their number is
suitable. After that all groups will re-estimate that task again. (this step may be
repeated several times until a compromise is reached)
+ Total estimated points for a story should not exceed a predefined certain
amount (20-40 man hours), otherwise the story may either be labeled as “epic” to be
broken into smaller stories so as to not violate that limitation.
34
36. Scrum - review meeting
Review meeting (time-boxed: 3-4 hours)
+ internal showcase for whole team (including chickens)
+ demonstrate what is being done
+ direct feedback (incomplete features do not count)
36
37. Scrum - retrospective meeting
Retrospective meeting (time-boxed: 2-3 hours)
(All Scrum team members raise their opinions about the Sprint, in 3 topics)
+ what we did well?
+ what did not go well?
+ which improvement should be applied right next Sprint?
37
40. Bonus - Scrum origins
Jef f Sutherland
Initial scrums at Easel Corp in 1993
IDX and 500+ people doing Scrum
Ken Schwaber
Scrum presented at OOPSLA 96 with Sutherland
ADM, Author of three books on Scrum
Mike Beedle
Scrum patterns in PLOPD4
Mike Cohn
Co-founded Scrum Alliance in 2002, initially within the Agile Alliance
40
Editor's Notes
{"27":"Easy to understand but extremely to implement.\n","23":"But move people out if they cannot adapt\n","18":"Easy to understand but extremely to implement.\n","24":"But move people out if they cannot adapt\n","13":"Ability to Change\nAdaptability goes down over time, regardless\nAgile enables higher adaptability longer\nWith pluggable architectures encouraged by frequent delivery\nWith encouraging the business decision makers to change their minds as they learn more about the market being sold to\nIn the beginning, if what is being created is the INFRASTRUCTURE, the investment needs to be protected from change. Adaptability goers down quickly as specs are frozen.\nIn agile, priorities may be changed and architectures may be refactored, resulting in systems that stay more adaptable longer\nRisk\nThe risk of making the wrong thing\nIn plan-driven, customers may not see the product until is is ready for release\nAgile solicited feedback all along the way on features that are fully baked\nThe risk of missing an important feature\nIn plan driven, risk is mitigated by strict change control.\nIn Agile, risk is mitigated by iterating to the correct answer.\nThere is never more than a single iteration of work at rick at a time.\n","36":"Different thinking between management and engineering levels -> engineering is forced to live a lie\n","25":"But move people out if they cannot adapt\n","14":"Agile principles?\n","37":"Different thinking between management and engineering levels -> engineering is forced to live a lie\n","10":"People may think that this is the way Scrum manages requirement changes\n"}