Agile practices have been around a long time, even before they were formalized in the Agile Manifesto https://agilemanifesto.org/ (2001). They promise to accelerate value delivery, reduce risk, and better adapt to change. The majority of companies I work with have either adopted Agile practices or are in the process of doing so. They realize that adopting Agile throughout the organization is key to becoming more competitive in the marketplace and faster at responding to changing customer demands.

However, while there are many reasons why Agile transformations struggle to take off, the lack of proper product thinking is often a likely culprit. In fact, even the best Agile teams cannot deliver much value if proper product visioning, prioritization, roadmapping, and validation practices are not in place or properly followed. Instead, Agile gets the blame and teams become resistant to change.

Where Agile fails

For all its benefits and — let’s be honest — hype, Agile is not the medicine that cures all illnesses. Here are four situations where I’ve seen Agile fail:

1) Just take half of the pill

Just “doing” Agile doesn’t mean necessarily “being” Agile. And this is an important distinction in terms of empowerment, culture, organization, customer focus, engineering practices, and reaction to failure. “Doing” Agile often results in teams adopting the practices but not understanding the principles behind them. For instance, they may adopt Scrum, work in 2-week sprints, do daily standups, and hold a retrospective at the end of the sprint. At face value, they are “doing” Scrum, but everything else in the product planning, validation, and delivery stays the same, the way that company has always operated.

As a result, the ”Agile” team may not see the benefits it expects, or it may feel as burdened as before. Often, these teams go through the motions of Agile without really adopting the mindset or the principles.

One example: a development team I recently worked with was given a list of work items at every sprint by their product owner, and that list was always at least twice the capacity of the team. The reasoning was, “better give them more work and getting something as a result, than have them slack”. From the developers’ perspective, they struggled with choosing what to work on and what to skip, multitasking their way through the sprint, and adjusting to a continuous change of priorities. The team members were not empowered, the culture didn’t support trust, and the work was mainly push-down execution focused. The end result? Nothing to show after several sprints of work.

I’ve written about “doing” Agile versus “being” Agile other times in the past https://www.5dvision.com/post/being-agile-versus-just-doing-agile/ Companies that adopt Agile half-heartedly try to “do” Agile but often struggle with the inevitable changes that are required for a transformation to be successful, and with the problems that inevitably Agile brings to the surface and need to be solved. Agile in itself is not the solution. A deeper change is needed to reap the benefits of agility and it often starts from changing the mindset and how the organization approaches work. This is usually where Agile coaches and effective Scrum Masters can help in driving a real transformation.

2) Management commits only to a half-hearted adoption

Sometimes a company is required to adopt Agile practices because of market forces. For example, a key customer demands that all suppliers adopt the same practices — these could be Scrum, SAFe, or others. The company then makes an effort at adopting Agile, often by training large portions of the organization and by establishing Agile teams. Yet, this is often a half-hearted adoption, as the mindset and the overall processes of managing work are not really affected.

A symptom of this brings to light a misunderstanding of what Agile is really about: I’ve heard senior leaders say, “I don’t want to adopt Agile because it gives my team the right to do what they want, whenever they want it”. And when these leaders are forced to become more Agile, they inevitably do so half-heartedly, hoping that the “wind” will shift soon in a different direction.

Instead, leaders should embrace the Agile transformation as an opportunity.

Instead of changing the whole organization at once, select a small target group and infuse a culture of agility there. Give proper direction in terms of vision, priorities, and objectives, then let the team members self-organize how best to do the work. Establish transparency throughout the process, including feedback loops with stakeholders. Inspect and adapt frequently, and provide the support needed for the team members to succeed. Once a small group reaps the benefits, sustain the momentum by expanding Agile practices to other groups.

3) Scrum is used as a slicing mechanism

This scenario is scary, not because it’s evil, but because it shows good intentions that are put into action without proper understanding of product development principles.

A couple of years ago a large US bank embarked in a modernization project to replace its 20+ year old legacy system with a modern Salesforce platform. Its teams spent more than six months documenting in excruciating details all the requirements and features of the legacy system that needed to be ported to the new platform. Then they estimated the amount of work at 12 months, set a deadline, and promised a delivery date to the senior management.

At that point they handed off the requirements to engineering. The engineering teams adopted Scrum and sliced the work in 2-week sprints. At the end of each sprint, the teams held a sprint review with the key stakeholders, demoing the work increment, and receiving feedback. Then the teams set off to work on the next slice of the requirements. They were building the whole product incrementally, one slice at a time.

The whole product had already been planned and detailed upfront, and the engineering teams were required to do what the plan specified. Scrum was considered a slicing mechanism to deliver the work. There was no concept of validation of functionality based on user needs, of adaptation of the plan based on what the team had learned throughout the process, or of prioritizing the backlog of work so that high-priority items were completed early and higher value could be provided to the users faster.

Everything had the same importance because, well, everything had to be built. In reality, this was a big waterfall project masqueraded as “Agile”. Unfortunately, it failed miserably when the 12-month deadline arrived and the system was only half built. The plan did not account for a partial delivery and validation, and the teams had to complete the entire product before releasing it to the users.

4) Forget the big picture

When an Agile team works repeatedly on the same product sprint after sprint, its main focus becomes execution, getting the next set of features done and out in production. While this focus is great, the danger is that the team becomes shortsighted and loses context of the big picture: Why is the team building the product? Why is the next set of features important for the customers? Why should the team continue building this product instead of something else?

In order to answer these questions and elevate the views of the Agile team, it’s important for the Product Owner to understand and uphold its role within the team. The Product Owner should continually provide the context the team needs to understand where the product fits within the larger vision and strategy; should invite the team members to do “gemba walks”, meet customers, and learn directly from them about needs and pain-points; should manage the backlog with a critical eye, not focusing on just execution, but also in discerning if the team’s energy would be best spent on working on something completely different.

A Product Owner I know makes the point of reviewing the product’s vision with the team every sprint, to keep it fresh in everybody’s memory and align their work to the bigger objective.

Shortcutting Agile is not the solution

If you do an online search today, you may find articles that state that companies have reached agile maturity or that they don’t need Agile anymore. Some of these companies refer to the speed at which they can deliver new products as a testament to their maturity.

No-code platforms like Unqork, Airtable, Salesforce, WordPress, and many others, speed up the development process and make it easier for business people (rather than technical people) to build business applications. Salesforce invented the cloud and pioneered the concept of a pre-made platform that was easy to customize with just business logic and no coding. WordPress allows anyone to build a website by using drag-and-drop modules rather than hard-coding HTML, CSS, etc. Unqork and Airtable let business users create applications and digitize business processes in a simple and fast way. All this is great.

But even if we can build a product faster, how do we know if what we are building is the right product?

Building the right product is not the same thing as building the product right. Whatever minimum investment we are making, we are still spending time, money, and resources into building something.

By bundling Agile and Product Thinking, we get the practices and mindset to maximize the value of our investment and deliver a product that customers want.

Even the most powerful platforms require some technical work for customization and support of specific use cases. Also, I would argue that faster development cycles don’t allow abdicating the need for proper understanding of what needs to be done and what needs to be prioritized. You can build things faster, but if you don’t deliver what users need, your product is destined for the trash bin anyway.

Agile principle #7 states that “Working software is the primary measure of progress”. So, if a team can deliver working software in a faster and easier way, that’s all additional value delivered. You may be working at complex custom system integration or at a simpler no-code implementation of a new business application. By using no-code or low-code platforms whenever suitable, development teams can speed up the process and provide value to their customers faster. These benefits are important regardless of the technology stack you are employing.

By using Product Thinking practices throughout the development process the team can create transparency, shorten the feedback loop, and improve the quality of its deliverables. These practices span technology and platform boundaries, supporting the team in building the right product and delivering value to the customers. Without these objectives in mind we risk building the wrong thing or limiting the value we deliver.

It’s all about Product Thinking

As stated above, a blind application of Agile won’t cure all illnesses. Even the most faithful agilist who diligently executes the practices, will have a hard time reaping the benefits and delivering value to its customers, if the right Product Thinking mindset and culture is not in place. A development team cannot do it alone. The organization must provide the culture, the vision, the empowerment needed for success.

I recently was asked to help a large team who was building a strategic digital platform the company direly needed. The team was hard working, putting long hours and solving big problems. But the leadership kept changing the overall vision for this product, and with it the priorities of what to build. For the team is was difficult to focus and getting anything completed before the next change happened. After months of development, they had nothing to show in production.

The problem was not with poorly adopted Agile practices. The problem was with poor product practices that didn’t support the application of important principles needed for Agile to flourish.

You may get away with poorly implemented Agile practices, but if you don’t have the right product practices you may be wasting your investment or be doomed from the start.

Infusing an effective Product Thinking mindset is key to the success of a product initiative and to an Agile transformation. Therefore, I always spend as much time working with teams and their leadership in adopting the right product practices as I spend on Agile practices. I make sure that organizations understand the importance and value of having a customer-centric approach, that they understand the customer needs and what benefits the new product would deliver to the end-users.

The product team should spend the majority of time in discovery mode, talking with stakeholders and end-users, testing prototypes, refining ideas. This is true not only at the beginning of the project, but also throughout its development.

The market always knows about the job-to-be-done by your product more than you do. Ultimately, the market is the one that decides if it needs the product or not, so it makes sense to learn from it as quickly as possible.

Understand what job the market needs your product to do. What problem the customers have that they cannot find a good solution for. Validate your hypotheses with real users, get feedback from them, and measure the outcomes.

Once you identify a solution, use ruthless prioritization to maximize the value delivered and to give your teams the focus needed to complete the work. Instead of making a big upfront plan and using Scrum to build one slice at a time, map out the most critical features your customers need, and build an MVP (Minimum Viable Product) to validate the solution as quickly as possible. Learn what works and what doesn’t, and then iterate on the plan with the next set of features.

Like a tree, to grow healthy and bear fruit, it needs the proper roots. Adopt and support effective product practices and your Agile transformation will flourish.