There’s nothing like starting a new job at a big company that you thought was Agile. And then find out they’re not Agile.

Not only that, but they don’t even realize that they’re not Agile!

It’s like the twilight zone every day trying to explain to clueless leaders what real Agile is, how they’re coming up short, and a plan for how they can achieve true Agile. The problem is that leaders only see big dollar signs when you explain the time & effort needed to become Agile, and then they decide it’s not worth it because “the current process is fine.”

Of course they say it’s fine because leaders don’t see any of the problems at the product team level. Often leaders are the big beneficiaries of this fake Agile process, because when Agile falls apart leaders will just go back to telling everyone what to do, how to do it, and when they want it. They love doing this! It’s very empowering for them to feel needed, even though it’s completely misguided and micromanaging at it’s worst. And some leaders think this is actually Agile, but in reality it’s a bad form of Waterfall chopped up into sprints to give the appearance of Agile.

In order for you to fight for the good of Agile, I’ll share the common signs I’ve seen over the years to help you determine whether your organization’s version of Agile is real or fake. But first let’s start by defining what Agile actually is…

Agile Defined

Let’s start by defining what Agile actually is. In my previous post on Agile, I defined it at a high level as:

“a methodology for developing software that delivers potentially shippable working code in short iterations, while providing the flexibility to manage uncertainty and adapt to changing requirements. It works by breaking software projects down from large feature sets into smaller bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two-week iterations called sprints. Analysis, design, coding, and testing are continuous activities that continue for the duration of the project. The primary measure of success at the end of each sprint is working software. And the rate at which teams can turn their customers’ wishes into working software is how Agile practitioners measure productivity.”

From a historical perspective, the Agile methodology was designed as a solution to circumvent the pitfalls associated with Waterfall, i.e. the de facto software development process for the first 60 years of software engineering. The primary benefits of using Agile over Waterfall include greater ROI with incremental return, faster time to market with greater adaptability, greater visibility, and higher quality.

Being a more flexible management framework, Agile allows teams to bypass traditional sequential paradigms and get more work done in a shorter time period. The Agile manifesto – outlined below – guides all Agile methodologies:

Now that you understand what real Agile is, I’ll help you spot fake Agile in your organization by listing some of the clear signs below…

Fake Agile Sign #1: Unsupportive Leadership

Lack of Leadership and/or Financial Commitment: A fundamental pillar of Agile is strong leadership support, both financially and strategically. In fake Agile environments, there’s often a glaring absence of leadership commitment. Many leaders hear the horror stories of digital transformations leading to millions in wasted capital, and often are not bought into Agile as a mechanism for positive transformation. Instead, leaders want the “light” version of Agile where they’re unwilling to pay for the necessary training and certification of their teams.

Or worse, if a leader is willing to pay for the training and certification, then the key leaders will often forgo most of the training thinking they know it all by reading an article or viewing an Agile presentation. This can be disastrous because the leader’s role changes drastically, and if they don’t know what to do in this new Agile world, then they’ll be a blocker to the whole Agile transformation as they continue to implement top-down policies while disregarding the customer-centric process.

In these scenarios, the absence of leadership support results in a disconnection from the core values of agile development.

Not Knowing the Customer and/or Not Prioritizing the Right Customer: Agile is inherently customer-centric, with a focus on delivering value to end-users. With fake Agile, leaders may lack a clear understanding of who their customers are or may prioritize the wrong customer. For example, I’ve seen many leaders focus on key stakeholders as the “customer” while completely ignoring the actual end users of their products! While it’s important to ensure your stakeholders have a voice in the process, you should never elevate their voice above that of your customers’ needs. This leads to misguided development efforts that do not align with the actual needs of the market.

Fake Agile Sign #2: Little Testing or Customer Feedback

Lack of Discovery: Genuine Agile thrives on continuous discovery, understanding evolving customer needs, and adjusting development accordingly. In the world of fake Agile, this continuous discovery is often neglected, resulting in products that miss the mark. Teams may find themselves building features that end up being irrelevant or unappealing to users.

No Dual Track Discovery + Development: Successful Agile development integrates dual-track processes, combining discovery and development to ensure a seamless flow of ideas and improvements (see graphic below). In fake Agile environments, this integration may be absent, leading to a disjointed development process that fails to incorporate valuable insights gained during the discovery phase.

Lack of Testing and Data Quality: Testing is a fundamental aspect of Agile development, ensuring that products meet quality standards. With fake Agile, testing may be sacrificed to expedite the development process, resulting in subpar products. Additionally, poor data quality or the absence of meaningful data can undermine informed decision-making, hampering the iterative nature of Agile.

Lack of Continuous Integration and Continuous Delivery: Continuous Integration and Continuous Delivery (CI/CD) are vital for Agile teams to deliver increments regularly. Fake Agile implementation may lack the infrastructure or commitment to implement CI/CD practices, slowing down the development cycle and impeding the ability to respond swiftly to changing requirements. Deploying a few times a year is not Agile, where you should be deploying every sprint (at a minimum).

Fake Agile Sign #3: Misaligned Resources

Project Managers (PJM) Converted to Product Managers (PM): In fake Agile setups, there’s a tendency to cut corners on crucial resources. One glaring example is at the outset of implementing Agile within existing organizations, where Project Managers (PJM) are converted into Product Managers (PM). These are completely two distinct and separate roles, where PJMs are largely focused on timelines as the measure for success, whereas PMs are focused on revenue, innovation, and meeting customer needs. Sure, some PJMs can handle the step up into this extremely important role, but most are not properly trained or have the right skills to do it well.

Lack of a Dedicated ScrumMaster: A ScrumMaster plays a pivotal role in ensuring the proper implementation of Scrum practices. Another example of fake Agile that I’ve seen is the lack of a dedicated ScrumMaster, with Product Managers (PM’s) often being thrust into the ScrumMaster role they aren’t adequately trained for while also forcing them to do two roles – usually for the price of one! This compromises the effectiveness of the Agile framework, as PM’s may not fully grasp the nuances of Agile principles and can lead to lots of wasted time and money, even failed products.

Lack of Design Integration: Design integration is crucial for delivering user-friendly and aesthetically pleasing products. With fake Agile, designers may be sidelined or forced out of a typical design process, resulting in products that lack the user experience finesse that Agile development is designed to deliver. I’ve even seen teams try to utilize design in an agency model, separating them completely from the development process and simply throwing requirements over the wall and expecting designers to deliver without allowing them to engage with the customers directly. This is a horrible idea and will destroy products and product teams quickly. You should respect the Agile triads for every product team, and ensure there’s leads for each of the three main disciplines of PM, Design, and Engineering.

Fake Agile Sign #4: No Clear Strategy or Focus

No Product Strategy: A well-defined product strategy guides development efforts, ensuring alignment with business goals. In fake Agile environments, the absence of a clear long-term product strategy can lead teams to focus on leaders’ random short-term ideas and/or stakeholder needs. I’ve seen this firsthand, where it slows product teams down considerably so that leaders can gain alignment on a “mini-strategy” for every project or feature. It’s exhausting working like this, and it often leads to aimless development, where teams lack a cohesive vision and struggle to prioritize features that truly matter.

Ideas Only Come from Execs/Leaders: Agile thrives on collaboration and input from all team members, where the best ideas truly come from anyone. In the world of fake Agile, ideas may be dictated solely by executives or leaders, stifling the creativity and innovation that emerges from teams that (should be) well connected to the end customers and often have deeper market and customer insights than leaders. Obviously leaders don’t want to admit this, but it’s easy to keep them in check by asking “how many customers did you talk with this week?”

Focus on Output vs Outcomes: Agile emphasizes delivering outcomes over mere outputs. Teams that practice fake Agile may be forced by leadership to prioritize the quantity of features delivered rather than the impact these features have on end-users. This focus on output undermines the core Agile principle of delivering value to customers.

No Opportunity Backlogs: An Agile backlog is a dynamic tool for prioritizing and organizing work. In fake Agile scenarios, the absence of a well-maintained opportunity backlog can result in chaotic development, with teams struggling to prioritize tasks and respond to changing requirements effectively. This is a clear sign that the product team is taking direct orders from leadership instead of developing opportunities based on understand their customers.

Fake Agile Sign #5: Misguided Values

Practicing a Methodology Without Adapting to Its Values: Perhaps the most detrimental aspect of fake Agile development lies in the misalignment of values. Organizations might adopt Agile methodologies as a mere checkbox exercise without truly embracing the cultural shift that comes with it. The result is a superficial adherence to Agile practices, devoid of the collaborative and adaptive spirit that defines Agile development. This often leads to frustration among team members and a failure to reap the benefits of true agility.

In fake Agile environments, leadership may be absent or unwilling to fully commit to Agile principles. This lack of commitment manifests as a disregard for Agile practices, creating a breeding ground for inefficiency and frustration among teams.

Conclusion

Agile product development has emerged as a transformative methodology, promising flexibility, adaptability, and customer-centricity. However, the market is witnessing a surge in instances where organizations claim to follow Agile principles but are, in reality, engaged in a deceptive dance of what can be termed as “fake Agile.” This deceptive practice often stems from a combination of factors, each contributing to the dilution of Agile’s core values.

In my 25 year career working at organizations of all sizes – from startups to large international corporations – I’ve learned that it’s easy to implement Agile at a startup with a dozen or so workers, but it’s much more difficult to implement at large enterprises. Unfortunately I’ve seen most large companies attempt to adopt Agile in some form and then work to evolve their Agile framework, but this often leads to the death of the product/platform – and sometimes even the organization! – by a thousand cuts.

The key difference between success and failure lies directly with leadership. The most successful organizations are the ones where leadership truly buys into Agile where they view the cost as an investment (vs sunk cost) that will pay off in the future. This mindset enables a large organization to fully adopt Agile within as little as 6 months! Incompetent leaders view Agile as a small shift in the IT process, but in reality, it’s a whole new philosophy for the entire organization. Leaders must embrace this new mindset – while recognizing these pitfalls of fake Agile – and commit to a genuine adoption of Agile principles to truly reap the benefits of this transformative methodology. The road to authentic Agile is paved by true leaders who fully commit their organizations to continuous improvement, collaboration, and a relentless focus on delivering value to the customer.