For the last 20 years, I have been in the business of helping companies get better at developing software products. I started my career believing that the highly structured processes like CMM Level 5 will magically take care of the software projects woes. After two disappointing years, I moved on to the Rational Unified Process (aka RUP). After another 6-7 years of disappointments with RUP, the natural progression in my thinking and (coincidently) software development process evolution took me down to the path to Agile. My success with Agile processes has made me a believer in the process.

Image credit: Miranda Kumar (at age 8)

Unfortunately, many of the teams that start their journey towards the Agile land don’t ever reach there. Across the board, I have found some common traits in the teams that failed with their Agile transformation effort. In this article, I have shared all of them. Feel free to add more from your experience in the comments below.

Some common traits in the teams that failed with their Agile transformation effort are as following:

1. Lack of Executive Sponsorship

Agile Transformation deeply impacts how an organization functions. It is expensive and it is painful. Without visible executive sponsorship, there is no hope for Agile practices to scale and deliver the promised values. If you are a middle manager trying to drive Agile at your level, do so knowing that you may have somethings working at the team level but the complexity and pain associated with the interactions with wider organizational processes and teams will increase. And without executive commitments, your teams gradually would fall back to the old ways.

2. Wrong Transformation Drivers/Leads

Most organizations do a bad job of picking up the person(s) to manage their Agile Transformation Program. A successful PMO Manager, Development Manager, or Product Manager doesn’t necessarily make the right fit for driving the Agile Transformation program. Pick the people with common sense, good people management skills, product management and development experience, working experience in Agile Organizations, and experience in leadership roles in at least one Agile Transformation or Large organization change management.

3. Narrow View of the Transformation

Keeping the scope of the Agile Transformation limited to the implementation of the Agile practices in the old organizational setup has little or no chance to succeed. I have never seen any company achieve the promised value of Agile without including the necessary changes to Culture, Structure (Product and Team Structures), Tools, Adjacent Processes (such as Marketing, Product Management, Sales, Product Release, Status Reporting, Customer Engagement, etc) and People Practices. Some changes need to get done before the roll-out of Agile Practices, some can go along with the roll-out and some can wait until after the teams have adopted Agile.

4. We are different Syndrome

Every failed team that I have worked with told me at least once that their product and environment were not like the other companies where Agile would work. They insisted to change the core practices before even trying them. While Agile practices should be tailored to an organization’s needs, any customization before trying out the recommended practices is very likely to reduce the odds of getting the desired value. I have worked with many teams that modified Agile practices in ways that added little or no value to the end goals. In fact, bad customization lead to overheads, team frustrations, and delivery issues.

5. Tools Too Much or Too Little

Keeping the focus solely on the tools upgrades can lead an organization into the never-ending retooling business. On the other hand, not thinking about the tools or not using the right tools will lead to operational challenges. The key is to know how to plan for the right tool upgrades so it doesn’t lag too far behind and also doesn’t divert the focus away from the other critical changes that are needed. Not everything needs to be replaced/upgraded at once. For instance, you don’t need to change the source code management system from Subversion to GIT to get started with Agile Practices in a distributed team environment. There should be a tool strategy like we should have one for each of the other changes. While, you may want to replace the tools down the line, changing how we use the current tools in a different way may lead to good enough results to get the teams going with Agile practice.

6. Wrong Coaches

Many Agile Coaches that I have worked with had no experience working on software projects (as a team member), had no experience with people management and budget management, and lacked business acumen, common sense, emotional intelligence, and change management experience. Coaches that have learned it from the blogs and books beat everyone up with Agile jargon and do very little or nothing to help the team by showing how by doing it for them if needed.

Besides the required change management experience, a good coach needs to be very humble and compassionate with very good people management skills. A coach should know how the work gets done and should have good working experience on software projects as a team member or product manager.

To succeed with Agile, you need at least one coach who has experience with Organization change management and Agile Transformation in a leadership role in addition to the hands-on experience working with Agile teams.
If your current coach(s) is not able to help you make a difference in 3-4 months, then the chances are that you have hired the wrong person(s) for the job.

7. No Customer Engagement

Ongoing customer collaboration is one of the basic premises for the success of Agile Development. A common problem with the most teams that I have worked with is the lack of engagement with the end customer/users in the Agile delivery model. Getting customers to participate in the development process is hard but if you are serious about building products that your customers would love, you must figure out a way to engage them in your Product Discovery and Product Delivery cycles.

8. No Time for Product Management work

In Agile organizations, the Product Owners still need to do Concept Discovery, POCs, Roadmap Planning, Product Strategy, and other product management tasks. It is very common for Product Owners to spend almost all of their time in product delivery cycles. This may work for a project based model but it is not a sustainable model for Product Organizations. The Product Owners and a couple of key technical team members should keep sufficient capacity for the ongoing product discovery/strategy/Roadmap work and for other product management tasks. The need for an effective Product Council/Committee is vital to avoid the teams working on low priority items with twisted inter-dependencies on other teams whose priorities don’t align.

9. Wrong Metrics

The most common mistake with the Agile Metrics program is to measure too many things and measuring the wrong things. The focus should be on measuring if Agile is moving the needle in the right direction and not just if the teams are following Agile or not. Keep the focus on value and anything more than 7 metrics is too many.

10. De-prioritization of Technical Stories and Learning

Agile development requires ongoing code refactoring and constant improvements in technical environments (infrastructure and tools). When Product Owners were not so directly in-charge of the work prioritization, technical managers made sure that the due attention was given to reducing technical debts and team members were given time to learn as needed. With an inexperienced Product Owner directly managing the work prioritization, you have a strong possibility of an increase in technical debt and lack of new learning that eventually would lead to unplanned production outages and/or productivity issues.

11. Trying to Fit the Old in the New

Agile and Gated processes are fundamentally very different. Any attempt to map the old gates onto the new approach yields little or no results. I have done it to satisfy compliance and some difficult stakeholders. The mapping was never completed to anyone’s satisfaction and was hardly useful. Leave the old terms, roles, and processes behind otherwise the chances of repackaging the old into the Agile world are very likely.

12. Too much consensus building

It is important to get inputs from various stakeholders to understand different perspectives. However, it is not possible to get everyone on the same page when it comes down to agreeing on the scope and approach for Agile Transformation and on to Agile practices. Driving Agile transformation through consensuses will increase the cost, delay the change, prolong the pain, and dilute the objectives.

13. Not Ready for Change

A fairly common and an expensive mistake is to drive Agile Transformation when an organization is not ready for it. In order to be successful among many other things the following is required:

• visible executive sponsorship for Agile
• urgency and need for change is clearly communicated
• change strategy and a transformation plan with end goals
• required resources are available
• strong organization alliances are formed to support change

Starting Agile Transformation without getting the organization ready will definitely lead to the chaos and bad memories of Agile among the ones that were subjected to it.

14. No Clear Goals and Urgency

It is not uncommon for teams to leave Agile transformation as an open-ended program with no clear goals and urgency. To succeed the teams should define the tangible goals and put aggressive timelines to achieve those. Longer you make your transformation program, more expensive and painful it will be and you are less likely to succeed.

15. Overly Sensitive or Insensitive about Feelings and Needs of the team members

The reality is that not all team members will like or embrace the changes. Transformation drivers and people managers will have to make some hard decisions and implement some practices that team members may not like. Many Agile coaches and managers take the populist path and end up bringing in Agile practices without creating the culture of Accountability, Transparency, Objectivity, and Honest Discourse. I have also seen coaches align just with managers and care very little about what is good for the team. Both extremes are bad. Without having empathy towards people’s needs within and outside the team, you would end up rolling something out that is not sustainable in the long run.