Adopting Agile Development

1
Adopting Agile Development

• Lessons Learned
• 14-April-2004

2

• The average failure rate for adoption of new
  technologies/methodologies is 55
• Gartner Group

3
Why Agile?

• Accommodate change
• Reduce risk
• Increase visibility (risks, schedule, etc.)
• Improve quality
• Address business needs
• Reduce missed and false features
• Fewer defects
• Increase maintainability
• Accelerate realization of business benefits

4
Agile Principles

• Iterative Development early and frequent
  delivery of working software contributes to
  project visibility, reduces project risk via
  regular feedback, fosters continuous improvement
  and enables early realization of business
  benefits
• Adaptive Planning change is expected and is
  part of the process
• Test-Driven Development testing plays an
  integral role in every phase of the project life
  cycle
• Automation - automation of key activities drives
  down the cost of change. Example - Continuous
  Integration
• Collaboration between product managers,
  business analysts, developers, and QA maximizes
  overall team efficiency
• Visibility all stakeholders are provided with
  maximum visibility into project progress
• Technical Excellence continuous attention to
  technical excellence and good design enhances
  agility

5
Agile Benefits
Predictive
Agile
Benefit
Project Management
Design
Development
QA
Change Management
6
People are more important than process

• An Agile process will not help under-talented
  and/or unmotivated staff succeed
• Agile processes require talented and dedicated
  staff. Curious professionals that have a passion
  for self-improvement. Not people who blindly
  follow a process or spec.
• Where possible, address people issues first and
  process issues second
• Leverage the visibility afforded by Agile to
  identify poor performers. Remove them from
  projects immediately. Their presence is a drain
  on team productivity.

7
Get the right people on the bus

• Do not force a new process onto the unwilling.
  They will fail and will blame the process.
• When adopting new techniques, staff pilot
  projects with motivated people. We recommend
  self-selection.
• Support pilot teams to the fullest extent
  possible. Their success will encourage viral
  adoption.

8
Middle managers are typically most resistant to
Agile

• Business sponsors, product managers and IT
  executives are typically the biggest supporters
  of Agile
• What business person or executive wouldnt want
  early delivery of results, greater visibility
  into project progress and more control over
  scope?
• Agile methods require more engaged project
  management
• Agile project managers must be leaders and
  facilitators. They cannot limit themselves to
  project tracking and status reporting.
• Agile project managers should be either domain
  experts, technically savvy or both
• Agile forces many project managers out of their
  comfort zone
• Agile methods require hands-on technical
  leadership
• Designers (Modelers) should write code. They need
  to experience the impact of their decisions.

9
Agile methods expose weak developers

• Good developers typically learn to love Agile.
  They learn, by doing, that Agile is more
  efficient.
• Weak developers typically dislike Agile due to
  the increased visibility. No one can hide on an
  Agile project.

10
Invest in the appropriate infrastructure

• Time Money
• Increased productivity saves time (and improves
  morale)
• n.b., investment includes the time and effort to
  configure and tune the infrastructure

11
Promote organization-wide support of Agile teams

• The most productive Agile team will not deliver
  to expectations if teams that they depend on do
  not live up to their commitments
• This is not limited to Agile projects
• If an Agile team depends on a waterfall team, be
  prepared for integration-hell
• Require non-Agile teams to adopt an iterative
  process
• Require that all teams adopt objective status
  reporting
• Use Features passing tests instead of Percent
  complete
• Dont let Agile teams look bad because their
  status reports are more accurate than those of
  other teams
• On large projects, every sub-team should view the
  other sub-teams as customers
• This is not limited to Agile projects

12
Quality is free for those who are willing to pay
dearly for it

• High quality software requires less effort to
  build trust us
• The first version of poor quality software may
  require little effort, but the incremental effort
  required to make it production-worthy is
  typically enormous
• Dont invest in an elaborate QA process. Rather,
  invest in QA throughout the entire project life
  cycle.
• Dont skimp on testing environments and tools
• Insist on automated unit testing
• No bad build policy
• Simple, clean designs are always higher quality
• Less opportunity for error
• Easier to isolate defects, performance issues,
  etc.
• Fewer code merge issues

13
Agile practices are synergistic and
interdependent
14
Beware of backsliding

• Sacrificing testing
• Automated testing is a prerequisite for frequent
  reliable builds
• Monitor unit test coverage
• Test cases ARE a requirements specification
• Customer not involved
• Dont let day job become an excuse of lack of
  business involvement
• If business cant/wont invest in active
  participation, the project is probably not worth
  doing
• Customer proxy alternative
• Iterations that never end
• Time-boxing
• Story sign-off instead of iteration sign-off

15
Velocity does not equal productivity

• Velocity compares actual time to ideal time
  estimates, whereas productivity influences ideal
  time estimates.
• Velocity helps to identify factors that either
  distract teams from project tasks or slow
  progress on project tasks
• Many distracting activities are perfectly
  legitimate (company meetings, coaching, personnel
  evaluations, fire-fighting, etc.)
• Management, not team members, have the most
  influence over velocity
• Providing additional resources (people,
  equipment, etc.)
• Altering policies (e.g., development team control
  over development environments)
• Altering priorities (you dont need to
  participate in the color scheme task force)
• REMOVING IMPEDIMENTS
• Velocity targets should be a management
  objective, not a team objective
• Estimate based on actual velocity (Yesterdays
  Weather) not targeted velocity

16
Agile does not eliminate the need for planning

• Project planning is a continuous process on Agile
  projects
• Release planning is important. Otherwise, the
  business cant make intelligent IT investment
  decisions.
• The key is that everyone must participate in
  adaptive planning
• Product management owns prioritization and
  release dates, development team (including
  developers) owns task planning and estimation
• Leverage the Planning Game
• The payoff is that although a typical Agile
  project does not deliver on all of the originally
  defined functionality, it delivers even more
  stuff that no one thought of at the beginning
• Build a staffing plan as well as a release plan
• For large projects, start with a smaller team of
  more experienced/skilled people. Solid
  architectures do not emerge from inexperienced
  teams.

17
Agile facilitates distributed development

• Shared code base, automated testing and
  continuous integration helps distributed teams
  act more like co-located teams
• Divide work by functionality (stories), not by
  technical layers (horizontally). Otherwise, you
  create an interdependence that makes the
  dependent sub-team less productive.
• The last person doesnt go home until the build
  is clean
• Invest in bi-directional travel. Its easier to
  work with a remote team if you personally know
  some of the players and are familiar with their
  environment.
• Invest in constant direct communication. Instant
  messaging, frequent conference calls (someone has
  to stay up late), etc.

18
Pilot Agile on high-value projects

• Success on high-value projects will be more
  widely recognized
• Its easier to obtain organization-wide support
  for high-value projects
• Many low-risk projects can be done just as
  effectively using predictive methods

19
Agile development is a form of risk management

• Every Agile technique addresses some project risk
• What if someone(s) doesnt deliver on time?
• Always focus on the highest value features and
  deliver fully-tested software every two weeks.
  This way, we will always have a working version
  of the most important functionality.
• What if a mandatory change is introduced at the
  eleventh-hour?
• Implement the simplest possible design and
  develop a comprehensive automated test suite so
  that we can minimize the cost of introducing
  changes.
• What if we lose a key person half-way through
  the project?
• Adopt a collective code ownership approach,
  program in pairs and develop a comprehensive
  automated test suite. This way, it will be
  unlikely that only one person has ever touched a
  particular unit of code and it will be easy to
  see if a change breaks something unexpectedly.
• Etc.

20
Agile maximizes the amount of work not done

• Why pay for features that are either never used
  or dont provide a sufficient return-on-investment
  ?
• Make sure that product managers are active
  participants. Their ability to prioritize may be
  the most valuable Agile practice.
• Even if you produce the same number of features,
  an Agile process ensures that they are the most
  valuable features

21
If you are afraid of a piece of code, refactor
it

• Short-term workarounds in an effort to avoid
  complex code rapidly contribute to increased cost
  and delays
• Avoids addressing potentially bad implementation
• Increases code bloat
• Contributes to tight-coupling between components
• Etc.
• Simple, clean designs are always higher quality
  and reduce integration headaches
• Implement unit tests whenever you refactor. The
  next guy will thank you for it.
• Use a peer review process to identify cases where
  developers did not refactor when they should have

22
Late adoption temporarily increases costs

• Learning curve
• Several iterations before the team is comfortable
  with the new process
• Time to adapt process to the organization
• And the reverse!
• Quality debt