Read: Fast Times

I lucked out on getting a $0.99/month subscription to Kindle Unlimited (but only for a limited time–ironically). And earlier today, I found a new title that was just published quite recently. Coincidentally, it felt relevant because of some recent strategy/planning discussions that I’m hearing about. So I went ahead and read it.

The book is “Fast Times: How digital winners set direction, learn and adapt” by Arora, Dahlstrom, Hjartar, Wunderlich. It’s a short, easy read — finished it within half a day.

Some takeaways:

  • Speed is an outcome of deliberate actions and behaviors.
  • Emphasis on learn-and-adapt — ABL: Always be learning.
  • Bold aspirations must be matched by corresponding commitment. Tentative measures will not deliver.
  • Chapter 5 shows a few numbers illustrating how fast looks like (e.g., normal product launch is in 6 months, fast is in 2 weeks).
  • We’re inundated with how important it is to be safe to fail, BUT it’s not an excuse to say it’s OK to fail all the time. Chapter 6 supports that with its mention of “Failing is not always acceptable” with an enumeration of when it’s plain wrong.
  • “You’ve got to make sure that if you make mistakes, you learn from [them].”
  • Chapter 7 revisits the all familiar Tribe-Squad-Chapter-Guild model.
  • Chapter 13 just brings to mind how security needs to be integrated in development.
  • Chapter 14 shares the Digital Transformation Office’s (DTO) many roles — in injecting coherence to how squads are structured, in implanting importance of learning, in having visibility on what’s working (and not), in capturing, codifying, disseminating best practices, etc.
  • All that learning –especially from failing– isn’t worth much if no one can find it.

Trying to understand Design Thinking

Warning: Relatively long post, thanks to a cancelled meeting from 7AM which got me on my laptop hours earlier than usual. Jump to here to skip a lot of references.

Mention “Design Thinking” to me and what comes into mind are post-its, and the 5-phase process or cycles of Empathize-Define-Ideate-Prototype-Test. But what I’d really like to understand is what sets it apart from any other problem solving approach. Apparently, I’m not the only one because I found this in Quora: “How does design thinking differ from other approaches to problem solving or innovation?” I’ll get to that later.

Starting with definitions and differentiation

“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”
—Tim Brown, Executive Chair of IDEO

Googled top results

Here are today’s top 5 results when I Googled “Design Thinking” and what they essentially had to say about it. The first one’s actually an ad so I’ll skip that.

Result #1: What is Design Thinking and Why Is It So Popular? Written just 1 month ago. The take away from that article (literally, because the heading is “The Take Away”): “Design Thinking is essentially a problem-solving approach specific to design, which involves assessing known aspects of a problem and identifying the more ambiguous or peripheral factors that contribute to the conditions of a problem. This contrasts with a more scientific approach where the concrete and known aspects are tested in order to arrive at a solution. Design Thinking is an iterative process in which knowledge is constantly being questioned and acquired so it can help us redefine a problem in an attempt to identify alternative strategies and solutions that might not be instantly apparent with our initial level of understanding. Design Thinking is often referred to as ‘outside the box thinking’, as designers are attempting to develop new ways of thinking that do not abide by the dominant or more common problem-solving methods – just like artists do. At the heart of Design Thinking is the intention to improve products by analyzing how users interact with them and investigating the conditions in which they operate. Design Thinking offers us a means of digging that bit deeper to uncover ways of improving user experiences.”

Result #2: 5 Stages in the Design Thinking Process. Written 2 weeks ago. It’s more focused on the 5 stages as you would expect from the title. But in the take away, it did say: “In essence, the Design Thinking process is iterative, flexible and focused on collaboration between designers and users, with an emphasis on bringing ideas to life based on how real users think, feel and behave.”

Result #3: Design Thinking. Doesn’t really count since it seems to just aggregate items tagged as falling under the topic.

Result #4: What is Design Thinking? from IDEO U. “Design thinking is a process for creative problem solving. …Design thinking has a human-centered core. It encourages organizations to focus on the people they’re creating for, which leads to better products, services, and internal processes. When you sit down to create a solution for a business need, the first question should always be what’s the human need behind it?”

Result #5: Design Thinking from good ol’ Wikipedia. “Design thinking refers to the cognitive, strategic and practical processes by which design concepts (proposals for new products, buildings, machines, etc.) are developed. Many of the key concepts and aspects of design thinking have been identified through studies, across different design domains, of design cognition and design activity in both laboratory and natural contexts.”

Going back to Quora

Let me just try to go over the 5 available answers to the question “How does design thinking differ from other approaches to problem solving or innovation?“, and summarize them below.

  • Emphasis on “Empathy” for the people for whom you are designing for and its focus on human values at every stage of the process
  • Contrast against traditional innovation process which uses a linear funnel “Toll-gate” approach for problem solving; whereas Design Thinking is “an iterative and fluid approach that uses prototyping for continuous user feedback and engagement”
  • It’s reinventing the wheel but it comes with the major advantage that it “re engages the client with the designer as a proper process of design communication”
  • Respondent list down some attributes like “user-centric, human-centric” but then adds “process oriented”.
  • Human centered, using elements such as “experimentation and empathy to come up with inventive solutions while incorporating the people’s needs, the prospects of technology, and what is required for the success of a business”

Hmm… It’s still just problem solving

Idk. It still feels like problem solving to me. On the aspect of being human-centered or user-centered, you can’t really do away with that because a problem is a problem to someone. You can’t take that someone out of the picture when you’re trying to understand the problem, more so when you’re trying to solve it. On the emphasis on empathy, it feels like that’s a given essential when you’re trying to understand the problem space. You need to understand why, how and to what extent is it being a problem to someone.

On the aspect of being iterative and on using prototyping, it still doesn’t feel like a differentiation. After defining a problem and coming up with ideas on how to solve it, it just doesn’t make sense to jump on the first idea or run all ideas. It throws me back to grade school when they were teaching us the scientific method wherein you hypothesize, then test (which could go either way), repeat, until you come up with a conclusion based from your test results.

So does it add value?

I wouldn’t discount it as not having value. There’s way too much content out there to say it’s not valuable. And more importantly, it’s still problem solving and problem solving that’s able to bring forth solutions is valuable.

Maybe what really differentiates are Design Sprints?

Oh, no, another term. Now what are Design Sprints? It’s highly popularized by the book Sprint by Jake Knapp (which is still in my reading backlog). But a quick google search on the difference between Design Thinking and Design Sprint gave this very useful point.

‘One of the things companies are struggling with when it comes to integrating Design Thinking is that it’s more of a philosophy than a true “out of the box” method. This is precisely the value of Design Sprint.’

The value-add I perceive are:

  • Design Sprints put a time box or defines a more concrete recipe on the Design Thinking process.
  • It engages the customers — so it’s not just the designers or developers brainstorming on the problem space and solution space.
  • It allows for quick feedback — for some points, you can validate right there and then because you have customers in the room with you. No need to send out an email, and wait for a response only to realize a need for a follow up email later on.
  • It really sets the stage for a collaborative design process. With the framework, it’s clear who will be involved, what will be needed during the time box, what outputs to expect within the time box. As opposed to more traditional approaches, you don’t have to second guess whether you can talk to the customer or course it through some stringent RFI (request for information) process. It’s a given that customer stakeholders and the design team will directly interact.

Now as to how it’ll seamlessly integrate with Agile Scrum, maybe that’s for another cancelled 7AM meeting. 🙂

Reads from this morning

Trigon, this app I occasionally play, can be such a time sink. I’d say “just one more game,” then after a while, I’d realize that an hour had just gone buy and I spent it just arranging shapes to align and disappear (pretty much like my time). So I caught myself this morning just about to tell myself “just one more game,” and decided to get back into my reading in Medium. Ended up bookmarking several stuff and reacting to a few.

“Active reading — taking notes, sketching, and talking with a friend about the text — can also help forge mental connections between the information you’re taking in and what you already know, increasing your retention. This doesn’t mean passively highlighting, re-reading, or retyping what you’re reading but effortfully engaging with the text: jotting down your own thoughts, questions, and connections that occur to you, whether you do it in the margins or take notes elsewhere.”
How to Remember More of What You Read

Sometimes I have instances of “I’ve read somewhere that so and so…” and vaguely recall an idea from a book or text I’ve read. Or I’m able to connect something I’ve read about to something at work. To have been able to pull something out of the well of insights I gained from reading tells me that I do remember enough to make some use of it. With the little I remember (I admit to not having the best memory which is why I like that quote saying the mind is not a vessel to be filled but a fire to be kindled), the information and even knowledge I’m able to connect to real life has been helpful. I can only imagine how much more so if I can remember more. I’ve started doing that to some of the books I’ve been reading since September i.e., more actively highlighting, taking down notes, and occasionally putting in some lols and side comments. Whether my memory improves, I’ve yet to find out, but at least I know where to find my notes if I need them.

“A great culture can ensure you are able to do something repetitively if you have done it before. It brings sustainability. It brings certainty in outcomes.”
Well, culture DOESN’T eat strategy for breakfast!

I’m not exactly in charge of culture building at work (but I do know my behaviors, my mindset, how well I execute has the potential to contribute to the culture). Nevertheless, I found this post and the book it shared (“What You Do Is Who You Are” by Ben Horowitz) interesting — especially the little anecdotes. No PowerPoint presentations in meetings. Just kill the snake, don’t play with dead snakes, opportunities start out looking like snakes. Shocking rules. Don’t !@#% the customer as a value. Interesting.

“In late 2019, the US Court of Appeals denied LinkedIn’s request to prevent HiQ, an analytics company, from scraping its data. The decision was a historic moment in the data privacy and data regulation era. It showed that any data that is publicly available and not copyrighted is fair game for web crawlers.”
Web scraping is now legal

This just throws me back to when our team was looking into LinkedIn integration to strengthen the expert profiles in the in-house app we built. Crawling was an idea we were cautious about since we feared the legal implications (so we obviously did not go there).

Other reads from this morning before my Trigon time was up 🙂

Tech lead thinks it's ok to skip Sprint Planning

I heard about a Scrum Master asking the Tech Lead to provide a heads up in advance in case he won’t be able to attend their meetings (in this case, it was their Sprint Planning). The Tech Lead said that his absence shouldn’t affect the Sprint Planning since the team would just be doing estimations (deduced meaning because the original reason he gave out didn’t make so much sense).

True that his absence shouldn’t keep the Sprint Planning from happening. But the Sprint Planning is not just about estimations. More than anything, it’s about alignment.

So what happens in a Sprint Planning? At least from my experience (affirmed by and sprinkled with some stuff I read about from Kniberg):

  • The team goes over the potential sprint backlog items from the Product Owner — sizing and discussing the stories, breaking them down further if needed, adjusting the prioritization if needed.
  • The team brings up any other technical user stories that need to be prioritized.
  • The team / Scrum Master brings up any user stories or improvement items from the retrospective that needs to be prioritized.
  • The team gets informed of any critical dates or targets that they should be mindful of in the sprint.
  • The team agrees on the following:
    • Sprint Goal
    • Sprint Backlog (defined as not just the list of stories, but also including a “plan for delivering the product Increment and realizing the Sprint Goal.”)
  • The team aligns on their availability (e.g., planned leaves, out of office dates for training, etc.)

So there. To me what’s essential about the Sprint Planning is starting off the sprint at the right foot with the team being in the same page. Ideally, it’s coming out of that meeting not feeling defeated (oh, no, we’re dead, we have an impossible deadline) but rather feeling united and empowered (we can do this).

Retrospection and learning time

Just recently, my engagement to my project since Nov of last year has ramped down. So the past couple of weeks has been a time of transition for me into my upcoming project and also from me to the new PO of my previous project. This allowed an opportunity for retrospection, and also a chance to pick up on new stuff.

While looking up the available knowledge sharing platforms within the company, I came across the option to host stuff in our enterprise GitHub instance. One link led to another, and I came across…

  • MkDocs – This is for project documentation; it allows the use of Markdown for writing content, and then you generate static site contents from that.
  • Documentation as Code (docs-as-code) – While I’m not a programmer, getting familiar with the concept wouldn’t hurt. And as I read more, it’s not really exclusive to programmers.
  • Diagrams as Code with Mermaid – Part of the family of stuff-as-code, this doesn’t trail far behind. I think what I find promising about this (apart from being free) is that this is going make comparison of versions easier since you’re comparing text files.

As mentioned, I did some retrospection. I collated some of my personal lessons learned and posted it in our project’s Confluence page. I also revisited Software Development’s Classic Mistakes. I tried rereading The Scrum Guide and some stuff on anti-patterns to see where we’re somewhat deviating (for guidance if it’s something we should continue or if we should “realign”). Then I tried to pull out project-agnostic stuff that could be helpful to me for starting a new Agile Scrum project and collated my notes.

With the notes in hand, I’m starting to use it as a reference for the new project, and I plan to just tweak accordingly as I find other useful stuff to add in. At this stage, there’s already a team working on the prototypes, and in theory, they’re prepping the solution or the design which will be handed over to the implementation team. So I’ll be keen on learning a lot more and looking for process improvements for the handover from Design Thinking to prototyping to implementation. Exciting stuff! 🙂

Highlights on “It Doesn’t Have to be Crazy at Work”

I was just looking for something to read in the hope of finding something to help myself with some of the stress at work. I came across this book by Jason Fried and David Heinemeier Hansson — published 2018, with 4.6 out of 5 stars from 114 reviews in Amazon. They’re actually the same authors of another title I was initially looking at, “Rework” — published 2010, with 4.5 out of 5 stars from 1280 reviews. I opted to go with the former just because the title seemed more relate-able.

Overall, the book was a quick and easy read. Started reading it late Saturday (nearly Sunday) and finished it Tuesday morning (not one sitting). There were indeed points that were relate-able but maybe for the most part it’s better geared towards management or folks who can really influence change. The last chapter did come with some sort of message in case “you don’t have the power to change at the company level” but really, mostly it’s for those with the power to change at the company level.

Sharing here some of the stuff I highlighted in the book…And there were a LOT of highlights I’ve noted…

Continue reading

Them product management links

Been bookmarking and clapping on several posts in Medium lately on product management. Thinking of consolidating them here for future reference.

What it is or what it’s not

Getting started

Taking care of the backlog

Capability assessment or building

Trials and tribulations

PO anti-patterns

Notes from webinar: Write Better User Stories…

Last week, I attended a free webinar by Mike Cohn of Better User Stories on the topic of “Write Better User Stories in Less Time With Less Aggravation”. Right after, I shared the replay link to some colleagues along with a few bullet points of pros and cons.

(+) interesting, maayos explanation
(+) ok din yung q&a
(+) insightful naman, gives you something to think about, stuff to google further
(-) promotional, the whole course is expensive $395

Posting my notes here since the learning from the webinar is something worth revisiting.

3 Techniques

  1. Conduct a quarterly story-writing workshop
  2. Split stories to demonstrate progress even if the result is not truly shippable
  3. Strive to add just enough detail, just in time

Technique #1: Conduct a quarterly story-writing workshop

  • Deliberate, focused meeting
  • Brainstorm the stories needed to achieve the period’s most important goal
  • Short-term focus causes teams to give in to what’s urgent over what’s important
  • Team able to step away from day to day crisis… Without that big goal, the crisis always wins

Focus on a single objective

  • “What shall we build?” — Wrong question, too broad, anything is fair game
  • PO selects the significant objective (SO)
  • SO typically achievable in about 3 months
  • MVP, sometimes overused, seems can only be used once
  • MMF = Minimum Marketable Feature = subset of overall feature that delivers value when released independently, smaller than MVP

Involve the whole team in writing stories

  • Time investment, pays back on time savings when team works on the user stories
  • They’ll have fewer questions later, they’ll have more context
  • Fewer interruptions to devs’ day
  • Devs may come up with better implementation, increased creativity

Visualize user stories with a story map

  • Story maps invented by Jeff Patton
  • Each card = 1 user story (1 thing the user needs to do)
  • Horizontally = sequence of activities (don’t obsess over combination of sequence at this point, some steps may be optional)
  • Vertically = alternatives (with most important on top)

Technique #2: Split stories to demonstrate progress even if the result is not truly shippable

  • 90% joke – Ask dev how done are you and he replies 90%. Come back after a week, and answer is still 90%.
  • Devs are not evil or liars, Estimating how done we are with something is notoriously difficult.
  • In Agile, easier, no need to estimate. Just 2 states = Not started or Done
  • 5 techniques for splitting stories (Lookup SPIDR), shared in the webinar were Splitting by Interface and by Rules
  • When you split stories remember the goal is to be potentially shippable — (1) high quality, (2) tested, (3) what it does, it does well

Technique #3: Strive to add just enough detail, just in time

  • Too much detail, too early vs Too little detail, too late
  • Bad habit – want to know all before starting — when they do that they’re not doing overlapping work (analysis first, before coding, testing…). Overlapping work is central tenet in most Agile processes (that’s why we don’t have phases in Agile). Time to market gets stretched.
  • Err on the side of too little, too late — you can improve by adding more detail next time
  • Question 1 (during refinement or other discussions on a user story): Do you need the answer before you start on that story? Sometimes you need it before you finish work on that story, not before you start.
  • Question 2 (during retro): Did we get answers just in time in just enough detail?

Reference / links:

Reads: On skills for Product Management

This morning’s read tried to capture the job of a PM into 4 words: “Figure out what’s next.” I think in the work we do in building software (regardless of what your role is in your Agile project), we have to do a lot of figuring out. Coming with ideas or solutions independently is so important, and so is working collaboratively to further refine those solutions. Although it’s important to differentiate when it’s collaborating from spoon-feeding or unnecessary hand-holding.

Anyways, the post also enumerates 7 core skills to build for the Product Management role (actual text from the post are in bold, elaborations that follow are mine). But regardless of what role you are in the project, I think these contribute to being a good team player.

1. Taking any problem and being able to develop a strategy to resolve it — When you’re in the business of building software, figuring things out (preferably independently, with little to no hand-holding) is a critical skill.

2. Executing, getting shit done*in any role, this is valuable*

3. Communication — *same… in any role, you need this*

4. Leadership through influence

5. Making decisions, informed by data

6. Building great products, and having taste — As PM/PO/PPO/BA, you work closely with your designers. I think you also need to brush up on UX so that you don’t undo any of the good work your UX designers present to you for your feedback.

7. Always be prepared — *important for any role* I like the quote the author shared.

[Great PMs] say what they’ll do, and then do what they say. Their follow-through is impeccable, and they don’t let details slip. When they join a team, quality and pace seems to dramatically improve overnight.
— Noah Weiss

And I couldn’t agree more with his recommendations for developing your “I got this” aura. Over the years, I’ve worked with a few folks who would sound like they’re so unsure of what they’re doing. It just doesn’t bode well — it doesn’t give the team (or worse, their stakeholders) confidence that they’ll get the work done. I mean it’s OK to admit that you don’t know everything, because no one does — even “experts!” And it happens, I’ve gotten into countless of interactions where I really have no idea on what to do. But I guess my confidence (or my display of not panicking) stems from knowing that I have the capability and means to figure it out. (And that it’s not the end of the world if I don’t.)

So anyways, I’ve rambled on. Go check the post for the recommendations!

Busy-ness

I saw this title in Medium – Being ‘Busy’ Doesn’t Mean You’re Successful – and had the feeling that I was going to pretty much agree with the content. And I was right. I’m really not a fan of being busy – Especially of being fake busy or of perceiving busyness as a sign of importance or, as the post mentioned, of success.

I looked back at an older post (from nearly 9 years ago!!). And I’d just like to reiterate some quotes and links. Who knows, maybe 9 years from now, if I happen to be swamped or overwhelmed at work, I’ll need a gentle reminder that there’s more to life than being “busy”.

  • “It is not enough to be busy. So are the ants. The question is: What are we busy about?” – Henry D. Thoreau
  • The Cult of Busy (Mar 2010, Scott Berkun)
  • You’re Only as Busy as You Want Yourself to Be (Jun 2009, Jurgen Appelo)
  • Being ‘Busy’ Doesn’t Mean You’re Successful (Jul 2019, Darius Foroux)
  • Derek Sivers’ notes to “A Guide to the Good Life: The Ancient Art of Stoic Joy” by William Irvine
  • “A good man will not waste himself upon mean and discreditable work or be busy merely for the sake of being busy.” – Seneca
  • “To live is the rarest thing in the world. Most people exist, that is all.” – Oscar Wilde