The problem with “Customers”

Several foundational aspects of agile project management focus on the role of the Customer. The role is of course best-defined in the context of work-for-hire, or consulting, or even in places where the team is doing volunteer work in an Open Source setting for a specified Maintainer. And historically this makes sense.

In the early days, I remember a lot of people in software projects would conflate the Customer with the User, even when they weren’t the same person. And then of course there’s the (risky?) conflation of Customer with Bill-payer, or (maybe more dangerous?) Customer with Project Owner (in a Scrum sense). But those are known problems, and the agile coaching community seems to have handled them reasonably well—in the context of traditional professional settings—if nothing else by repetitive correction.

The trouble I’ve found recently is how often the term puts off explorers, those who are tempted or solicited to try an “agile for one” (or “agile for us”) approach to their investigatory work—the just-try-it-and-see-what-happens projects that fill our days as engineers, scientists, artists and Makers more generally. To some extent the problem is the word and the freight it carries, and the diverse languages and cultures of from which those folks come, and the cultural antipathy prevalent between communitarian life-of-the-mind folks and doing-it-for-the-money folks.

I know, having spent so much time among the uppity agile rebels, that this “Customer” can be you, or all of you together (as long as you can arrange to Speak with One Voice), or nobody in particular. I understand that the point of the role is some combination of (1) identifying the most valuable thing to deliver next so you can focus on that and deliver it next, and (2) avoiding the Mission Creep and Babbage’s Disease that keeps projects from ever delivering anything of use at all, and (3) learning the (surprisingly rare) skill of Not Producing Unintelligible Crap.

But the word itself, and the freight it carries, seems to put off people—not least students and other academics—who I have to say are among the most “at risk” for failing to ship any useful work at all, ever. The deep usefulness of the Customer concept, as far as I’m concerned, is that somebody ought to be able to dynamically and adaptively sort the many things you might do next into an ordered list that reflects current perception of value.

To me, “being Customer” in my projects—whether I’m doing open-ended research or targeted software development—is a visceral change I make in my beliefs, desires and intentions. If I’m sorting stories or planning the next day or week, I try to look not at the subjective experiences I’ll have when making progress and doing work, but instead at the value I expect (right then) to obtain from the statement of purpose each story represents. It doesn’t matter than I’m the Customer and the “Development Team” on certain projects, as long as I can differentiate the stance I take when making decisions in those two roles. It doesn’t matter that the “story” is “make one and see what happens”; as a Customer I see that as a time-boxed deliverable, and demand it change to “spend one day making one, and publish a result at the end of that day”.

(What I try never to do as “Customer” is assign expectations of how long something will take. I am there, at that moment, only to see the value in various stories as they’re presented, and add new ones, and rearrange their order. If I need to decide how much might be done before the end of the iteration, or even whether one single “story” won’t or can’t fit in the allotted time, I’ve got to consciously switch over to “Maker” role. Oh, and also I try to avoid ever saying, “Go away, and never come back!” to myself….)

That’s how I try to run my research, and what I want to see in others. It’s safer exploration. It’s the opposite (as far as I can tell) of how academics and STEM folks think most often, and absolutely the opposite of how schoolwork and most technical professional work is planned, because those are simply given lists of comprehensive requirements. Bit three-ring binders full of “it must do all these things”.

Maybe the problem is that these folks, starting off as they do with such deep antipathy to the culture that led to the term, think the “Customer” role is some sort of permit for premature assessment, some kind of master:slave relationship, a debt and an onerous promise to fulfill that debt. But in practice, sorting tasks by value does not entail punishing failures to deliver on those tasks (and this is the deepest reason why measuring “velocity” is so fraught). “Let’s spend a day getting this better!” is not the same as “Get this done by Friday!” The former implies that no matter what happens—we get distracted, we had an emergency, we couldn’t think of a way to make it better, we make it better enough that it goes away entirely—there’s always another round of planning in which we can do the same thing again, another day somewhere down the line where there is perceptible value in working on that thing a bit more. And by the same argument, it means that progress on other fronts is (for the moment) more valuable than working on that thing until it’s “done”!

It saves huge amounts of time to use the Customer role explicitly. That saves my life, some days. It lets me have something to show for my work every day. Me, the “Customer”. Otherwise me, the “Developer” would wander off somewhere doing whatever random crap caught his attention, and end up rushing the useful work at the end.

I don’t know a better word than “Customer”. But I don’t know a better word than “agile” yet, and it’s getting close to the day when that also will need to change. I don’t think I can use the word in print any more, so I’m looking for a replacement soon. Spend a day thinking about it and send me whatever you find by the end of that day, OK?