The following content is taken from the popular whitepaper, “Agile Project Management: What’s the story?” written by Jerry Manas. It’s so good, we wanted to make it free to our readers and give it everlasting life on our blog for your enjoyment.
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.
Ten common management fears are:
- It won’t work for big, complex projects.
- It’s too open-ended. We can’t predict costs. It’s “sanctioned scope creep.”
- It sounds like “back of the napkin” design and planning.
- It’s too “techie” focused.
- Software developers don’t talk the same language as customers.
- Customers don’t have time to get involved in planning.
- We don’t want our customers to see our dirty laundry.
- This “teamwork” approach doesn’t sound practical.
- Daily meetings? Our employees will feel like they’re under a microscope.
- It’s too rigid and inhibits individual creativity.
The truth is that Agile involves more planning than they realize—with each iteration in fact. Plus, customer and business involvement are higher, and communication is elevated, so the focus isn’t strictly on technology. But other concerns are quite legitimate.
Overall, the following ten strategies can address typical concerns:
- Make the strategy fit the situation – use the right methodology for the right job; Agile is best for a cohesive team working on knowledge work with a level of uncertainty.
- Reduce risk by focusing on business symptoms over solutions – don’t lose sight of the business problem being solved.
- Adopt a “see for yourself” policy to assess the user experience – before and after.
- Foster a systems-thinking approach – think beyond the software; think also of processes, upstream and downstream systems, stakeholder impact, and so on.
- Engage a business analyst to ensure that details aren’t overlooked – developers often lack an understanding of business details.
- Bridge the culture gap between technicians and customers – 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.
- Embrace change but manage it – assume features will change based on learnings, but have discussions about overall scope, and manage and log changes to the scope.
- Focus on product evolution, not project evolution; manage by prioritized features and release; have release targets – 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.
- Gain management commitment to attend retrospectives and open demos – without management and customer involvement, the Agile methodology loses its power; gaining commitment is key.
- Focus on outcomes and value, not activities or hours – don’t make people feel like they’re under a microscope – 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 – freedom with hours and creativity can balance out the heavy focus on achievement, and agreement on what’s achievable can reduce pressure.
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:
- Understand – build the knowledge necessary to be successful on the project; do research; examine the current and desired user experience.
- Prepare – gain the capabilities to execute the project successfully, such as training, the right tools, gaining stakeholder commitment, etc.
- Iterate – plan and execute iteration/sprints to deliver value through planned releases.
- Transform – focus on ongoing support and self-sustainability for the customer; be sure to educate the team on lessons learned to be applied to future releases.
Lastly, there are some situations where Agile is probably NOT the best approach.
Here are eight examples of where to avoid Agile methods:
- Large enterprise initiatives that need requirements defined up front, and generally require heavy documentation
- Where formal specs are needed for auditability, safety, or preciseness
- Where scope and requirements are known, can be defined, and are unlikely to change much
- Where lots of approvals are needed by multiple parties
- Where the organizational or team culture is incompatible with an Agile approach
- If customers/users are not generally available to participate
- If the team lacks interpersonal skills or heavy technical knowledge (i.e. they can’t be empowered)
- If the team is too large to be effective at cross-communication (i.e. over 100 people, though this number can vary depending on the culture and technology involved)
Virtual Teams and Agile
According to Gartner, by 2015, three quarters of knowledge-based project work in the Global 2000 will be completed by distributed virtual teams. This presents new challenges in collaboration, which is a central tenet of Agile. With this in mind, an understanding of new media and online collaboration tools will become more and more important.
Agile teams will need to employ methods to stay in regular communication, whether by teleconference, webinars, Twitter-like tools such as Yammer, collaboration websites, or other media. Some organizations have even taken to the use of Wikis to capture, organize, and share knowledge.
This also applies to organizations that are currently unable or unwilling to co-locate their development teams. Most Agile experts agree that co-location is best, but with the right technology and the right principles, distributed teams can still be effective.
See if the Agile method is right for you and your organization by registering for a free demo today! Learn more by visiting https://www.planview.com/lean-agile-delivery/. We hope you’ve enjoyed this series and have garnered many key takeaways. Stay tuned to the Planview blog for more Lean and Agile content.
