Archive for May, 2016

User Stories

May 9, 2016

Before the internet, back when geeks wrote software that they later sold to geeks, there was functionality. Designers today comment about how bad it was. There was no UX. There were no HF people or UI designers or designers of any kind (aka art people). Well, there were software designers (geeks). There were geeks and there were economic buyers. Those economic buyers were not users, but bosses of users usually separated by layers of other bosses.

If you were discontinuous, you didn’t sell to IT, so there was no requirements analyst that later studies found got in the way of collecting requirements, because they insisted that carrier trumped carried.

But somehow software got written and used, software companies sold software, and economic buyers got the competitive advantage they paid for. But, how? Technical writers had to turn functionality into user tasks, trainers had to do task analyses to find out what we now call “the job(s) to be done.” No ethnography was done either. Care was not taken to capture the cognitive model of the users. So, instead, the users were taught how to get from functionality to the tasks or jobs to be done. Users who knew how to think about their jobs and how to do their jobs were taught how devs would think and how devs would do their jobs. Obviously, the mismatch was huge. Unfortunately, the mismatch, the gap, is still there.

Technical writers had to go from a context ID referring to a particular dialog to a task, but only one of the tasks that could be done in the dialog or through it. There was no one dialog one task rule back then. So some tasks fell through the context ID gap. Even today a context ID does not refer to a user story.

Sales applied the feature-advantage-benefit (FAB) framework. Benefit translates to task/user story/job to be done. Sale reps can turn any feature into a FAB statement. Back in the day, everyone compensated for the developer. The developers didn’t notice most of the time.

Technical writers could turn any feature into a task. I remember one particular task in a manual, “Using Independent Disk Pools.” Beware. “Using” is not a task, and this task is a fake task. No user woke up in the morning thinking, “Hey, I get to use the independent disk pools feature today.” No. They woke up thinking, “Hey, I’ve got to set up geo mirroring today. Setting up is a real task.

User stories can fail just like those feature to task conversions.

Agile succeeded in the internal IT context. But, when Agile escaped that context, I can’t say either way. The one vendor I worked with that was Agile, failed. There was no communications outside the dev team and that was much smaller than the span of control of the VP of Dev. Other people still depend on clear communications about what is getting done. Agile made developers even more reclusive.

So when I encountered the user story tweet, I had had enough of the Agile evangelist. I need to know what the size of the typical deliverable will be, and when it will show up. If you can’t tell me that, you won’t be on my team. Agile, DevOps, this method, that don’t help me even if they make Agilists artists and uninterested in money.

Somehow Agilists are supposed to be ethnographers, marketers, and managers while keeping their coding skills up to date. The point of all the people making up the rest of the firm is specialization, knowledge, silos and all those things that make dev hard. Sorry, but I need devs that can code. I don’t believe they can do it all. Just like I don’t believe in the business generalist. Yes, your bosses boss took your job 101 back in college. He knows it all. Hardly.

But, what about using user stories when developing architecture? What about that “ideal architecture?” There is no ideal. There is now and there is yesterday. There is today’s users and yesterday’s users. There are users seen through the lens of the technology adoption lifecycle phases. Then, there are users seen through the lens of the pragmatism steps that fragment the phases into tinier populations.

That pragmatism is a problem for marketing, sales, development and everyone else. When we operate on a scale wider than the pragmatism step, we tend to mix the populations and smudge the addressability and cognitive fitness of the software, marketing, and ultimately, the firm itself. On a pragmatism step, the population references its own members. The early adopters are not in the reference group. They are too weird, too early. The early adopters are on a different step, so their opinions and results don’t matter at all.

People in firms are on different pragmatism steps, so firms are respectively on different pragmatism steps. The people in firms refer to each other to the degree that they are on the same step. Likewise, firms tend to show up at tradeshows with the other firms in their reference base.

This makes the ideal a difficult proposition. A developer could get stuck on a particular pragmatism step. That developer could be very responsive to those users, which just serves to isolate the developer and the application they are developing.

Sales has to address the step of the current prospects. Marketing has to address the steps of the retained, incumbent customer, the step of the installing customer, and the step of the prospect. Way too much is going on. Likewise, the developer can’t just sum the distributions and hope for the best. The segmentations must be preserved.

Those pragmatism steps do give a product manager the ability to price the app each independent population differently. Each group would never hear what the other group is paying since they don’t reference each other.

Aspect-oriented programming can help with all these segmentations by taking the segmentation into the code itself.

I’m very much a no tradeoffs, no averaging of functionality, no gaps in the cognitive models, and one use case to one feature person. Stop the smudging. Stop the averaging. Stop the trading off. Alas, I want too much.

Architecture is a developer facing thing. Developers are the users of an architecture. Much of the ease of what developers do these days is due to the underlying architecture. The easier it is to do, the longer its been around in the stack. The longer its been in the stack, the less likely its got a user story written for it.

Much of what developers do these days is about coding carrier functionality. Drawing the lines between carrier and carried is difficult, but it gets harder when you’re drawing the line between carrier and the next layers of the carrier stack. Different populations own different portions of the stack, so there are different terminologies, cultures, perspectives, points of view. The user in the stack is a developer, but a different developer. Who is doing this? The 101 guy or the PhD in this? The developers that think their developer users are just like them are in for a shock. In the old days we could write an API and not worry about it being copied as long as it was easier to use than write or rewrite.

A clear definition of the user is essential. The user story is just part of getting to that clear definition. Keep in mind that form is not the issue.

There is the expert’s cognitive model. It has overcome the all the plateaus. Each performance plateau constitutes a segmentation of the population. Not every use has encountered the trick to get beyond this or that plateau. Not everyone is an expert. An application built on that segmented cognitive model will also have to deal with the transitions between those levels of expertise. How will your users get from novice to mid-level performance? Where is the ideal here? The segmentation can help you keep ideal limited to one particular scope of the cognitive model.

The pragmatism steps get spit into carried and carrier as well. Architecture gets split likewise, so the pragmatism segmentation plays here as well keeping the carried expert clearly separated from the carrier expert. There are two pragmatism dimensions. Have fun with that.

I know I tweeted about other dimensions of the user story as pathway to the ideal architecture. But, it’s been a while.

It’s probably easier today, since the task analysis actually happens earlier before stuff gets written. The 101 ethnography gets done as well. We observe. We interview. But, we are not ethnographers. Spend the money. Encode the cognitive model. We don’t do that today. Instead, we rely on the developer’s idea and hope a population springs up around it. Lean checks that a population actually emerges. Not everything can be lean. Lean is where we are today on the technology adoption lifecycle. Lean would not have gotten us where we are today. We have the stack. We rely on that stack of ole.