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!

One link leads to another

Sometimes I come across posts or material in the internet on topics that piques my interest. It could be something I want to know more or understand more about. Or it could be related to a conversation or two I’ve had within the day that makes me question certain things. So sometimes I google, and sometimes I just stumble upon them through various feeds — could be Twitter, email, Medium, IG, and Facebook even. And then one link leads to another and before I know it, it’s 2AM and I should be getting some sleep. So anyways, here’s a dump of some recent links, in no particular order. I hope someone finds them helpful or interesting as I have.

Agile Product Ownership in a Nutshell (15 minute video) – I like how the content was easy to follow. There were a lot of points worth highlighting, but I guess what hits home the most is the mention of three things that need to be balanced:

  • Build the right thing (PO tends to focus here)
  • Build the thing right (dev team)
  • Build it fast (SM or Agile coach)

So you want to be a Scrum Master (book) – This is a Leanpub book which you can get for free, or not if you can afford to make a payment / contribution. It’s written by an Agile community of interest with the intent of sharing what they’ve learned and what they’ve seen to have worked.

The 3 most effective ways to build trust as a leader (post/article) – Got this from Rob Lambert but I can’t remember where exactly — “Three typical management activities that get poor results and three that get good results”. I’m not really a leader by title but the three ways of building trust that the post enumerates are still relevant to me and they emphasize points that I value: Empathy, clarity of intent, and follow through.

DISC Profile Types (personality test) – This is something I picked up from Rob Lambert’s webinar. For each profile type, there are recommended ways on how to better communicate with them, and inversely there are recommended ways on how to encourage others to better communicate with you. Took the test myself and got 48% Compliance, then Dominance, Steadiness, and lastly Influence.

12 common mistakes made when using Story Points (post/article) – This reminded me of something a colleague had shared wherein their Scrum Master wants them to estimate in hours rather than in story points, and also her thinking that story points can be easily translated to hours.

Agile Makes No Sense (post/article) – Let me just quote some lines (actually last 2 paragraphs) that I liked…

What is the smallest thing that could add value (and make sense)? A better standup? A better retrospective? Inviting a customer to a demo? Pairing for a day? Agreeing to get something into product in a couple days? Try that. Make one thing make sense as in “wow, I can see how that created value”.

When you take this humble approach — instead of “installing” a bunch of artifacts, tools, roles, and rituals AKA doing Agile — I think you’re embracing the true spirit of Agile.

Something to google: Sprint 0

There was an interesting topic while a couple of colleagues and I were on our way to buy coffee. It was triggered by a question about Sprint 0. Based from my limited working experience, Sprint 0 is like an initiation phase wherein the project gets set up. Dev environments get set up. First set of epics and user stories are created. Some initial designs get created. Project team members get on-boarded. Working agreements get defined. Collaboration tools like where to capture user stories and clarifications get finalized. Etc, etc. Basically, the team buys itself some prep time so that they can hit the ground running by the time Sprint 1 comes — ideally, by then, the team could commit to completing user stories and actually have features working at the end of the sprint. But then I thought, we don’t necessarily release anything after Sprint 1, so would calling Sprint 0 “Sprint 1” make any difference?

Idk. Maybe there’s this extremely high expectation about being or switching to Agile that makes it feel like you’re doing it wrong if you don’t have anything visible to some of your stakeholders by the end of a Sprint N. Being part of the development team, I know that infra setup is important, design work is important, all those other prep work are important. I know how 2 weeks could so easily fly by without seeing something that an end-user could potentially see. But to someone outside of the development team who might not be so familiar with Agile, they might have this extreme notion that “Hey, you’ve just completed 2 weeks! Where’s my working software?” And so maybe project teams resort to having a Sprint 0 to “protect” themselves or the concept of Agile to better manage expectations. Idk.

I went out of that conversation thinking that’s something I’d google. Just a few of the interesting stuff I found, and I’m sure I barely scratched the surface:

  • Sprint 0 (forum topic) – there’s mention of using Sprint 0 as a crutch
  • Scrubbing Sprint Zero – apparently, there’s no official “Sprint 0”; there’s the idea that it’s an anti-pattern; it’s been discussed by Agile Manifesto signatories all way back in 2008. I loved the Alistair Cockburn (often pronounced like “Co-burn”) quote:

I have a sneaking feeling that someone was pressed about his use of Scrum when he did something that had no obvious business value at the start, and he invented “Oh, that was Sprint Zero!” to get the peasants with the pickaxes away from his doorstep.

… and then others thought that was a great answer and started saying it, too. … and then it became part of the culture.

  • Sprint Zero: A Good Idea or Not? – there’s mention of the “project before the project”; and it links another post about using scrum for an analysis project whose output is not necessarily immediately working software
  • Antipattern of the Month: Sprint Zero – Lol, that quote: “Sprint 0 is like Casper, the friendly ghost. Well-meaning, but creepy.”

And, that’s all she wrote! Time for bed!

Reading up on Progressive Web Apps

So I’ve been working in a new project and what sets it apart the most from previous projects I’ve worked on is that our team is building Progressive Web Apps (PWAs). I got thrust into the project in firefighting mode, and I’ve pretty much managed to get by with my experience in working on web apps and hybrid mobile apps. Essentially, my simplistic understanding was PWAs are amped up web apps because they’re app-like [they’re just websites that took all the right vitamins.” – Alex Russell].

  • They can be easily be “installed” from the web browser without having to go through app stores or MDMs like AirWatch.
  • They can be available from your mobile device’s home screen.
  • When you open them, they look like an app — full screen, without the browser header and navigation bar.
  • When you switch apps on your mobile, they’re there along with other “normal” apps.
  • They’re responsive — the same app on my desktop Chrome browser has a “mobile-friendly” version on my mobile’s Safari or Chrome browser or when opened as an app.

But when you have to keep on throwing around the term “Progressive Web App” or “PWA” (people ask about push notifications which you then push back on with the reasoning that it’s currently a limitation for iOS), you want to have a better understanding of what you’re talking about. Well, at least I want to.

So I’ve read up a bit on what PWAs are or what makes a web app a PWA. Common to most of the results are some attributes of the PWAs and some baseline criteria to qualify as PWA.

Attributes

This list is a mix verbatim from Alex Russell (he used colons) and from Wikipedia (em dashes). These are the attributes or characteristics of PWAs.

  • Progressive — Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet. [This seems similar to responsive though]
  • Responsive: to fit any form factor
  • Connectivity independent — Service workers allow work offline, or on low quality networks.
  • App-like — Feel like an app to the user with app-style interactions and navigation.
  • Fresh: Transparently always up-to-date thanks to the Service Worker update process
  • Safe — Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
  • Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them
  • Re-engageable: Can access the re-engagement UIs of the OS; e.g. Push Notifications
  • Installable: to the home screen through browser-provided prompts, allowing users to “keep” apps they find most useful without the hassle of an app store
  • Linkable: meaning they’re zero-friction, zero-install, and easy to share. The social power of URLs matters.

Baseline Criteria

This is more of implementation requirements — so might not be quite visible to business owners. Copy-pasted the 3 listed items below verbatim:

To be a Progressive Web App, a site must:

And apparently, there’s the Lighthouse tool which can run automated checks to evaluate whether a site/web app is a PWA or not. It’s easily install-able as a Google Chrome extension and generates a nice looking report which also could seem like a reference on what to improve for your web app.

Sample output of report (this is just the summary, there’s a breakdown that actually follows)

So after going over all those links and references, do I know how to define a PWA?  Idk, I’ll probably revert to: they’re amped up web sites which can be installed behave like apps. 🙂

References

Wondering how much it matters: initial load of page

Background: I found that when I accessed the home page of one of the apps our team was working on, there were around 1000+ requests and over 10MB transferred in a span of 10 minutes (and it was still going). On screen, what’s visible is just the login page.

After they’ve fixed it, I went ahead and checked our current apps in the test environment. Just a disclaimer though — I’m not a performance tester and I just gathered the info I got via Chrome Dev Tools.

AppRequestsTransferredFinishDOM Content LoadedLoad
App 1503.6 MB2.6 min28.4 s48.69 s
App 2301.9 MB19.06 s11.12 s12.35 s
App 3413.6 MB26.95 s7.52 s12.52 s
App 4181.7 MB9.41 s3.93 s9.41 s
App 514742 KB3.17 s1.36 s3.18 s

3.6 MB and all that’s visible is the login page?

That prompted me to then google what’s the average out there. I’ve come up with a bunch of interesting results that’ll most likely make up my weekend reading:

Feel free to suggest in the comments section if there are more relevant references I could also look into. Thanks!

Read: The Dance of the Possible

I’ve just consumed Scott Berkun’s newest book, The Dance of the Possible. As promised by the author, it was a short book intended so that we can get what we can out of it, get it out of the way, and dive into actually creating something. It was divided into three parts — each of which I consumed in one sitting of around an hour. You can breeze through it in less, but I liked reflecting on points raised by the author and recalling experiences where I can relate them (or could have related to them).

If I were to describe the 3 different parts of the book, I’d say part one is about the generating ideas. Part two is when you’re already developing your ideas. And part three is when it’s getting extra challenging to keep going and you need that extra boost.

He captures in writing some of the things I personally go through in my own creative process which made me just virtually nod in agreement and think “Oh yeah, that was what I was doing!” And I guess in making me aware, I could be more intentional in applying them and accepting when I feel like I’ve hit some sort of slump (that I will get over, of course).

I’ve long been intending to read a book on creativity (among many other things). Having Scott’s book come along with the invitation to do a book review really pushed me. When he described one of the seven sources of fuel for why people create the things they do (i.e., “Deliberately put yourself in situations where you have no way out but through.”), I couldn’t help being amused and thinking “Yeah, that happened!” I think even without the book review aspect, I’d have enjoyed reading his book as I’ve enjoyed some of his other writings. It just adds another dimension and it feels like it’s full circle because the book on creativity actually prompted me to create!

[Edit: Same content is posted as an Amazon book review over here.]

Are you interested in software testing?

So yesterday I shared a link to 30 Things Every New Software Tester Should Learn in some other social network. Now I know it says “new” and I’m not exactly new anymore. But still, I don’t know everything so I’m sure I’ll pick up something new. Besides, whether you learn something or not depends on your willingness and openness to the possibility of learning.

Anyways, that post consisted of a series of tasks, and the first of which was to do an introspection. It asks this key question:  Are you interested in software testing? I guess it’s pretty safe to say that I am. I’ve been in testing for a long time now and I do enjoy it. I tweet and blog about it. I like finding bugs, figuring things out, working with fellow testers and the devs, and essentially just helping in making our product better (and maybe our project too).

Now this is something I also wonder about whether fellow testers are actually interested in software testing. I totally understand that for some it’s a 9–5 job, and for some their interests lie in their personal pursuits (be it art, sports, pets, other hobbies) — after all, there is more to life than just work! I don’t take it against anyone if they’re not in love with their work (so very few are and that’s in general) or so gung-ho with software testing pride (pumps fists up in the air). But interest is critical. It could mean the difference between just getting by with the motions and excelling or exceeding expectations. And it could mean the difference between drudgery and enjoyment. At the very least, I do hope people like their work and not just for the reason that it pays the bills.

I know there are some folks who fell into software testing by chance — it happened to be an opportunity that was available, or they had to shift from another part of software engineering to testing. Some folks got into testing because they took a programming course in college but aren’t too keen on doing coding. And inversely, there are some who got into testing with the hopes of shifting into coding. But regardless of how you got here and whether you’re still testing the waters to figure out if testing is really for you or not, please exercise diligence. Testing might turn out to be something you can excel in so give it its fair chance.

And maybe to be interested in software testing, the first step is to make a conscious decision to be interested in it.

“The very first step towards success in any occupation is to become interested in it.” – William Osler