Doxcelerate Engineering

1
SCRUM
Thierry Thelliez CTO Doxcelerate thierry_at_acm.org
2
Subtitle

• Society for the Complete Ruination of Universal
  Mankind
• The Art of Possible, Ken Schwaber
• Real Time Process Improvement, Jeff Sutherland
• From Scrum user group
• A Practical Team Methodology
• All-at-once Development
• My own definition
• Extreme Accountability
• A syncretic form of Process

3
Agenda

• Background
• IT observations and outrageous ideas leading to
  Agile process thinking
• Scrum overview
• Scrum details and lessons learned
• Bootstrapping
• Certification, Performance Review, Meta-Scrum
• Benefits / To improve

4
Who we are

• Start-up company, founded in 2001 and located in
  Los Alamos, NM
• Primary product (RevCom) is based on software we
  created at LANL and subsequently licensed out
• Customers include several U.S. Government
  agencies

5
What we do

• RevCom Web based application for collaborative
  review and commenting of large regulatory
  documents (directives, technical standards,
  manuals, compliance) 2000 users reviewing
  200-page documents in two months
• Application characteristics Continuous evolution
  and customization, 5th version
• Hybrid Workflow Content Management
• Hierarchical Visibility Rules
• Embedded surveys
• Customer specific security
• Business Characteristics
• Development
• Hosting
• Packaged application
• Support, training
• Consulting

6
Personal Background
France
USA
Small Family Business
Software Engineering
Computer Science
Team Leader
Chief Software Architect
CTO Co-Founder
Post Doc
TransPlastic
Hyperlog
Small Business
Medical RD
IT
RD
Educational
Science/IT
Industrial
IT
Scrum
Sky is the limit
CMM
OOA/OOD
Outsourcing
Use Cases
Waterfall Model
Objects
Design Patterns
Fusion
UML
RUP
7
Scrum's Origins

• Lessons from Fuji-Xerox, Canon, Honda, NEC,
  Epson, Brother, 3M, Xerox, HP
• The relay race approach to product
  developmentmay conflict with the goals of
  maximum speed and flexibility. Instead a holistic
  or rugby approachwhere a team tries to go the
  distance as a unit, passing the ball back and
  forthmay better serve todays competitive
  requirements.
• The New New Product Development Game, Hirotaka
  Takeuchi, Ikujiro Nonaka in Harvard Business
  Review, 1986.

8
Rugby - Origins
Soccer origins William Webb Ellis Rugby School
England 1823
9
Rugby Team Oriented
Rugby symbol for team based activities
(especially in Europe) No prima donna
quarterback, everyone depends on their teammates
10
Rugby
Ball flows continuously between players
11
Rugby - Scrum
12
Rugby Team Support
Reaching higher with your teammates!
Interesting positions
13
IT Status No good news

• Pick your Analyst
• Out of a total cost of 37B for the sample set,
  75 of Department of Defense projects failed or
  were never used, and only 2 were used without
  extensive modification
• Jarzombek. The 5th Annual JAWSS3 Proceedings,
  1999
• Gartner Group reports that 70 of Java projects
  fail. 2004
• Standish Group We're losing ground
• IT Success 2002 34 2004 28
• IT projects canceled before completion
• 2002 15 2004 18
• Remaining 51 seriously late, over budget and
  lacking expected features
• Conclusions
• Big projects more likely to fail
• Big projects means less iterations
• Lack of executive support and involved users
• -gt Keep projects smaller

Same data also used in CMM TSP and PSP
presentation!
14
Process Improvement
Agile
Conventional
CMMI
Scrum
TSP
PSP
XP
ISO 9000
DSDM
Crystal Clear
Six Sigma
iDesign
Fusion
Pick one! But no silver bullet
RUP
15
Fear of Changes

• Recent Example
• U.S. Government Computer Blunders are Common and
  Expensive
• The FBI said earlier it might shelve its
  custom-built, 170 million Virtual Case File
  project because it is inadequate and outdated.
• Technology Review, Ted Bridis, January 2005
• A project representative who defended the debacle
  said In software development, everyone knows
  that changing requirements is a recipe for
  disaster.
• NPR, February 2005

16
Unpredictable World

• Examples
• 9/11
• Asian financial crisis
• Internet/Web
• ERP
• Euro
• Supply-chain integration
• Consequences of deregulation (CA energy crisis)

17
Change is Imperative

• Wasserman's Seven Factors Driving Change
• Criticality of time to market
• Shift in computing economics
• More powerful desktop computers
• Extensive networks and the Web
• Growing availability of object technology
• WIMP (windows, icons, menus, pointers)
• Unpredictability of the waterfall model of
  software development
• Tony Wasserman. Toward a Discipline of Software
  Engineering. IEEE Software 13623-31, Nov 1996

18
Coping with Change

• Idea 1 Reduce Changes
• Prescriptive Planning
• Upfront Requirements/Analysis/Design
• Customers Sign-off
• Idea 2 Reduce Cost Of Change
• Iteration
• Lean Manufacturing Thinking (cut waste)
• Empirical Process

19
Prescriptive Planning

• Pros
• Management friendly
• (Illusion of) Control
• Many available tools
• (MS Project, Open Source)
• Cons
• Hard to predict predefined tasks
• Hard to involve all parties
• Typically, activity-focused instead of
  deliverables
• Parkinsons law -gt explicit permission to use all
  the time
• Work expands so as to fill the time available
  for its completion. 1957
• Late activity cannot be made up by the next
  activity (not independent)
• Huge safety buffer added
• Work is prioritized for plan convenience
• Forthcoming book Agile Planning, Mike Cohn

Gantt Chart
20
Planning Issues

• What if Activity 2 finishes early?

How do you maximize resources?
Forthcoming book Agile Planning, Mike Cohn
21
Student Syndrome
Procrastination
Forthcoming book Agile Planning, Mike Cohn
22
Details First Feature Creeps
Asking requirements to be agreed and signed-off
upfront generates feature creeps by fear of
missing an opportunity. Features and functions
used in a typical system Often or always
used 20 Rarely or never used
64 Standish Group Study, 2002
23
Details vs. Decisions

• Heart Attack Prediction
• Problem How to accurately refer patients to
  coronary and intermediate units?
• Common practice Diagnosis accurate between 75
  - 89, following taking extensive medical history
• Lee Goldmans decision tree (Cook County Hospital
  emergency room in Chicago)
• Only four factors/questions
• Two year study Accurate at more than 95 (70
  improvement)
• Safer
• The secret is knowing which information to
  discard and which to keep

24
Wicked Problems Righteous Solutions

• Wicked problems have no definitive formulation.
  Each attempt at creating a solution changes your
  understanding of the problem.
• No stopping rule. The problem-solving process
  ends when resources are depleted, stakeholders
  lose interest or political realities change.
• Solutions are not true-or-false, but good-or-bad
  getting all stakeholders to agree that a
  resolution is "good enough" can be a challenge.
• No immediate or ultimate test of a solution.
• Every implemented solution has consequences.
• No well-described set of potential solutions.
  Various stakeholders have differing views of
  acceptable solutions.
• Each problem is essentially unique. Part of the
  art of dealing with wicked problems is the art of
  not knowing too early what type of solution to
  apply.
• Each problem can be considered a symptom of
  another problem. A wicked problem is a set of
  interlocking issues and constraints that change
  over time, embedded in a dynamic social context.
• The causes of a wicked problem can be explained
  in numerous ways.
• The planner (designer) has no right to be wrong.
• Conclusions All-at-once development
• Rittel, H and Webber M. Dilemmas in a General
  Theory of Planning. Policy Sciences, Vol. 4.
  Elsevier,1973.
• Degrace and Hulet's book, Wicked Problems,
  Righteous Solutions, Prentice Hall, 1990

25
Lean Development

• The approach to product development exemplified
  by Honda and Toyota in the 1980s, typically
  called lean development, was adapted by many
  automobile companies in the 1990s. Today the
  product development performance gap among
  automakers has significantly narrowed.
• Lean Software Development, Mary Tom Poppendick,
  2003

26
Lean Development

• Proven Lean thinking principles applied to
  Software Development
• Eliminate Waste Only add value for customers, no
  delay. Learn to see waste.
• Learn Constantly Frequent Iterations, regular
  releases.
• Delay Commitment Decisions at last responsible
  moment.
• Deliver Fast Respond to customer need, fast.
• Build Integrity In Initial delivery and Over the
  long term.
• Empower the Team No one understands the details
  better than the people who actually do the work.
• See the Whole Measurements and Incentives
  focused on achieving the overall goal.
• Lean Software Development, Mary Tom
  Poppendick, 2003

27
Lean Development Waste

• The Seven Wastes of Manufacturing The Seven
  Wastes of Software Development
• Inventory Partially Done Work
• Extra Processing Extra Processes
• Overproduction Extra Features
• Transportation Task Switching
• Waiting Waiting
• Motion Motion
• Moving artifacts from one group to another
  is
• a huge source of waste in software
  development.
• Defects Defects
• Test immediately, integrate often, and
  release to production as soon as possible.
• Lean Software Development, Mary Tom
  Poppendick, 2003

28
Team Motivation

• Based on psychological research from the past 70
  years, these are the six things that motivate
  people
• 1. Recognition
• 2. Challenging work
• 3. A sense of belonging
• 4. Feeling heard and acknowledged
• 5. Contributing ideas, expertise, and creativity
• 6. Creating something meaningful and significant
• Erika Jones, ABQ SPIN, March 2005

29
Team (De)Motivation
Forced Ranking Could Improve Business Performance
Forced-ranking systems, where a predetermined
percentage of low-performing employees is fired
every year, can improve a companys workforce,
according to a new study. The results were
published in the latest issue of Personnel
Psychology, from Blackwell Publishing.
One thing the study did not cover is the effect
of a forced-ranking system on employee morale or
on a companys reputation, positively or
negatively. "We recognized thats a critical,
important variable, but we werent really able to
put our finger on it and say, This is how morale
would be affected, " Scullen says.
Workforce Management, March 2005

• But most often with forced ranking
• People working to protect themselves.
• People not taking risks -- risk exposes the very
  real possibility of being fired.
• Managers consciously hiring not-so-great
  employees every so often, so they'd have someone
  to fire.
• People working to maximize their
  review/evaluation, not for the good of the
  company or the product.
• Johanna Rothman, March 2, 2005

30
The (dream) team
Bronze medal
Team vs. Group
31
Team Size

• Sweet spot is 5-7 people
• 491 medium sized projects with 35,000-95,000
  SLOC (source lines of code)
• Putnam, Lawrence H. and Myers, Ware. Familiar
  Metrics Management Small is Beautiful-- Once
  Again. IT Metrics Strategis IV812-16, Cutter
  Information Corp., August 1998.

Development time in months
32
Accountability and Trust

• Accountability ? Blame
• Accountability "required to render account".
• Accountability a way of creating trust.
• The business world uses accountability a lot. For
  example, it is very common for sales people to
  have sales quotas.
• Many business people think that developers hold
  themselves accountable to certain things (whereas
  most of the developers still don't do this).
• Offshoring trend programming jobs searching for
  accountability
• Kent Beck pointed out that the main requirement
  for companies to achieve CMM Level 5 is for these
  companies to be able to render account.
• Kent Beck's November 17, 2004 Presentation at
  SDForum

33
Organization Structure

• Conways Law
• Organizations which design systems are
  constrained to produce designs which are copies
  of the communication structures of these
  organizations. This first appeared in the April
  1968 issue of Datamation. The law was named after
  Melvin Conway.

34
Multitasking

• Clark and Wheelwright (1992) studied
  multi-tasking and determined that when working on
  more than two tasks, a persons time spent on
  value-adding work drops rapidly.

35
Models
Waterfall
Assumes that the underlying development processes
are defined and linear.
Requirements Analysis Design Coding Test
Spiral
Iterative
36
Iterative and Incremental Development (IID)

• 1960 Weinberg teaching IID at IBM Systems
  Research Institute
• 1977-1980 IBM FSD builds NASA Space Shuttle
  software in 17 iterations over 31 months,
  averaging 8 weeks per iteration
• 1996 Larman meets with principal author of
  DD-STD-2167
• David Maibor expressed regret for the creation of
  the waterfall-based standard. He had not learned
  of incremental development at the time and based
  his advice on textbooks and consultants
  advocating the waterfall method. With the
  hindsight of iterative experience, he would
  recommend IID.

37
Defined vs Empirical Process

• 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

38
Defined Process

• Light (direct/indirect/flash)
• Film speed/grain
• Lens Aperture

• Motion (subject/camera)
• Composition (static/dynamic)
• Depth of field
• Subjectivity

Photography
?


Film Camera
Light Meter
39
Empirical Process
Film Camera
Digital Camera
Shorten Feedback Loop Reduce Change Cost
Control is through inspection and adaptation
40
Emergent Behavior

• Funded by NASA, Attila was built in the early
  1990s to move over unknown territory without any
  human input. The concept was used for the rover
  "Sojourner" that sent back photos from the Mars
  Pathfinder mission.

41
Agile and Fixed Price?

• Fixed Price, Time and Scope
• What about the value?
• How to maximize value? vs. How to minimize cost?
• Software value is greater than cost
• Other costs
• Cost 20 at delivery, 80 after that
• Peoples time on project
• Opportunity cost
• Contractors use strategy of low bids expensive
  change requests
• Fixed Price and Time
• We have x to spend and we need a release on Dec
  1st. We will collaborate together to come up with
  the best set of features to go live on that
  date.
• Deliver better product that can be currently
  envisioned because we will learn more as the
  project proceeds
• Or cancel the project early
• Martin Fowler

42
Estimation Recommendations

• Dont get tricked into making an instant
  estimate ask for time to think about (a week,
  a day, even an hour)
• State the estimate in terms of confidence levels,
  or ranges, etc.
• Jim McCarthy (formerly of Microsoft, author of
  Dynamics of Software Development) make the
  customer, or other members of the organization,
  share some of the uncertainty.
• Project manager I dont know precisely when
  well finish but Im more likely to be able to
  figure it out than anyone else in the
  organization. I promise that as soon as I have a
  more precise estimate, Ill tell you right away.
• Do some reading and research to become better at
  this area, e.g.
• Bargaining for Advantage Negotiating
  Strategies for Reasonable People, by G. Richard
  Shell (reissue edition, Penguin Books, June 2000)
• Getting Past No Negotiating Your Way from
  Confrontation to Cooperation, by William Ury
  (Bantam Doubleday Dell, 1993)
• Ed Yourdon

43
Agile Manifesto

• Official definition from the Agile Manifesto
• (www.agilemanifesto.org)
• "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 items on the left more."

44
Agile Processes Books

• Extreme Programming (1999) Kent Beck et. al.
• Crystal (2001) Alistair Coburn
• Scrum (2001) Ken Schwaber
• Lean Software Development (2003) Tom Mary
  Poppendieck

45
Scrum

• Developed with the assistance of the DuPont
  Advanced Research Facility and presented to the
  Object Management Group in 1995.
• Key developers and promoters of Scrum are Jeff
  Sutherland, Ken Schwaber, and Mike Beedle.

46
Scrum has been used in

• Independent Software Vendors (ISVs)
• Fortune 100 companies
• Small startups
• Internal development
• Contract development

Source An Introduction to Scrum by Mike Cohn
47
Scrum is being used in

• FDA-approved, life-critical software for x-rays
  and MRIs
• Enterprise workflow systems
• Financial payment applications
• Biotech
• Call center systems
• Tunable laser subsystems for fiber optic networks
• Application development environments
• 24x7 with 99.99999 uptime requirements
• Multi-terabyte database applications
• Media-neutral magazine products
• Web news products

Source An Introduction to Scrum by Mike Cohn
48
Scrum Principles

• Scrum is founded upon two basic principles
• Team Empowerment. The project team is divided
  into self-managing, multi-function units called
  Sprint Teams, consisting of up to seven people.
  The team is empowered to use whatever development
  methods or tools they think best to prepare their
  deliverables.
• Iterative Development. The project deliverables
  are built over several iterative development
  cycles, each adding additional features, and each
  resulting in demonstrable results working code,
  written documentation, viewable designs, etc.

Source An Introduction to Scrum by Mike Cohn
49
Scrum Process
24 hours
Daily Scrum Meeting
15 or 30 days
Backlog tasks expanded by team
Sprint Backlog
Potentially Shippable Product Increment
Product Backlog As prioritized by Product Owner
Source Adapted from Agile Software Development
with Scrum by Ken Schwaber and Mike Beedle.
50
Scrum Team

• Committed
• Accountable
• Ready to learn
• Problem solvers

51
Scrum Team Lessons Learned

• Cross-functional
• Development, Test, Support, Infrastructure,
• Specialists vs. Generalists
• Generalizing Specialists, Scott Ambler, 2003
• Good grasp of how everything fits together
• New ways to work for many coaching needed
• Not hierarchical

52
Product Backlog

• A list of all desired work on the project
• Usually a combination of
• story-based work (let user search and replace)
• task-based work (improve exception handling)
• List is prioritized by the Product Owner
• Typically a Product Manager, Marketing, Internal
  Customer, etc.

Source An Introduction to Scrum by Mike Cohn
53
Product Backlog

• I always think of the ideal product backlog item
  as something incredibly vague "Wouldn't it be
  neat if we could...." Ideally that very vague
  statement could be turned into potentially
  shippable software by a highly cross-functional
  team that worked together to figure out what it
  means and then build it.
• Mike Cohn, Users Stories

54
Product Backlog Lessons Learned

• Use a central repository
• System used Request Tracker
• EVERYBODY can contribute, anywhere, any time, any
  idea, any request
• Easy report access (by priority, date,)
• Define common vocabulary
• Issue ranking Scream gt Critical gt Severe gt
  Important gt Major gt Minor gt NTH
• In practice only three levels for Product backlog
  reviews A, B and C.
• Product Backlog Reviews
• We do not have a real Product Manager
• Product Management Steering is difficult in a
  startup-like company
• Choosing Most bang for the buck vs. Reacting to
  Sales Opportunistic approach
• Every actor involved in the review/prioritization
  should be present (Sales, Support, Development,)
• Be ready to make a case for your request
• Conduct Frequent Reviews (monthly)
• To avoid long list of items
• To keep people engaged in the process
• Keep Backlog item titles as self-describing as
  possible
• Very useful to buffer latest Sales requests
• Urgent today -gt NTH two weeks later

55
Sprint

• Sprint Team Contract
• List of items from Product Backlog
• Commitment
• Accountability
• Deliver completed tasks
• Strict length definition

56
Sprint

• Depend on others to execute their part/commitment
• Cannot be interrupted

57
Sprint Lessons Learned

• 2 weeks iterations
• Long enough to stay focused on mission and
  deliver valuable increments
• Short enough to keep Sales/Customers engaged in
  the process
• Early signs of issues, no more than two weeks
  wasted
• Pace yourself One sprint every two weeks!
• Build process and Configuration management are
  essential
• CVS, ANT
• Explicit Sprint Goals
• Example Author User Interface
• Team can add/remove tasks to meet Sprint goals
• Clear indicator of noise level
• Finishing tasks is not trivial
• Obstacles will happen
• Disk crash, Sickness,
• Bad Sprints will happen (few a year)
• Adapt during the Sprint

58
Sprint Planning

• Team fills the next sprint with top backlog items
• Team members commitment
• Bottom Up
• How can I contribute to the sprint?
• Who can volunteer to this task?
• Game plan Stick with the collaborative call
• Outcome Sprint backlog
• Only team members

59
Sprint Backlog Example
Source An Introduction to Scrum by Mike Cohn
60
Sprint Planning Lessons Learned

• We added an explicit reflective part in the
  meeting for the team only (vs. Sprint Review)
• How was the last sprint?
• What can we work better together?
• Estimating is always hard but lower granularity
  helps
• Staff not necessarily 100 available
• Support

61
Tasks

• 1 to 16 hours
• Done
• Shippable

62
Tasks Done?
Pick your definition
"Testing? What's that? If it compiles, it is
good, if it boots up it is perfect." Linus
Torvalds
Tasks are only "done" when it's released and the
team have received the first mail from a user
saying what great a feature it is and how well it
works. In other words, it has been delivered and
starts to return benefits. from Scrum
users group

• Our Done definition
• Implemented and Committed
• Tested by peer
• Refactored and Documented

63
Tasks Lessons Learned

• It does not have to be code
• Technical development
• Feasibility Study, Design
• End users documentation
• Server update
• Marketing collaterals
• Vendor comparison
• Shippable ? Released

64
Scrum Master

• Manage the process
• Responsible for setting the team up for success
• Inverted Management Serves the team
• Organize meetings
• Daily Scrum
• Sprint Planning
• Sprint Review
• Shield from Noise

65
Scrum Master Lessons Learned

• Tough Role
• Shielding the team from noise, politics,
• Development Manager vs. Scrum Master hats
• Very Disciplined and Demanding Role
• No bad day allowed
• Similar to a sports coach
• Soft skills are always hard
• How do you develop, grow, and maintain a
  functioning self-organizing team?

66
Daily Scrum Meetings

• Daily meeting
• 15 minutes
• Standup (to avoid too long meeting)
• Not for problem solving
• Three questions
• What did you do yesterday?
• What obstacles are in your way?
• What will you do today?
• Chicken and Pigs are invited
• Only Pigs talk
• Report to the team, not to the Scrum Master
• Eye contact for commitment (no emails)

67
Daily Scrum Meetings Lessons Learned I

• Remember that you are doing it every day!
• Keep it short and in time
• Team Motivation, Erika Jones
• Accountability and Trust, Kent Beck
• Day-to-day verifiable progress
• Hard to keep short
• We started at 40 minutes, Still above 20 minutes
• Scrum Master
• Watch for noise
• Length is ok as long as people time is not lost
• Sometimes use a big count down clock
• Watch recipient of message

68
Daily Scrum Meetings Lessons Learned II

• 93000
• Keep it at precise time Better rhythm for
  everybody
• Forces people to make it to the office at a
  decent time!
• Every pig involved in delivering value
• System administrator gradually involved in the
  team effort.
• Amazing emergent behaviors
• Constant adaptation (Attila like)
• Random first speaker, clockwise after that
• Team members will not always be available
• You will need a teleconference system
• Experimented on rare occasions with IM. Not a
  good substitute for eye contact.
• Finish meeting with Any other issues?
• Usually reduce need for other meetings
• Great on-the-fly training

69
Sprint Burndown Chart

• Hours Remaining by Date
• Ideally, the burndown chart drops one day per
  team member every day
• Updated daily
• How much is left to be done
• Decision tool to adjust the Sprint
• Visible to all the team

70
Sprint Burndown Chart Lessons Learned

• Updated daily Keep the chart administration to
  the minimum
• Keep it highly visible
• Shape more important than actual numbers
• We estimate by tasks, not by hours
• Each task counts for three points
• Team pattern identification
• Velocity calculation
• Student syndrome
• Added new/unexpected tasks count for Sprint
  review (noise measurement)

71
War Room
Only a recommendation
Burndown Chart
Issue Criteria
Done Definition
930 three item Agenda
Architecture Overview
Top Backlog Summary
Release Calendar
Issue Metrics Critical/Severe Others
Obstacles
Parking Lot
Speakerphone
Tasks with completion status
72
War Room Lessons Learned

• Could not live without it!
• Team memory
• Burndown chart raw data
• Digital picture for the Sprint Reviews
• Tasks status tracking
• Nothing to hide

73
Sprint Review

• Team presents Sprint accomplishments
• No PowerPoint Slides, light preparation
• Mandatory Demonstrations
• Team
• Scrum Master
• Customers
• Management
• Product Owner
• Team Celebration/Show-off

74
Sprint Review Lessons Learned

• Demonstrations are essential
• Better understanding of where the engineering
  team is
• Never skip a demonstration! Real accountability
• Feel good (or bad)
• Early Victory Sociologist Karl Weick calls this
  "small wins
• Constant learning
• Sales team always impressed!
• Celebrate

75
Releases and Responsibilities
Feedback cycles
Roles
Months
Release Plan

• Product Manager
• Manage the Vision
• Manage the ROI
• Manage the Release
• Scrum Master
• Manage the Process
• Team
• Manage the development iteration

Weeks
Iteration Plan
Days
Customer Tests
1 Day
Daily Meeting
Hours
Story Conversations
Minutes
Programmer Tests
Seconds
Pair Programming
76
How we bootstrapped

• Finishing features every month seemed unrealistic
• Started with Product Backlog
• Added daily meetings
• Huge Deliverable Started Official Sprints.
  Picked two weeks for three months. Stuck with
  that since.
• Initially used Staff meeting for Sprint Reviews.
  Now split

77
Scrum Implementation
Weeks
78
Performance Review

• How to perform individual performance reviews in
  the context of a team based effort?
• Our development organization came up with a
  review process in 2004 where everyone had six
  goals. Two were team based and were evaluated
  based on team performance. Namely
• Achievement of Sprint goals and
• Adhering to scrum practices (keeping burndown
  charts, daily Scrum meetings, team members
  working outside their role etc..)
• Goals 3 and 4 were functionally oriented and
  evaluated the team member's performance as it
  relates to their primary functional area
  (programming, testing , tech writing, etc..).
• And the final two goals ( 5 6) were individual
  goals selected by the individual generally
  related to learning or knowledge sharing
  objectives.
• Bill McMichael, Primavera, Scrum Users Group,
  April 2005

79
Large teams Meta Scrum
Source An Introduction to Scrum by Mike Cohn
80
Miscellaneous

• Certification
• CSM Certified Scrum Master
• Growing Rapidly
• Decertification
• CMM
• Scrum compared to CMM level 3

81
Benefits

• Productivity
• Metrics
• Subjective We did not have real metrics to start
  with
• Mike Cohn measured about six-fold improvement
  compared to more traditional approach
• Spectacular Delivery
• Example Delivered a complex new workflow engine
  in less than three months
• Implicit improvement focus and cut waste
• Transparency
• More predictable
• Team building
• Company communication
• Sales I cannot believe it. This is exactly what
  I need to know.
• External assessment
• VCs You are a lot more mature than the other
  startups we usually see.

82
To improve

• Finish Sprints
• Tempted to apply Scrum to other areas (Sales,
  Marketing)
• Product Management
• Pacing
• How to renew ourselves?
• Short term Sprints vs. longer term RD
• Testability of the application
• Test Driven Development (unit, FIT)

83
References

• Scrum
• http//www.controlchaos.com/
• Users group
• scrumdevelopment_at_yahoogroups.com
• Agile Alliance
• http//www.agilealliance.org/

84
The end

• Questions?