6 ms·

To play Devil’s advocate: that’s 2 months a customer went without being able to use that feature. What could you or the company have learned if you shipped an e

by ozmbie 8y ago

To play Devil’s advocate: that’s 2 months a customer went without being able to use that feature. What could you or the company have learned if you shipped an earlier version and measured how people used it? Was your feeling of control and happiness worth the business information of not having that feature in the wild for 2 months?

wolco 8y ago
To play devil's advocate. Other work can be assigned so in two months the customer gets the entire website. If they did it the other way every two weeks something would be finished but at the end they need to rewrite the backend adding an addional months because they didn't have the chance to look ahead and see that module 1 and 2 can't run at the same time.
- scarface74 8y ago
  Which is actually very relevant to the project that I’m referring to. All four services were database intensive. They all worked perfectly independently. But when messages started at service 1, did some database work and put a message in the queue to kick off the next process and so on. When all four were running at the same time processing messages, the database screamed and made the website unresponsive. It took me longer to tune performance than to write the code. Can you imagine four developers working together tweaking code, queries, indexes, number of simultaneous threads, etc?
riskable 8y ago
The solution to this problem is to solicit user feedback all the time. As in, the moment you get your code kinda sorta working you get some feedback from the ultimate end users (e.g. NOT the product manager, LOL)... "This rough implementation is how I (we) envision this feature working. What do you think?" "We've got the feature working well but it requires non-trivial back end changes. Would you be willing to wait or will you be satisfied if it works but only in a very manual way until we get the back end changes in place?" Week 2 after release: "The feature is live... What do you think? How is it working?" These are conversations the developers should be having with the end users. Regularly! It's when developers only ever talk to their boss and/or the project manager that pushes development into the anti-user zone.
- gronne 8y ago
  Good luck getting the customer to provide feedback on a <2 week cycle. Ime. customer feedback and/or approval is a serious dev bottleneck.
  - LaGrange 8y ago
    That is also feedback. Having unresponsive customers is a bad sign, often suggesting that maybe they're not as interested in the product as the smiles the hyper-gregarious sales team receives would suggest.
    - scarface74 8y ago
      It’s not always about customer feedback when implementing functionality. For instance, take the rules governing rail car maintenance. https://www.railinc.com/rportal/documents/18/260641/GuideforRailroads.pdf https://www.railinc.com/rportal/documents/18/260641/Guidefor... The software for it has to work. There will be months of work implementing the rules engine before you have anything to show the customer besides a mock-up.. You won’t really need two week sprints to get feedback from customers. It either implements all of the rules or it doesn’t. I can imagine the same happening for tax software.
      - lstamour 8y ago
        That’s taking a strictly algorithmic approach, and assumes the rules are equally understood by all parties and have no inconsistencies or undefined states. And as an example, I happen to know TaxCycle is unusually responsive to customer feedback on releases and offers early previews. Here’s a list of improvements from 2017 feedback: https://www.taxcycle.com/News/Your-feedback-becomes-features-in-TaxCycle-Look-what-youve-done-for-TaxCycle-this-year https://www.taxcycle.com/News/Your-feedback-becomes-features...
    - adrianN 8y ago
      Your customer might not have the manpower to test your product all the time. They're presumably already spending a lot of money on you, they might not want to spend an extra headcount just for testing your work. They might feel that that's your job.
jasonlotito 8y ago
> a customer went without being able to use that feature. Well, by definition, a feature that takes 2 months to build takes 2 months to build. Shipping part of the feature early doesn't provide feedback for the finished product. It provides feedback for the incomplete feature. How valuable is that feature? In addition to that,a feature that takes 2 months to build will take longer if you are releasing multiple sub versions. You have to account for actually making it production ready, and releasing it, and handling errors and feedback. This is why experience matter. Was your feeling of control and happiness worth shipping half-finished, substandard product to your customers?
- scarface74 8y ago
  And in the real world, you often go through all of the ceremony of a “release” but it isn’t put in production until it’s complete anyway. Until then, the feature is just on a UAT server and the code is officially “in production” but it’s behind a feature flag.
scarface74 8y ago
The communication and coordination overhead of four or five developers working together is non-neglible on top of that if any part had to be reworked that also would have involved overhead between multiple developers. No matter how well you spec something out, there are always the unknowns - i.e. I forgot about this piece of business logic based on a checkbox on the front end which is going to cause a boolean to be passed in the model that’s going to affect all four services and a database table. Now I need to either communicate with all of the developers, or do it myself and dig through code I am not familiar with. In this case, I just make all six changes myself, do a quick test and commit the code and update the docs. Then all four developers would have had to coordinate with the Devops guy. This is all getting into “Mythical Man Month” territory. Instead of me trying to explain it, I might as well crib the explanation from Wikipedia. Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them. Four equally qualified people should be able to deliver more features in the same amount of time working independently than four people working together.
JustSomeNobody 8y ago
This is an "ideal" which I would argue almost never happens in the real world.
rawoke083600 8y ago
exactly !! if a feature is worth having... its usually value in having it in one week rather than 3.. sooner is better... scrum does not allow this
- dagw 8y ago
  Not if that early feature is broken and doesn't work. Then the conventional wisdom will quickly become "Don't use feature X, it's broken" and you're going to have to spend a lot of time re-educating your user once you've actually gotten around to fixing it (assuming you actually get around to fixing it and aren't pulled away to do something more 'important')

by ozmbie 8y ago

wolco 8y ago

To play devil's advocate. Other work can be assigned so in two months the customer gets the entire website. If they did it the other way every two weeks something would be finished but at the end they need to rewrite the backend adding an addional months because they didn't have the chance to look ahead and see that module 1 and 2 can't run at the same time.

scarface74 8y ago
Which is actually very relevant to the project that I’m referring to. All four services were database intensive. They all worked perfectly independently. But when messages started at service 1, did some database work and put a message in the queue to kick off the next process and so on. When all four were running at the same time processing messages, the database screamed and made the website unresponsive. It took me longer to tune performance than to write the code. Can you imagine four developers working together tweaking code, queries, indexes, number of simultaneous threads, etc?

riskable 8y ago

The solution to this problem is to solicit user feedback all the time. As in, the moment you get your code kinda sorta working you get some feedback from the ultimate end users (e.g. NOT the product manager, LOL)... "This rough implementation is how I (we) envision this feature working. What do you think?" "We've got the feature working well but it requires non-trivial back end changes. Would you be willing to wait or will you be satisfied if it works but only in a very manual way until we get the back end changes in place?" Week 2 after release: "The feature is live... What do you think? How is it working?" These are conversations the developers should be having with the end users. Regularly! It's when developers only ever talk to their boss and/or the project manager that pushes development into the anti-user zone.

gronne 8y ago
Good luck getting the customer to provide feedback on a <2 week cycle. Ime. customer feedback and/or approval is a serious dev bottleneck.
- LaGrange 8y ago
  That is also feedback. Having unresponsive customers is a bad sign, often suggesting that maybe they're not as interested in the product as the smiles the hyper-gregarious sales team receives would suggest.
  - scarface74 8y ago
    It’s not always about customer feedback when implementing functionality. For instance, take the rules governing rail car maintenance. https://www.railinc.com/rportal/documents/18/260641/GuideforRailroads.pdf https://www.railinc.com/rportal/documents/18/260641/Guidefor... The software for it has to work. There will be months of work implementing the rules engine before you have anything to show the customer besides a mock-up.. You won’t really need two week sprints to get feedback from customers. It either implements all of the rules or it doesn’t. I can imagine the same happening for tax software.
    - lstamour 8y ago
      That’s taking a strictly algorithmic approach, and assumes the rules are equally understood by all parties and have no inconsistencies or undefined states. And as an example, I happen to know TaxCycle is unusually responsive to customer feedback on releases and offers early previews. Here’s a list of improvements from 2017 feedback: https://www.taxcycle.com/News/Your-feedback-becomes-features-in-TaxCycle-Look-what-youve-done-for-TaxCycle-this-year https://www.taxcycle.com/News/Your-feedback-becomes-features...
  - adrianN 8y ago
    Your customer might not have the manpower to test your product all the time. They're presumably already spending a lot of money on you, they might not want to spend an extra headcount just for testing your work. They might feel that that's your job.

jasonlotito 8y ago

> a customer went without being able to use that feature. Well, by definition, a feature that takes 2 months to build takes 2 months to build. Shipping part of the feature early doesn't provide feedback for the finished product. It provides feedback for the incomplete feature. How valuable is that feature? In addition to that,a feature that takes 2 months to build will take longer if you are releasing multiple sub versions. You have to account for actually making it production ready, and releasing it, and handling errors and feedback. This is why experience matter. Was your feeling of control and happiness worth shipping half-finished, substandard product to your customers?

scarface74 8y ago
And in the real world, you often go through all of the ceremony of a “release” but it isn’t put in production until it’s complete anyway. Until then, the feature is just on a UAT server and the code is officially “in production” but it’s behind a feature flag.

scarface74 8y ago

The communication and coordination overhead of four or five developers working together is non-neglible on top of that if any part had to be reworked that also would have involved overhead between multiple developers. No matter how well you spec something out, there are always the unknowns - i.e. I forgot about this piece of business logic based on a checkbox on the front end which is going to cause a boolean to be passed in the model that’s going to affect all four services and a database table. Now I need to either communicate with all of the developers, or do it myself and dig through code I am not familiar with. In this case, I just make all six changes myself, do a quick test and commit the code and update the docs. Then all four developers would have had to coordinate with the Devops guy. This is all getting into “Mythical Man Month” territory. Instead of me trying to explain it, I might as well crib the explanation from Wikipedia. Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them. Four equally qualified people should be able to deliver more features in the same amount of time working independently than four people working together.

JustSomeNobody 8y ago

This is an "ideal" which I would argue almost never happens in the real world.

rawoke083600 8y ago

exactly !! if a feature is worth having... its usually value in having it in one week rather than 3.. sooner is better... scrum does not allow this

dagw 8y ago
Not if that early feature is broken and doesn't work. Then the conventional wisdom will quickly become "Don't use feature X, it's broken" and you're going to have to spend a lot of time re-educating your user once you've actually gotten around to fixing it (assuming you actually get around to fixing it and aren't pulled away to do something more 'important')