AgileNCR 2010 conference was held in Gurgaon on 17th & 18th July 2010. This largest community driven conference was the Fourth edition of Agile NCR and was organized in collaboration with ASCI. This time the event was based on four major themes : 'Agile for newbies', ' Agile Adoption Challenges', 'Workshops and Software Craftsmanship', and ' Post Agile'.

1. Agile Adoption: Making it Successful

2. Agile Adoption: Making it Successful For a successful adoption, it is important to be clear about “Why" the move to agile? “What” are the benefits that adopting agile will bring? “Which” practices of agile make sense for the organization to adopt? “Who” all will be affected? “How” should we adopt agile and bring about the “change”? This presentation aims to highlight some of the key considerations for a successful agile adoption.

3. Introduction Ambreesh Bangur Development / Project Manager / Agile Enthusiast 11 years of s/w industry experience as developer and manager Involved with adopting agile in 3 teams over the last 4 years ranging from a services firm to a startup, where a more traditional, “waterfallish” model was in place. Intended Audience People planning to adopt agile – Can consider the ideas presented to help define a strategy for trying agile People who are/have adopted agile – May be some of the issues discussed here are applicable to them

4. Agenda Introduction The “Why” The “What” The “Who” The “How” Questions

5. The “Why” Be clear about "why" the move to agile? What are the key pain points today? What are the improvements that agile can bring? Is this the latest “trend”? Share the “why” Acceptance vs Imposition

6. The “What” Which practices of agile make sense for the organization/team to adopt? What customizations to the practices should be done to adapt them to our context? Large Team, Distributed team across time zones

7. The “Who” This is the most important piece “Individuals and interactions over processes and tools” It is important that people are “trained” in agile “principles” & “values” not just “practices” “We have lots of bits of paper on the walls, and we ask the 3 Scrum questions at stand-up every day, and we don’t do any planning, design, or documentation, but software still isn’t coming out!”

8. The “Who” Who all will be affected? And “how” Dev, QA, Documentation, Localization, Product Management, Steering Team etc.. Business and stakeholder buy-in is important and the right expectations need to be set.

9. The “Who” Agile Teams need specific behaviors Adaptable Self organizing & self-disciplined Collaborative and collective ownership Interaction Simplicity, “Do what makes sense” attitude

10. The “How” Just following superficial practices will not help Doing a daily stand up, iterative development is “easy” but not enough Cross functional involvement, customer or customer representation, feedback is important

11. The “How” Like any change in an organization, this needs to be planned, managed and dealt with There will be resistance Agile “Coach” / “Mentor” can help teams

12. Summary Adoption itself could be "agile" Done in an iterative way with regular feedback Begin a “Pilot”? Guiding principles are more important than practices Collaborative and evolutionary rather than prescriptive

13. Questions Resources http://alistair.cockburn.us/Is+the+failure+in+agile+adoption+due+to+cargo+cult,+shu+actions,+or+just+laziness http://martinfowler.com/articles/agileOffshore.html http://martinfowler.com/articles/newMethodology.html

14. Agile Adoption Case Study “Why” Developing a new product, needed something for adaptable and quick in terms of delivering a working system I had experience with Agile and SCRUM and thought it would work “Who” Discussed with all involved about the “change”, got buy-in Checked the impact with each team – Dev, QA, Documentation, Product Management and Business.

15. Agile Adoption Case Study “What” Dev and QA team in different sites, co-located them Product Manager, Business in the US Daily Scrum, reduced frequency later System Metaphor, Minimal Design documents Wiki User centric design, frequent showcases, prototyping No Burndown, Weekly feature based milestones Regular review of Product Backlog and Feedback No Test Driven Development, No Automation of System Tests for v1. No Pair Programming, Peer Review “How” Date and people were “fixed”, Scope was managed Introduced people to the key concepts of “Agile” Checked for feedback every 3-4 weeks