Thread by @allenholub

Customer empathy and (iterative) problem discovery are central to agile thinking. Excuse the long thread, but this is a big question. First we need to get our terms straight. 1/12

https://twitter.com/_/status/1434163296052006912

I’m talking about Agile as conceived, not about Scrum (as usually implemented) or SAFe or any of the myriad pseudo-Agile processes and frameworks that have diverged so much from Agile thinking that they’re no longer recognizable as such. 2/12

You need to go back to the Agile Manifesto, which is admittedly too concise, so to understand that, you need to understand the processes it summarizes (such as Extreme Programming [XP]). 3/12

Nonetheless, we see "Customer collaboration over…negotiation" and"harness change for the customer's competitive advantage," which is an awkward way of saying that we must emphasize with our customers. The whole notion of user stories (from XP) centers around that. 4/12

Working with users in order to understand their problems is the first stage of the story-capture process. Our goal is to understand and solve our customer’s problems. When you hear agile folk talking about "adding value," that’s what they mean. 5/12

This all feeds into problem discovery. We discover problems, not only by having deep conversations about how they work, but sometimes working side by side with them. 6/12

We capture those problems in "user stories"—very short capsule descriptions of _our users_ problems and domain-level solutions. Stories describe our customer’s work, not ours. Then, working closely with our customers, we sort those by value to the customer. 7/12

That’s a collaborative process, so value to the business is, of course, a factor, but the feeling is that the thing that’s most valuable to most customers is also the thing that’s most valuable to the business. 8/12

We then implement those stories in an iterative process that, if done properly, involves close collaboration with the customers. We build a little (maybe only a few minutes work), get feedback, and adjust based on that feedback. 9/12

This is, ideally, a "come over here and look at this" process, not a formal infrequent review. The feedback, of course, identifies things we got wrong, and we fix them right then. 10/12

Now, whether you see this sort of thing happening at actual so-called Agile shops is another matter entirely. Certainly the companies I work with do it, as do many others. 11/12

I will not argue if you say that Agile has been corrupted to the point where many self-identified "Agile" orgs have lost the customer connection, however. I don’t do that sort of Agile™ and none of the orgs I work with that are truly successful do it either. 12/12

I’ll add that you can learn this entire process in my Stories to Code workshop, coming up in a couple weeks. There’s more info at holub.com/stories