5 ms·

This article isn't disparaging having a process for developing features or for maintaining a pipeline of features. It's disparaging conditions that prioritize t

by sidlls 7y ago

This article isn't disparaging having a process for developing features or for maintaining a pipeline of features. It's disparaging conditions that prioritize the release of features for the sake of releasing features as opposed to for supporting the business' needs (as determined by data--including analysis of the performance of features, market conditions, and other factors). This article describes the last company I worked for very well: that company was and is struggling precisely because the senior leadership promoted a culture of feature releases without consideration for their impact and consistently changing the focus of feature development not based on data, but whim, so that the product was steadily losing focus and coherence.

dragonwriter 7y ago
> It's disparaging conditions that prioritize the release of features for the sake of releasing features Perhaps more to the point, it's disparaging having delivering features as the priority instead of delivering customer value.
0x445442 7y ago
> as determined by data--including analysis of the performance of features, market conditions, and other factors What would be refreshing are internal ROI dash boards for each project and group instead of just technical dash boards. On almost every project I've worked on this data is not available and there's never any real evidence presented to the practitioners for things such as tech stack or process decisions. Typically, it's just a bunch of assertions, hand waiving and requests of trust.
- BlueTemplar 7y ago
  Ultimately, we might be running into the issue that the impact is spread over time and cannot be condensed into a single ROI number ?
  - TheOtherHobbes 7y ago
    Impact is spread over time and multiple vectors. So now you have three problems in addition to getting working code the door - prioritising proposed features based on estimates of value, finding accurate metrics for assessing value after release, and mapping value changes over time. The nice thing about feature-driven-development is that it avoids the hard work of having to understand what you're actually doing. You can make the hamster wheel spin really fast and persuade yourself you're really going places. Until the wheel falls off.
    - 0x445442 7y ago
      I have no data to back this up but I'd say the majority of projects I've worked on during my career my time would have been better spent working on things that made the development teams more efficient. That is to say, with rare exception, I don't think the software actually generated anywhere near the benefit it cost to develop and maintain.
userium 7y ago
Exactly. Feature factories build features based on random assumptions, and not based on actual data. I just wrote about this yesterday (https://teamsuccess.io/hdd https://teamsuccess.io/hdd). I work as a consultant with lots of Scrum teams, and many devs feel like they're just sitting in the factory, cranking out features. Without knowing whether they're adding real value to the end-user. So what can you do to break free from the feature factory? Something that I recommend for the teams I work with, and noticed that actually works, is "Hypothesis-Driven Development". In short, replace the items in your product backlog with experiments rather than user stories. Instead of starting with a user story or epic, start with a testable hypothesis. Then run small experiments that will prove or disprove that hypothesis. My favorite question nowadays is "Wait, why are we building this feature again?" :)
- bob33212 7y ago
  In my experience people are afraid to ask that question. The answer to that question may lead to questions around total addressable market which could cause uppermanagement to question the viability of the product or at least the cost / benefit of having a big development and product management team in the first place.
  - Super_Jambo 7y ago
    This is a terribly sad comment on the structure of our society, people worried they might be making something pointless. And the solution is to make sure the people paying for it don't realize.
  - rhizome 7y ago
    Afraid with good reason. I think it's more likely that it would be seen as disrespectful to managment, product, bizdev, etc. who asked for it. That it's challenging their judgement.
  - cerberusss 7y ago
    What were the circumstances that people were afraid like that? For example, was this an in-house development team, or hired consultants? And how did you find out that people were afraid to ask these questions?
yibg 7y ago
Describes a company I was at very well too. Focus on timelines and delivering some defined scope. Most of the symptoms in the article were present. Is this just a natural course for startups unless conscious effort is put in to counteract it? I mean in the earlier days of startups just delivering features and catering to customer asks might be a good thing.

by sidlls 7y ago

dragonwriter 7y ago

> It's disparaging conditions that prioritize the release of features for the sake of releasing features Perhaps more to the point, it's disparaging having delivering features as the priority instead of delivering customer value.

0x445442 7y ago

> as determined by data--including analysis of the performance of features, market conditions, and other factors What would be refreshing are internal ROI dash boards for each project and group instead of just technical dash boards. On almost every project I've worked on this data is not available and there's never any real evidence presented to the practitioners for things such as tech stack or process decisions. Typically, it's just a bunch of assertions, hand waiving and requests of trust.

BlueTemplar 7y ago
Ultimately, we might be running into the issue that the impact is spread over time and cannot be condensed into a single ROI number ?
- TheOtherHobbes 7y ago
  Impact is spread over time and multiple vectors. So now you have three problems in addition to getting working code the door - prioritising proposed features based on estimates of value, finding accurate metrics for assessing value after release, and mapping value changes over time. The nice thing about feature-driven-development is that it avoids the hard work of having to understand what you're actually doing. You can make the hamster wheel spin really fast and persuade yourself you're really going places. Until the wheel falls off.
  - 0x445442 7y ago
    I have no data to back this up but I'd say the majority of projects I've worked on during my career my time would have been better spent working on things that made the development teams more efficient. That is to say, with rare exception, I don't think the software actually generated anywhere near the benefit it cost to develop and maintain.

userium 7y ago

Exactly. Feature factories build features based on random assumptions, and not based on actual data. I just wrote about this yesterday (https://teamsuccess.io/hdd https://teamsuccess.io/hdd). I work as a consultant with lots of Scrum teams, and many devs feel like they're just sitting in the factory, cranking out features. Without knowing whether they're adding real value to the end-user. So what can you do to break free from the feature factory? Something that I recommend for the teams I work with, and noticed that actually works, is "Hypothesis-Driven Development". In short, replace the items in your product backlog with experiments rather than user stories. Instead of starting with a user story or epic, start with a testable hypothesis. Then run small experiments that will prove or disprove that hypothesis. My favorite question nowadays is "Wait, why are we building this feature again?" :)

bob33212 7y ago
In my experience people are afraid to ask that question. The answer to that question may lead to questions around total addressable market which could cause uppermanagement to question the viability of the product or at least the cost / benefit of having a big development and product management team in the first place.
- Super_Jambo 7y ago
  This is a terribly sad comment on the structure of our society, people worried they might be making something pointless. And the solution is to make sure the people paying for it don't realize.
- rhizome 7y ago
  Afraid with good reason. I think it's more likely that it would be seen as disrespectful to managment, product, bizdev, etc. who asked for it. That it's challenging their judgement.
- cerberusss 7y ago
  What were the circumstances that people were afraid like that? For example, was this an in-house development team, or hired consultants? And how did you find out that people were afraid to ask these questions?

yibg 7y ago

Describes a company I was at very well too. Focus on timelines and delivering some defined scope. Most of the symptoms in the article were present. Is this just a natural course for startups unless conscious effort is put in to counteract it? I mean in the earlier days of startups just delivering features and catering to customer asks might be a good thing.