Over the years, I have been exposed to several “Agile transformations” within the private and public sectors. I had the honor of leading three of these engagements since 2006. Without getting into a detailed conversation regarding my views on Agile, it would suffice to say that I believe Agile has certainly become the buzzword of the decade with many organizations experimenting with it (in their own unique ways) and many employees (or hope-to-be employees) listing it on their resume. While I see a lot of potential in the use of Agile methodologies, tools, and techniques, I strongly believe that there is a right time, approach, and place for the use of this framework. Many organizations today are displaying an increased appetite and desire to be Agile for a wide variety of reasons, ranging from, changing customer needs to past project failures and sometimes, just a general drive to go after ‘that shiny thing everyone seems to be doing/trying to do’. While most of the time, the decision to implement an Agile framework in organizations is driven by noble intent, it is rarely handled and implemented in the right spirit. Here is a list of three common challenges that I have repeatedly seen with organizations trying to rollout Agile methodologies:

Challenge 1: Lack of Buy-In and Support

Employees do not support the rollout of Agile in their organization, and make every effort to resist and in some cases, sabotage the deployment.

Why? While the literature positions Agile as a methodology that relies on self-managed teams that are highly collaboratively and are given the autonomy to make key decisions, this is rarely how organizations deploy it in practice. Unfortunately, the decision to transform to Agile is usually mandated by management, and then the execution is supported by consultants over a short period of time (6 – 12 months) using a ‘carrot and stick’ model – get rewarded for doing what we tell you to do or get punished for not doing so. This is incongruent with the spirit of Agile and builds resistance among employees right from the beginning as they feel threatened by the change imposed on them. This is not because employees are malicious by nature or they do not want the organization to succeed; in fact, they are afraid of uncertainty and feel that their existing skillset is rendered useless by this decision. In one extreme case, I found that employees would manipulate the physical Scrum boards in the office, and take off sticky notes to highlight the ‘vulnerabilities’ of Agile-Scrum. In another case, I had a Project Manager completely blackout while walking me through his Sprint Backlog as I asked a question; he excused himself to go look at his Microsoft Project Schedule to answer my question. Apparently, he felt that he had to create Scrum deliverables to satisfy the MANDATE, but was managing the project using Waterfall in the background. Potential Solution: There is no one size fits all solution for this; it depends on the organizational culture and context. That being said, I have realized the optimal value in building support for Agile adoption at the grassroots level – while it is important to have the support and buy-in from the leadership, it is also critical to make sure that the employees understand the need for change, show desire to change and finally embrace the new process or methodology to implement the change. This can be time-consuming, but guess what, you are dealing with people. If you want them to change the way they work, you better involve them in the change rather than impose it on them.

Challenge 2: Negative Perception of Agile

There is a negative disposition towards Agile – Agile is seen as a chaotic methodology that allows project team to make decisions on the go without any regard for scope and timelines.

Why? Due to “bad” implementations of Agile in MANY organizations, employees have started to resent this term altogether. In many cases, they are forced to use it, but they neither believe in the value nor do they apply it correctly. To each organization, Agile means something different – I have seen many variations over the year; use of user stories (by BAs at their desk), implementation of work in 3 month iterations and replication of Waterfall work breakdown structure on sticky notes. I have been teaching a course on Agile Methodologies for many years, and have had well over 200 students take the course. Over 50% of these students expressed some negative experiences with Agile. Among many things, Agile is associated with ‘no documentation required’, ‘no change management’, ‘scope creep is okay’, ‘no issue or risk management’ and ‘flavor of the month’. These students took the course because they were either asked to do so, or they genuinely wanted to see if Agile is what their organization is currently “doing”. Potential Solution: It can be challenging to change people’s negative disposition towards Agile, but one powerful tool towards driving and maximizing value is to drop the buzzword “Agile”, and simply provide people the (Agile) tools and techniques to address their pain points; show quick wins and successes along the way – pace yourself and roll out what’s needed and when it is needed rather than all or nothing mindset. Maybe, all that employees need right now are frequent retrospectives; maybe, they need better visibility into their work (Kanban); perhaps, they could ditch long weekly meetings for 15-min daily stand ups. Get them started, show them value and they will come to you for more …

Challenge 3: Lack of Patience for Results

Agile is assumed to be the silver bullet that will magically fix all organizational delivery problems, in NO TIME. There is very little patience, high expectations and absolutely no tolerance for a negative outcome.

Why? Many organizations look at using Agile methodologies after experiencing some sort of a disaster. It is not uncommon for organizations to go after Agile when their flagship project fails to deliver, or is unable to meet customer expectations. All three Agile transformations that I led originated as a result of a major setback experienced by respective organizations; these setbacks ranged from inability to deliver on time (or on budget) to customer dissatisfaction and complete project abandonment. While it is fantastic that the organizations reflect on their failure at this stage, realize that something needs to change and take the leap of faith to try something different (Agile in this case), the execution beyond this point is usually botched. Typically, the decision is made to use Agile (a new methodology that no one fully understands) on the next MOST CRITICAL project with absolutely NO TOLERANCE FOR FAILURE. As you can tell by now, this is a recipe for an even worse disaster. Essentially, the people impacted by the change are not involved in the decision, and are rushed to learn and use the new methodology PERFECTLY so the organization can deliver successfully this time around. Potential Solution: It is important to understand and appreciate that there is an organizational change involved with the use of Agile methodology; it is a fundamentally different way of working – everything from management of projects to team leadership needs to change. Guess what? Changes need to be managed, especially when there is an impact to your employees. Just like any new technology requires time in R&D, you need to allow time for employees to first ‘embrace’ this change and then to learn and apply it. You also have to be open to them failing at this methodology once, twice or even more – in fact, this may not even be the right methodology for your organization but you will only find out if you allow sufficient time for experimentation. How can you expect people to be PERFECT at something they have never used before … the first time around? To be truly successful at an Agile implementation, you need to start off in a safe environment to provide employees soak time to learn and use the Agile toolkit prior to applying it on mission-critical projects. While this is not a comprehensive list of challenges associated with Agile transformations, I have certainly seen these three come up repeatedly in different organizations. What are your thoughts and experiences?