Going Agile


Published on

Basics an

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Going Agile

  1. 1. GOING AGILE @ Westwing Oliver Mann – June 2012
  2. 2. The Holistic View Understanding of Basics Projects &Agile Fundamentals
  3. 3. A typical ProjectWhat Customer thought of What was specified What was delivered What was documented Costs of Project What customer needed
  4. 4. Why ?
  5. 5. System´s are not simplealthough there are no big numbersWater = H2O behaviour predictable?
  6. 6. Systems TheoryStructure of systems is Simple or ComplicatedThe predictability of behaviour of systems depends
  7. 7. People are not simple their behaviour & interactionPeople interacting in an organization
  8. 8. Why Projects fail Poor Communication Unclear Requirements and Goals Qualification Team-Members Politics, unclear Stakeholder/Leads Not enough Ressources on Start Disturbing Management, Missing Commitment Wrong MethodologyMore details: http://www.gpm-ipma.de/fileadmin/user_upload/Know-How/Ergebnisse_Erfolg_und_Scheitern-Studie_2008.pdf
  9. 9. Projects fail ´cause of People Knowledge & Discipline
  10. 10. Rise of Project Knowledge
  11. 11. Traditional Methodology – Focus on ScopeMain decisions at Project-StartContract and Scope at Project StartNo learnings during implementationFocus on Scope. Every change will risk scope and timeline
  12. 12. Agile Methodology – Focus on Goals Initial Scope can changeDecisions made when necessary & clearCommittment & Reviews for every IterationChanges possible, Optimizing everything
  13. 13. Cost of change Traditional Methodology Agile MethodologySource: http://agilemodeling.com/essays/costOfChange.htm
  14. 14. You see Agilityhas advantages
  15. 15. What is Agility ?Learning and adaptationThe Agile approach accepts that there are many things we cannot anticipate, so it is structured to allow us to first learn about those unknowns and then adapt towhat we learn.CollaborationThe Agile approach places high value on all stakeholders collaborating continuously, including the programmers and their customers.Customer focusThe customer is the central focus of an Agile project and is actively involved throughout.Small self-directed teamsAgility capitalizes on self-directed teams and recognizes that small teams can self-direct most effectively.Lean principlesPrinciples of Lean Manufacturing are embodied in Agility, especially concepts like "Just Enough" and "Just in Time."Progressive requirements elaborationWe expect to learn about the system requirements as the project progresses, so trying to nail them down in a full-blown specification at the beginning of theproject doesnt make sense. Agile projects establish a roadmap and elaborate the details as they are needed.Incremental deliveryThe best way to ensure we are building the right system is to regularly get feedback from our customer. Agility always includes incremental delivery of theproduct to the customer - at least for acceptance testing.Iterative planning and adaptationAgile projects place a high value on planning. They engage in planning at various levels of detail and engage in it regularly. Again, this is driven by the fact that wecannot foresee everything that is important, so we must adapt our plans as we learn.
  16. 16. What Agility is not ! an excuse for undisciplined practicesNo documentationThe documentation that an Agile project produces is significantly different from what traditional projects produce, and an Agile team will always ask whyvarious documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.No planningAgile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit andadapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet dailyto check their progress and plan the days work.No requirementsThe Agile teams Product Owner (customer) defines a Product Vision, and they work together to document the products high-level requirements (called theproduct backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.No schedule or budget controlAgile projects always operate within a "Time-Box." That is, they have definitive start- and end-dates and are not expected to violate those dates. And becausepeoples time is the largest part of a software projects budget, the time-box limits the project budget as well. The Agile mantra is, "We will deliver the greatestpossible customer value within the project constraints!"Developers doing whatever they likeCustomer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agileproject. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The teams only role is toestimate what can be done in limited timeframes. The teams customer determines how that effort will be directed.
  17. 17. The Value of AgilityThe right productCustomer/Stakeholder are continuously involved in the project, ensuring that valuable software is being built and prioritizing the work. In addition, the customeraccepts or provides critical feedback on each increment of the product that is produced. With this level of involvement by the customer, there is no way that thewrong product can be built.QualityAgility always includes a strong focus on the quality of what is built. This includes not only the customers acceptance testing, but also many technical qualitypractices. Properly functioning Agile teams produce high-quality software.Schedule and budgetTime-boxing of an Agile project means that its schedule and budget are rarely "over-run" If things dont work out as planned, the low-priority features can beskipped or cut short.Early warningAn Agile project is a series of short mini-projects, problems become apparent very earlyAdapting to changeChange is a fact of business. Agile projects can adapt to changes in the business environment, within the organization, or with the customer much moreeffectively than any other methodology.
  18. 18. A reduced Agile Framework
  19. 19. Responding to Change … and the problems with it
  20. 20. Be aware of Communication & Interpretation „Describe what you see!“View 1 View 2 Holistic View (Management)
  21. 21. Every Change needs timewether it´s Tools, Process, Team-Members
  22. 22. Team Building Process
  23. 23. No inspect & adapt = No Change
  24. 24. Square of ConstraintsSource: http://www.managment30.com
  25. 25. Escher Cube of Constraints
  26. 26. Confused ?
  27. 27. Solutions next week !Questions every time