A Scrum Master's Existential Crisis: Should my team exist?

It’s no secret that Scrum is a framework most commonly used for building products and solving complex problems. My company is organized into 8 teams, each working on different but overlapping sections of a website. Our website is huge and was initially built over 20 years ago, and hundreds of engineers have contributed to all the different pieces of it. Today, my company’s value is largely in the data we own and the high traffic we get to our website. Our website provides value to its users by solving a problem for them, and it has done this for years. That puts our Product organization and Scrum Teams into a bit of a weird situation. We are constantly wanting to iterate and provide more value to users, but our users’ problem is already solved by our site, and our opportunities to branch out into a new problem for them is limited by our Legal team, our client stakeholders, ads stakeholders, and SEO stakeholders.

So we are “Product” teams, without a real, specific product, in that we share the site and the codebase with 7 other teams, and without a real, clear problem to solve for our users. This issue makes everything we do in Scrum quite difficult. On a high-level, I think we’re a very mature Agile organization, in that we release frequently and easily, and we implement Scrum quite well for all of our teams. But without a clear problem to solve, it’s hard to figure out why we are doing this, or why we are even funding and staffing Product teams. I have a sneaking suspicion that we would be more profitable with maintenance teams who did nothing but keep the lights on. 

Our teams are empowered in that they lead the technical design of their work. They get to decide how to build what we’re building, but they don’t get to come up with what we should build. That comes from our Product Organization, along with our Design team, who operate in a manner that is anything but Agile and certainly not Lean. Directors of Product will make 20 page slide decks with intricate designs, pitching their big ideas to stakeholders and clients. By the time it is “ready” for the team to work on, meaning Design has poured over the mocks for months, Legal has signed off on the copy, and every stakeholder has approved the business rules, a year has passed. Our Product Owner will take their piece of the work to their team and explain what it is. When asked why we’re doing it, the answer is that it’s a piece of the bigger picture the Director has created. Sure, that big picture may be (hopefully) based on user research, but those learnings are now over a year old, and we haven’t even started work on it yet. 

When we finally do build the new feature, we set up Do-No-Harm testing, to make sure the new feature doesn’t decrease our traffic or click-through-rate. We’ll launch it with a Feature Flag system so that we can easily toggle it off if it does start to hurt any of our metrics. But we aren’t great at identifying what positive metrics we’re even trying to affect. More often than not, we’re designing new features because Amazon or Airbnb have implemented them, and they’re the closest, seemingly best performing analogues to our product. Keeping up with those Joneses while not actively damaging our metrics is our definition of success. 

We don’t have a feedback loop around user value or revenue. We don’t have a way to know whether the things we’re building are delivering solutions to customers’ problems. We just execute the plans that our Product leadership came up with, and we hope and assume that they must be doing that research and validating those hypotheses. But they’re always planning the next new feature, and it doesn’t seem likely that they’re doing much in retrospection.

Sometimes I truly question whether we are all working on these new features just to give ourselves something to do and to keep our company employing us. We’ve been bought and sold and acquired and merged 4 times in the 5 years I’ve worked here, and the people truly at the top have no idea who I am, what my team’s name is, or what part of our product we work on. They don’t understand Agile or Scrum, and they have very outdated, old-fashioned ideas about product development. My department is able to show that we’ve released software a lot of times, finished a lot of story points, and made a lot of things every quarter. We don’t really know if anyone uses those things or if they mean anything to our customers. But I suppose we’re lucky that our leadership doesn’t seem to understand that that’s something they should care about. We have the best SEO in our industry and a hugely-valuable dataset, so we aren’t going anywhere. I’m sure in the next couple years we’ll be sold to another giant conglomerate, and that their leaders won’t take the time to understand what we do or why we do it, they will just want to get their hands on our juicy data. They probably won’t want us to do anything new with that data either though. But over here we’ll keep eagerly pushing out new tweaks to our little website and debating with each other about priorities and coordination between teams. We all like having our six-figure salaries and relatively low-stress jobs. As a Scrum Master I can’t decide whether I should be coaching our Product Leadership on actual product development, or keeping quiet so that I don’t disrupt the big charade that lets us comfortably plug away at our messy, pointless backlogs.