The way I learned to use the term “user story”, back in the late 1990s at the beginnings of what is now called “agile programming”, was to describe a kind of roleplaying exercise in which you imagine a person and the person’s use case as a way of getting an outside perspective on the design, the documentation, and especially the UI of something you’re writing.
For example:
Meet Joe. He works for Randomcorp, who has a nasty huge old Subversion repository they want him to convert to Git. Joe is a recent grad who got thrown at the problem because he’s new on the job and his manager figures this is a good performance test in a place where the damage will be easily contained if he screws up. Joe himself doesn’t know this, but his teammates have figured it out.
Joe is smart and ambitious but has little experience with large projects yet. He knows there’s an open-source culture out there, but isn’t part of it – he’s thought about running Linux at home because the more senior geeks around him all seem to do that, but hasn’t found a good specific reason to jump yet. In truth most of what he does with his home machine is play games. He likes “Elite: Dangerous” and the Bioshock series.
Joe knows Git pretty well, mainly through the Tortoise GUI under Windows; he learned it in school. He has only used Subversion just enough to know basic commands. He found reposurgeon by doing web searches. Joe is fairly sure reposurgeon can do the job he needs and has told his boss this, but he has no idea where to start.
What does Joe’s discovery process looks like? Read the first two chapters of “Repository Editing with Reposurgeon” using Joe’s eyes. Is he going to hit this wall of text and bounce? If so, what could be done to make it more accessible? Is there some way to write a FAQ that would help him? If so, can we start listing the questions in the FAQ?
Joe has used gdb a little as part of a class assignment but has not otherwise seen programs with a CLI resembling reposurgeon’s. When he runs it, what is he likely to try to do first to get oriented? Is that going to help him feel like he knows what’s going on, or confuse him?
“Repository Editing…” says he ought to use repotool to set up a Makefile and stub scripts for the standard conversion workflow. What will Joe’s eyes tell him when he looks at the generated Makefile? What parts are likeliest to confuse him? What could be done to fix that?
Joe, my fictional character, is about as little like me as as is plausible at a programming shop in 2020, and that’s the point. If I ask abstractly “What can I do to improve reposurgeon’s UI?”, it is likely I will just end up spinning my wheels; if, instead, I ask “What does Joe see when he looks at this?” I am more likely to get a useful answer.
It works even better if, even having learned what you can from your imaginary Joe, you make up other characters that are different from you and as different from each other as possible. For example, meet Jane the system administrator, who got stuck with the conversion job because her boss thinks of version-control systems as an administrative detail and doesn’t want to spend programmer time on it. What do her eyes see?
In fact, the technique is so powerful that I got an idea while writing this example. Maybe in reposurgeon’s interactive mode it should issue a first like that says “Interactive help is available; type ‘help’ for a topic menu.”
However. If you search the web for “design by user story”, what you are likely to find doesn’t resemble my previous description at all. Mostly, now twenty years after the beginnings of “agile programming”, you’ll see formulaic stuff equating “user story” with a one-sentence soundbite of the form “As an X, I want to do Y”. This will be surrounded by a lot of talk about processes and scrum masters and scribbling things on index cards.
There is so much gone wrong with this it is hard to even know where to begin. Let’s start with the fact that one of the original agile slogans was “Individuals and Interactions Over Processes and Tools”. That slogan could be read in a number of different ways, but under none of them at all does it make sense to abandon a method for extended insight into the reactions of your likely users for a one-sentence parody of the method that is surrounded and hemmed in by bureaucratic process-gabble.
This is embedded in a larger story about how “agile” went wrong. The composers of the Agile Manifesto intended it to be a liberating force, a more humane and effective way to organize software development work that would connect developers to their users to the benefit of both. A few of the ideas that came out of it were positive and important – besides design by user story, test-centric development and refactoring leap to mind,
Sad to say, though, the way “user stories” became trivialized in most versions of agile is all too representative of what it has often become under the influence of two corrupting forces. One is fad-chasers looking to make a buck on it, selling it like snake oil to managers forever perplexed by low productivity, high defect rates, and inability to make deadlines. Another is the managers’ own willingness to sacrifice productivity gains for the illusion of process control.
It may be too late to save “agile” in general from becoming a deadening parody of what it was originally intended to be, but it’s not too late to save design by user story. To do this, we need to bear down on some points that its inventors and popularizers were never publicly clear about, possibly because they themselves didn’t entirely understand what they had found.
Point one is how and why it works. Design by user story is a trick you play on your social-monkey brain that uses its fondness for narrative and characters to get you to step out of your own shoes.
Yes, sure, there’s a philosophical argument that stepping out of your shoes in this sense is impossible; Joe, being your fiction, is limited by what you can imagine. Nevertheless, this brain hack actually works. Eppure, si muove; you can generate insights with it that you wouldn’t have had otherwise.
Point two is that design by user story works regardless of the rest of your methodology. You don’t have to buy any of the assumptions or jargon or processes that usually fly in formation with it to get use out of it.
Point three is that design by user story is not a technique for generating code, it’ s a technique for changing your mind. If you approach it in an overly narrow and instrumental way, you won’t imagine apparently irrelevant details like what kinds of video games Joe likes. But you should do that sort of thing; the brain hack works in exact proportion to how much imaginative life you give your characters.
(Which in particular, is why stopping at a one-sentence “As an X, I want to do Y” is such a sadly reductive parody. This formula is designed to stereotype the process, but stereotyping is the enemy of novelty, and novelty is exactly what you want to generate.)
A few of my readers might have the right kind of experience for this to sound familiar. The mental process is similar to what in theater and cinema is called “method acting.” The goal is also similar – to generate situational responses that are outside your normal habits.
Once again: you have to get past tools and practices to discover that the important part of software design – the most difficult and worthwhile part – is mindset. In this case, and temporarily, someone else’s.
Epistemic status: spitballing.
Now consider what happens when you give this to a shop full of shadow-autist programmers and tell them they’ve got to use it for all their requirements-writing. They don’t have a social monkey*, so they’re going to approach it exactly the same way they approached bullshit-encrusted essay-writing in school: come up with formula and stereotypy just sufficient to technically fulfil the rules while they spend all their actual mental effort on non-narrativium approaches to the task.
I’m not saying the snake-oil salesmen and fad-chasing managers aren’t responsible too, but programmers actively co-operate in hollowing out user-stories into an empty ritual, because they don’t really work for the dominant neurotype within the field.
* Oversimplification, but you knew that.
>Oversimplification, but you knew that.
I wondered when somebody was going to bring the autists into the discussion.
Yes, actually you are oversimplifying. I mean if they’re shadow autists they do have some other-minds capability that they can use for this technique. I think a good guide for the boundary is whether your dominant-neurotype programmer can read fiction for enjoyment.
If he can, that argues that he has enough identify-with-others capability to design by user story. Even if he flubs much more difficult problems like chatting up women.
There’s probably a slice of the spectrum between “too impaired to enjoy fiction” and “too impaired to sling code” that’s represented among programmers. I don’t think it’s very large, though. I’d take a lot more persuading to think it was responsible in more than a very minor way for the trivialization of the technique.
> There’s probably a slice of the spectrum between “too impaired to enjoy fiction” and “too impaired to sling code” that’s represented among programmers. I don’t think it’s very large, though. I’d take a lot more persuading to think it was responsible in more than a very minor way for the trivialization of the technique.
Except that I think that writing fiction is, metaphorically, “NP-complete”. Verifying (enjoying) fiction can be done in “polynomial time”, but producing fiction can’t be done in polynomial time on a deterministic brain. I can enjoy fiction, and I can worldbuild, but I have trouble creating plot and characters.
And it might not even be metaphorical: while the stereotype has many flaws, the typical Aspergers/shadow autistic case comes across as machine-like to the rest of the population, and the general population comes across as capricious and arbitrary to autists. What if the difference is that the autistic mind is closer to a deterministic Turing machine, and the normal mind to an NTM? If creating good fiction is complete for some non-deterministic complexity class, this would predict that a given degree of autism would impair fiction writing much more than enjoyment.
For *writing*, as opposed to enjoying, fiction, I think that impairment may actually *enhance* ability to write code, and vice versa. If normal brains approximate an NTM by randomly shotgun-sampling the branches of the computational tree at high levels of parallelism, then they would be bad at following the one path of a DTM, which would impair code writing. Meanwhile, a brain that approximates a DTM will take a long while to work its way through the entire computation tree of an NTM, which, if fiction writing requires sampling a really branchy tree, will be very expensive.
>I can enjoy fiction, and I can worldbuild, but I have trouble creating plot and characters.
But I have the exact same profile, and I consistently come out boringly neurotypical on the test instruments. So though you might have your finger on something here it’s not something that coincides with the divide between neurotypicality and Asperger’s/autism.
> So though you might have your finger on something here it’s not something that coincides with the divide between neurotypicality and Asperger’s/autism.
It can define both boundaries without the boundaries coinciding.
Fiction writing ability (especially the ability to make a career out of it) may require a degree of ability to function as an NTM that is as aneurotypical as autism, but in the other direction.
The ‘career’ part of writing fiction is an entirely different thing that *writing* fiction. A career implies selling the work, and that is, if not exactly random, then subject to many factors the author has no control over.
I doubt this. My description was distilled in part from my own experience (gee, whoda thunkit?) and I can definitely read fiction for enjoyment (and not just idea-as-hero SF, either).
Although my initial reaction was to reject it, on reflection I think Jon Brase’s hypothesis might be right. My other-minds capability exists, yes, but it’s analytic rather than synthetic — it runs poorly as a predictor but not at all as a freerunning generator, even though the two ought to be strongly linked. Maybe my brain’s running top-k and NTs run top-p ;)
(I don’t agree with his NTM/DTM theory, though. Code may be deterministic, but writing code is not; it’s art.)
> (I don’t agree with his NTM/DTM theory, though. Code may be deterministic, but writing code is not; it’s art.)
But you have to be able to follow along with the determinism of the code to be capable of that art, and my theory is that the neurotypical brain tries to treat the computer as an NTM and shotgun-sample its computational tree, and thus mispredicts what the code it writes will do.
I’m sure that even severely autistic brains are closer to NTMs than DTMs (even A-list aspie hackers make the equals-instead-of-equal-equals blunder), and functioning as an NTM is doubtless necessary to sample the space of code that might be written to solve a problem, but keeping the error rate down, and not being *too* frustrated when you generate a bug and the machine doesn’t DWIM, may well require ability to function as a DTM.
>But you have to be able to follow along with the determinism of the code to be capable of that art, and my theory is that the neurotypical brain tries to treat the computer as an NTM and shotgun-sample its computational tree, and thus mispredicts what the code it writes will do.
Sorry, I still think I am a rock on which your theory founders. Because I stubbornly continue not to show clinical or even subclinical signs of autism, and yet there is plenty of behavioral evidence that I do the DTM thing in the way you ascribe to autists.
All kinds of theory-building in this area would be easier if I could be binned as a shadow autist. Hell, explaining much of my life would be easier! Which is why it’s all the more interesting that I can’t be.
>Sorry, I still think I am a rock on which your theory founders. Because I stubbornly continue not to show clinical or even subclinical signs of autism, and yet there is plenty of behavioral evidence that I do the DTM thing in the way you ascribe to autists.
I think that there’s good evidence that, by female standards, *all males* are shadow autists.
Furthermore, I’m not taking the DTM/NTM distinction as binary: is perfectly plausible for the degree of DTMness needed to write code to interfere sufficiently with NTM function to prevent writing good fiction, but to remain well short of the boundary for even subclinical autism. Furthermore, I’d expect good general intelligence to raise both DTM and NTM ability, so it’s plausible that someone could function at autistic levels of DTMness without actually being an autist, or, conversely, that a very smart autist could reach levels of NTMness sufficient to not even show up as subclinically autistic.
>Furthermore, I’d expect good general intelligence to raise both DTM and NTM ability, so it’s plausible that someone could function at autistic levels of DTMness without actually being an autist
Yeah, I think that’s me. I’ve speculated previously that (a) autists and shadow autists have a bunch of super-competence behaviors at things like programming that are enabled by not being distracted by the social-status-seeking hamster wheel constantly spinning in a neurotypical’s brain, (b) a sufficiently bright neurotypical can do the same stuff in spite of his hamster wheel.
But once you’ve arrived at this theory it becomes much more difficult to make true claims with the precondition “is an autist or shadow-autist”.
My speculation here isn’t so much that programming competency is enabled by not having the hamster wheel as that the same factor that creates programming competency warps the hamster wheel and makes it hard to run on. Removing that factor beats the hamster wheel back into shape, but deranges the machinery needed for programming.
A test of whether one is a (shadow) autist or a bright neurotypical might be something like the difficulty of interrupting out of hack mode. If leaving hack mode is exothermic with a low activation barrier, you’re likely neurotypical. If it’s endothermic with a high activation barrier, you’re likely (shadow) autistic.
Of course, good general intelligence will probably reduce the apparent height of the activation barrier, but the potential difference between the two states should keep the same sign.
IOW: You’re alone in the house, hacking. You start to feel hungry around 6 PM. How likely are you to continue hacking past 8 PM? 10? Also, with no outside commitments, how much phase shift to you typically experience per day?
>IOW: You’re alone in the house, hacking. You start to feel hungry around 6 PM. How likely are you to continue hacking past 8 PM? 10? Also, with no outside commitments, how much phase shift to you typically experience per day?
I see where you’re going with this, but on that set of criteria I ought to be a shadow autist, and he screening tests I’ve taken say I’m not. I’ve taken several of them because this result kept surprising me, but it’s consistent.
> I see where you’re going with this, but on that set of criteria I ought to be a shadow autist, and he screening tests I’ve taken say I’m not. I’ve taken several of them because this result kept surprising me, but it’s consistent.
Actually, it surprises me that you meet the interrupt difficulty criterion, because you do strike me as neurotypical on a number of less easily quantifiable criteria, such as social adjustment and willingness to advertise your own strengths. I’ve definitely seen you piss off shadow autists in your orbit by being a bit freer with your self confidence than many of the type think proper. Then again, I’ve been trying to figure out for a while if that aversion is learned or innate in my case. The “learned” part would be the fact that I was quite cocky about my intelligence in 2nd grade, and rubbed my peers’ faces in it, with predictable social results. The “innate” part would be a bent toward pathological honesty, and the fact that liars often place themselves on the overconfident side of Dunning-Krueger. The innate part seems to be a feature of many autists and shadow autists, and the learned part may be a fairly common experience for the type. Depending on the weight of innate versus learned, the habit of deliberately placing oneself on the underconfident side of Dunning-Krueger and being uneasy with people who don’t may be more or less reliably diagnostic of shadow autism. It does seem likely to be at the root of the meritocratic nature of hacker culture, whether nature or nurture.
As to my own reaction to you specifically, you do from time to time set off my social monkey’s arrogance alarms (especially 10 years ago when I was first following A&D), but while that particular spinal reflex makes me uncomfortable, I’ve seen little indication that you’re on the wrong side of Dunning-Krueger, so I’ve never seen fit to actually bring it up (except now to say that it strikes me as a possible diagnostic of neurotypicality).
Is it helpful or confusing if report that I have the “bent toward pathological honesty”?
You are right to be perplexed about where I fit. I’m perplexed about it myself.
To an extend for me it’s less that I’m interested in programing despite having a well developed hamster wheel but that it is so hyperactive that it has me constantly looking for threats to my status and programming lets me disengage from that.
In any case I’m another example of “intuitive understanding of social stuff + enjoys and is good at technical work”
You’re overestimating how difficult the exercise you described is for autists. For starters one needs to know a bunch of people closely enough to have a basis from which to create these personas.
If an autistic person is high-functioning enough to hold down a job at a tech company, or even to participate meaningfully in an open-source community, they are high-functioning enough to get usefully good at the practice Eric describes. The main difference between us and normies is that normies come with much of their social-monkey stuff implemented in firmware; for us, it’s a skill that has to be learned. And it’s much lower risk to mentally inhabit a fictional character than, say, to come up with appropriate things to say to your boss or a girl you’re trying to date, so with our detail-oriented rational minds we can readily learn how to do this sort of thing. We even take part in exercises that help develop this skill as hobbies; for example, roleplaying games[0] or writing fan fiction.
If a developer has trouble coming up with credible personas on their own, you can try using stock characters. For example, “You’ve designed a system suitable for Rick. How would Morty react to using it?”
Oh, and — autistic women are much better at this sort of roleplaying than autistic guys are. The world is full of movies like Heathers and Mean Girls and Clueless where the pretty, bitchy, popular girls find a shy, frumpy bookworm and “make her over” to be more like them. It works — in the movies and in real life — because the popular girl stuff actually takes and the bookworm engages in a long-form imitative exercise to improve her social standing.
[0] Tabletop RPGs, like just about every other nerd hobby, are currently undergoing an SJW takeover. Which goes to show that SJWs are pretty much highly dysfunctional normies who couldn’t cut it at the cool kids’ table so they plot to take over the nerds’ table — better to rule in hell than serve in heaven.
To drift a little….
>Which goes to show that SJWs are pretty much highly dysfunctional normies who couldn’t cut it at the cool kids’ table
Substitute ‘credentialed but useless’ for dysfunctional….and tada! Well yes. You may not be aware of it but it generalizes.
The parasite load on institutions dominated by the ideological allies of the SJW is already too high for those institutions to provide the livelihood the SJW has been led to expect as their due. So new worlds must be conquered.
See for example, OWS.
One may argue that it may be time to eradicate SJWs the exact same way all parasites are eradicated.
Having the hosts die off?
Yes, but only if someone puts in significant effort to teach us how (or provides materials and time for us to bootstrap ourselves), rather than relying on “it’s narrative, People already know how to do that”. IME companies trying to ‘go agile’ pick the latter option.
Tabletop RPGs (which I actually thought of when writing my original comment) have rulebooks and adventure modules carefully written by experienced game designers to elicit role-playing behaviour from players who don’t necessarily know how on their own. And I bet you’ll find that most GMs are less autistic than their players.
I don’t know enough neuropsych to properly account for it, but female autism typically manifests so differently to the male that if we hadn’t reductionistically identified a few specific traits as diagnostic of autism, we’d probably think they were different syndromes entirely. Which shouldn’t be surprising; modal female brains are optimised for such different metrics from modal male brains that it’s little wonder they exhibit different symptoms from the same underlying pathology.
Statistically, the popular-girl stuff speaks to a primeval desire in the female psyche that’s still present in the autistic female (as it’s orthogonal to the ability that autism interferes with), but is much weaker in the male (autistic or otherwise).
(In case it’s not clear: generalisations in the above are not absolutes, merely population-level statistical things. Which shouldn’t need saying, but does in case the leftist mobs are around.)
>And I bet you’ll find that most GMs are less autistic than their players.
Related: If you have a team full of A-list hackers who are all shadow-autist except for one, guess which one is almost certainly the team lead and main focus of personal loyalties in the social constellation? If you guessed “the one least deficient in other-minds modeling” give yourself a gold star.
And yes, I am speaking from direct personal experience here. There are bright autists who follow me around. By an amazing non-coincidence, several of them are A&D regulars.
>I don’t know enough neuropsych to properly account for it, but female autism typically manifests so differently to the male that if we hadn’t reductionistically identified a few specific traits as diagnostic of autism, we’d probably think they were different syndromes entirely.
Truth.
My wife Cathy revealed a few years back that she suspects that she might be a female-version shadow autist (see also “autists follow me around” previous comment). Having already considered the possibility I could not but agree this was plausible.
But if she has autistic impairments they are very, very subtle – much less overt than in a typical male autist. My understanding is that this is typical in female autists.
Cathy always struck me as exactly the kind of geek girl I would love to be associated with. I never considered her impaired in any way.
>Oh, and — autistic women are much better at this sort of roleplaying than autistic guys are. The world is full of movies like Heathers and Mean Girls and Clueless where the pretty, bitchy, popular girls find a shy, frumpy bookworm and “make her over” to be more like them. It works — in the movies and in real life — because the popular girl stuff actually takes and the bookworm engages in a long-form imitative exercise to improve her social standing.
I think just as important is that they’re more motivated: autistic guys are more capable, emotionally, of surviving isolation, more inclined to self-isolate on principle if they find something in society morally offensive, and when they find isolation to be unhealthy, are likely to be much more cautious about making sure that any rapprochement with society is on their terms.
>[0] Tabletop RPGs, like just about every other nerd hobby, are currently undergoing an SJW takeover. Which goes to show that SJWs are pretty much highly dysfunctional normies who couldn’t cut it at the cool kids’ table so they plot to take over the nerds’ table — better to rule in hell than serve in heaven.
I suspect there’s also an interaction between this and your previous paragraph: at least some fraction of SJWs seems to be made-over bookworms who have been taught that “smart is rude” and play dumb for the normal crowd, but meanwhile want recognition for being smart from the nerdy crowd, but try to impose “smart is rude” on the nerds so as not to fall out with the normal crowd, which causes the nerds to reject them utterly, which they take a an indication that the nerds are sexist, and with the number of nerds that have been through something like this by age 18, they may be half-right.
Meanwhile there seems to be an unfortunate interaction between the red flags autists and females use to identify Trump-like males. For autists, it’s dishonesty and braggery, for females it’s bluntness. Trump and his ilk are big-lie braggarts, a perfect storm of all of these faults. Meanwhile, the autists are pathologically honest (and proud of it) to the detriment of tact, the females are pathologically kind to the detriment of honesty (or have been shamed into it by other females), and feminism teaches them to assert their credentials any time they think they’re being called into question. The result is that the autists and the females each see their red flags for Trump-likes in the other group, and the Trump-likes get to play them against each other without lifting a finger, and thereby win.
>I suspect there’s also an interaction between this and your previous paragraph: at least some fraction of SJWs seems to be made-over bookworms who have been taught that “smart is rude” and play dumb for the normal crowd, but meanwhile want recognition for being smart from the nerdy crowd, but try to impose “smart is rude” on the nerds so as not to fall out with the normal crowd, which causes the nerds to reject them utterly, which they take a an indication that the nerds are sexist, and with the number of nerds that have been through something like this by age 18, they may be half-right.
This reads as ‘low status losers try to find someone else to dominate so as to at least be in the middle of the dominance hierarchy rather than at the bottom’.
Or as ‘shit flows downhill’ and abused children are mean to animals.
Imposing rules on a group that is not your own is not a kind, thoughtful, generous or polite act.
>The world is full of movies like Heathers and Mean Girls and Clueless where the pretty, bitchy, popular girls find a shy, frumpy bookworm and “make her over” to be more like them. It works — in the movies and in real life — because the popular girl stuff actually takes and the bookworm engages in a long-form imitative exercise to improve her social standing.
This can work on guys, too.
I once had a shadow-autist friend (before he went all SJW and decided I was beyond the pale) who I taught how to chat up up girls.
My wife Cathy helped. We were very considered about it – talked theory, took him through role-playing exercises. Then I took him to where there were women (notably at an SF convention and a streetful of bars in Austin, Texas on a Saturday night) and at an SF convention, taught him how to spot girls who are shopping for boyfriends, then said “watch closely” and showed him what a successful pickup looks like.
At the SF convention I was able to explain what I was doing to some women who were actually helpful and gracefully flirted with him instead of just cutting him dead, bless them. It helped that he was not ugly, knew a bit about how to dress and looked exactly like a bright young man with good job prospects. The main thing he had to get over beside the shadow-autist deficit was an utter terror of rejection and failure.
I had to go to the level of handholding of “Hi, this is my friend who I’m trying to teach how to talk to women,” and “OK, now you ask her for her phone number.” But with enough coaching it did sink in. Well enough that he found and courted a woman that would marry him, and it stuck.
So, existence proof by example.
>* Oversimplification, but you knew that.
I think the simplification fails in a significant way, though: my experience is that I *do* have a social monkey, and that in many (not all) cases it fails to predict normal behavior at a rate *much worse* than random chance. In other words, the social monkey is an Aspergers case. For example, the average advertisement makes me disinclined to buy the advertised product because my social monkey is terrified that the other social monkeys will judge it for falling for such transparent manipulation. In reality, all the other social monkeys are judging it for not buying the cool product with the funny add like all the hip-and-modern social monkeys.
I don’t disagree with any of this. (I myself have in the past argued quite vehemently that we autists don’t have no theory of mind like Baron-Cohen and his ilk think; we just have a different one.)
But I don’t see how it helps you write a user-story that models anyone but another aspie, and the odds are you can already write a UI that they’ll get along with, without need of user-stories.
>But I don’t see how it helps you write a user-story that models anyone but another aspie,
It doesn’t, but the failure mode is important, I think (OTOH a normal person might respond with “I overthink. FTFY, nerd”).
>“I overthink. FTFY, nerd”
Last night my very neurotypical Kung Fu instructor said something of the form “If [you have predicate X that Eric satisfies] you are officially a nerd.”
He had no idea how hilarious I found this, and probably never will, because…how do you explain being a geek-cred certification authority to somebody who (a) has no apparent contact with any geek subculture, and (b) shows zero signs of being able to mentally model the thought processes of geeks if he did?
The mental modeling is why I bring this up, and what ties it to the current discussion. Because Sifu is representative of a fair percentage of neurotypicals – possibly most of us, I don’t really think I know – who can’t model the thought processes of geeks in general and shadow-autist “standard-profile” geeks in particular at all.
It’s not an IQ thing, or at least not solely that. Sifu is not a stupid man; his day job is in criminal forensics and intelligence analysis. But there’s a point past which he has no patience for “overthinking” and that point is way, waaay sooner than it would be for any of the neurotypicals in this crowd.
Yeah, I hear that. I remember being about 12-years-old and my 8-year-old sister was APPALLED that I had chose Coke rather than Pepsi when I took the “Pepsi Challenge” at a mall. Meanwhile I thought, “I got a free soft drink, and now I have empirical evidence of which soft drink I should buy.”
My handling of these situations tends to be “Company trying to fad-up its product with a publicity stunt? I’ll pass, and move the product down in my preference list for being produced by an obnoxious company.”
For what’s is worth there are lots of NTs who would judge you for wearing a heavily advertised product. The amount of NTs who wouldn’t be caught dead in an Adidas or Nike product must be counted in millions and some probably take it up all the way to brands like The North Face.
ETA: to clarify this isn’t about avoiding one brand because they stan another but about avoiding any brand with a given level of mind share.
Suddenly, user stories remind me of Dungeons and Dragons – living in the head of my character.. the more you could get into his or her life, and forget your own motivations, the more enjoyable and successful the game was. Thanks!
I think it’d be detrimental in the end due to stereotyping, but the thought of a bunch of SW engineers in a room hunched over character sheets and rolling dice during a session of user story design is deeply amusing.
Perhaps there’s a kernel of usefulness there. If designing a product or group of products that might be used by a team with many roles, then spending an hour or two to “build a character” and then RP them using the hypothetical product(s) for an intensive design session with your coworkers RP-ing their own characters could be useful. I wouldn’t do it all the time, but there could be some good in it. It’d take a pretty strong team to do, however.
I think that’s brilliant! Assume that “Papers and Paychecks” is a game and start by rolling up a character!
I would distribute points from a pool, with certain requirements for working in different fields. For example, to work in marketing you need very high CHA, but that would leave fewer points to give to INT and WIS…
That makes sense. I wonder whether there’s a product that could be built from this discussion?
Assume that “Papers and Paychecks” is a game
It is:
https://www.drivethrurpg.com/product/227291/Papers–Paychecks
And long before that, as the blurb notes, it was a cartoon based on Advanced D&D. (I can confirm that from personal experience at the time. IIRC there was even an RPG with that name back then, though it was never officially published.)
I’d seen the cartoons years back. I never knew that someone had actually turned it into a game – some people have too much time on their hands!
It is, as of a couple years ago. https://github.com/rpgreview/papersandpaychecks
Eric, you should consider looking into User Personas and Customer Journey Mapping and Design Thinking.
Everything you’re talking about has simply shifted into the UX role over the past 10 years.
>Everything you’re talking about has simply shifted into the UX role over the past 10 years.
I have no reason to doubt you. Now explain to me why a software engineer who wants to be really good at what he does shouldn’t make himself able to do “the UX role” at least competently. And, in pursuit of that, learn this technique.
> Now explain to me why a software engineer who wants to be really good at what he does shouldn’t make himself able to do “the UX role” at least competently. And, in pursuit of that, learn this technique.
At least at the companies I’ve been at thus far, they do!
It might be less common to see involvement the further from design the software engineer sits
Isn’t that part of the problem? UX is seen as a layer to put on top of the code instead of being built into the very bones. We’ve all seen how well that works in practice.
Integrated teams don’t see it that way. But it definitely can be!
> from becoming a deadening parody
A group of us would refer to our current development process as “Scrumfall”. Waterfall development with daily scrum meetings. Because management and process or something.
I believe the term of art is “Waterscrumfail”
Are there competent engineers who don’t use either shorthand or multi-word descriptions when starting “As an X, I want to do Y” stories? I’ve seen approaches where the designers have a set of characters like Joe, and they would start a user story as “Joe Novice wants to convert a large Subversion repository to Git”. Others would write “A very junior developer, new to an organization and to our software, wants to convert a large Subversion repository to Git.”
At that point, the first two questions should be: Does the software help with this? (Obviously yes; this is a simple version of a key purpose of the tool.) Okay, but this user is a novice, so how do they figure out how to do what they want? (This is why conventions are so important for user interfaces. They provide a design language that makes it easier for the user to explore features and functions.)
For a more experienced user, the second question is instead: How easy is it for the user to do what they want; what do they have to recall as opposed to recognize?
The third question for both types of users usually ends up being: What complications are they likely to run into, how do they recognize those, and how does the software help recognize and handle the complications?
>Are there competent engineers who don’t use either shorthand or multi-word descriptions when starting “As an X, I want to do Y” stories?
Well, there’s me. That formula didn’t exist when I learned the user-story method just after it was invented in 1998; one source I tripped over suggests the formula wasn’t invented until a couple of years later in 2001.
My objection isn’t to using the short form, it’s to thinking that you can or should stop there.
That’s my problem with the formula as well. At my current company the development team I’m on does in-house software. We started officially using Scrum a few months back. For the most part that’s great, and does to a large extent deliver on the promise of bringing at least some of open-source methodology to a business development group.
Except, like I said, we do in-house software. And the new development group I’m on (as opposed to maintaining the legacy software which the newer stuff will eventually replace) spends much more time on internal design and testing compared to getting feedback from the company workers using the software. (I’m not saying it’s not important, just proportionally in terms of number of tickets we so far have done a lot more internal work than “customer” facing.)
So the vast majority of tickets in our system have a description that is “As a developer, I want to (fix bug x | add feature y), because (we don’t want the software to have bug x | we want the software to be able to do y).” For me, the extra cruft beyond “fix bug x” or “add feature y” is just template text that doesn’t add any real information. Obviously it’s a minor irritant but it’s frustrating when things like this that are meant to improve a process and up just being fixed formulas.
Yeah. Instead of saying “because I don’t want to have bug x”, t should be “because I don’t want t have .” That is useful guidance to the guy who’s actually fixing the bug as to what a good fix needs to do. Similarly, add feature y” should be in terms of “so we can do .”
I suppose the idea of shifting mindset to tell yourself a user story applies more broadly to system design: software, RPG adventures, boardgames, household chore duties. Having studied software engineering in the early 90s and then reading the first XP book in ’99, I had taken for granted that anyone speaking of Agile understood the foundational principles. When Agile buzzwords started coming out of the mouths of clients in the marketing realm, I concluded it was just shiny-thing chatter because I could see no evidence of people claiming “we’re doing this project in an agile way” of actually matching the definition. Gradual corruption into a static set of rituals does explain how we got here.
I always appreciate when you integrate the pieces and then conclude with actionable advice, Eric.
> …a kind of roleplaying exercise…
Found the problem. What follows is painting in broad strokes from my professional experience. Design by user story (and agile generally) falls down when a project’s requirements mostly come from the dev team itself. But when they mostly come from external users, (e.g., paying customers, QA, marketing) then this methodology shines.
If I was a PM and saw the behavior you’re observing in my team, I’d so some combination of dumping agile or disciplining the team to quit navel-gazing and get a feedback loop with external users going.
Bahahahaha. You want to keep your job, don’t you?
In a typical agile shop, the customer is represented by a person with a special role often called a Product Owner, or sometimes Business Analyst. The development team’s requirements come from the PO, and the PO generally prioritizes work and approves changes once they’re complete. Oh, and sometimes they get rather tetchy if you should propose having the developers talk to actual users rather than these officially blessed intermediaries.
I’ve seen that. Even if the BA is smart, which not all are, and comprehend what the users tell them, which not all do, they’re still not going to have the knowledge of a user. I get why BAs were invented; I’ve seen how incoherent users can be when asked to explain their processes. But most of the BAs (and PMs) I’ve seen are ex-programmers and they just end up as extensions of the programming team.
In my mind, “agile” jumped the shark really early, when it was captured by the training and certification industries. Then it became just another check-mark on your CV.
Are you a “certified scrum-master”? ;-)
Some good ideas there, though.
> a trick you play on your social-monkey brain that uses its fondness for narrative and characters to get you to step out of your own shoes.
Along these lines, some advice that I would give to my past self:
“Yes, you have a social-monkey brain too. Sure, you’re a little better at math and probability and decision theory than most people. You avoid falling into some common traps and, on the right kind of problem, you can code circles around other people. But your ‘hardware’ is still a gigantic kludge hacked together by a couple million years of evolution that is far better optimized for playing social status games than anything like programming or mathematics. There’s no shame in this.
What is shameful is trying to pretend that this isn’t true. You’ve got special purpose hardware to think about narrative and social dynamics; it runs several orders of magnitude faster than what you think “correct” reasoning is. You shouldn’t blindly trust it, but thinking in terms of narrative does not make you a lesser thinker. Refusing to think in these terms is a pointless handicap you’re giving yourself.
It also makes you more susceptible to someone else manipulating you, because that social-monkey brain did not go away while you were pretending you could ignore it.”
I’m not sure how many other people have fallen into this trap, but I suspect it’s at least somewhat common among aspiring programmers.
Eric, that’s a very, very find critique. I will be following this thread very carefully.
*Sigh* “…fine critique.”
Design by user story … maybe this is the wrong question to ask, but is there any relation between this and behavioral driven development?
I find it a little disturbing that developers require a specific mind-hack in order to EXPERIENCE EMPATHY, but nonetheless this is very insightful.
It’s not that they require a mind-hack in order to experience empathy, but that they need that mind-hack to understand how someone not in their tribe would do things.
Most people can’t model how people outside their tribe think. It’s just that most of them aren’t building stuff that *require* you to think like someone outside your tribe.
Most people (at least before the modern educational/media system got rolling) at least understood that there *were* people outside their tribe, who *thought*. Presumably differently.
Developers, in 20+ years of experience working with them without being one of them, generally aren’t that advanced in their understanding of the world.
‘Insular’ is a hilarious understatement.
Yeah, but how does one reach the conclusion that there exist not-tribe, of different customs and culture?
By spending time with them in an environment where they behave and speak in ways that one can tell is alien.
If you spend time with developers in a developer space, you are seeing them when they know that behaving as a developer will be seen as appropriate. How do they behave at Church, etc?
Developers experience retrospective empathy well enough. The issue is predictive empathy, where they tend to expect that the other party will have emotions typical of a developer.
If I remember correctly I have originally met what you describe as user story (or user scenario) in some now old article on Joel on Software.
On the other hand the mnemonic “As an X, I want to do Y”, or rather “As a , I want an (so that )” is a good shortcut to describe requirements coming from external users – and to not forget that a feature should have a “business” goal (in the case of your example it would be what for the old Subversion repository is being converted – if it is for a tool that is no longer used, and shares no history and no ideas with current work, it could be stupid busy work; though maybe as “sharpening a saw”…).
It was meant to read “As a ‘Role’, I want an ‘Action’ (so that ‘Benefit’)” – I forgot that WordPress strips everything that looks like HTML tag, in angle brackets.
I never understood the big deal with made up personas. I see what people are trying to do, and what you get out of it in your example, but in my experience it’s a lot of chlichee slinging, because people don’t actually understand the people they’re trying to imagine. Now people tell me I’m not an empathic person, so it could just be my personal deficiency here, but I also recognize clichee when I see it, and I see it nearly every time “agile personas” are used.
I think the way to good UX is simpler, albeit more involving: talk to your users, and observe them. Find their microfrustrations and remove them. This is very much the old way of doing UX, but so far the legwork involved in doing has always paid off for me. People are more complex and diverse than I can imagine, even with “brain hacks”.
The whole agile thing is about better communication (more frequent, and involving the stakeholders more), and that part absolutely works, even if the process part of it is perverted. It’s odd that you’d pick the thing in there that avoids communication as worth pursuing. Personas are a stop gap measure for when you can’t talk to your users, maybe something for secretive startups, but when you’re working out in the open anyway, why bother with them?
>Personas are a stop gap measure for when you can’t talk to your users, maybe something for secretive startups, but when you’re working out in the open anyway, why bother with them?
Well, one reason for me is that getting FTF with my users to do UI testing would be difficult and expensive; they’re scattered all over the planet and I don’t have a corporate budget backing me up.
Even if I did, how many managers would pay for that?
There are various screen sharing programs that would enable you to “sit at their shoulder” in real time anywhere in the would, and most of *your* users understand enough to be able to set this up.
Getting feedback from actual users does not obviate the usefulness of personas. The personas are composite characters, or other abstractions of your actual users. They help you weave together the bits of feedback you get from your actual users into a cohesive… well, story.
You’re lucky if you can meet all your users in person, but usually you can meet at least a few, and with a little bit of encouragement they’re happy to talk about their personal gripes with the software in my experience.
Of course, if we’re talking about reposurgeon, we’re talking about a tool with very few users that might actually be difficult to meet in person. But then again, they’re probably also smart and know how to express themselves with some precision, so that text or phone communication can be a substitute. It might be more difficult to talk to them, but why should that be an obstacle. It’s what I meant with “legwork” earlier. Or we could think about how “telemetry” maybe shouldn’t provoke an immediate knee-jerk avoidance reaction.
As for managers, they haven’t been an issue with this for me. Whether it was about a conference (a fancy way of saying that devs and users meet) or providing field support (same thing on an individual basis), management tended to be reasonable, i.e. some expenses aren’t an issue when the feedback is positive.
It’s not so different when it’s about private projects that maybe you can’t or won’t spend money on. What you spend instead is time. My argument here is that talking to actual users instead of imaginary ones is worth the developers time, because the insights gained will be more relevant, hopefully leading to a better received product.
Relax Eric, the people who are good at agile are still using your “user stories”, it’s just that the terminology has changed in the past decade.
(Is there lots of bad agile practice around? Of course there is. No process or methodology cannot be misapplied. Around here it’s most often called wagile, waterfall agile, by people trapped inside old fashioned organisations trying to be trendy. Others call it agile cosplay.)
Your “user story” is now called an “epic” by the software development managers, perhaps a “journey” by the higher level and less technical user experience people. The “users” themselves, Joe and Jane in your example, are now “personas”. Other than that, (good) agile developers are still doing what you described.
So what’s with the “As an X, I want to do Y” user stories? Just the new name for feature requests. I don’t know why the name changed, but they are genuinely useful.
Writing “As an X” is a brief reminder of the skills and expectations that the user has. In some agile teams the personas were all thoroughly discussed and developers don’t need any more, in a sufficiently large project it’s the name/role to look up in the project Wiki. (And if X isn’t in memory or the project Wiki, “wait, when did we agree to expand the project for X?”)
Writing “I want to do Y” is a brief reminder to the developers that a new feature should actually be of some benefit to someone. Agile emphasises YAGNI.
And forcing the whole thing to fit on a post-it or index card discourages over-specification up front, another agile value.
>Relax Eric, the people who are good at agile are still using your “user stories”, it’s just that the terminology has changed in the past decade.
Thank you for that positive and intelligent response. The book I’m not-so-secretly working on now includes this:
The blog post from which this episode was expanded elicited the expected flurry of comments from programmers inside organizations at which “agile” had become a dead set of static rituals and “user stories” have devolved into exactly the formulaic parody described here – or worse. However, I also got a report that some current variants of agile use what I learned to call a “user story” under
different terminology, labeling it an “epic” or a “journey” and fictional users as “personas”.
Fair enough; “persona” is, I think, better terminology, though I find “epic” and “journey” a bit grandiose for my taste and would prefer a less emotively loaded word like (say) “scenario”. But the terminology
is relatively unimportant – map, not territory. The important part is
holding onto (or rescuing from the wreckage of “agile”, if necessary) the technique that it points at.
“Frito rolled his eyes heavenward. It was going to be a long epic.”
The thing is, most large companies, and quite a few small ones, are intrinsically unable to develop in an agile fashion. Oh, they do user stories, epics, sprints, daily standups, and all the other trappings of agile. But they miss the core idea of agile, which user stories is only part of the edge of. And that is the user feedback loop.
If you aren’t writing small chunks of usable functionality, releasing them quickly, and getting user reactions to improve what you wrote – you aren’t agile. It doesn’t matter if you check 100% of the other boxes of agile as it is currently preached by the consulterati. And I would argue that if releasing small chunks quickly and iterating is all you are doing, you are.
Don’t get me wrong, the way that the ceremonies are organized is useful. Standups remind people that they should have at least one thing they did every day to talk about. Sprints are useful for leadership to apply pressure to increase velocity. The end of sprint planning showcase and retrospective provide everyone a day without useful work to recharge. And all of these are a way to show upper management that your team is doing something, and thus should be kept around. But none of those things are specific to actually developing software in an agile fashion. They are can be (and in fact in medium to large companies usually are) used to help manage decidedly non-agile processes.
The user story is a helpful way to organize what you should be iterating on. But it’s the iteration and interaction with the user that’s important.
My experience is limited but I have actually never seen this done. I have a suspicion, from reviewing student placements, that they may not even know that frequently iterating code with the user is what makes ‘agile’ agile. It’s degenerated into a buzzword.
What Hugh said. I came here to say it. I’ll just add a few points as a coach of teams who are adopting agile for the first time.
As a very early step, the team defines personas with as much detail as in your description of Joe. In my world of enterprise IT, the teams work on internal systems. Their personas are composites of real people that the Product Owner and other team members know personally or by reputation.
Some of these teams like using mnemonics for the persona names (e.g., Joe the Junior Developer), and word their stories in the form “As Joe, I want…” rather than “As a Junior Developer…”.
The user stories refer to the personas to keep them small enough to deliver in a day or so. Joe’s complete adventure could take months to build.
The personas are also useful in prioritization. The Product Owner may decide to focus on helping Joe reach a certain level of competence first and to address concerns of “Sue the Sys Admin” later. By anchoring priority to the personas that the whole team knows, everyone understands the decisions and can challenge them productively.
The significant difference I see is that users usually tell me where they want it in the user interface when I ask for a user story, while they don’t if I ask for a feature request.
User story version:
“Stephen the Spreadsheet Guy right-clicks a chart he’s inserted in his document, chooses ‘Edit this chart’, and changes the markers from circles to squares.”
Feature request version:
“I want an option to edit an existing chart so I can change the markers from circles to squares.”
“We added this functionality last year; please upgrade to the latest release.”
“I’m on the latest release! It must have a bug.”
“I can’t reproduce your problem. What happens when you try?”
“The option isn’t there!”
“Are you sure? Go to Edit > Charts > Modify Existing and pick the one you want to change. Which step ‘isn’t there’?”
“That’s stupid. Make it so it shows up when I right-click the chart.”
Yeah, I’ve seen this applied to a different field by a programmer.
This guy using the handle Mailanka is doing an adaptation of Star Wars to GURPS, attempting a replication of the feel without being tied to the IP and design choices of Star Wars.
Mailanka is a programmer, and very early in the project described four personas for understanding aspects of player needs that may conflict.
I spent the evening yesterday with the owner’s manual provided with my daughter’s car.
Just the “X wants to do Y” thing would have been a giant step forward for the team writing and editing the manual, index, table of context, etc.
User Stories as most agile shops know them today come from Extreme Programming (XP). I daresay they co-opted the idea from the Usability space but it serves a different purpose. The original XP “Stories” were intended as a short bootstrap description into the thing to be developed. It was never intended as an end, merely a beginning. The phrase frequently used was “promise for conversation”. “Lightweight Use Cases” was also used.
A description by Kent Beck is “The story is used by the customer to make informed decisions about the scope of the next release, decisions informed by the estimated cost of the story and the velocity with which the team can develop. When the story’s iteration rolls around, it becomes a work unit by being split into tasks (or not on smaller developments) and a test unit by being coded as a bunch of acceptance tests. ” (Note: “Customer” here refers to the XP customer, as in the one who is the gold owner of the system) The point of the index cards was to allow you to pin it to a story board. Also, if it had to fit on an index card you had an explicit cap to how much you could put down without having to split it.
You mention “As a X I want Y”. This came about through Behaviour Driven Development (BDD) which at it’s core is a slighty alternative methodology to TDD. It’s also missing one of the core pieces… “So that Z”. The idea was given those three sentences i know who wants it (X), what they want (Y) and what they’re hoping to achieve with it (Z). I’m not surprised if you’ve seen versions that drop the “So that Z” because describing the theoretical business value of a story is hard and no-one wants to do it… but they really should. Some even undermine the X but putting “As a someone”…
The original example of a BDDified story was :-
which was followed up with two scenarios :-
(If you’ve used Cucumber before and didn’t know where it’s syntax came from… now you know).
I would echo what others have said, the keyword you’d probably get better results out of is “Personas”. Searching for “Design by Persona” gave no hits but the first hit was an adobe blog post where the sample text was “Creating personas can help designers step out of themselves and recognize that different people have different needs and expectations. By thinking about the needs of a fictional persona, designers may be better able to infer what a real person might need. Identify with the user they are designing for.”
Thank you for taking the time to write this up. I’d like to say that because you wrote it, the open source community will listen, have some clarity about what agile and user-centric development are all about, and finally up its UI game. But who am I kidding — it’s 2020 and there’s a growing list of transgender people with blue hair who have more pull in the open source community than you do. And the leading desktop for Linux — GNOME — is still playing the same “let’s pretend we’re Steve Jobs and tell our users what they want” game they have been playing since the project’s inception. But the old-time hackers will listen, as will those who aspire to be like old-time hackers.
I especially like the elucidation of what went wrong with corporate agile — which I often compare to Mornington Crescent. Like the British radio game show, in every agile show I’ve been in, agile is ostensibly supposed to have one set of rules and one set of goals, and everybody talks and acts as though this were the case, but there’s actually a hidden game with entirely different rules and goals being played. It’s refreshing to hear voices like yours — people who are Big Deals in the programming community and even Big Deals in the agile world — acknowledge this discrepancy between stated and actual goals and explicitly call it out.
“it’s 2020 and there’s a growing list of transgender people with blue hair who have more pull in the open source community than you do.”
This is not a feature.
Though I’d s/people with blue hair/people with blue hair who have never slung code for a living or even a serious hobby/ .
Just as an illustrative counterexample, one of those bluehairs was the head of Linux’s USB3 efforts before they dropped out.
Which is why my change is pertinent.
As Eric says: show me the code!
> I especially like the elucidation of what went wrong with corporate agile
I’ve worked in 3 shops since 2012 that did “Agile” to one degree or another.
One, the one that was least formal and the largest company (probably) did it best because somehow the lead developer managed to create more or less a wall between the organization and the rest of the company, then they did what they wanted internally with little bother from “above”. In part they were able to do this because they did their job REALLY REALLY well. Until a new Director blew things up. In less than 2 years after I’d left almost no one was still there (my leaving didn’t cause it, I was just the first rat off the ship).
Here’s the thing–Culture is *hellishly* hard to change, and Agile done right is a *culture change* from a bureaucratic, top down, silo approach. If you have a waterfall environment, or any sort of top down, executive driven, siloed bureaucracy then Agile (and it’s bastard offspring DevOps) is a MASSIVE threat to large numbers of people who exist simply to move things from their inbox to their outbox.
Agile wants everyone to be involved and to have skin in the game, and TO BE ACCOUNTABLE. Bureaucracies are largely driven by ass covering and blame avoidance.
Presented without further comment from today’s “The Daily WTF”:
https://thedailywtf.com/articles/mega-agile
(Why, yes, I would like to book passage on the ship to Serendip, thank you!)
As a person who works in an “agile” environment, I’d say that user stories *as they are used* are poorly named. Stories have become a description of the smallest measurable unit of work — that can usually be completed in 1-5 days. If we sat down and tought about things that deeply for every user story, there would be no time to actually do the work, or product ownership would require many assistants.
It would be useful to have something between an epic and a user story in size, that captured the kinds of details that you wrote, that actually help with design.
Scrum (and other agile flavors) isn’t a panacea, but when it’s used somewhat competently, it’s far, far better than waterfall. Mostly that there isn’t multiple months or years worth of work that is thrown out when it turns out your design doesn’t meet the users’ needs. Instead, it’s typically 2 sprints’ worth of effort or less that’s tossed. That, in and of itself, makes it worth it in large corporations.
That’s kind of the point I made in a previous comment. “Story” means nothing more than “trackable unit of work” because usually the stuff in the Agile Manifesto doesn’t matter at all to the people actually buying what agile consultants are selling — managers and executives. The only thing that matters is can the work be tracked from inception to completion and performance evaluated for each developer on each task. Everything else, including values like “individuals and interactions over processes and tools” can and will be sacrificed to meet this end. Hence, in a corporate shop, “Agile” usually means doing Scrum with Jira — defined in terms of a process and a tool. Larger shops will retrofit their various Scrum-based efforts into SAFe, which is just RUP with the serial numbers filed off and is all about trackability.
If the only thing that matters is trackability and microaccountability, then why bother with agile at all? The likely answer isn’t pretty: it’s to convince the programmers that the organization is doing one thing when it’s really doing something else. In other words, a game of Mornington Crescent.
Talk about damning with faint praise!
> “Story” means nothing more than “trackable unit of work” because
> usually the stuff in the Agile Manifesto doesn’t matter at all to
> the people actually buying what agile consultants are selling —
> managers and executives.
Then you bright boys and girls need to figure out how to explain to manglement what it’s *really* about.
It’s like “DevOps”–it’s become a meaningless buzzword describing a vague set of technology stacks because *most* of you technocrats can’t (or won’t) think and won’t talk about anything but the technology.
Miyamoto Musashi said “If you know the way broadly you will see it in all things”.
If you can’t lead your managers and executives, how smart are you really?
I think you answered this yourself:
Scrummerfall happens because managers are optimising for something other than success of the company, or the project. From within their own selfish incentives, they are acting rationally by cosplaying agile (so they can look hip and forward-looking to the C*s) while continuing to actually run things in the same old way that lets them play the game of bureaucratic office politics to best advantage. Finding better ways to argue “real agile will help us ship better products and make the company more profitable” won’t help our case, because the managers don’t care about that and the C*s can’t tell the difference — as far as they know, the company is already Doing Agile and what are these developers complaining about?
The only way I know of to avoid this is for the C*s to be developers themselves, at which point they generally find ways to do things without large capital concentrations, thus either small and lean (the startup where everyone knows if they don’t pull their weight they won’t get a paycheque because the company will fold) or without needing a company at all and oh look we’ve just reinvented the open source project from first principles. Where these approaches are inapplicable — where the capital concentration is necessary, and thus so is all the apparatus to protect it from misappropriation or misdirection — the misaligned incentives are inevitable and the line troops will be sad.
> From within their own selfish incentives, they are
> acting rationally by cosplaying agile
Again, if you can’t manage up the chain of command, how smart are you?
*SHIPPING BETTER PRODUCT* is the very, very best thing you can do for the world, which means for your company, which means for your career, which means for you and the people around you.
I’m beginning to see where the SJWs come from when they say “It’s not our job to educate you”. The best of us tried to communicate what it’s really about by creating a movement. That movement was co-opted. If management is entitled to be arbitrarily bloodyminded and still claim “It’s your own damn fault for not effectively communicating” then what’s the point of even trying?
(By the way, the same is happening to open source. Companies like MongoDB are backpedaling hard from OSI-compliant open source to make more money and/or avoid handing the keys to the kingdom to their competitors.)
DevOps became a meaningless buzzword because managers wanted to cut costs by having their devs double as ops people, and along came the cloud companies to sell them on this dream. Of course, it costs considerably more to host in the cloud than it does to host on own silicon, but it saves them the hassle of having to find, hire, and retain good sysadmins!
> If we sat down and tought about things that deeply for every user story, there
Not every user story is worth thinking deeply about. Some of them (like the “bug” I reported up yesterday[1]) are bloody stinking obvious and all the thought required is “Yeah, do that”.
> would be no time to actually do the work, or product ownership would
> require many assistants.
Just create a developer story to think about the user story.
[1] The app I use has a “send on the way text” button right above “mark delivered” button. On at least 4 occasions I’ve been “multi-tasking” and hit the “mark delivered” then “ok” buttons when I meant to hit the “on the way text” button. When you hit the “delivered” button the order disappears, including the address. Meaning you have to call support and get them to unfuck you. This is me being a bozo, but it happens. The “user story” I sent up said “grey out the “delivered button” until the “on the way” text has been sent. This is not something that needs deep thinking about, it’s something that you should hear “oh, no shit. Why did it take us this long to think of that”.
On shadow autists and suchlike: why is it even programmers who should write user stories?
The old waterfall rigidly separated requirements, specification, design, and implementation, i.e. the broadly what, exactly what, broadly how, and exactly how. Only allowed programmers to do the exactly how. First three were done by system designers. Bad idea. We all know.
But are now programmers supposed to define even the broadly what? That is the opposite extreme. At least the broadly what, the user story, should usually not be written by programmers, I mean, ESR writing it is okay, the average programmer not, shadow autist super not.
Another thing is, even if Alan and Bob both know the use cases perfectly, if Alan implements it, Bob should spec it and vice versa. This is obvious. There is a conflict of interests. If you are the one to implement it, it influences your spec in a bad way. Either you hunt for problems with interesting difficult solutions, or the opposite, get lazy and reject requirements hard to implement.
Hard NOPE. If you and I implement two halves of it, you spec mine, I spec yours. No one should be allowed to be a judge in his own case. No one should write the requirements he is going to fulfill, implement.
> why is it even programmers who should write user stories?
As I understand it, *anyone* can write a user story, but a “good” user story should have certain characteristics in it, and not everyone is clued in enough to do that.
Let’s say you have a business app that does something financial. You may have a business user who reports “This value is wrong”. What they actually mean, upon investigation is that “the value on this report is supposed to line up with the value on that report, and some percentage of the time it doesn’t.
That user story is actually going to spawn anywhere from 2 to a brazillion other stories dealing with more specific parts of the backend that a “real” user never sees. For example in investigating this financial app you may realize that you are getting poorly transformed data out of a legacy database–there’s a separate “user story” where there really isn’t anyone we think of a as a “user” involved for 8 or 10 more steps. Can’t have Sally the Reporting Analyst write that story, she doesn’t know ebcidic from double byte character encoding.
Also to have a real “user story” you need to have users, so at certain points in the development there are real users, only potential users. When you are in that phase of the product you really only have managers, programmers and potential users who can generate stories.
Usually, programmers should not write user stories. They (are supposed to) form an extensional description of the system from a user’s POV. The users are the obvious authors if you want good user stories, and each dev team in agile ideally has a user representative, someone who will actually use the system being written. Of course, how things work in reality is often quite different. See my above post about BAs and POs.
Hey Eric, off topic question, but I think you’ve discussed this before. I’m trying to help a friend with their writing, and one of their main problems is with the unspoken rules of how modifiers are use. For example, it’s correct to say, “…big, gray, Victorian house,” but not to say “…Victorian, gray, big house.” I vaguely recall you posting on this at one point, and if not I thought that given your interest in linguistics the problem might be of interest to you. If you’ve posted on this before, I’d love to have the link, and if not I’m curious whether you know of some rules which govern what sounds right (or not) as modifiers are applied.
>I vaguely recall you posting on this at one point
No, I have not posted on this. Summary here.
I think somebody else wrote about it in a comment here. I vaguely remember that.
Thanks for the link. It’s exactly what I was looking for!
Another off-topic comment: I’m a general Linux hobbyist with a little interest in programming, including chess programming. I play with the source code of GNU Chess 3.1 and 4.xx, mostly version 3.1 as I figure the older program might be easier to improve than a later one. But in the course of reading about old chess software, I’ve run across mention of an interface program called Chesstool. The program may have been developed at DEC, which was sold and resold and I don’t know who has the rights to DEC software these days. But I’d like to find and try Chesstool just for the retrocomputing helluvit, and am wondering if any of your connections might have and be willing to post the source of that. I’m running an old i5 and Mageia 7.1, btw, good enough to beat me easily. My modifications to Gnu Chess 3.1 show the maximum depth of a position’s analysis that typically is from 20 to 35 plies. My brain does about 4 plies…
Beyond what I said above, that it is weird that it is programmers who write the user stories and not people whose job is to work with users, not to write code, the one-liners come from that general tendency that there are no universal tools, all tools are only useful for some cases. But tools tend to become bureaucratic rules in orgs, even enforced by software tools themselves. So they think, rightly or wrongly, that in this case a user story is not useful, hence they satisfice.
I am about to submit a bug report about shared-source corporate code, reading the code made me realize they are not sanitizing database inputs in their queries. I could not test it, it requires devices I do not have. Maybe they do it on the device level. Still at least I want to raise the question.
So the bug report form has fields like “expected behavior” and “actual behavior” i.e. the perspective of a user, user story. In this case what am I gonna fill there? “Not getting pwned by Little Bobby Tables” and “likely getting pwned by Little Bobby Tables”? Similar story.
OFFTOPIC: your idea that all interesting human behavior is overdetermined can be explained by saying blows evolve until they are able to kill multiple flies?
There is this big corporation and one of their products, a plug-in to one of their servers that integrates it with a popular webshop framework. Hundreds of people around the world work on selling, configuring and supporting it. It was developed by one dude in Germany. He showed me part of the code. Not a big deal, just mapping, because the frameworks used on both sides are really good. He does not even have to deal with stuff like exceptions, the implementation consultants can just configure the frameworks to report severe exceptions by email and not so severe ones into a log. These tools made programmers really producitive these days, if one guy can create hundreds of jobs this way.
All those hundreds of people interact with users. They should write user stories. Does Agile really say that this one guy who writes all the code should write his own user stories ?!
(BTW when I used to read Reddit they always talked about big dev teams with multiple layers of management and design by contract. Why? This is a popular product written by one guy. What does one need big teams for?)
You need a big team because half of your programmers are incompetent and couldn’t implement “no big deal, just a mapping” with both hands and a map. And you need to hire incompetent programmers because there aren’t enough competent ones on the market to fill up a big team. It’s the ciiiiiircle of life.
(Cynical? Moi?)
Getting permission from the money people to make hiring decisions and knowing whether someone is competent are different skills, and not everyone has both. Predicting a future need for a set of tasks, scraping up the funding, and nailing down a definition of what competence means for those tasks is going to work out badly, some of the time.
When a project has enough inherent complexity, you have to decide how to split it up among more than one person.
Another case is the only available funding is coming from a very large bureaucracy, with processes that are supposed to ensure reliability, and will be hiring some of the workforce union, or civil service, or both.
Consider an example of developing an air defense artillery system, which if selected will be seeing extensive software maintenance over the next forty years. One of your customers is Lt. Col. Tyrone Johnson, an artilleryman serving at the Pentagon with some of the procurement programs. How do you design the software architecture of the system so that you can convince him that the software maintenance will not be so hellishly impossible that the system will be scrapped in a few years?
Anyway, number of incompetent programmers is partly because programmer is so vary wide a range of work, and it hasn’t been as successfully segmented into trainable, certifiable, sub fields as some occupations have.
The layman understands why they might not want to just go find a carpenter when they have a problem with a leaky pipe. Even the bureaucrats in charge of funding large buildings have figured out that they don’t hire aerospace engineers to handle bridge problems. Programming is newer than even Aerospace Engineering, and not only does the public think that a programmer is a programmer, the breadth of programming is complex enough that a skilled programmer may not understand the development and validity of tools used in a different sub field. (Of course, some of the other broad occupations should not be throwing stones about that.)