3 ms·

Are you being sarcastic? I ask because Agile methodology, when done correctly as a bi-directional contract between team and stakeholders, does not have to be l

Are you being sarcastic? I ask because Agile methodology, when done correctly as a bi-directional contract between team and stakeholders, does not have to be like that at all.

bitwize 9y ago
At any organization whose business model has evolved beyond "burn through investors' money, ask investors for more money", management NEEDS to have meaningful answers to these questions: * What remains to be done? * How much will it cost? * How long will it take? * Is the team on track or falling behind? Forget contracts. Answers to these questions are non-negotiable for the team. Because the PM or engineering manager will be held accountable for those answers by the executives. The best way to provide those answers is to adopt a data-driven approach. You have stories in the backlog. At the start of each sprint, the developer(s) to whom the stories are assigned break the story down into tasks and assign an estimate IN HOURS to each task. As the tasks are completed throughout the sprint, each developer logs how many hours they spent on that task, preferably daily. This amplifies the benefits of Agile because the manager doesn't have to guess, they can look at the burndown chart and see -- are the developers meeting their estimates? If not, by how much are they missing? Are they taking on an appropriate amount of work each sprint? Should they do less? More? Who is doing well and who is struggling? Then, decisions can be made with respect to who should do how much work on what, with rapid turnaround time. "If it can't be measured, it can't be managed." This is fundamental to management, and has been a maxim in software management even during the Waterfall days. What Agile gets you is shortened feedback cycles and more rapid turnaround.
- ryanbrunner 9y ago
  Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: - It's possible to know what tasks are required to complete a project at the outset of a project. - It's possible to estimate how long those tasks will take to complete. Any team I've ever seen who claims to do well with both of the above points either had massive sandbagging problems, sometimes openly acknowledged by everyone, and often failed to deliver the best solution they could due to the rigidity of their project plan and the political consequences of straying from it. Furthermore, "if it can't be measured, it can't be managed" is true to a degree, but over-reliance on metrics can result in tunnel vision towards those metrics, resulting in accumulation of technical debt, quality issues, less team cohesion and a host of other problems as your teams myopically focus on hitting their numbers above all else.
  - bitwize 9y ago
    > Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: > - It's possible to know what tasks are required to complete a project at the outset of a project. Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1-3 months, with certainty going down as the time horizon gets farther out. This is why Agile works. > - It's possible to estimate how long those tasks will take to complete. This is part of why you need to capture estimates and actuals. Even if those estimates are wrong, in practice, by comparing estimates to actuals by each developer, a picture will emerge of how far that developer will overshoot or undershoot their own estimates. Those estimates the become actionable data, even if they're wrong 100% of the time.
    - ryanbrunner 9y ago
      > Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1-3 months, with certainty going down as the time horizon gets farther out. This is why Agile works. Fair enough on the level of a sprint. In my experience, management and stakeholders rarely care about a sprint, they care about the project as a whole. And again, in my experience, the accuracy of estimates falls off precipitously once you get beyond 1 or 2 sprints, unless you're willing to pad estimates or lock down your plans to a degree that will hurt the success of your project (by not taking into account learnings as you build). > This is part of why you need to capture estimates and actuals. Even if those estimates are wrong, in practice, by comparing estimates to actuals by each developer, a picture will emerge of how far that developer will overshoot or undershoot their own estimates. Those estimates the become actionable data, even if they're wrong 100% of the time. This would be true if estimates had high precision, but low accuracy (i.e. developer A consistently overestimates, and developer B consistently underestimates). In my experience, the opposite is more true than not - developers have relatively well tuned accuracy, but horrible precision. If everything goes according to plan, developers can estimate that fairly well. It's the amount of times things don't go according to plan that's the problem.
  - fmihaila 9y ago

Are you being sarcastic? I ask because Agile methodology, when done correctly as a bi-directional contract between team and stakeholders, does not have to be like that at all.

bitwize 9y ago

At any organization whose business model has evolved beyond "burn through investors' money, ask investors for more money", management NEEDS to have meaningful answers to these questions: * What remains to be done? * How much will it cost? * How long will it take? * Is the team on track or falling behind? Forget contracts. Answers to these questions are non-negotiable for the team. Because the PM or engineering manager will be held accountable for those answers by the executives. The best way to provide those answers is to adopt a data-driven approach. You have stories in the backlog. At the start of each sprint, the developer(s) to whom the stories are assigned break the story down into tasks and assign an estimate IN HOURS to each task. As the tasks are completed throughout the sprint, each developer logs how many hours they spent on that task, preferably daily. This amplifies the benefits of Agile because the manager doesn't have to guess, they can look at the burndown chart and see -- are the developers meeting their estimates? If not, by how much are they missing? Are they taking on an appropriate amount of work each sprint? Should they do less? More? Who is doing well and who is struggling? Then, decisions can be made with respect to who should do how much work on what, with rapid turnaround time. "If it can't be measured, it can't be managed." This is fundamental to management, and has been a maxim in software management even during the Waterfall days. What Agile gets you is shortened feedback cycles and more rapid turnaround.

ryanbrunner 9y ago
Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: - It's possible to know what tasks are required to complete a project at the outset of a project. - It's possible to estimate how long those tasks will take to complete. Any team I've ever seen who claims to do well with both of the above points either had massive sandbagging problems, sometimes openly acknowledged by everyone, and often failed to deliver the best solution they could due to the rigidity of their project plan and the political consequences of straying from it. Furthermore, "if it can't be measured, it can't be managed" is true to a degree, but over-reliance on metrics can result in tunnel vision towards those metrics, resulting in accumulation of technical debt, quality issues, less team cohesion and a host of other problems as your teams myopically focus on hitting their numbers above all else.
- bitwize 9y ago
  > Your system makes two assumptions that have been thoroughly, repeatedly proven wrong: > - It's possible to know what tasks are required to complete a project at the outset of a project. Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1-3 months, with certainty going down as the time horizon gets farther out. This is why Agile works. > - It's possible to estimate how long those tasks will take to complete. This is part of why you need to capture estimates and actuals. Even if those estimates are wrong, in practice, by comparing estimates to actuals by each developer, a picture will emerge of how far that developer will overshoot or undershoot their own estimates. Those estimates the become actionable data, even if they're wrong 100% of the time.
  - ryanbrunner 9y ago
    > Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1-3 months, with certainty going down as the time horizon gets farther out. This is why Agile works. Fair enough on the level of a sprint. In my experience, management and stakeholders rarely care about a sprint, they care about the project as a whole. And again, in my experience, the accuracy of estimates falls off precipitously once you get beyond 1 or 2 sprints, unless you're willing to pad estimates or lock down your plans to a degree that will hurt the success of your project (by not taking into account learnings as you build). > This is part of why you need to capture estimates and actuals. Even if those estimates are wrong, in practice, by comparing estimates to actuals by each developer, a picture will emerge of how far that developer will overshoot or undershoot their own estimates. Those estimates the become actionable data, even if they're wrong 100% of the time. This would be true if estimates had high precision, but low accuracy (i.e. developer A consistently overestimates, and developer B consistently underestimates). In my experience, the opposite is more true than not - developers have relatively well tuned accuracy, but horrible precision. If everything goes according to plan, developers can estimate that fairly well. It's the amount of times things don't go according to plan that's the problem.
- fmihaila 9y ago