The document discusses common myths and misconceptions surrounding Agile methodologies, particularly in relation to TFS and Visual Studio 2012. It clarifies that Agile is not a fad, is often more successful than traditional approaches like Waterfall, and ultimately promotes early and continuous testing and collaboration. The text also emphasizes that Agile practices do not eliminate documentation or control, and that effective Agile implementation can lead to improved productivity and quality without necessarily doing 'more with less.'

1. Agile: Myths and
Legends
FEATURING: TFS AND VISUAL STUDIO 2012

2. Angela Dugan
Application
Lifecycle
Management
Project
Leadership
.NET Solutions
Mobile
Solutions

3. Obligatory Dilbert

4. Agile Tenets
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

5. Quick review of Agile/Scrum
SCRUM = Agile
Agile <> Scrum

6. My Top Agile Myths & Legends
1.
Organizations are not succeeding with agile
2.
Agile works better than traditional approaches (e.g. Waterfall)
3.
Traditional (Waterfall) works better for distributed/offshore
teams
4.
Agile teams waste a lot of time testing that traditional teams
don’t
5.
Agile teams don’t produce documentation
6.
Daily stand-ups are just glorified status meetings
7.
Without detailed records, I don’t know that my people are really
working all the time!
8.
If we convert to Agile, that means we can “do more with less”
right?

7. Myth #1
Organizations are not succeeding
with agile
(a.k.a. “Agile is just a fad”)

9. Regarding that fad nonsense…
Agile has been around as a general methodology since as
early as the 70s
Agile was introduced as an “official” flavor of software
development processes in the early 90’s
The Agile Manifesto came into being in 2001

10. Myth #1
Organizations are not succeeding
with agile
False: At least 86% are trying, and most are succeeding!

11. Myth #2
Agile generally works better than
traditional approaches (e.g. Waterfall)

12. The Numbers Don’t Lie

13. But Agile Projects Still Fail!
Agile is more than 3 time LESS likely to fail than Waterfall.
Agile is 3 times MORE likely to succeed than Waterfall.
But…
Agile is not a guarantee of Success (“no silver bullet”)
Agile will never be perfect so long as imperfect people
are executing it

14. Myth #2
Agile generally works better than
traditional approaches (e.g. Waterfall)
True: Anybody can fail with Agile, but when done right I’ve yet to see a
situation where adopting agile practices didn’t improve things

15. Myth #3
Traditional (Waterfall) works better for
distributed/offshore teams

16. Challenges of Distributed Teams
Communication and coordination can be hampered by timezone differences
Self-management and communicating impediments is
difficult for some cultures
Daily stand-ups may require additional technology to
facilitate
Peer review and code quality/standards enforcement may
require extra effort and diligence

17. TFS 2012 Team Dashboard

18. TFS 2012 Backlog Planner

19. VS 2012 Code Review Tool (requires VS Premium or better)

20. Distributed Agile Strategies
Coordinate schedules to ensure overlap in the work-day
Meet face to face to establish trust
Install web cameras, Skype, and/or on-line task boards to
enable real-time communication
Establish continuous integration CI and target high test
coverage across all teams
Keep iterations short

21. Myth #3
Traditional (Waterfall) works better for
distributed/offshore teams
Sometimes: Agile can work for distributed teams, but takes work and it IS succeeding.

22. Myth #4
Agile teams waste a lot of time up front
testing that traditional teams don’t

23. Why Does Testing Early and
Often Matter?

24. Agile Testing Practices
TDD
ATDD
Automated Unit Testing
Automated Regression Testing
Continuous Integration
Exploratory Testing
Again… tools are your friend!

25. VS 2012 Unit Test Frameworks

26. MTM 2012 Exploratory Testing

27. MTM 2012 Web UI

28. Myth #4
Agile teams waste a lot of time up front
testing that traditional teams don’t
False: Agile teams do a LOT more *continual* testing than traditional
Waterfall teams, but I wouldn’t say the time is wasted. Testing early and
often builds in quality, rather than tests in quality.

29. Myth #5
Agile teams don’t produce
documentation

30. Agile Tenets
Individuals and interactions over processes and tools
Working software over comprehensive
documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

31. VS 2012 Storyboards

32. Myth #5
Agile teams don’t produce
documentation
False: Agile teams only produce as much documentation as necessary

33. Myth #6
Daily stand-ups are just glorified status
meetings

34. Daily Standups
Should be 15 minutes or less
Limited to what you did, what you plan to do, impediments
Goal is coordination and collaboration
If it devolves into a status meeting you are DOING IT
WRONG!

35. TFS 2012 Task Board

36. Myth #6
Daily stand-ups are just glorified status
meetings
False: Standups are only about the entire software team
collaborating on the next 24 hours of work.

37. Myth #7
Without detailed records, I don’t know that
my people are really working all the time!

38. http://www.slideshare.net/willevans/kanban-forcreatives-slideshare

39. TFS 2012 Sprint Planning tool

40. TFS 2012 Remaining Work Report
F i n d a n s w e rs t o t h e s e q u e st i o n s :
 H o w fa s t i s t h e t e a m b u r n i n g d o w n
re m a i n i n g w o r k ?
 I s w o r k b e i n g a d d e d d u r i n g t h e i t e ra t i o n ?
 H o w m u c h p ro g re s s c a n t h e t e a m m a ke i n
t h e ava i l a b l e t i m e ?
 A p p rox i m ate l y w h e n c a n t h e t e a m f i n i s h
the work?
 I s t o o m u c h w o r k i n p ro g re s s ?
 I s t h e f l o w o f w o r k b e i n g i m p e d ed o r
b l o c ke d ?
 W h e n w i l l t h e t e a m f i n i s h t h e c u r re nt
i t e rat i o n ?

41. TFS 2012 Cross-Team Reporting

42. Be Careful What You Measure
Time to rethink what you are measuring! ;)

43. Myth #7
Without detailed records, I don’t know that
my people are really working all the time
With agile you are MORE likely to know EXACTLY what
people are working on every day.
The better question might be, why are you focusing on
the number of hours worked?

44. Myth #8
If we convert to Agile, that means we
can “do more with less” right?

45. The Cost of Multi-Tasking
http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html

46. Do More With Less
Humans are TERRIBLE at multi-tasking!
Multi-tasking includes meetings, answering email, one-off
conversations, they are all distractions
You will get 6 – 7 hours of productive time a day out of
people AT BEST, but only if you *leave them alone*
Agile is not magic, you won’t get more hours in a day, but
you will deliver more VALUE in the same amount of time

48. Myth #8
If we convert to Agile, that means we
can “do more with less” right?
Sort of: People will be allowed to focus, and you
will see more value delivered with less bugs in
the same amount of time

49. Good reads
http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805
Drive: The Surprising Truth
About What Motivates Us
Daniel H. Pink
$10 on Amazon

50. Good reads
http://www.amazon.com/Visual-Studio-Team-Foundation-Server/dp/0321864875
Visual Studio Team Foundation
Server 2012:
Adopting Agile Software Practices
Sam Guckenheimer
Neno Loje
$30 on Amazon

51. Questions?