1 / 20

Adopting Agile

Adopting Agile. The practices behind the theory. Agile Manifesto. http://www.agilemanifesto.org/. Individuals and interactions over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation

dylan
Télécharger la présentation

Adopting Agile

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Adopting Agile The practices behind the theory

  2. Agile Manifesto http://www.agilemanifesto.org/ 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

  3. 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

  4. 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

  5. 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 • Waterfall • Agile

  6. Timeline comparison Traditional Agile

  7. 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

  8. 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

  9. Art of agile in 4 easy steps 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 Focus on flexibility

  10. 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 Value vs. Waste

  11. Sashimi • 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

  12. Decrease the cost of change • 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

  13. Frequent feedback • 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

  14. 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? What makes a project a good fit for agile?

  15. 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 Best ways to fail with agile Common pitfalls

  16. Stages of adoption - Introduction

  17. Stages of adoption - Emerging

  18. Stages of adoption - Understanding

  19. Stages of adoption - Perfecting

  20. Questions?

More Related