You can't do agile without a customer

I’ve worked on many projects during my career. Many of them eventually delivered high-quality products that were used by a good amount of customers. However, most of them went over budget, as is very common in the software development industry [forbes].

I can’t speak for all projects in the world, but I can say a few things about how the projects I’ve been a part of could be improved. In this article I want to focus on the idea that you can’t do agile if you don’t have a customer.

I’m a firm believer that agile methodologies, like SCRUM, can help a project deliver in-budget and on-time. However, the projects I’ve worked on all pretended to do SCRUM, but didn’t actually embody the spirit at all.

In SCRUM and other agile methodologies the customer is central. This is because agile requires validation of ideas by people who are actually using the product. Only end-users can say if a product works for them or not. There is no valid substitute for end-user feedback. Not from your sales department, not from your service department, not from your project managers, not from anyone else. Only the people who have a problem when you product doesn’t do what it’s supposed to can tell you if you’ve delivered the right things.

What’s worse, when end-users are substituted with people inside your company, you’ll see that the agile cycle becomes a sort of make-believe game between the developers and the company stakeholders. You’ll know you’re in one of these games when you hear phrases like: “we could sell this if we had feature X” “We can’t go to the customer yet because Y doesn’t do what I think it should yet.”

In one of the projects I’ve worked on this game of make-believe went on for 2 years. I tried pushing to get some feedback from actual end-users, but there was no willingness to get the product in front of a customer before we had the green-light internally; and there was always some reason that a green-light couldn’t be given. Every time the Minimum Viable Product goals were reached, the goalpost moved because the product wasn’t yet what the people internally had envisioned.

Of course, eventually the product was presented to end-users, who decided very quickly to not be enthusiastic about the product at all. That wouldn’t really have been a problem if we had that feedback 12 months earlier, when the direction could be clearly explained for the first time. However, now huge sums of money and heaps of time were already invested into something that didn’t actually do anything for our users. Having to go through that realization is not fun.

My story doesn’t have a bad ending though. The framework we built could easily be adapted to fulfill an actual customer need that we discovered from the feedback we received on our first failed attempt. And that’s precisely why agile works in cycles: your first idea is never what the customer needs, but it’s the one you can use to discover where the real problem is. The sooner you get your prototype in front of a real customer, the sooner you can get to work on the actual problem instead of the one you imagined.