How many of you know deep down that the team is working on something that no customer wants?

Flojo

Expert Member
Joined
Sep 24, 2009
Messages
1,365

Snippet:
Picture this: your team is under immense pressure to crank out a new software project. The daily stand-up is mostly about reporting that the code will be checked in by sprint end. The team's nights, weekends and family time are sacrificed to get this super important project to Done™. The new code is delivered by the Date™, it's unstable but nobody knows that because the testing is mostly happy path anyway, don't get me wrong, people do test it and they do find bugs - I mean, they don't find things like low frequency of occurrence crashes, slow-but-important memory leaks, race conditions and poor performance under load - but they do find enough bugs that everyone is lulled into a false sense of safety. The project completes and success is declared! Then nothing happens. For months. No news of customers. No field bug reports. Complete radio silence. You forget all about the project, and you never hear of it again.

What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:
  • Not wanted - Company specified a solution to a problem that customers don't actually have
  • No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
  • Incorrect Packaging - Customers need a website, but the company created an iOS app instead
  • Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
Agile teams that truly iterate with the customer can often avoid these problems because the customer is there the whole way through and the team continuously pivots to close gaps discovered by the customer throughout the project, thereby building something the customer actually needs and wants.
 

TheRidDlerX

Senior Member
Joined
Apr 30, 2008
Messages
803
Not even deep down. It's just a fact. Or worse working on 'new features' for weeks at end ignoring the bugs being reported on existing ones, and claiming to be to busy to fix it because of work on said new features. Wtf
 

rambo919

Executive Member
Joined
Jul 30, 2008
Messages
9,247
Rule#1: The idiot boss of bosses is always right.... even when he runs a game company but never plays games, or runs a accounting software company but does not even know bookkeeping, etc.....
 

Compton_effect

Honorary Master
Joined
Sep 7, 2006
Messages
12,158

Snippet:
Picture this: your team is under immense pressure to crank out a new software project. The daily stand-up is mostly about reporting that the code will be checked in by sprint end. The team's nights, weekends and family time are sacrificed to get this super important project to Done™. The new code is delivered by the Date™, it's unstable but nobody knows that because the testing is mostly happy path anyway, don't get me wrong, people do test it and they do find bugs - I mean, they don't find things like low frequency of occurrence crashes, slow-but-important memory leaks, race conditions and poor performance under load - but they do find enough bugs that everyone is lulled into a false sense of safety. The project completes and success is declared! Then nothing happens. For months. No news of customers. No field bug reports. Complete radio silence. You forget all about the project, and you never hear of it again.

What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:
  • Not wanted - Company specified a solution to a problem that customers don't actually have
  • No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
  • Incorrect Packaging - Customers need a website, but the company created an iOS app instead
  • Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
Agile teams that truly iterate with the customer can often avoid these problems because the customer is there the whole way through and the team continuously pivots to close gaps discovered by the customer throughout the project, thereby building something the customer actually needs and wants.
So - which bank do you work at?
 
Top