Whether you’re new to Agile or part of an experienced Agile team you will inevitably be faced with various challenges in becoming a successful team. In this session we will look at some common challenges teams are faced with and discuss various ways of overcoming those challenges.

1. OVERCOMING
CHALLENGES IN AGILE
David Yancey

2. DAVID YANCEY
 @davidyancey
 www.david-yancey.com
 dave@david-yancey.com
 www.linkedin.com/in/davidyancey
 about.me/davidyancey

3. AGILE MANIFESTO
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 the items on the left more.

4. 12 PRINCIPLES OF AGILE
SOFTWARE
 Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
 Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive
advantage.
 Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
 Business people and developers must work together daily
throughout the project.

5. 12 PRINCIPLES OF AGILE
SOFTWARE
 Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
 The most efficient and effective method of conveying information
to and within a development team is face-to-face conversation.
 Working software is the primary measure of progress.
 Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.

6. 12 PRINCIPLES OF AGILE
SOFTWARE
 Continuous attention to technical excellence and good design
enhances agility.
 Simplicity--the art of maximizing the amount of work not done--is
essential.
 The best architectures, requirements, and designs emerge from
self-organizing teams.
 At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

7. COMMON CHALLENGES
 Business/Corporate Challenges
 Team Challenges
 Individual Challenges

8. BUSINESS/CORPORATE CHALLENGES
 Estimating / Budgeting
 Transition from traditional project management
 Documentation
 Trust

9. ESTIMATING / BUDGETING

10. ESTIMATING / BUDGETING
 No approved budget with out estimates
 Estimates are inherently inaccurate
 Estimate often
 Adjust Estimations
 Communicate Estimations

11. TRANSITION FROM TRADITIONAL
PROJECT MANAGEMENT
 Understand the differences
 Given-Choose-Adjust

12. DOCUMENTATION
 It’s in the story

13. TRUST
 Attempts breeds failure
 Failure breeds Success
 Success breeds trust
 Communication of the above ensures trust

14. TEAM CHALLENGES
 Team Commitment
 Team Involvement
 Off-shore/Off-site teams

15. TEAM COMMITMENT
 Understand the commitment
 Own the commitment
 Stand-up for the commitment

16. TEAM RESPONSIBILITIES
 Understand the team
 Don’t leave anyone out

17. OFF-SHORE/OFF-SITE TEAMS
 Isolated stories
 Team Liaison

18. INDIVIDUAL CHALLENGES
 Test Driven approach
 QA/Developer toss back
 Silo avoidance
 Knowing when your done

19. TEST DRIVEN APPROACH
 Start with functional test
 Let the test drive the design
 Test => Test.Morf(UnitTest)

20. QA/DEVELOPER TOSS BACK
 Pair QA
 Pair up to write UAT

21. SILO AVOIDANCE
 Drive-by Pair Programming
 Story sharing

22. KNOWING WHEN YOUR DONE
 Create Done Chart
 Create UAT before Coding