CTPopup1

Recently, I've had several projects that had very little structure to them, and seemed to drag on forever. It's frustrating for everyone when a story/ticket/etc has been open for days and days, or even weeks and weeks.

For the product owner, it gives them very little visibility into whats going on, and it makes predictability difficult. Product owners and folks in business leadership usually care hugely about predictability. In fact, that is often one of their biggest concerns.

For the developer, it's demoralizing. This story was only 2 points, it was supposed to be easy, and here we are on week 2? What's wrong?

Here are a few strategies I use to turn this problem around:

  1. Define exploration vs building Often times, when the story drags on forever, it's because work we thought was well defined, wasn't. When this happens, I recommend breaking out the spike or exploration work, separate from the implementing. Make the original story an exploration or spike (possibly with no points, depending on how your team thinks about story points), and add a note that you will write up follow up stories once you figure out what they are.

  2. Break out stories As you figure out the different pieces of the work during the spike, add in stories. Flesh them out fully, because your future self won't remember the context of your three word reminder. These stories should be a much smaller piece of the original, too big story.

  3. Break down tasks smaller Once you've added your smaller stories, and you're ready to stop exploring (for now) and start building, break down the steps of your task. By now, having explored, you should have a pretty darn good idea how to build this, so you can get pretty fine grained. Try to make each step something you can accomplish in less than half a day, and ideally more like 2 hours. For my brain, nested lists inside nested lists helps me get to the right granularity.

  4. Find meaningful chunks of work and notice that they're done One of the most demoralizing things about the endless story is that you have no sign of progress and your brain doesn't get the “I finished a thing, hooray!” dopamine hit. Many of us need that, and need an extra dose of it, to keep going. Make sure to stop and notice what got done. Check the box, click done, just breath it in. Notice your progress.

  5. Merge often To the extent possible, aim to commit to main/prod daily, once you get to building. (After you throw away your spike!) This helps with feeling a meaningful sense of progress and accomplishment, and it keeps you and your teammates in sync. It might, sometimes, need feature flags, and that's a worthwhile investment. Smaller change sets are easier to review, and easier to examine if something breaks.

  6. Use an exploration doc for exploring I think more details on this might be an upcoming topic, because I really love my exploration doc format. I write down the question I'm exploring and how I plan to explore it. I take quick notes as I observe things that are interesting. Then I write down the next exploratory question, number it, and repeat, in a running google doc.

I would love feedback on my newsletter, even just a thumbs up, thumbs down. Is this interesting? Would you like to read more about a specific topic? Let me know what you're thinking. You can find me @ctaymor@hachyderm.io or reply to the email.

Recently, I've been working on some Twilio tools for a client. This work requires a number of new skills for me. I want to share a few things I use to learn faster, in case they are useful for you in learning.

  1. Speed up your iteration cycles. It's hard to stay focused while you wait if it takes you 3 minutes to verify whether your code worked (much less 30). Your attention will drift, and when you come back to your results, you will have to reload the context. This takes you out of flow which interrupts your learning. It also means you can learn fewer things in the same amount of time. How can you learn something faster?

  2. Experiment in small pieces Often, when a domain is new, the whole piece of the puzzle is too big to deal with. It needs to be broken into smaller pieces. Also, those smaller pieces often create faster iteration cycles. I'm a huge fan of writing simple learning code and scripts, to figure something out. That might mean writing a tiny Twilio function that just errors the arguments passed in, a mini bash script, or trying it out in the Rails console. What is the smallest piece you can break this into?

  3. Clarify your questions When I'm frustrated when learning, I like to have a very clear question in mind. It helps me stay focused. While less directed exploration also has value, I can get lost in that, and struggle to remember what I was trying to do.

It helps me to answer one question at a time, and write down the other questions that come up as I explore. I often use a journaling method similar to what I lay out in my Getting Unstuck: Using the Scientific Method for Debugging RubyConf talk, writing down an experimental question, a hypothesis, and what I observe in a running doc.

If you don't have a clear first question to start, but a whole jumble of wonderings, that's when I engage in Question Shrinking, as taught to me by Shaun Martin and KK Ong. That's a whole other post (or a series, even). But I'd recommend writing down your questions, and everything you know, on paper or a white board. And then write down the connections between them, the other things you remember you know, and explore, to see what you don't know yet.

  1. Write down your mental stack When you're learning, it's easy to get overwhelmed. It helps me to keep a written stack of questions, tasks, and more so they don't use up my working memory. I usually use either physical sticky notes (one note per thought), or the Stickies for Mac app (as just a list). You can then add to your stack, or pop things off your stack as you go.

  2. Accept being outside your comfort zone Another thing I learned from Shaun and KK is that learning happens in flow and outside your comfort zone. This is, by definition, uncomfortable but it's required for learning. Try to notice and accept the discomfort, without judgement.

  3. Take breaks You need idle time and sleep to process, and form neural connections with the new information when you're learning a lot. Taking an actual break to move my body, or reflect quietly always helps a heck of a lot more than scrolling on my phone (even though I do love scrolling Mastadon or playing Square Valley or Monster Hunter Stories).

Please tell me if this post was helpful to you, if you learned something new, if it was boring, whatever. I'd love to hear from you, even a thumbs up or thumbs down. Or even better, share your learning-new-things tips!

A 6 week popup blog on software – Popup 1 Inspired by Nat at SimplerMachines and Paolo Amoroso's invitation to join #BringBackBlogging, I am trying a pop up blog.

I love Nat's pop up blogs and Seasons of blogging. Every one has been a pleasure to read. Especially when the seasons or pop ups are short, I want to read it, and the tasty tidbit leaves me wanting more.

I've been enjoying Mastadon greatly. As many have said, it feels a bit like the old days of the internet, in a good way. One of the great things about the old days was blogs. Long form writing by so many people, with such varied interests. So I was inspired by the BringBackBlogging challenge to give it a try.

Here's what you can expect: * I will blog 1-2 times a week here, from Jan 19 to March 10, 2023. * After March 10, 2023 this first blog popup will wrap up. If you have subscribed via RSS, you won't get more posts. If you subscribed via email, the email list will be deleted. It's a pop up that goes “poof” when it's done. * I will be writing about software, defined very broadly. It might be digging into a specific piece of software, or musings on process, a review of a book that influenced my software development thinking, or thoughts on working as an independent software consultant. * Posts will be longer than a Toot and less than 5 minutes to read.

If you enjoy my writing, please share it and let me know! If you have feedback, or want to talk more about it, please say hi at @ctaymor@hachyderm.io. I would LOVE to hear your thoughts.

Enter your email to subscribe to updates.