5 ms·

Having managed agile projects at startups and big tech, there's a few problems that were common: 1) lack of customer feedback loop - agile is meant to ship fea

Having managed agile projects at startups and big tech, there's a few problems that were common: 1) lack of customer feedback loop - agile is meant to ship features quickly to customers, get feedback, and iterate/enhance/pivot based on their feedback. Often times the projects were simply things that "had to be done" and the whole agile process was not necessary. 2) inaccurate estimation - projects would start with asking engineers to estimate "t-shirt size" efforts on user stories, and what happened in reality is the projects always ended up taking longer than expected due to unknowns, dependencies etc. I've only worked with a few senior engineers who can accurately estimate, but junior engineers starting their careers in a big company, it's a tall order to ask them to be accurate.

willio58 4y ago
As I have taken on more senior roles I’ve learned how to estimate better and most of the time it’s just estimating much more time
- theshrike79 4y ago
  Good old Miracle Worker formula. Take your original estimate and double it. =)
- antupis 4y ago
  Initial estimation * 2 is my way nowadays.
  - rmnclmnt 4y ago
    Golden formula of time estimation!
  - aliswe 4y ago
    How unscientific - 3.14 is the way to go.
    - antupis 4y ago
      shitty the boss with excel yelling about bad estimations -> add more pi-decimals.
- Dyac 4y ago
  I've taken to doubling my estimate and then stepping up to the next order of magnitude. Eg. 2 hours becomes 4 days. It allows for delivery, QA, bug fixes and documentation.
- thewileyone 4y ago
  Just use Scotty's rules :)
chronofar 4y ago
#1 is I think often the biggest issue, or rather a direct easy to spot symptom of the central issue which is that "agile" is just blanket applied as a development methodology to everything, including many projects that have no business being agile, while the project requirements aren't agile at all. Agile is better thought of as a product management than a development methodology. It is meant to be agile in developing your product to iterate quickly and respond to feedback from real users. It's a great fit after a MVP is released to users to iterate on their interaction in a responsive way. It's not an ideology to be followed religiously for all projects with all constraints (particularly those where those paying for it want specific features/dates are a poor fit). - If a given project is only agile on the development side and not also the project and product management/sponsor side, there's going to be a ton of friction. - If all projects use the same methodologies (be it agile or waterfall or some other new hip flavor) to develop regardless of their scope and needs and sponsor, there's going to be a ton of friction. - If your teams adjust their approach to meet the needs of the project at hand, and all aspects of the team for a given project are in sync with that approach not just developers, you just may be able to glean a relatively smooth experience.

willio58 4y ago

As I have taken on more senior roles I’ve learned how to estimate better and most of the time it’s just estimating much more time

theshrike79 4y ago
Good old Miracle Worker formula. Take your original estimate and double it. =)
antupis 4y ago
Initial estimation * 2 is my way nowadays.
- rmnclmnt 4y ago
  Golden formula of time estimation!
- aliswe 4y ago
  How unscientific - 3.14 is the way to go.
  - antupis 4y ago
    shitty the boss with excel yelling about bad estimations -> add more pi-decimals.
Dyac 4y ago
I've taken to doubling my estimate and then stepping up to the next order of magnitude. Eg. 2 hours becomes 4 days. It allows for delivery, QA, bug fixes and documentation.
thewileyone 4y ago
Just use Scotty's rules :)

chronofar 4y ago

#1 is I think often the biggest issue, or rather a direct easy to spot symptom of the central issue which is that "agile" is just blanket applied as a development methodology to everything, including many projects that have no business being agile, while the project requirements aren't agile at all. Agile is better thought of as a product management than a development methodology. It is meant to be agile in developing your product to iterate quickly and respond to feedback from real users. It's a great fit after a MVP is released to users to iterate on their interaction in a responsive way. It's not an ideology to be followed religiously for all projects with all constraints (particularly those where those paying for it want specific features/dates are a poor fit). - If a given project is only agile on the development side and not also the project and product management/sponsor side, there's going to be a ton of friction. - If all projects use the same methodologies (be it agile or waterfall or some other new hip flavor) to develop regardless of their scope and needs and sponsor, there's going to be a ton of friction. - If your teams adjust their approach to meet the needs of the project at hand, and all aspects of the team for a given project are in sync with that approach not just developers, you just may be able to glean a relatively smooth experience.