agile myths and legends
Post on 10-May-2015
Embed Size (px)
DESCRIPTIONHave you heard any of these statements? As a manager I will have no control or visibility into my teams activities with Agile! Agile practices are unstructured, everyone is a cowboy! An agile development team doesnt work from requirements, and testing goes out the window! and my personal favorite - Agile means no documentation! Ahhhhhhhhh, no wonder Agile is a scary word for managers and testers. If any of the above statements are true in your organization, then someone is doing it wrong. I am here to tell you from personal experience at a number of clients, both large and small, that none of these claims are true if you are truly following the tenets of Agile. Actually, these statements reflect a situation that is really the OPPOSITE of what can happen on a mature, well-functioning agile team. In this presentation, we will discuss what Agile really IS, and debunk some of the popular myths that make organizations hesitate from adopting Agile into their organization.
- 1.Agile: Myths and Legends FEATURING: TFS AND VISUAL STUDIO 2012
2. Angela DuganApplication Lifecycle ManagementProject Leadership.NET SolutionsMobile 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/ScrumSCRUM = AgileAgile Scrum 6. My Top Agile Myths & Legends 1.Organizations are not succeeding with agile2.Agile works better than traditional approaches (e.g. Waterfall)3.Traditional (Waterfall) works better for distributed/offshore teams4.Agile teams waste a lot of time testing that traditional teams dont5.Agile teams dont produce documentation6.Daily stand-ups are just glorified status meetings7.Without detailed records, I dont 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) 8. 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 90s The Agile Manifesto came into being in 2001 9. Myth #1 Organizations are not succeeding with agile False: At least 86% are trying, and most are succeeding! 10. Myth #2 Agile generally works better than traditional approaches (e.g. Waterfall) 11. The Numbers Dont Lie 12. 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 13. Myth #2 Agile generally works better than traditional approaches (e.g. Waterfall) True: Anybody can fail with Agile, but when done right Ive yet to see a situation where adopting agile practices didnt improve things 14. Myth #3 Traditional (Waterfall) works better for distributed/offshore teams 15. 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 facilitatePeer review and code quality/standards enforcement may require extra effort and diligence 16. TFS 2012 Team Dashboard 17. TFS 2012 Backlog Planner 18. VS 2012 Code Review Tool (requires VS Premium or better) 19. 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 teamsKeep iterations short 20. Myth #3 Traditional (Waterfall) works better for distributed/offshore teams Sometimes: Agile can work for distributed teams, but takes work and it IS succeeding. 21. Myth #4 Agile teams waste a lot of time up front testing that traditional teams dont 22. Why Does Testing Early and Often Matter? 23. Agile Testing Practices TDD ATDD Automated Unit TestingAutomated Regression Testing Continuous Integration Exploratory TestingAgain tools are your friend! 24. VS 2012 Unit Test Frameworks 25. MTM 2012 Exploratory Testing 26. MTM 2012 Web UI 27. Myth #4 Agile teams waste a lot of time up front testing that traditional teams dont False: Agile teams do a LOT more *continual* testing than traditional Waterfall teams, but I wouldnt say the time is wasted. Testing early and often builds in quality, rather than tests in quality. 28. Myth #5 Agile teams dont produce documentation 29. Agile Tenets Individuals and interactions over processes and toolsWorking software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 30. VS 2012 Storyboards 31. Myth #5 Agile teams dont produce documentation False: Agile teams only produce as much documentation as necessary 32. Myth #6 Daily stand-ups are just glorified status meetings 33. Daily Standups Should be 15 minutes or less Limited to what you did, what you plan to do, impediments Goal is coordination and collaborationIf it devolves into a status meeting you are DOING IT WRONG! 34. TFS 2012 Task Board 35. 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. 36. Myth #7 Without detailed records, I dont know that my people are really working all the time! 37. http://www.slideshare.net/willevans/kanban-forcreatives-slideshare 38. TFS 2012 Sprint Planning tool 39. 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 ? 40. TFS 2012 Cross-Team Reporting 41. Be Careful What You MeasureTime to rethink what you are measuring! ;) 42. Myth #7 Without detailed records, I dont 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? 43. Myth #8 If we convert to Agile, that means we can do more with less right? 44. The Cost of Multi-Taskinghttp://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html 45. Do More With Less Humans are TERRIBLE at multi-tasking! Multi-tasking includes meetings, answering email, one-off conversations, they are all distractionsYou 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 wont get more hours in a day, but you will deliver more VALUE in the same amount of time 46. 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 47. Good reads http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805Drive: The Surprising Truth About What Motivates Us Daniel H. Pink $10 on Amazon 48. Good reads http://www.amazon.com/Visual-Studio-Team-Foundation-Server/dp/0321864875Visual Studio Team Foundation Server 2012: Adopting Agile Software PracticesSam Guckenheimer Neno Loje $30 on Amazon 49. Questions?