Agile died while you were doing your standup

As technology professionals, we have been stuck at metaphorical basecamp for years. We’ve looked at the summit, attempted the various routes other teams have created, and worked hard on dialling in the basics of making sure we have food, water, and shelter.

We have gone from wilderness survival to wilderness living. We learned the ways of the land—I would even say some have perfected this way of living. But in order to make progress toward the peak, we must pick up our gear and tackle the next part of the climb. It is painful, in some regards. The knowns have helped us find stability; allowed us to confidently work through challenges and find solutions. But now it’s time to move forward. We’ve been at basecamp too long.

Despite the successes Agile has brought us, it’s time to take the things we have learned from Agile and move on. Like the technology we use to build the products we love ages and gets left behind, Agile has died while we were perfecting our standup. In this post, I’ll explain why.

Working in a post-Agile world

I’ve had a lot of people ask me, “Why are you writing this?” Big companies have spent millions investing in these practices in a heroic effort to modernize the way they develop products. Personally, I can’t stop thinking about the pain that this new reality— the one that comes after Agile—is going to cause a lot of enterprise companies. But someone needs to, or we are going to keep maintaining the status quo at basecamp, and not set out to climb to new heights. Because behind those big companies are the things that matter most; the people. And they crave the challenge of the climb.

We are in the midst of an awakening. An awakening so big that it will create a ripple through how executive teams, boards, and organizations will consider approaching products for years to come. Some will listen, but most will not. And just as the Titanic saw the iceberg, it will be too late for some to turn the ship around. Ultimately it will take them down.

For your future success, pause for a minute and create some space to think differently about what you are doing right now. All of it. Culture, people, organizational design, and your current process. Is it meeting the needs of your team and company? Is it delivering the outcomes you desire? If you are hungry for the next leg of the journey continue reading. We are in a post-Agile world and the terrain has changed. Here’s how to move on from basecamp:

Acknowledge it’s not the idea’s fault, it’s the implementation

Agile isn’t to blame for this. Rather, it’s the way it was introduced to the enterprise. Huge consultancies and one-off consultants have been paid to implement a great manifesto as a repeatable process, not taking the size, stage, growth, culture, and capabilities into consideration. Everyone got the same implementation. Despite a step in the right direction, these practices fade away if they are not imbued with the context of the organization they serve.

The second issue surrounding these implementations is the current expectations around the business, and the attempt to mechanize teams. A shiver runs down my spine the second I see Jira open. Burndown charts galore, task flow diagrams, card throughput, developer efficiency metrics…come on! We are building and creating a product. Respect the craft a little. We are creators. You can build and ship a product, but to ship an experience that has a deep, long-lasting impact requires massive creative thought.

The road from basecamp starts with moving away from a specific process and instead aligning around an outcome. I still walk into companies today and hear “My engineering teams don’t ship fast enough,” or, “What they are shipping is a pile of things that don’t work together technically or as a solution for the customer.” The root cause of this is how the teams are organized.

Read how overengineering can kill your product. 

Today, most teams are strategically pointed at delivering outputs rather than achieving outcomes. It’s time to change all that by aligning teams for direct connection to a shared mission/vision and the strategy it serves. At its core, the implementation of Agile is a very output-driven process; how much can we get out the door each quarter, twice a year, or in a sprint. This is the destructive thinking keeping us from leaving basecamp. It all needs to be blown up. Continuous discovery and delivery around an outcome is the road forward.

Realize the way we are structured keeps us from adapting quickly

Agile did a great job in creating the need for customer collaboration and influencing the way we build software. But the way the information we gathered from customers was communicated in Agile stifled its ability to empower teams. We built “Scrumfall”. We still get a list of requirements and have project managers and scrum masters drive shipping outputs in a process we call “sprints,” mostly in two-week intervals.

Customer insights come from matrixed user experience or product management teams to help us understand the customer context a little deeper, but are still separate from the engineering team. And without allowing the engineering team to see, feel, and hear what is occurring for users on a daily basis the impact of the insights lose their power. This matrix structure keeps the teams from co-creating and removes the ability to solve problems and adapt the solution quickly.

To continue your journey forward, realize that the matrix is dead. Reorganize your product management, user experience, engineering, dev-ops, and whatever your company’s core competency is into one team, one mission, under one leader. Give it complete autonomy with accountability. I still see a lot of egos out there in the C-suite over who owns the “how,” the “what,” and the “when.” It’s time to let it go. Embrace the Experience Organization, and then build teams within it. The old matrix design is not in the best interest of the business or the customer. Read how to navigate tricky work relationships. 

You need small, cross-functional, co-located teams who have autonomy and accountability. These teams can discover and deliver a product solution to the customer as often as the team likes. This is how you connect the heart and soul of the company to your customer—it fuels passion and desire to solve those problems. Additionally, it teaches a team to work together and most importantly, empowers your teams to ship a shared outcome at a very reasonable pace. Velocity and accuracy are all but guaranteed.

Embrace the most important ingredient: Discovery

Discovery work is relatively new to our world in the context of developing products. Simply put, Discovery allows the team to continuously bring the customer or user to the table at the inception of the idea. This means contextual research practices such as interviewing, immersion visits, and prototype observation sessions are everyday occurrences. They allow the team to work together in increasing their confidence in an idea to deliver the best outcome to the user.

Painfully, nearly all the teams I have worked around or have inquired about (in my roughly 400 customers visits last year) aren’t involving the customer in their process at all. The ones who are, however, sit within a user experience silo where all the context is lost to the greater team. What’s more, the developers are so committed to delivery that the value in talking to customers doesn’t align with their output goals and they assume it will only slow them down. It’s not until you show them the value of listening and watching a customer use their product in front of them — then give them the power to change it and watch the impact of customer elation — that you see a monumental shift in psychology.

To help you make the final push toward the summit, I am going to humbly take one for the team by sharing my cautionary tale. If you are unfamiliar with my past, I made a massive crater in the ground (destroyed a product) by errantly building a solution for “me” not “us.” I didn’t talk to the customers who would be using and buying my product (and trust me, in enterprise SaaS, those that use and those that buy are very different from each other), and the result was a complete and devastating miss that put the company on the ropes.

When Agile entered my world I was thankful simply to see the mention of customers or users in the conversation instead of just scoping projects and pumping them through the sausage maker. Knowing your customer is everything. For the B2C commerce and digital marketing folks out there, I know you can relate to the difficulty of doing this well. Personalized commerce and omnichannel experience today depends on it. In all cases, our teams need to be doing early discovery together.

This means that at the inception of a new idea, a plus-one, or infrastructure project, all the members of the team need to be huddled around the fire having a chat about what outcome they want to achieve, who they need to be talking to, and how they are going to use this information to co-create, measure, and iterate. Once you road-test this you will see the byproduct is actionable data that empowers the team.

More importantly, it becomes one of the best tools for leadership. Seeing discovery data matched alongside shipped experiences that meet outcomes garners real trust that the teams can work autonomously (with accountability), and means you know they are shipping something that meets both company and user objectives.

Enjoy what you’ve read? Good, because there’s an entire book full of this stuff!

I’ve been working with two masters of product Richard Banfield and Martin Eriksson on writing a book that all product professionals can benefit from. Partly out of curiosity and on the back of our own experience, we’ve interviewed almost one hundred product leaders. Their insights and experiences will open up the conversation and take the lid off the mystery of great product leadership.

The Product Leadership book is being published by O’Reilly and will be out on shelves in May 2017 but you can pre-order the book on Amazon today!