If Agile fails, blame Product Management

Agile practices have been around a long time, even before they were formalized in the Agile Manifesto (2001). They promise to accelerate value delivery, reduce risk, and better adapt to change. The vast 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. While there are many reasons why Agile transformations struggle to take off, the lack of proper product management is often a likely culprit. In fact, even the best Agile teams cannot deliver much value if proper product visioning, backlog refinement, prioritization, roadmapping, and discovery practices are not in place or properly followed. Instead, Agile gets the blame and teams become resistant to change.

Agile planning in a development team is strengthened by Product practices

It’s all about managing the product

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 management 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 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 the organization understands the importance and value of having a customer-centric approach, that it understands 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 more about your product 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. Validate your hypotheses with real users, get feedback from them, and measure adoption metrics. Use ruthless prioritization and respect the priorities you set 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 Agile practices to deliver that plan one slice at a time, map out all the features you’d like to build, identify a subset, and build an MVP (Minimum Viable Product) that you can bring to market as quickly as possible. Learn what works and what doesn’t, and then iterate on the product 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.

Short-cutting Agile is not the solution

If you browse the world wide web you can find dozens of articles describing would be solutions in making Agile work or getting rid of it altogether. The most recent one I read was “Agile has failed” from the CEO of Unqork. Besides the not-so-subtle marketing push of his platform, he argued that with modern SaaS tools there is no need for Agile anymore because things are faster. We don’t need to inspect and adapt anymore because we are just soooo fast in building things.

But even if we can build a product faster, how do we know that we are building the right product? Whatever minimum investment we are making, we are still spending time, money, and resources into building something. Agile and Product practices give us the guidelines and the boundaries to maximize the value of our investment and deliver a product that customers want.

No-code platforms like Unqork, 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 lets business users create applications and digitize forms in a simple and fast way. All this is great.

However, 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 a 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 Agile practices throughout the development process the team can create transparency, shorten the feedback loop, and improve the quality of its deliverable. 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.

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 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, and yet they may not see the benefits they expect, or they may feel as burdened as they were 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. Companies that adopt Agile half-heartily 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) Half-heartily 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-heartily 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-heartily, 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) Slicing mechanism

I like this one, 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 I worked for 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 Agile (more specifically, Scrum) and sliced the work in 2-week sprints. At the end of each sprint, they held a sprint review with the key stakeholders, demoing the work increment and receiving feedback. Then they set off to work on the next slice of the requirements.

Agile practices were just a slicing mechanism and were a way to deliver the work. The whole product had already been planned and detailed, and all engineering was required to do was building it — exactly as specified. There was no concept of discovery of new user needs, of adaptation 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 was provided to the users. Everything had the same importance because, well, everything had to be built. It was a big waterfall project masqueraded as Agile and it failed miserably when the 12-month deadline arrived and the system was only half-built.

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; they should invite the team members to do “gemba walks”, meet customers, and learn directly from them about needs and pain-points; they 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.

About the author

Valerio Zanini is the CEO of 5D Vision, a company that helps organizations spearhead their Product and Agile practices through training and hands-on coaching. He’s also the author of “Deliver great products that customers love” and the co-author of “Sprint Your Way to Scrum”. Valerio lives in Washington, DC and travels worldwide.