Adopting Agile THE PRACTICES BEHIND THE THEORY

Agile Manifesto Individuals and interactions over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Respond to change rather than follow a plan

Agile Principles The highest priority is to satisfy the customer through early and continuous delivery of valuable software Always welcome changing requirements Deliver working software frequently Business people and developers must work together daily throughout the project Build projects around motivated individuals, and give them the environment they need to get the job done Face-to-face communication is the most effective and efficient means of conveying information Working software is the primary measure of progress Agile processes promote sustainable development

Agile Principles 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 be more effective, then tunes and adjusts its behavior accordingly

Agile and waterfall comparison Phases of development Artifact based milestones Infrequent delivery Limited, prevented, costly changes High periodic ceremony, high documentation Big up front requirements Large, departmental centric teams Strict role adherence Work breakdown structure Cycles of development Delivery based milestones Frequent delivery Regular, embraced, low-cost changes Low frequent ceremony, light documentation Just in time elaboration Small, cross-functional, project centric teams Blended roles Feature breakdown structure WaterfallAgile Page 5 April 5, 2012

Timeline comparison Page 6 April 5, 2012 AnalysisDesignDevelopmentTestingOpsProd EpicStoriesCycleReviewOpsProd Traditional Agile

Agile Myths Agile development is undisciplined Agile teams don’t plan Agile development is unpredictable and we need predictable plans for future planning Agile is the latest fad and won’t work here. Waterfall/ CMM/ISO are much more stable and consistent Lean thinking is a recent trend and will be replaced by something else There is no end to a project; agile development continues forever

Agile Myths The big infrastructure must be delivered first and then we can release features The tester will find any defects that exist, they can test out any issues Development was broken into sprints and we attended all the scrums; therefore we should be successful An application that is still in flux can’t be tested Agile teams don’t plan more than 3 weeks out The Scrum Master is our project manager

Focus on flexibility Constantly remove waste – Value vs. waste vs. necessary waste Practice of sashimi – Feature breakdown vs. work breakdown – Minimal marketable feature Decrease the cost of change – Remove unnecessary waste – do less – Simplify and automate Frequent delivery and frequent feedback Art of agile in 4 easy steps Page 9 November 17, 2011

Value vs. Waste Team constantly evaluates work in progress Value Added Stories that directly or indirectly add value to the project Activities that directly or indirectly add value to the project Necessary Waste Work that needs to be done but does not directly add value Pure Waste Activities that add no value to the project Delays in hand-offs Continuous drive to eliminate/minimize waste and focus on Value Added

Sashimi November 17, 2011 Page 11 Feature breakdown vs. work breakdown Important to get vertical slices of functionality Focus on demonstrable stories vs. technical tasks Something that the product owner would pay for Responsibly breakdown as small as possible

Decrease the cost of change November 17, 2011 Page 12 Requires extra discipline in development Requires technical environment to support it Good design – single responsibility principle, abstraction, encapsulation If it’s painful, do it more often Practice, practice, practice Carry less baggage

Frequent feedback November 17, 2011 Page 13 Embrace late changing requirements Focus on actual need vs. perceived need Don’t know what we want until we try it Difference between course correction and spinning Time value of features

What makes a project a good fit for agile? Changes are likely Cost of a change is low Full team participation Risk level? Team ability / skills? Overall cost? Visibility? Would I build a house this way?

Best ways to fail with agile Change practices without changing behavior Ignore the engineering disciplines Avoid / delay the painful activities Apply work breakdown structure Ignore the status data Focus on only one discipline Maintain discipline silos Common pitfalls

Stages of adoption - Introduction 1. Daily scrums with full team participation - all analysts, all developers, all testers, and product owner, adhering to scrum rules - less than 15 minutes, active stories only, 3 questions, NOT issue solving 2. Conducting retrospectives regularly with outcome documented in a central location, achievable number of action items assigned to an owner, and implementing identified opportunities 3. Release Review - Reviewing every story with the entire team and encouraging ACTIVE conversation about assumptions and outstanding questions while assigning story points 4. Peer code reviews on each story 5. 80% automated unit test code coverage for newly developed / changed code

Stages of adoption - Emerging 6. Creation of stories and progression through standard story lifecycle workflow 7. Reviewing Status Report / Dashboard regularly to improve velocity and estimation and identify potential bottlenecks 8. Respecting Work In Progress limits - focus on getting fewer things done vs. lots of things started 9. Small incremental changes with frequent (daily) check-in to source repository…..Stories are integrated into trunk, source tagged, and deployed to a controlled environment before moving story to final validation 10. Product Owner involvement throughout the life cycle of the project - writing of Epics, feature breakdown, providing the value statement for the work being done, and validating all stories

Stages of adoption - Understanding 11. Every Story is a minimal marketable feature being a vertical slice of the system, and follow the INVEST model - Independent, Negotiable, Valuable, Estimateable, Small and Testable, with a meaningful goal statement 12. Writing acceptance criteria in Given When Then format using business examples rather than values for granular variables, and carefully selecting test scenarios to reduce redundant tests (equivalence partitioning analysis) and include boundary values

Stages of adoption - Perfecting 13. Fully automated deployment - including DB scripts, app deployment, container configuration 14. Automated BDD / ATDD - Behavior Driven Design / Acceptance Test Driven Design (Acceptance tests written before coding, higher level application interface emerges) with 100% automation of Acceptance Test

Questions?