Skip to main content
added 1824 characters in body
Source Link
David Espina
  • 37.2k
  • 4
  • 35
  • 92

I am reading three separate and distinct issues: 1) current team is "stuck" in testing and debugging; 2) new project with an initial target of six months and now a commitment to a target of two months; 3) fear of a stretch role.

  1. What does stuck mean? If during your testing you're finding an abnormal amount of defects and defects skewed to a high severity, then I would argue you are not stuck in testing but rather not finished with development. You should kick back the product and finish development properly.

  2. To analyze whether the six to two is an issue, you need to take a look at your assumptions and basis of estimate and the range of your estimate. If you assumed your current team who was "stuck" in the previous project, then perhaps you padded the six months in order to finish. Regarding the range, where did the six months fall? If you estimated one month to six months to finish, most likely three, then a two-month duration is aggressive but not unrealistic. If six months was already aggressive in your range, say 5 best, 9 worst, 7 most likely, then do not accept the two-month commitment. So there are a lot of unknowns about this project for anyone here to answer but here are a few questions to answer to get you started on that analysis. Read below on my opinion about task resource elasticity. Crashing your schedule by loading it up with workers is CERTAINLY an available option but you MUST evaluate resource elasticity in the environment in which you are working.

  3. Get over it. Stretch. Lean in. Jump in when you are not comfortable. If you wait until you are comfortable, your peers will pass you by in growth and rank. You will make mistakes, which is fantastic because you can learn from them. Seek out a mentor.

Original but unacceptable answer:

Not a direct answer to this problem but a word of caution when considering the notion of the mythical man month. This is not a valid construct across all types of tasks. Don't just assume that adding employees would cause all tasks to increase in duration all the time. Different tasks have different degrees of resource elasticity and will respond differently, both up and down, when adding or removing workers against that task. Adding workers against a task can most certainly have a favorable effect on crashing your schedule in many circumstances so you need to evaluate the tasks at hand on a case by case basis.

Not a direct answer to this problem but a word of caution when considering the notion of the mythical man month. This is not a valid construct across all types of tasks. Don't just assume that adding employees would cause all tasks to increase in duration all the time. Different tasks have different degrees of resource elasticity and will respond differently, both up and down, when adding or removing workers against that task. Adding workers against a task can most certainly have a favorable effect on crashing your schedule in many circumstances so you need to evaluate the tasks at hand on a case by case basis.

I am reading three separate and distinct issues: 1) current team is "stuck" in testing and debugging; 2) new project with an initial target of six months and now a commitment to a target of two months; 3) fear of a stretch role.

  1. What does stuck mean? If during your testing you're finding an abnormal amount of defects and defects skewed to a high severity, then I would argue you are not stuck in testing but rather not finished with development. You should kick back the product and finish development properly.

  2. To analyze whether the six to two is an issue, you need to take a look at your assumptions and basis of estimate and the range of your estimate. If you assumed your current team who was "stuck" in the previous project, then perhaps you padded the six months in order to finish. Regarding the range, where did the six months fall? If you estimated one month to six months to finish, most likely three, then a two-month duration is aggressive but not unrealistic. If six months was already aggressive in your range, say 5 best, 9 worst, 7 most likely, then do not accept the two-month commitment. So there are a lot of unknowns about this project for anyone here to answer but here are a few questions to answer to get you started on that analysis. Read below on my opinion about task resource elasticity. Crashing your schedule by loading it up with workers is CERTAINLY an available option but you MUST evaluate resource elasticity in the environment in which you are working.

  3. Get over it. Stretch. Lean in. Jump in when you are not comfortable. If you wait until you are comfortable, your peers will pass you by in growth and rank. You will make mistakes, which is fantastic because you can learn from them. Seek out a mentor.

Original but unacceptable answer:

Not a direct answer to this problem but a word of caution when considering the notion of the mythical man month. This is not a valid construct across all types of tasks. Don't just assume that adding employees would cause all tasks to increase in duration all the time. Different tasks have different degrees of resource elasticity and will respond differently, both up and down, when adding or removing workers against that task. Adding workers against a task can most certainly have a favorable effect on crashing your schedule in many circumstances so you need to evaluate the tasks at hand on a case by case basis.

Source Link
David Espina
  • 37.2k
  • 4
  • 35
  • 92

Not a direct answer to this problem but a word of caution when considering the notion of the mythical man month. This is not a valid construct across all types of tasks. Don't just assume that adding employees would cause all tasks to increase in duration all the time. Different tasks have different degrees of resource elasticity and will respond differently, both up and down, when adding or removing workers against that task. Adding workers against a task can most certainly have a favorable effect on crashing your schedule in many circumstances so you need to evaluate the tasks at hand on a case by case basis.