Agile Died While You Were Doing Your Standup

BY NATE WALKINGSHAW ON APRIL 04 2017

agile-peak-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.

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 product 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 opened. 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 deep, long-lasting impact requires massive creative thought on all the teams’ behalf.

basecamp
Photo by Tommy Lisbin

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, 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 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 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 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. 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 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 “we.” 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 omni-channel 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.


Product Leadership BookEnjoy 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!

Nate Walkingshaw

About NATE WALKINGSHAW

Nate started his first company in 2004 where he revolutionized medical evacuation with Paraslyde, later acquired by Stryker Medical. In 2011, Nate left Stryker to build Brightface, a product development company that focused on mobile and web applications including Cycleface which was acquired by Strava, the #1 fitness app for endurance athletes. Nate then became the Chief of Research and Innovation at Tanner Labs, where he built O.C. Tanner’s first human-centered product development team. In January 2015 Nate was named the Chief Product Officer for Pluralsight, the largest providers of online technology learning, where he built a user centered product team, and in February 2016 Nate’s role expanded to Chief Experience Office to also oversee Development, Content, and Product Marketing. He is also the co-author of Product Leadership: How Top Product Leaders Launch Great Products and Build Successful Teams (O’Reilly 2017).

RELATED CONTENT

Read more about Organisation ...

#mtpcon SF 2017 : Product is People

  • Jon Stone

    Excellent piece Nate – It amazes me at times, when I see such blinkered approaches to instilling an Agile mindset among organizations, which is why we have so many companies that are ‘doing’ agile and not ‘being’ agile. And with the growth of the UX groups, and the value they provide the business, and by extension, the customer, what you were highlighting is naturally evolving – as you said, many companies won’t even acknowledge this, except standouts like the Spotify’s, Amazons, Googles etc. of today. I expect to see a new set of names emerging in the coming years, that embrace Agile principles, layered with a heavily customer focused UX approach to work, and flat organizational structures.

  • jonkernpa

    Nice article.

    If “people crave the challenge of the climb,” what holds them back? (<- rhetorical)

    I guess I have lived by the personal motto(s) to “Act like an owner. Care deeply about the customer — sometimes more than they do. And beg for forgiveness rather than ask permission.”

    (And my wife and I saved our money to ensure safety at home for me to challenge authority and do the right thing. I always encourage the devs I work with to do the same. Make sure to build up X months of living expenses, and not live paycheck-to-paycheck.)

    I can sympathize and maybe even empathize.

    Don't blame Agile, Scrum, tools, or any other acronym.

    Take responsibility. Be the change you wish to have.

    It is not easy. Things of great value rarely are.

    Do not be afraid to try and fail and try again. Learn. I do this daily.

    BTW: no need to bash JIRA (or cringe) or any other tool, for that matter. Misuse is not the tool's fault. (My snarky alter ego used to quip "A fool with a tool is still a fool" when I was building and hawking TogetherSoft's Control Center UML tool. But I am kinder and gentler now.)

    BTW#2: Large organizations likely fall into the traps of HR, career ladders, merit based objectives, performance reviews, command-and-control, org hierarchies, fiefdoms… That summit out there? If it even exists? Even if it looks the same for many in the org?… has little bearing on most employees working inside the matrix. If it were to be a goal, imagine how hard it is to work as a collective force, and not as individual silos, and still get your bonus or raise. Now add to that, the fact that to many large orgs, the "software" is not the majority of the profit and loss generation. It's just a part of the business.

    • nwalkingshaw

      Jonkernpa,

      Thanks for the passion and the note man. Really means a lot. Also sounds like you need to get out and write! You have a lot to say and from the sounds of it, it may be worth while for the rest of world to hear it. I hear you on the HR traps and that is what I am really trying to tease out. I think it all needs a fresh look. Performance based compensation places an individual contributor at odds potentially against another team mate as you point out. Team based compensation deserves an article all by itself. I just wanted to clarify. The intention is not bashing Jira, but what we do within the tool that matters. Using the name that is widely adopted for purposes of relating to the reader was the goal. Thank you again for the meaningful dialog and perspective. It’s the conversation that needs to get out in front of others.

      • jonkernpa

        If you are not already, check out the Modern Agile slack channel. modernagile.slack.com And look up John P Cutler. Wish we could drink a pint or two together 😉

        And yea, I hear ya on the writing… too busy running two “start-up-esque” product development teams (day shift and night shift) :-p

        • nwalkingshaw

          I will check it out. I know John! #smartcookie Good luck on the start-ups!

    • JustRodders

      I agree with the sentiment of the article. I’m pretty sure there are agile teams and companies out there who are making good strides along this path, but from what I’ve read in various online communities it does seem that “Doing Agile” is the dominating mindset.
      What I really like from this article and the comments, is the analogy between mountain trekking and agile product development. If you’re trekking in the mountains, would you want the most accurate map, or the most experienced guide? Both have value but, for me, the guide brings judgement and a human intelligence that is required for the difficult job of staying safe and finding valuable experiences in the trek.

  • Sandra Davey

    Hi Nate, really enjoyed what you had to say and I agree with a lot of it.

    I’ve found over the last 18 months helping mid-size companies change the way they approach and “do” product management, that most of the work is change management. As you also point out, the work is across organisational structure, culture, skills development, and the myriad unspoken or unconscious biases that organisations operate under, that inevitably hold progress or innovation back.

    I’ve found that most of the work I’m doing is “not with Tech” but the rest of the business, because the value created in Tech stalls when the “rest of the organisation” still operates under traditional management and structures. It’s the “rest of the organisation” where effort and change is most needed.

    I’ve avoided using the term “agile” and have instead, used product management, product development or product innovation. This has helped move the conversation towards the entire business, not just the stuff going on in Tech. It also allows conversations on waterfall, design thinking and lean product to emerge and not be set up to “compete” with agile.

    They all offer techniques and frameworks for the Product Manager’s toolkit. Having said that, I concur that we haven’t left Basecamp with regards to the the mindset and philosophy of agile, lean or DT, the stuff and change that occurs deep within ourselves and our organisations, and your point around outcome v output is one example of how organisations are “miss the point”.

    In a way streamlining product management is easy, it’s the effort around the organisation, its structure, and culture, that is much harder. It requires deep reflection and change; something a lot of organisations find too hard in the race for output.

    By the way, I love your conversation around outcomes v outputs. A lot of us are having this conversation with our clients.

    I disagree with one point … doing customer discovery is not new. For those of us who’ve done product management since the 90’s, discovery is not new. It is however, much more sophisticated and better baked into the overall product management process.

    I’m really looking forward to reading your book.

    Cheers
    Sandra

    • nwalkingshaw

      Sandra, Thank you for the thoughtful response. Loved all the context you shared as well.

  • Charles Rivet

    Agile (sorry, agile – little “a”, i.e., the manifesto) has many great things going for it, but you are correct in your analysis. People have (seemingly always) looked at process and gurus as a panacea, as an excuse to stop thinking. We don’t need gurus, we need guides to climb from basecamp and make the summit. Guides who have climbed before. Guides who know the mountain and its treachourous passes. Guides who can read the lay of the land and not just follow a static map.
    Thank you for your verve and your passion.

    • Nate Walkingshaw

      Thanks for the note Charles. The the thought behind guides, what occurred for me was this notion of guides to you are real life practitioners that have summited before. If that is the case I completely agree.

      • jonkernpa

        Well, IMHO, the analogy breaks down a tad with the “summited before” as most of us are not making the same climb over and over. (More on that later.)

        Mostly it is about learning techniques that work. Being exposed to different terrain. Sometimes bouldering, sometimes trekking, at times roping up. And once in a while putting on crampons and crossing glaciers and crevasses.

        Mountain climbing is a lot like agile development in another way. Risk assessment/management. When climbing, one should be constantly re-evaluating the climb — and from a myriad of perspectives. The same should be true of an agile development team.

        *Multiple Summiting.*

        In a few businesses, I have done the same summit a few times. That is, *completely* re-doing the code base for each next major version. Only following better routes — or at least different routes. (That is, redoing the architecture, typically.)

      • Charles Rivet

        Yes, that’s what I meant by guides. Would you trust a guide who has not climbed that mountain before?

        • nwalkingshaw

          Agreed!

  • Josh L

    Very nicely put, you managed to word how I’ve been mildly annoyed by what our processes and scrum teams have become, “scrumfall” is a great word that brings up a thousand examples in my head.

    Hopefully others have much better experiences than I do, but so far in the last 5 years and two employers I have been with, we set out with the best of intentions to create our own versions of agile teams, for our evolving processes, needs and context, only to create monsters that not only do not help us work better together, but we constantly fool ourselves about the quality of what we ship because it’s Agile-with-a-capital-A.

    Again, Agile/Scrum/etc isn’t at fault, it’s what we make of it – and we are failing hard. Right now, thinking about the mess back at the office I am dreading to go back to, we constantly review and update our processes every other month, which is good, but the end to end chain is direly broken by politics, ego wars and new-is-always-better mentality.

    Honestly, we could go back to straight-up waterfall, and it would likely work better for us – it won’t happen, management will not admit it did not get the heart of Agile/Scrum at this point, but something tells me big chunks of resources, time and effort were wasted.

2.6K Shares
Share
Share
+1
Email
Tweet