Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Defined Processes
Output
Defined Process
Output Output
Assuming every step is understood, a given well-defined set of inputs produces the same set of outputs every time. Predictability is key.
The Waterfall
Job Function A Job Function B Job Function C Job Function D Job Function E
Development
Documentation, Signoffs, Handoff
Testing
Documentation, Signoffs, Handoff
Empirical Processes
It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.
Process Dynamics, Modeling, and Control,
Ogunnaike and Ray, Oxford University Press, 1992
Process
Inspect & Adapt
Iterative Development
Adaptability
Iterative Development
All-At-Once Development
Time
Iterative Development
Visibility
Iterative Development
All-At-Once Development
Time
Incremental Development
Value
Incremental Delivery
All-At-Once Delivery
Time
Incremental Development
Risk / Uncertainty
Incremental Delivery
All-At-Once Delivery
Time
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.
Scrum Disadvantages
Its hard! Makes all dysfunction visible
Scrum doesnt fix anything: the team has to do it Feels like things are worse at the beginning
Bad products will be delivered sooner, and doomed projects will fail faster High risk of turnover
Some people will refuse to stay on a Scrum team Some people will refuse to stay if Scrum is abandoned
Partial adoption may be worse than none at all If adoption fails, time will have been wasted, and some people may leave
Scrum Basics
Pete Deemer CPO, Yahoo! India R&D
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
Product Owner
Responsible for the overall project vision and goals Responsible for managing project ROI vs. risk Responsible for taking all inputs into what the team should produce, and turning it into a prioritized list (the Product Backlog) Participates actively in Sprint Planning and Sprint Review meetings, and is available to team throughout the Sprint Determines release plan and communicates it to upper management and the customer
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
Team
7 people, + or 2
Has worked with as high as 15, as few as 3 Can be shared with other teams (but better when not) Can change between Sprints (but better when they dont) Can be distributed (but better when colocated)
Cross-functional
Possesses all the skills necessary to produce an increment of potentially shippable product Team takes on tasks based on skills, not just official role
Self-managing
Team manages itself to achieve the Sprint commitment
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
Manager
The Team
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
Product Owner
Possible issues?
Team Member
Possible issues?
Manager 2.0
Manager 2.0
Step 1 Create list of everything the Manager used to be responsible for (come up with as many items as possible, at least 10 items) Step 2 Cross off this list everything that:
Conflicts with Scrum Is unnecessary in Scrum Would undermine the team's self-organization and self-management
Decide task assignments among the team members and assign them Keep track of whether team-members have done the tasks Ive assigned to them Make commitments on behalf of the team about how much they can get done by X date Give direction to the team on how to do the work, so they can meet the commitment I made Convince team that the commitments made on their behalf are attainable Monitor the team's progress, to make sure they stay on schedule, and aren't having problems Conduct weekly update and 1:1 meetings with team, to surface issues, and provide direction Recruit, interview and hire new members of the team Fire team-members who are consistently not able to perform
Provide coaching and mentorship to teammembers Surface issues to the team that they might overlook scaling, performance, security, etc. Provide input on features, functionality, and other aspects of whats being produced Do performance evaluations and provide feedback to team-members Provide advice and input to the team on difficult technical issues that come up Plan training for team, and do careerdevelopment and planning with teammembers Stay abreast of latest developments in the technology their team uses, industry news, etc. Plan and oversee budgets and financials, and think about tools, skills and other future needs Help remove impediments that the team is not able or well-placed to resolve themselves
Manager 2.0
Step 3 Help the manager turn this into a new job description Step 4 Get sign-off / agreement from the managers manager
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Product Backlog
Retrospective
Product Backlog
Product Owner lists items in descending order of priority (highest priority item is listed first, next-highest is second, etc.) Size estimates are rough estimates (can either be arbitrary points, or ideal days)
Product Backlog
List of everything that could ever be of value to the business for the team to produce Ranked in order of priority
Priority is a function of business value versus risk
Product Owner can make any changes they want before the start of a Sprint Planning Meeting
Items added, changed, removed, reordered
How much documentation is up to the team and Product Owner to decide The farther down the list, the bigger and less defined the items become
~2 Sprints worth are defined in detail
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Product Backlog
Retrospective
Attended by Team, Product Owner, ScrumMaster, Stakeholders May require 1-2 hours for each week of Sprint duration
2 week Sprint = 2-4 hours, 4 week Sprint = 4-8 hours
Sprint Planning
Team understands the details of what the Product Owner has prioritized on the Product Backlog Team decides how much productive time it has available during the Sprint Team decides how many Product Backlog items it can commit to complete during the Sprint
Whats on the Product Owners shopping list
How many items on the shopping list can we afford to buy with that money
Sprint Planning
Team understands the details of what the Product Owner has prioritized on the Product Backlog Team decides how much productive time it has available during the Sprint Team decides how many Product Backlog items it can commit to complete during the Sprint Sprint Pre-Planning Meeting
Sprint Planning
Team understands the details of what the Product Owner has prioritized on the Product Backlog Team decides how much productive time it has available during the Sprint Team decides how many Product Backlog items it can commit to complete during the Sprint Sprint Pre-Planning Meeting
Sprint 4 Begins
Weds
Thurs
Fri
Mon
Tues
Sprint Planning
Team understands the details of what the Product Owner has prioritized on the Product Backlog Team decides how much productive time it has available during the Sprint Team decides how many Product Backlog items it can commit to complete during the Sprint Sprint Pre-Planning Meeting
Sprint Planning
Team understands the details of what the Product Owner has prioritized on the Product Backlog Team decides how much productive time it has available during the Sprint Team decides how many Product Backlog items it can commit to complete during the Sprint Sprint Pre-Planning Meeting
10
2
15 16
3
Last Day of Sprint
4
17 Sprint Review & Retrospective 24
13
14
5
20 Sprint Planning Meeting 21
6
22
7
23
27
28
29
30
31
10
1
14 15
2
16
3
17
4 9
24
13
5
20 21
6
22
7
23
8 13
30
10
27 28
11
29
12 17
14
31 Sprint Review & Retrospective
15
16
18
5
6 Sprint Planning Meeting 7
6 1
14
8 3
10
2
15 16
4
17 Sprint Review & Retrospective 24
13
5
20 Sprint Planning Meeting 21
6
22
7
23
8 3
30
1
28 29
2 7
4
31 Sprint Review & Retrospective
27
10-Hour Day
hacking, reading blogs, playing foosball lunch and tea breaks reading and writing e-mail meetings
10-Hour Day
fixing P1 critical bugs hacking, reading blogs, playing foosball lunch and tea breaks reading and writing e-mail meetings
10-Hour Day
hacking, reading blogs, playing foosball lunch and tea breaks reading and writing e-mail meetings
10-Hour Day
hacking, reading blogs, playing foosball lunch and tea breaks reading and writing e-mail meetings
1/4 Day
1 Day
1/4 Day
1/4 Day
Sprint Planning
Team understands the details of what the Product Owner has prioritized on the Product Backlog Team decides how much productive time it has available during the Sprint Team decides how many Product Backlog items it can commit to complete during the Sprint Sprint Pre-Planning Meeting
Product Backlog
Owner
Sanjay Jing Tracy Tracy Joe Philip Philip
Estimate
4 2 2 6 8 4 2
Defining Done
In Scrum, Done is defined as Potentially Shippable
RELEASE RELEASE RELEASE RELEASE RELEASE RELEASE SPRINT SPRINT SPRINT SPRINT SPRINT SPRINT
RELEASE
SPRINT
SPRINT
SPRINT
SPRINT
SPRINT
PRE-RELEASE SPRINT
How many teams are able to achieve potentially shippable from Sprint 1?
Getting to Done
Backlog Item Task
Design business logic Design user interface Enable all users to place book in shopping cart Set up shopping cart module Implement back-end code Implement front-end code Unit testing Regression testing Documentation Upgrade transaction processing module
Owner
Sanjay Jing Tracy Tracy Joe Philip Philip Tom
Estimate
4 2 2 6 8 4 2 3
DESIGN
CODE
TEST
SPRINT
DESIGN
CODE
TEST
SPRINT
SPRINT
SPRINT
CODE
TEST
SPRINT
Owner
Sanjay Jing Tracy Tracy Joe Philip Philip Tom
Estimate
4 2 2 6 8 4 2 3
Task Estimation
Do we need to be 100% accurate in our % Likelihood estimations for tasks, in order to be time successful in Scrum?
Time
Owner
Sanjay Jing Tracy Tracy Joe Philip Philip Tracy Joe Philip Philip
Initial Est.
4 2 2 6 8 4 2 5 6 3 3 214
Total
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
The Sprint
Sprint Length
4 weeks is standard in literature Many teams start with 2 week Sprints
Intensity
Intensity
Waterfall
Scrum
Time
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
Impact of Change
What happens if the Product Owner gets to add just a small amount of work, or swap work in & out during the Sprint? Current Sprint
Product Owner Satisfaction Level Teams ability to deliver what it committed to Teams sense of accountability to deliver what it committed to
What if the Team is Responsible for Emergency Response (P1 Bugs, etc.)?
Not Scrum standard!
Proceed at your own risk
P1 Bugs
(emergency requests that need to be responded to immediately)
D.R.
P1 Bugs
(emergency requests that need to be responded to quickly)
Commits to fit P1 bugs. May work on items from lower on Product Backlog (items >13)
P1 Bugs
(emergency requests that need to be responded to immediately)
8-Hour Day
8-Hour Day
bug buffer
Risks
Becomes a back door for change during the Sprint Buffer overrun
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
No discussion, conversation until meeting ends Product Owner can attend and report Update of artifacts after standup
Owner
Sanjay Jing Tracy Tracy Joe Philip Philip Tracy Joe Philip Philip
Initial Est.
4 2 2 6 8 4 2 5 6 3 3 214
1
2 2 4 6 6 3 2 10 6 3 2 220
2
0 2 2 6 6 3 2 8 6 3 2 205
Total
Burndown Chart
Task Board
TO DO IN PROGRESS DONE
Task Board
TO DO IN PROGRESS DONE
Owner: Sanjay
Task Board
TO DO
Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac
IN PROGRESS
DONE
Task Board
TO DO
Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac
IN PROGRESS
DONE
Task Board
TO DO
Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac
IN PROGRESS
Task: Configure database and SpaceIDs for Trac
DONE
Task Board
TO DO
Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac
IN PROGRESS
Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac
DONE
Task Board
TO DO IN PROGRESS
Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac
DONE
Task Board
TO DO IN PROGRESS
Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac
DONE
Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac
Task Board
TO DO IN PROGRESS
Task: Configure database and SpaceIDs for Trac
DONE
Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac Task: Configure database and SpaceIDs for Trac
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
Sprint Review
Purpose of the Sprint Review is
Demo what the team has built Generate feedback, which the Product Owner can incorporate in the Product Backlog
Attended by Team, Product Owner, ScrumMaster, functional managers, and any other stakeholders A demo of whats been built, not a presentation about whats been built
no Powerpoints allowed!
4-Week Sprint
Product Owner
1 2 3 4 5 6 7 8 9 10 11 12 13
The Team
Review
Commitment
No Changes
(in Duration or Deliverable)
Retrospective
Sprint Retrospective
What is it?
1-2 hour meeting following each Sprint Demo Attended by Product Owner, Team, ScrumMaster Usually a neutral person will be invited in to facilitate Whats working and what could work better
Go around the room, and give each person an opportunity to add 1 or more items to the 3 lists If people agree with something already on the lists, put a tick mark next to them Select a subset of the Things to try... list to try in the next Sprint (ScrumMaster responsible for tracking this)
WHAT WORKED
Team felt more focused than before on hitting its goals Sense of commitment for the team was higher Team had a better sense of where it was in the Sprint because of the burndown chart The Daily Scrum Meeting improved Team communication during the Sprint Good idea came out during the Sprint Review
S P R I N T 0
SPRINT
SPRINT
SPRINT
SPRINT
PRE-RELEASE SPRINT
S P R I N T 0
SPRINT
SPRINT
SPRINT
SPRINT
However, there are Scrum-specific methods that many teams find more effective that their previous approaches Estimation in Scrum is based on whats called Velocity
Velocity is measure of how much Product Backlog the team can complete in a given amount of time
Product Backlog
90 points 120 points 100 points ~105 size points per Sprint
Teams velocity is ~105 points per Sprint Therefore, in 6 Sprints, the team should be able to complete 6 x 105 = 630 points worth of Product Backlog
Velocity Calculation
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 SPRINT 5
Release Planning
Product Owners determines whether
Its a feature-driven release (launch when features X, Y, Z can be completed) Its a date-driven release (launch on April 15 with as many features as possible) Its date- and feature-driven (launch on April 15 with features X, Y, Z)
Planning Poker
1. Everyone has cards: , 1, 2, 3, 5, 8, 13, 20, 50 2. ScrumMaster reads description of backlog item 3. Everyone selects and simultaneously shows cards 4. If estimates vary significantly, high and low estimators briefly explain 5. Repeat steps 3-5 until estimates stop converging 6. Decide estimate for backlog item 7. Move to next backlog item
Contract Terms
the party in the first part shall remunerate the party in 3.1.1 Vendor will demo potentially shippable software to Customer every 30 days. There will be no additional charge for this. Customer can replace any requirements that Vendor hasnt yet started working on with one or more of equal total size (in the estimate of Vendor) at any time. There will be no additional charge for this. Customer may request interim releases at any time, and will be charged an agreed-upon time and materials cost. If Customers business goals are satisfied early, Customer may terminate contract early for 20% of the remaining unbilled contracted amount.
3.1.2
3.1.3
3.1.4
Yes, but...
Distributed Scrum is not as good as Colocated Scrum However, its still better than Distributed Waterfall
Quote
"If you are going to hire a group of developers halfway around the world in a time zone 12 hours away, how should you work with them? Should you give them a huge requirements document and wait to see what they give you in six months? Or should you ask for something every week?" When it's difficult to communicate, you need to shorten the feedback cycle and measure results frequently.
AgileDevelopment On a Fast Track Global Services Magazine, Jan 2007
Mailing list for Product Owner and all team members, with most project-related emails cc:ed to this list
Verbose subject lines to emails
At least 1 weekly 1-hour real-time check-in between Product Owner and team In-person planning and review regroup in India or US between Product Owner and team at least once per quarter
Sprint Planning
Team has 1 hour real-time meeting with Product Owner to discuss goals of Sprint, broad review of Product Backlog Items (example: Weds night IST) Team spends 1-3 hours doing preliminary analysis and breakdown of Product Backlog Items (example: Thurs afternoon IST) Team spends 1-3 hours real-time with Product Owner completing analysis and breakdown of Product Backlog Items, and makes commitment (example: Thurs night IST) Sprint begins (example: Fri morning IST)
Distributed Team
Stucture B: Team split between two locations
For example, 3 developers, 1 tester, and 1 analyst in US, 5 developers and 1 tester in India
2 separate daily standup meetings Notes from each teams standup emailed to the other and read at the beginning of the meeting
(this is in addition to all the previous recommendations)
Human Dynamics
The quality of the human relationships and communication will significantly influence the outcome of the project. So... Invest in the relationships Invest in the communication
If relationships are week, these things become evidence in a story of badness the other team is crazy, incompetent, evil, malicious, etc.
This is extremely difficult to repair
Spend some savings at project inception to help people get to know each other
Plan work, but also plan play dinners, outings, sightseeing, etc.
Send US customers and project managers to India for creation of initial release plan with team Colocate key members of the team for first several sprints Rotate selected team members to different locations Emphasize the human element these are people, not just voices on a phone or names on email
Team wiki with photos, bios
Instant Messaging
IM is useful, particular because it shows whether the person is there may have to configure to make the status refresh more often
Videoconferencing
Just seeing someones face can make a big different if you dont have professional videoconferencing equipment, buy webcams for both sides
Wikis
Use wikis to share as much project-related information as possible
2. Call It a Pilot Program Pilots are supposed to be chaotic, uncertain, bumpy, messy Keep calling it a pilot as long as possible People will ask whens the decision going to get made to officially adopt Scrum
Wait to make that decision until there are no more teams lining up to make the change Then ask yourself what is it about the remaining teams?
3. Change is Scary to Many People... and Scrum is Really Scary to Some People
Some people will be uncomfortable, unhappy, scared
And is it unexpected? How many management fads have preceded Scrum?
Some of those people will get past it, some of them wont Just 4 months in, some of the biggest early Scrum skeptics had evolved into the greatest Scrum evangelists
Give people the room to change Avoid battle-lines
4. Patience is a Virtue
Err on the side of making fewer teams more successful Every team will hit some big bump kicking off scrum
Many will need some support, if only moral
In the early days, there are many more evangelists for failure than for success Even the undecided will assume that an early failure is a strike against scrum Overbudget the time early teams will need to work through systemic issues
Scrum Pragmatists
Tend to be more effective in big organizations Also more prone that the purist to compromise, possibly at the expense of effectiveness
6. Set a High Bar and Low Expectations for Teams that Want to Use Scrum
Its very easy when evangelizing scrum to set unrealistic expectations
potential benefit work required
People know when theyre being sold People also pick up on respectful realism
tell them its hard, tell them it involves risk, and emphasize that only they in their hearts know if it might be right for their team
Help teams learn from each other Be ready to stage a rescue mission
There are some problems teams cant solve by themselves
10. Be Prepared to Use Guerilla Tactics to Get Things Done Some of the obstacles to Scrum are big
Organizational, policy, management...
13. Measure the Results Early and Often Scrum is in part about making things visible
So measure the results and experiences from a bunch of different angles Publicize both the good and bad
15. Scrum will Always Be Messy Scrum is about people, and people are messy
Inconsistent, insensitive, erratic, make mistakes
LAST