{"id":7718,"date":"2018-12-27T11:42:00","date_gmt":"2018-12-27T17:42:00","guid":{"rendered":"https:\/\/blog.planview.com\/?p=7718"},"modified":"2019-08-15T11:25:17","modified_gmt":"2019-08-15T16:25:17","slug":"addressing-your-concerns-about-agile-project-management","status":"publish","type":"post","link":"https:\/\/blog.planview.com\/addressing-your-concerns-about-agile-project-management\/","title":{"rendered":"Addressing Your Concerns About Agile Project Management"},"content":{"rendered":"

\"Addressing<\/p>\n

The following content is taken from the popular whitepaper, \u201cAgile Project Management: What\u2019s the story?\u201d written by Jerry Manas. It\u2019s so good, we wanted to make it free to our readers and give it everlasting life on our blog for your enjoyment. <\/em><\/p>\n

Since the beginning of the Agile movement, defenders of traditional methods have been skeptical. Some of their concerns are valid, while others are rooted in ignorance of true Agile methods.<\/p>\n

Ten common management fears are:<\/strong><\/h2>\n
    \n
  1. It won\u2019t work for big, complex projects.<\/li>\n
  2. It\u2019s too open-ended. We can\u2019t predict costs. It\u2019s \u201csanctioned scope creep.\u201d<\/li>\n
  3. It sounds like \u201cback of the napkin\u201d design and planning.<\/li>\n
  4. It\u2019s too \u201ctechie\u201d focused.<\/li>\n
  5. Software developers don\u2019t talk the same language as customers.<\/li>\n
  6. Customers don\u2019t have time to get involved in planning.<\/li>\n
  7. We don\u2019t want our customers to see our dirty laundry.<\/li>\n
  8. This \u201cteamwork\u201d approach doesn\u2019t sound practical.<\/li>\n
  9. Daily meetings? Our employees will feel like they\u2019re under a microscope.<\/li>\n
  10. It\u2019s too rigid and inhibits individual creativity.<\/li>\n<\/ol>\n

    The truth is that Agile involves more planning than they realize<\/a>\u2014with each iteration in fact. Plus, customer and business involvement are higher, and communication is elevated, so the focus isn\u2019t strictly on technology. But other concerns are quite legitimate.<\/p>\n

    \"Building<\/a><\/p>\n

    Overall, the following ten strategies can address typical concerns:<\/strong><\/h3>\n
      \n
    1. Make the strategy fit the situation<\/strong> \u2013 use the right methodology for the right job; Agile is best for a cohesive team working on knowledge work with a level of uncertainty.<\/li>\n
    2. Reduce risk by focusing on business symptoms over solutions<\/strong> \u2013 don\u2019t lose sight of the business problem being solved.<\/li>\n
    3. Adopt a \u201csee for yourself\u201d policy to assess the user experience<\/strong> \u2013 before and after.<\/li>\n
    4. Foster a systems-thinking approach<\/strong> \u2013 think beyond the software; think also of processes, upstream and downstream systems, stakeholder impact, and so on.<\/li>\n
    5. Engage a business analyst to ensure that details aren\u2019t overlooked<\/strong> \u2013 developers often lack an understanding of business details.<\/li>\n
    6. Bridge the culture gap between technicians and customers<\/strong> \u2013 this can be done through training for developers on customer interaction or by engaging others to interpret and translate to bridge the gap between developers and customers.<\/li>\n
    7. Embrace change but manage it<\/strong> \u2013 assume features will change based on learnings, but have discussions about overall scope, and manage and log changes to the scope.<\/li>\n
    8. Focus on product evolution, not project evolution; manage by prioritized features and release; have release targets<\/strong> \u2013 most sprints do not result in a deliverable to the customer but provide some level of value; releases do result in customer deliverables; also, be sure to prioritize features and set milestones tied to releases.<\/li>\n
    9. Gain management commitment to attend retrospectives and open demos<\/strong> \u2013 without management and customer involvement, the Agile methodology loses its power; gaining commitment is key.<\/li>\n
    10. Focus on outcomes and value, not activities or hours<\/strong> \u2013 don\u2019t make people feel like they\u2019re under a microscope \u2013 focus on what is needed, not how to go about it; allow flexibility and individual creativity, and focus only on agreed-upon outcomes and value for each sprint \u2013 freedom with hours and creativity can balance out the heavy focus on achievement, and agreement on what\u2019s achievable can reduce pressure.<\/li>\n<\/ol>\n

      One additional way to reduce other shortcomings of Agile is to take an integrated approach to emphasize that which is generally outside of the Agile methodology. To address this, use a four-phased approach that can sit on top of your current methodology. The acronym spells UP-IT<\/strong>:<\/p>\n

      \"Agile<\/p>\n