Agile Died While You Were Doing Your Standup
(Cross post from Mind the Product Blog)
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 dialing 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 the 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 confidentially work through challenges and find solutions. But now it’s time to move forward.
We’ve been at basecamp too long. And despite the successes that 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 eventually ages and dies, Agile has also died while we were perfecting our standup.
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 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, without setting 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 awaking. An awaking so big that it will create a ripple through how executive teams, boards, and organizations will consider approaching product for years to come. Some will listen, but most will not. And just as the Titanic saw the iceberg, it is going to be too late to turn the ship. 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 customer, 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 manifesto as a process, not taking the size, stage, growth, culture, and capabilities into consideration. Everyone got the same implementation. Despite the step in the right direction, these practices fade away if 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 opened. Burndown charts galore, task flow diagrams, card throughput, developer efficiency metrics. Come on now. 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 deep long-lasting impact requires massive creative thought on all the teams’ behalf's.
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.
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, 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 illustrating the need for increasing 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 the matrix’d 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 actually 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 ego out there in the C-suite over who owns the “how,” the “what,” and the “when.” It is 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.
You need small, cross-functional, co-located teams with the autonomy and accountability to discover and deliver (to production) a product solution to the customer as often as the team would like. This is how you connect the heart and soul of the company to your customer. It fuels passion and desire to solve those problems. It teaches a team to work together and most importantly, it empowers your teams to ship a shared outcome at a very reasonable pace. Velocity and accuracy is all but guaranteed.
Embrace the most important ingredient: Discovery
Discovery work is relatively new to our world in the context of developing product. Simply put, Discovery allows the team to continuously bring the customer or user to the table at the inception of the idea stage. This means contextual research practices such as interviewing, immersion visits, and prototype observation sessions are everyday occurrences that allow the team to work together to increase their confidence in an idea, “plus one,” or infrastructure improvement 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, and the ones who are 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 land 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 release) by errantly building a solution for “me” not “we.” I didn’t talk to the customers that 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 to simply 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 omni-channel experience today depends on it. In both 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 chit 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), knowing 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 Martin Eriksson and Richard Banfield 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.
You can follow us at @rmbanfield, @bfgmartin, and @nwalkingshaw.
The Product Leadership book will be published by O’Reilly and on shelves in May 2017. You can pre-order the book on Amazon.
