Will your Agile Transformation be an Epic Failure?
Author
March 2, 2017
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.
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.
Pranshu Goyal, Director of Products at Mirekta, states: “We envision DSM to be used by every small to a medium-sized organization dealing with bad data and want to get rid of duplicates easily with no cost. We have faced issues dealing with duplicates in our organization. That inspired us to make a solution that is not only simple to use but can be used widely to make the organization’s data clean to make them more efficient and productive. We want DSM to be a solution for every organization looking for duplicate management capability better than the Salesforce out-of-the-box solution with no additional cost.”
Recent Posts
-
Salesforce 2025 Game-Changing Trends You Need to Know28 Jan 2025 Blog
-
Agentforce 2.0: Everything You Need to Know About the Latest Update22 Jan 2025 Blog
-
The Ultimate Guide to NetSuite Development: Tools and Techniques10 Jan 2025 Blog
-
How Salesforce Nonprofit Cloud Transforms Fundraising Strategies10 Jan 2025 Blog
-
The Impact of Salesforce Development Partners on Small and Medium Businesses08 Jan 2025 Blog
-
Key Questions to Ask When Hiring a NetSuite Development Partner08 Jan 2025 Blog
-
Salesforce Agentforce Demystified: Your Essential Guide08 Jan 2025 Blog
-
Salesforce and NetSuite Integration: Driving Business Efficiency with Precision06 Jan 2025 Blog
-
Everest Group has positioned Mirketa as an Aspirant in the report24 Dec 2024 Press Release
-
Salesforce Einstein20 Dec 2024 E-Book
-
Order to Cash Cycle with NetSuite20 Dec 2024 E-Book
-
Empower Your Marketing Strategy with Salesforce Marketing Cloud's Automation Studio Activities13 Dec 2024 Blog
-
Salesforce CPQ for Subscription-based Businesses10 Dec 2024 Blog
-
Unleashing the Magic of Einstein Prediction Builder10 Dec 2024 Blog
-
Customized Templates and Branding with Salesforce Experience Cloud10 Dec 2024 Blog
-
Unleashing the Power of Real- Time Reports and Dashboards in NPSP10 Dec 2024 Blog
-
Top 4 Salesforce Automation Tools in 202409 Dec 2024 Blog
-
Salesforce Service Cloud Implementation: The Ultimate Guide09 Dec 2024 Blog
-
Salesforce CRM Implementation Partner Enhancing Automation in Healthcare09 Dec 2024 Blog
-
Shorten Your Sales Cycle in 8 Steps: Salesforce CPQ Implementation Guide09 Dec 2024 Blog
Categories
Featured by












Office Locations

11501 Dublin Blvd STE 200, Dublin, CA 94568, USA

B-4/5 First Floor, Sector- 63, Noida 201301, India
