Outcome Story Templates

In yesterday’s post about Outcome Stories, I don’t think I quite got the story right.

I suggested changing the story from “As a writer, I want to publish posts, so I can share it with readers.” to “To get readers, a post must first be published.” I do think this does put more emphasis on the goal because it’s the first few words of the story.

But, it would be better if it were the subject of the sentence. The subject is what we’re talking about, and in my fix, we’re talking about the post, not the outcome.

So, tweaking it more, you could say “Getting readers requires that the post is published.” Maybe this is semantics. The more important thing is that the goal is early in the sentence, but if it can also be the subject, it will carry more weight.

But, if we go down this route, maybe we can develop a template around it

  • [Outcome] requires [the object] to [have a state]
  • [Outcome] requires [the persona] to [do an action] to [an object]
  • [Outcome] requires [the persona] to [do an action] to [an object] when [a trigger happens]

So, we end up with: “Getting readers requires the author to publish the post when they are done writing it.”

And again we’re clear that this is necessary, but not sufficient to accomplish the goal.

Outcome Stories

User Stories are centered around the user persona, which seems like a good idea, but it would be better if they were centered on a business outcome.

Consider the Publish button in WordPress.

One way to write a specification for this is to mock that screenshot I pasted above in Figma and say what the button does when clicked. Perhaps you’d use the typical User Story format and add “As a writer, I want to publish posts, so I can share it with readers.”

That works well in the sense that the production software will probably do what was specified. But, we’ve lost an opportunity. The story is focussed on a persona, but doesn’t emphasize the goal. I’m not even sure the persona matters at all here.

And just like no one wants a drill, I don’t want to publish. I want to influence readers. Others might want ad revenue or newsletter subscribers or to sell books. So, can we take the opportunity in this story to remind everyone about the business goals? The final state is not a published post.

It seems like a small tweak, but I’d word it “To get readers, a post must first be published.”

And now it’s obvious that this is insufficient. Yes, we need a Publish button, but that won’t accomplish the goal. This wording begs for more features to support the actual goal. It also implies that the metric for the success of the Publish button is the number of readers not (for example) the number of published posts. How would the design of publishing in WordPress be different if it was centered around the business goal of the users?

Publishing should lead directly to distribution, but in actual WordPress, the end of the publish step is a button to copy the link.

I guess I’ll go tweet it myself.

Sell Your Learning Plan, Not Your Roadmap

The reason software companies adopted agile practices was so that they could adapt their roadmaps to whatever they learned along the way.

If you learn something and do not change the roadmap, then there was no point to learning it. You might as well be doing a waterfall process. I think everyone accepts this. After all, waterfall is a myth. No one really thinks that the roadmap is set in stone.

But the business needs to plan. Marketing has events that need lead time to develop messages and material. Sales has prospects that want to know where the product is headed. Support, Training, and the Documentation team need time to get ready for new releases.

Some of this can be solved by developing support material alongside product development. For example, an embedded Product Marketing Manager can be closely following the trajectory of the roadmap and be developing messages at the same time. Even better, they can be helping to shape the roadmap from insights they get from their customer engagement.

The hard part is what to do with prospects. If you’re Apple, you never talk about what’s coming until you are ready to sell, but most of us can’t do that. Our prospects will certainly have unmet needs, and if you know you are actively working on them, it’s tough not to tell them. But, what should you say?

The truth is you don’t know the roadmap beyond the next few sprints. You are actively hoping that you learn something that will change it. New information is highly correlated with innovation.

But you are not changing your mission as easily. You know which customers you want to serve and what jobs of theirs you want to help with. So, talk about that and not the specific features you currently think will help. And talk about what you do know is coming (if you want). Even in a learning organization, the short-term roadmap should be pretty solid.

Product Development might not be able to commit to exact features, but they should commit to a learning plan, and that’s the roadmap that is safer to talk about.

An Unnamed Programmer in Peopleware is One of my Heroes

I read Peopleware early in my career and revisit it every few years. Yesterday I wrote about what they meant about 10x programmers, and while doing that, I looked for this excerpt, which I think about all of the time (emphasis mine).

One of the upper managers buttonholed me to request that I assess […] his project staff. He was particularly curious about one woman. It was obvious he had his doubts about her: “I don’t quite see what she adds to a project; she’s not a great developer or tester or much of anything.”

With a little investigation, I turned up this intriguing fact: During her 12 years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn’t obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talking to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them.

Peopleware

They go on to say “The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who just do work.”

I don’t know who she was, but this programmer was one of the most influential role models of my career. I constantly ask myself what would she do. My post about How Senior Software Developers Think is my take on it, but it’s much more than that. Coding is certainly an important part of being a software engineer, but most projects can technically be done by a wide range of coders. The other skills, the work that makes the project succeed, are a lot more rare in my experience.

How to Become a 10x Programmer

The idea of the 10x programmer probably originated with Peopleware. The authors ran pairs of developers from the same organization through a “coding wars” exercise. They collected data from many organizations over several years and measured that the best coders did about 10x better than the worst and about 2.5x better than the median ones.

But, probably everything you have heard about what that means is wrong.

For one, even though the pairs did not work together at all, their results were highly correlated with each other. Secondly, the participants in the exercise worked at their desks in their normal working environment. Finally, there wasn’t a correlation to experience level or technology used.

The authors conclude that the organizational environment and culture is a major factor in the effectiveness of its programmers.

The bald fact is that many companies provide developers with a workplace that is so crowded, noisy, and interruptive as to fill their days with frustration. That alone could explain reduced efficiency as well as a tendency for good people to migrate elsewhere.

So, how do you become a 10x programmer? By changing jobs to an organization that provides an environment where you can be effective.

Recommendation: Digital Zettelkasten by David Kadavy

I just bought and finished reading Digital Zettelkasten by David Kadavy. It’s a quick read and a good companion to How to Take Smart Notes, which I talked about in Write While True Episode 2: Small Bits of Writing and Write While True Episode 3: First Drafts.

Like David, I think of note-taking as primarily about writing and is the starting point of my original writing. His book covers his workflow, which is a lot like mine. I got a few new tips, but it was mostly a reinforcement of how I think of note-taking.

As I covered in my podcast, I “read” by writing. At the end of reading a book, I have generated bits of writing in Obsidian and flash cards for Anki (covered in Write While True Episode 14: Spaced Repetition). This has helped me retain the information I have read, have new ideas, and develop them into new writing.

If you write, but don’t currently have a note-taking practice and would like to see how one writer does it (in detail), this book is worth your time.

June 2021 Blog Roundup

I took a few weeks off to travel, see friends and family, and get some rest.

WWDC was in the beginning of June, so I wrote about that:

I also wrote about software process and testing

I also took a break from podcasting, but made these in June:

I expect to have an episode Monday on taking breaks.

Put Aggravation (and Joy!) in the Spreadsheet

When I am trying to figure out if something is worth the cost or how to charge for something, I might build a little model in a spreadsheet. All the things that can be expressed as a number probably end up in it. What usually makes the difference though, is when I force myself to express my mental costs and benefits as a number too.

For example, I like my apartment, but sometimes I think of moving. Maybe get a condo instead of renting. But, when I put the numbers together, if I make line items about my “feelings”, I see that I can’t justify the cost difference. I just don’t value what I’d get and I personally find some parts of home-ownership very aggravating.

The same kind of line items also show up when I am trying to price my consulting services. I price in my feelings. I want to be neutral to the customer’s choice. It’s the standard “say no with a number” advice, but this is how I get to that number.

Write While True Episode 15: Combine Identities

I made this podcast, but I wanted to self-host, so I learned how to do that with s3 and wrote my own way to get analytics. So, Podcasting leads to programming. And then I wrote up a blog about that program (so it led back to writing) and now I am telling you about it on this podcast. Round and round it goes.

The more times I go around the circle, the easier it becomes to write or podcast or program about one of the other things I’m doing. The content for this podcast is mostly taken from a blog post I made in February. Back then I just said that I should come up with some way to combine programming and writing more. This podcast was the result of that thinking.

Transcript

Waterfall is a Myth

I think everyone who programs has heard the story of the failure of the waterfall process.

Back in the olden days, to build software someone would first write up a document with all of the requirements. Then, the software architects would design a system and produce a document with that. And, then, I guess there would be some kind of implementation plan and that would be completed. Then, the programmers would code it up. And finally, the testers would test it. Then, you ship it.

It looked like this:

I’m going to say that I think this never happened in real life. I doubt anyone seriously tried it for anything big. Or, if they did, I hope they failed super-fast and started over.

This diagram comes from a 1970 paper called Managing the Development of Large Software Systems by Dr. Winston Royce. Right after this figure, he says: “I believe in this concept, but the implementation described above is risky and invites failure.”

Then he goes through a bunch of fixes to the process and ends up with:

The process as described seems completely reasonable to me (see the original paper) . It features

  • Code review
  • Automated tests
  • DevOps manuals
  • The idea of a spike implementation to learn and de-risk the real one
  • Including Customers in the process (every circle icon in the figure)

So, even in 1970, it was known that waterfall could never work, and the term was only coined later to describe Royce’s first diagram, which he had immediately rejected.

I think waterfall only really existed as a concept to immediately reject and fix, not a serious suggestion for what to do for a large software project.