David Putman

1
Management Perspective on Agile Development
David Putman Rachel Davies
2
Managing Software Development...
its about as easy as nailing jelly to a tree

• is HARD

3
Death March?

• Is your Software Development Processes Hurting?
• Software delivered late or only through heroic
  efforts
• Unexpected delays, cost overruns, defects levels
• High staff turnover

4
What is XP?

• XP is a lightweight methodology for small to
  medium sized teams developing software in the
  face of vague or rapidly changing requirements.
  Kent Beck, 1999
• Where lightweight method means fewer roles,
  rules and artifacts to be invoked in software
  process before delivery of working software,
  implies more cost effective.
• Other lightweight processes DSDM, FDD, Scrum,etc
• But who wants to be a lightweight? ...

5
Agile Alliance

• Early 2001, leading methodologists and
  practitioners met to explore the commonality and
  differences in lightweight approaches to software
  development.
• Now Agile not lightweight methods

6
Agile Manifesto

• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
  
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• While there is value in the items on the right,
  the Agile Alliance value the items on the left
  more

7
Individuals and Interactions

• Agile software development methods reduce cost
  by
• Using direct (verbal) communication and feedback
  in favour of documentation.
• Collaborative teams working together not
  dispersed specialists
• Building team knowledge not document library

8
Demings Interaction Equation

• The full capability of the people in the
  company, working together, working with and for
  each other may be expressed as
• Individuals A B C D
• Interactions (AB)(AC)(AD) (BC)(BD)
  (CD)
• An organisation that encourages its employees to
  collaborate gets the benefit of both parts of the
  equation.
• A company that prefers its employees to work in
  isolation gets the benefit of only the first line.

9
Responding to Change

• Cost of Change curve, observed by Boehm in 1981
• Agile methods embrace change, attempt to
  flatten this curve
• Incremental planning allows change to be absorbed
• Process artifacts duplicate information, without
  them less rework/maintenance needed

10
A Different Process Model
Spiral Process
11
We Need a Plan

• Plans are not set in stone
• We know the customer will change his mind
• We know our plans will be inaccurate
• But planning is indispensible
• If we dont have a plan, we cant change it
• Plan often, then plan again and again
• The plan tells us that we are working on the most
  important thing

12
Working Software

• Incremental development processes focus on
  delivering working software
• Team delivers software at regular intervals
• Customer can refine requirements based on feedback

13
Continuous Integration

• Nightly builds are for wimps - Kent Beck
• Pairs aim to integrate code into the baseline
  several times a day
• Automated tests are run on the baseline
• Always have a build ready to ship

14
Emphasis on Quality

• Unit tests
• Test-first design
• No more knock-on effects
• User acceptance tests
• Used as requirements documentation
• How can we go wrong ?
• Regression tests
• Run everyday, never more than one day to fix
• Caring about Quality

15
Software Projects

• Product development
• shrink-wrapped software, large external user
  base
• Bespoke product development
• product for an individual customer
• Internal Software development
• own organisations information systems
• The main differences between these scenarios
  related to the relationship with and proximity to
  the customer. How ..
• your requirements reach you
• you handle feedback to the customer
• you deploy the finished product

16
Customer Collaboration

• Agile processes require more customer involvement
• Customers have more control
• What they ask for is delivered according to their
  business priorities

17
The Ladder of Inference
If we thought about each inference we make, life
would pass us by When we view our conclusions as
obvious, we dont see a need to say how we
reached them When we disagree, we hurl
conclusions at each other from the tops of our
ladders

• This is why we need feedback with our
  communications

18
Where Do Tests Come From?
19
Where Should Tests Come From ?
20
Agile Management

• Achieving observable results
• Maintaining Predictability
• Team maintenance
• Communication
• Motivation
• Developing skills

21
Visible Feedback

• Whole team can see the plan and current progress
  on iteration and release plans
• Index Cards pinned on a pinboard create a wall
  Gantt
• Coloured stickers are used to indicate progress
  on tasks in iteration plan
• Daily Stand-up meetings
• Update progress/replan

22
Reliable Estimates

• XP Tracking
• Developers estimate technical tasks
• Measure your Velocity
• Total of estimated units for Stories accepted by
  the customer at the end of the iteration
• Yesterdays Weather
• Use the number of estimated units completed last
  iteration to predict likely number of units next
  iteration

23
Collective Ownership

• Modules are owned by the team not by individuals
• Everyone has the right to check out and modify
  any code
• Things are fixed when they are found
• Promotes reuse
• All programmers are familiar with all of the code
• Team can accept absences

24
Tuning

• Fine tuning your development process
• After each iteration hold a retrospective
• Reflect on what worked and what didn't over past
  work period
• Make adjustments
• Repeat this cycle
• Team communication improves, more control
  promotes intrinsic motivation

25
Communication

• A manager needs make sure communication is
  happening
• Communication of business priorities to team
• Communication across whole team in building a
  plan
• Manage Customer expectations
• Communication between peers

26
Motivation

• The best motivators are intrinsic
• The most powerful motivational force is
  attraction
• The Motivation Matrix shows that most strongly
  motivated people are attracted towards intrinsic
  motivators

27
Sustainable Pace

• When youre tired you make mistakes
• Developers make most mistakes after 5pm
• 40 hour week should be the norm
• We can do overtime but only for a short period
• Are you working undertime?
• Life outside work relieves stress

28
Developing Skills

• Mentoring, use an experienced Coach (an
  individual or rotating role)
• Individual appraisals
• Use a self-assessment professional development
  scheme like the BCS CDF so they can monitor their
  own progress.
• Try Gold Cards
• Reserved time for learning and exploration
• see XPUniverse 2001 paper from Connextra

29
Useful Links

• Ward Cunningham's wiki
• http//www.c2.com/cgi/wiki?ExtremeProgrammingRoadm
  ap
• Agile Alliance
• http//www.agilealliance.com
• Extreme Tuesday Club, XTC
• http//www.xpdeveloper.com

30
Reading List

• Extreme Programming Explained Kent Beck
• Agile Software Development Alistair Cockburn
• Agile Software Development Ecosystems Jim
  Highsmith
• Questioning Extreme Programming Pete McBreen
• The Fifth Discipline - Peter Senge
• The New Economics - W. Edwards Deming