Reads on Evolutionary Organizations

I read Aaron Dignan’s Brave New Work: Are You Ready to Reinvent Your Organization? last January, and in the past week I read the illustrated version of Frederic Laloux’s Reinventing Organizations. As I read the latter, a lot of the stuff mentioned — terms, concepts, examples — felt so similar and consistent with BNW which made me think if Dignan just made a spin-off of Laloux’s work. Maybe he did, maybe he didn’t. Either way, I found both books interesting and they were both easy reads.

As for differences, I think RO elaborated more on the evolution of organizations throughout our history. It also promotes the metaphor of organizations as living systems. There were some enumerations on management structures and practices that need upgrading, but not all items were discussed in the book (but maybe they’re covered more in the non-illustrated version). The book does have companion resources including a crowd-sourced wiki that has elaborations on the stuff not elaborated in the book.

BNW focuses more on the organization’s Operating System — elaborating on the different domains or parts that make us the OS canvas. Examples of the domains (there are 12) include purpose, strategy, meetings, membership, etc. Each domain gets covered with examples and you get ideas or suggestions of what you can consider applying to your own organizations. I think BNW also offers more guidance or aides e.g., sensing tensions (78 tensions that can be used as conversation fodder), proposing practices (deck of practice cards), conducting experiments (experiment worksheet).

I made a lot of highlights in both books, and I saw several instances of me saying “interesting…” in my notes. I guess one of my favorite ones (might be trivial) is on the use of the word “fractal” in BNW.

“Like organizational purpose, strategy is multidimensional and fractal—it’s happening on many fronts at many levels. Which means coherence matters.

Say fractal and images of geometric figures with repeating patterns come into mind. A definition of fractal is “a curve or geometric figure, each part of which has the same statistical character as the whole.” To describe something consistently happening at all levels at all fronts as fractal is such a cool word choice.

Do we size bugs with story points?

I found a question posted in one of the social channels at work: How should one give out story points to bugs/defects that one does not yet know how to fix yet and requires investigation? The original question asks how but I think even before we go there it would be nice to know whether we need to in the first place. I plan to write about this in 2-parts: (1) how I might go about with it — no explanations, but based on past experiences as a member of Agile Scrum teams and what I’ve read on the topic, and (2) links and quotes galore.

How I might go about with it

  • If it’s a bug found during testing of a user story we’re working on in the sprint AND it’s small enough (implicitly sized) to be fixed within the same sprint: It goes into the sprint backlog. No need to size it. Just prioritize it accordingly.
  • If it’s a bug unrelated to user stories that we’re testing this sprint (say, from an older feature) OR it’s too big a bug or complex (again implicitly sized) to be fixed within the sprint: It goes to the product backlog. It’ll be groomed as you would with other user stories to give it enough details for the team to work with. And if it makes it way into the Sprint Planning, then size the bug.
  • Now what if the bug that goes into the product backlog requires more investigation than usual (all bugs require investigation, but in some cases I suppose devs already have an idea of how to fix it, in some, totally no idea hence more investigation is needed): Tag it as a spike (not a term in the Scrum Guide, FYI). If it goes into the Sprint Backlog, meaning the team agrees to invest time on investigating that bug within the Sprint, no need to size it.
    • For that spike in the Sprint, it’ll just mean there’ll be a time-box (1-3 days of effort) for investigating that bug. At the end of the time-box, whoever works on it reports their findings and the team can discuss the next steps.
    • Assuming the team agrees on a resolution, duplicate the bug with the spike tag. Close the original one. In the duplicate, remove the Spike label. If it’s to remain in the Sprint Backlog meaning the team will fix it within the Sprint, then size the bug. Otherwise, the new bug (the duplicate) goes to the Product Backlog and no need to size it yet.
    • But what if there’s still no resolution or identified workaround. The team can opt to extend the time-box. But at some point, you can’t just extend and extend it forever. Once a threshold is met (is 3 months too long/short?): Tag it with a label your team agrees to use on such items, and then archive it.
  • At the end of the Sprint, the Scrum Master will be able to gather the following data in case they want to use it for some forecasting:
    • User Stories – total story points, bugs per user story
    • Bugs – total story points, total number of bugs
    • Spikes – total number of Spikes worked on, total number of Spikes closed, total points from Spikes that were converted to new bugs

That turned out longer than I expected. The next part are for some links on the topic and could give you the opposing views to help you come up with your own answer.

Links and quotes galore

12 common mistakes made when using Story Points – This has a lot of other interesting points not just about on whether you size bugs or not.

  • “Story Points represent the effort required to put a PBI (Product Backlog Item) live.” So story points are not limited to user stories.
  • “Story Points are about effort. Complexity, uncertainty and risk factors that influence effort but each alone is not enough to determine effort.
  • [Common mistake #5: Never Story Pointing Bugs] “A bug which is unrelated to the current sprint should just be story pointed. The bug represents work the team needs to complete. This does not apply if the team reserves a fixed percentage of time for working on bugs during the sprint. A bug related to an issue in the sprint should not be story pointed as this is part of the original estimation.”

Should Story Points Be Assigned to a Bug Fixing Story?

  • [I think this is with respect to legacy bugs or when the team is dealing with a large database of agile defects] “My usual recommendation is to assign points to bug fixing the agile defects. This really achieves the best of both worlds. We are able to see how much work the team is really able to accomplish, but also able to look at the historical data and see how much went into the bug-fixing story each sprint.”

Should you ‘Story Point’ everything? – This is a thread in the Scrum.org forum.

  • (No points for bugs) ‘They are called story points for a reason. They are not call[ed] “Item Points”. Ideally you should only have stories in your backlog and the technical tasks should be inside…’
  • (Yes or no points for bugs) “It is critical as a Scrum Master to ensure that story points are being used properly within an organization. They serve two purposes only: to help the Development Team and Product Owner plan future sprints, and to be accumulated for done items at the end of a sprint for velocity calculation purposes. They are not a proxy for value delivery. … That said, it seems there are a number of different items (bugs, technical tasks, spikes) that have a capacity impact on the Development Team each sprint. For planning purposes, if the team prefers to not point these items, a mechanism to determine the capacity impact is still desired….”
  • (No points altogether) ‘I have found, and this may depend on your team, that removing story points entirely helps the team and stakeholders focus on the sprint goal instead of “How many points”….’

What’s a spike, who should enter it, and how to word it? Since I mentioned “spikes”, I’ve put in this other link about it.

  • “A spike is an investment to make the story estimable or schedule-able.”
  • “Teams should agree that every spike is, say, never more than 1 day of research. (For some teams this might be, say, 3 days, if that’s the common situation.) At the end of the time-box, you have to report out your findings. That might result in another spike, but time-box the experiments. If you weren’t able to answer the question before time runs out, you must still report the results to the team and decide what to do next. What to do next might be to define another spike.”
  • “It’s also best if a spike has one very clear question to answer. Not a bunch of questions or an ambiguous statement of stuff you need to look into. Therefore, split your spikes just as you would large user stories.”

Let me know if you find anything more conclusive or helpful.

Read: The Culture Code

Just finished reading The Culture Code: The Secrets of Highly Successful Groups by Dan Boyle. I read it even though I pretty much think the key to highly successful groups is having great individuals rallied together by a clear purpose and a selfless leader. That’s no secret — it’s just that getting that right mix is what’s elusive. Anyways, the book was a quick and easy read peppered with Ideas for Action (that’s literally the title of 3 chapters) on how you (but ideally your leader) can help in 3 things: (1) building safety, (2) sharing vulnerability, and (3) establishing purpose.

Actionable ideas

Be mindful of 3 basic qualities of belonging cues — Energy, Individualization, Future Orientation. So in your interactions with your team mates, invest energy by giving attention and being present in the interaction. Acknowledge the individual, don’t make him or her feel like he’s just another random person. Hint at a future, don’t make it feel like it’s just a hello and goodbye interaction.

Build Safety — We are safe and connected.

  1. Overcommunicate your listening – Start off with actually trying to listen, and hopefully your posture, expression, and whether you give a steady stream of affirmations (yes, uh-huh, gotcha) or encouragement to the speaker to keep going would shine through. If not, watch out for whether your posture, expression, reactions are conducive towards the speaker continuing to speak up.
  2. Spotlight your fallibility early on–especially if you’re a leader – Radiate humility and actively invite input with simple phrases like “This is just my two cents,” “I could be wrong here,” “What am I missing?”, “What do you think?”
  3. Embrace the messenger – When someone shares a truth especially bad news or tough feedback, don’t chew off their head. You have to make it feel safe for people to speak the truth.
  4. Preview future connection – Hmm… similar to above on future orientation. Maybe share some vision of the future that you have for the person (like if you see him or her as possibly the next great thing) or with the person.
  5. Overdo Thank-yous
  6. Be painstaking in the hiring process
  7. Eliminate bad apples – Bad apples like jerks, slackers, and downers just aren’t good for the psychological safety of the team.
  8. Create safe, collision-rich spaces – By “collision” he means serendipitous personal encounters. I guess this is about trying to increase the chances of interactions among the team. Could be as elaborate as setting up an extremely nice team area to something as simple as the team having coffee.
  9. Make sure everyone has a voice – Not just the loudest person gets heard. Everyone gets heard, and I guess what follows through is more important i.e., when it actually converts to change or action.
  10. Pick up trash – “Muscular humility”–a mindset of seeking simple ways to serve the group. Other examples could be allocating parking places, picking up checks at meals. “These actions are powerful not just because they are moral or generous but also because they send a larger signal: We are all in this together.”
  11. Capitalize on threshold moments – It’s not just in day one. In successful groups the author visited, they also paid attention to moments of arrival. “They would pause, take time, and acknowledge the presence of the new person, marking the moment as special: We are together now.” Think about it: A warm greeting to a team mate when he arrives versus not even batting an eyelash.
  12. Avoid giving sandwich feedback – Separate handling of negative and positive feedback — negative through dialogue, positive through “ultraclear bursts of recognition and praise.”
  13. Embrace fun

Share Vulnerability — We share risk here.

  1. Make sure the leader is vulnerable first and often – Recommended 3 questions for leaders to ask their people:
    • What is one thing that I currently do that you’d like me to continue to do?
    • What is one thing that I don’t currently do frequently enough that you think I should do more often?
    • What can I do to make you more effective?
  2. Overcommunicate expectations – People aren’t psychic and things don’t just magically fall in to place. “[Be] explicit and persistent about sending big, clear signals…”
  3. Deliver the negative stuff in person
  4. When forming new groups, focus on two critical moments – “At those moments, people either dig in and become defensive and start justifying, and a lot of tension gets created. Or they say something like, ‘Hey, that’s interesting. Why don’t you agree? I might be wrong, but I’m curious and want to talk about it some more.’ What happens in that moment helps set the pattern for everything that follows.”
    • The first vulnerability
    • The first disagreement
  5. Listen like a trampoline – Not just about nodding attentively, you add insight. “The most effective listeners do four things:…”
    • They interact in ways that make the other person feel safe and supported
    • They take a helping, cooperative stance
    • They occasionally ask questions that gently and constructively challenge old assumptions
    • They make occasional suggestions to open up alternative paths
  6. In conversation, resist the temptation to reflexively add value – Don’t try to end the conversation with your own solution. Let the discussion flow (except maybe if time-boxed or if the folks are going in circles).
  7. Use candor-generating practices like AARs, BrainTrusts, and Read Teaming – AARs are After-Action Review done by Navy Seals — It’s like our Retrospectives. BrainTrusts are by Pixar. Red Teaming is a way for exposing risks by creating a team to purposely think of ways to make you fail. One good AAR structure is to use five questions:
    • What were our intended results?
    • What were our actual results?
    • What caused our results?
    • What will we do the same next time?
    • What will we do differently?
  8. Aim for candor; Avoid brutal honesty
  9. Embrace the discomfort – “One of the most difficult things about creating habits of vulnerability is that it requires a group to endure two discomforts: emotional pain and a sense of inefficiency. But as with any workout, the key is to understand that the pain is not a problem but the path to building a stronger group.
  10. Align language with action
  11. Build a wall between Performance Review and Professional Development
    • Performance evaluation tends to be a high-risk, inevitably judgmental interaction, often with salary-related consequences.
    • Development is about identifying strengths and providing support and opportunities for growth.
  12. Use Flash Mentoring – Hours, instead of months or years
  13. Make the leader occasionally disappear – Not to be confused with toxic absenteeism. Given the right foundations and having set them up to know what to do, the team should still be able to perform.

Establish Purpose — This is what matters.

  1. Name and rank your priorities
  2. Be ten times as clear about your priorities as you think you should be – “Leaders are inherently biased to presume that everyone in the group sees things as they do, when in fact they don’t.” It doesn’t help when all the leader sees are nodding heads. Overcommunicate priorities.
  3. Figure out where your group aims for proficiency and where it aims for creativity – “Building purpose [for proficiency, machine-like reliability, usually for service] is like building a vivid map: You want to spotlight the goal and provide crystal-clear directions to the checkpoints along the way…. Generating purpose [for creativity, for empowering groups to build something that has never existed before] is like supplying an expedition: You need to provide support, fuel, and tools to serve as a protective presence that empowers the team doing the work…. Most groups, of course, consist of a combination… The key is to clearly identify these areas and tailor leadership accordingly.
  4. Embrace the use of catchphrases – No way, Jose. Corny. “They aren’t gentle suggestions so much as clear reminders, crisp nudges in the direction the group wants to go.
  5. Measure what really matters
  6. Use artifacts – “Their environments are richly embedded with artifacts that embody their purpose and identity … they all reinforce the same signal: This is what matters.
  7. Focus on bar-setting behaviors – Example given what about a hockey team that rallied their culture around a specific behavior they called “Forty for Forty” — it’s something that they do as part of their play and I guess it captures who they are in some way. I guess the closest analogy I can think of is for testers, we often said “Trust and verify.” Because that was really what was happening and what needed to continue happening. You have to take care of the relationship between you and the devs where you show them you trust them and you can be trusted; and that it’s not about distrust towards them when you do your checks or tests on their work; it’s because you have to do what you have to do i.e., to test.

That’s it. Summarized the 3 chapters (and I guess pretty much the whole book). Of course, the book can provide better context. Go buy it if you want, or buy me a hardcopy which I’ll gladly leave lying around in the office for sharing. Thanks for reading this far (or skimming this far, it’s ok), now maybe you can go over the list of actionable ideas again and this time look for what you can apply or explore further.

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.

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 🙂

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

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!

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!