Scammers demand payment by gift card

Through Consumer Sentinel we hear from people across the country about frauds they encounter in the marketplace. One thing we learn from these reports is how scammers want to be paid. People are telling us that they’re increasingly being told to pay with gift cards – specifically, by giving someone the PIN number off the back of a gift card. Often people are specifically asked for certain brands, like iTunes and Google Play cards.

We found that from January through September of this year, gift cards and reload cards (like MoneyPak) were reported as a payment method in 26% of the fraud reports in which people told us how they paid, up from just 7% in 2015 – a 270% increase. Con artists favor these cards because they can get quick cash, the transaction is largely irreversible, and they can remain anonymous.

It’s not just tech support scams. When people report paying a fraudster with a gift or reload card, about four times out of five the fraud they report is an imposter scam – in fact, gift cards and reload cards are now the number one reported method of payment for imposter scams. These scammers pose as well-known businesses, family members, friends, or government agencies. They deploy various tactics to compel people to pay. 

You can read the details here, and what to do to prevent this from happening to you.  

Example of a System Sequence Diagram (SSD)

Here is a video showing you how to make a UML Sequence Diagram using Lucidchart. 

School Surveillance

Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable

This is the title of blog by Henrik Kniberg @ Crisp Consultants.  I read about the earliest testable/usable/lovable MVP in Patton's User Story Mapping book in Chapter 3, "Plan to Learn Faster".  This chapter is about Eric, who is the product owner of a team.

One of the hard parts of being a product owner is taking ownership of someone else's idea and helping to make it successful, or proving that it isn't likely to be.

The rest of the chapter about "learning faster" uses Eric as an example, but think about your own team, too.

• Discussing Your Opportunity (Your first story discussion is for framing the opportunity), 
• Validate the Problem (validate that the problems you're solving really exist), 
• Prototype to Learn (sketch and prototype so you can envision your solution), 
• Watch Out for What People Say They Want (the real proof is when those people actually choose to use it every day.  And it's going to take more than a prototype to learn that.
• Build to Learn
• Iterate Until Viable
• How to Do It the Wrong Way -- this is where the blog from Henrik Kniberg about Making Sense of the MVP is especially important. 

There is a simple visual in the chapter, but the full blog is really great, and offers examples of the car (mentioned in the chapter), but in much more detail.  

There are also examples of Spotify, the Music Player (really great if you remember back to the early days of Spotify, but certainly great to see how they started thinking of a "music player") and Lego (When they first started exploring the concept, they did paper prototypes and brought them to small kids. The kids’ first reaction was “hey, who are the bad guys? I can’t see who’s good and who’s bad!”) Oops.  Back to more design iterations.

The blog ends with Improving on "MVP" - but what he really means is...

Read his blog, it's great, and I learning about it early will be helpful when you are working on your value proposition and prototypes.

Comments?

The Essence of Agile

According to Martin Fowler,

It's been over a decade since the developers of agile methods first started to talk about their approaches. In this time agile thinking has changed from a niche activity to an approach that is widely used. However, like any popular technique, agile software development has suffered from semantic diffusion, so much of what we see under the name of agile doesn't bear much resemblance to what the early pioneers were doing. So I think it's important to revisit the essential elements of agile thinking

I've always seen the essence of agile thinking resting on two contrasts with traditional plan-driven software engineering.

Plan-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform with this design. Success is measured according to how well development follows this plan. 

Agile plans are a baseline that we use to help us control change. Agile teams plan just as carefully as traditional teams, but the plans are constantly changing to reflect the things we learn during a project. Success is based on value delivered by the software.

Watch the 20-minute video of Martin Fowler explaining the history of software projects with the beginnings of plan-driven engineering (i.e., Waterfall) with agile plans.

Disturbing Digital Coincidences :)

Here is a New Yorker column, called "Shouts and Murmurs" that is usually funny, or tongue in cheek, and in this case, it's related to how pervasive advertising is tied to our social media.

It starts...

"I am beginning to experience what I would call disturbing digital coincidences. Call me crazy, but on Wednesday I asked my Amazon Echo Dot, “Alexa, what time is it?” On Thursday, I got an e-mail from Wayfair suggesting that I might like to order a thirty-inch farmhouse-style wall clock that lends any room a touch of charm. Coincidence?"

Then...

"While chatting with a colleague via Skype, I cleared my throat and coughed twice. Hours later, my Facebook feed displayed an ad for Mucinex. On Sunday night, I watched a YouTube video of ice agents hassling immigrants. On Monday morning, the first song in my Spotify “Discover Weekly” playlist was “Cold as Ice” by Foreigner."

You get the idea.   Either pretty funny, or scary....   Read more... 

Blog for MIS 441

The purpose of this blog is to:

• Offer links and articles that are related to topics we cover in class.

• Offer posts that I want to blog about, but do not want to clutter the Collaborative Learning links, or D2L discussions.

In short, this blog is tech-related news I found interesting.  You can add your comments here, too.