As Agile and Scrum are increasingly used to manage software development projects in large companies, Nancy Nee, VP Global Product Strategy at ESI International, provides us with her viewpoint on how the transition to Agile is going on. She also shares some advice on how make the adoption process as smooth as possible.
Question: What is your feeling about the Agile adoption rate in the software development world? Has a majority of companies shifted to Agile? Do they adopt a “full” or a “partial” version of Agile?
Answer: Agile is being adopted by many organizations at a steady rate. This adoption of Agile, be it full or partial, is highly dependent upon the maturity and readiness of the organization to embrace the tenants of Agile. Because many organizations have invested in tools for traditional project delivery, we see that organizations are using a blended approach of Agile and traditional project delivery. Whether the adoption is full or partial or blended, there is no right or wrong as long as the organization is realizing the benefits and value that Agile adoption brings.
Question: Behind Agile there are both “soft” values, like trust or people empowerment, and “hard” practices like iterations or daily stand-up. How do you consider the “soft” and “hard” Agile adoption by companies?
Answer: Organizations who are trying to adopt Agile will have challenges in both the “soft” and “hard” principles and practices. Remember, Agile is a mindset change which impacts what you have called “soft” values. Organizations typically struggle with the concepts of motivation and trust which lead to empowerment. This is at the heart of what drives Agile. The “hard” practices of Agile are also a struggle because most organizations have been operating under the traditional approach and struggle with altering their application of the traditional project skills to Agile. At the end of the day, the organizations’ maturity level for Agile readiness and adoption are the drivers of the “soft” values and “hard” principles.
Question: Is the transition to Agile in software projects done more in a big bang way or through evolution?
Answer: This question is similar to the question on Agile adoption in “full” or “partial”. The answer to this question is dependent upon the maturity and readiness of the organization to embrace the tenants of Agile. However, from a project perspective, there are certain types of software projects that lend themselves to leveraging Agile in a big bang way such as new product or software development. Then there are projects that will never be able to achieve big bang, but can leverage a blended approach such as maintenance and compliance of software systems.
Question: What do you think are the main impediments to Agile adoption by organizations and how to work around these impediments?
As with any significant process change the biggest barrier seen to the adoption of Agile Development is the ability to change organizational culture followed by general resistance to change. This goes back to understanding and assessing the organization’s maturity and readiness level to embrace Agile. To help with these impediments, organizations must look at the competencies of the project team members, the process for project delivery, and the level of resource commitment from stakeholders and decision-makers.
Question: In one of your paper you introduce the “proof point” concept for Agile adoption. What is it and how does it work?
Answer: A “proof point” is a live case study or feasibility project that showcases that Agile will work in the organization. It is showing “proof” that this transition can be embraced and successful within an organization. Once the organization makes the decision to give Agile a try, it is critical not to turn the implementation into a “big bang” project. Instead the organization should select a small (and relatively easy) project from its “innovative projects portfolio” and build a team to execute the project. This will require assigning the right project manager (PM) and the most experienced team members to the project. Once the team has been formed, it goes through formal training to learn about Agile and executes the project in an iterative manner using Agile methodologies led by the PM with the help of the project sponsor(s). As the project progresses, the team and the organization conduct “Reflection Workshops” to assess the maturity and improve the team and the organization’s capability to execute Agile projects. Over time, the organization can use the lessons learned to build more teams and execute more projects using the Agile framework.
Question: You wrote in one of your articles “There’s no reason why an Agile approach cannot have a Gantt chart if managers or stakeholders request one – as long as it’s made clear that the chart will only schedule out as far as the iteration or release currently being built.” If you are trying to introduce Agile in a company, how far can you be flexible to this type of requests and when should you negotiate with or educate your stakeholders, saying “no, if we want to be Agile we don’t do this”?
Answer: Being flexible and nimble is the core of Agile and the level and the type of documentation are dictated by the sponsors. However, each time a request comes in that is quite similar in nature to a traditional project deliverable, as an Agile team member, the responsibility of the team should be to not blindly accept it, but to gently question and understand why the request is being made. What information or lack of information is generating this request? Typically, the answer to these requests and questions will lend itself to not allow for this type of change to occur, but rather, it will help educate and refocus on the value that Agile brings.
Question: You wrote that feedback, communication and motivation are the key for successful collaboration among the team. How to foster these values when you try adopting Agile in large or distributed project teams?
Answer: High performing teams rely heavily on open communication, feedback, and motivation. To allow for this in Agile teams that are distributed or collocated, it is imperative that the teams commit to conducting iteration retrospectives, release retrospectives, and project retrospectives. During these retrospectives, it is important that the facilitator and project leader allow the team members to improve upon the Agile process and approach that is being utilized. In doing this, the team feels entrusted, accountable, and committed to ensuring that subsequent work is delivered “better and faster.”
Author biography: Nancy Y. Nee, PMP, PMI-ACP, CSM, CBAP, VP, Global Product Strategy, ESI International, guides clients in the development and implementation of learning programs customized to their specific needs. A recognized expert in Agile PM and SCRUM, Nancy also brings strong experience in strategic enterprise architecture, project governance, business process analysis, continuous process improvement and automated solutions to her engagements. www.esi-intl.co.uk