5 ms·

"3 weeks is the realistic estimate, 2 weeks is our best case scenario. The original deadline is no longer realistic due to <changes in scope>|<missing materials

"3 weeks is the realistic estimate, 2 weeks is our best case scenario. The original deadline is no longer realistic due to <changes in scope>|<missing materials>|<whatever>, but if you wish to launch on Friday we can do so by removing tasks from scope, would you prefer that solution" This reminds me what stuck with me after reading Shape Up, at a time when it was presented as the replacement for our Agile framework at work. What these methods have in common is a ritualized way to manage disappointment and help management to accept the loss of something they really wanted.

bartread 5y ago
Sort of, but that's not been the real value of Shape Up, at least not for us. We've found it's changed the conversation about what to build into one framed by investment and return, which has helped to take a lot of the emotion out of the discussion and decision-making process (and is also a much sounder basis for decision-making than, for example, how long things might take, or simply caving to the loudest voices[0]). So, yes, you could say it helps us manage disappointment but, whilst true, that's somewhat reductionist. What it's really enabled is an effective working relationship between our technology team and the other value-generating areas of the wider business. In turn, the primary value that's delivered is to ensure our development teams are working on projects that (are much more likely to) add real, strategic value as we build our platform and products, as opposed to just chasing individual client requirements - requirements that would deliver short-term cash, but which would tie us in knots and lead to dead ends that would destroy our ability to scale our business. (Of course, we don't do Shape Up in exactly the way described in the book: rather than cargo-culting, we've tailored the process to fit our business, which is a very different business to Basecamp. Happy to offer more detail if anyone is interested.) [0] It certainly gives us a way to manage and involve those voices though.
- lukestevens 5y ago
  > (Of course, we don't do Shape Up in exactly the way described in the book: rather than cargo-culting, we've tailored the process to fit our business, which is a very different business to Basecamp. Happy to offer more detail if anyone is interested.) Sure, would love to hear more about your use of Shape Up. What have you found that has worked in your context that goes beyond the initial framework, for example? :)
  - bartread 5y ago
    No stress. Here are a handful: - As I mentioned, our business is very different to Basecamp's. We're a technology driven MR and insights consultancy that is increasingly platform and product focussed. As such we have four or five different customer/stakeholder groups, each with their own requirements. Our betting table is therefore larger, and includes representatives from each of these groups, as well as our product managers, and some technical representatives. This makes the meeting tougher to wrangle but does give everyone a voice. Like Basecamp, the CEO and I have final say over what the teams actually work on, but we've only overridden a betting table decision once. - Our pitches include an ROI estimation. It's not particularly detailed, and we originally used something like t-shirt sizing. We now just give an estimated range. This helps us to have a more dispassionate discussion about which work to prioritise. - We are about to implement a change to the way we shape pitches, to break this up into two phases which run across two cycles. The first phase will focus on clarity about the problem we're trying to solve, the value of solving it, and our investment appetite. We'll then make decisions about which pitches we want to take to the second phase, which is a kind of extended validation, and will be where more research is carried out, and proposed solutions are roughed out. This should help us more effectively manage workload around pitch preparation, and ensure pitches are ready for teams to start work on at the beginning of cycles where they are prioritised. - We have regular check-ins with business stakeholders throughout each project, and they are involved in decision-making around any changes of direction or scope, or trade-offs that need to be made. - We have strong guidance in place for the teams around where they should be throughout the cycle: e.g., when they need to stop adding functionality, and focus on delivery; derisking each project, which should happen early, when UX testing should occur, etc. - We do sometimes reprioritise our strategic roadmap to ensure that we are adding necessary functionality to our platform in order to bid for and service high value client projects; such projects still get oversight from the betting table and could, at least in theory, be deprioritised if there were serious objections. It's not all been plain sailing though. For example, we still struggle to appropriately shape small batch projects, and getting people outside of tech onboard with creating pitches is an uphill battle, though one we are slowly winning.
    - lukestevens 5y ago
lbj 5y ago
More generally I would say that you need to religiously manage expectations and to keep in mind that this is much easier going into a project than halfway through. Giving an estimate of "1 month" is easy. Giving "1 week" 4 times is very painful, which is why I always work off buffers.
- jrumbut 5y ago
  In a nice work environment giving an estimate of 1 month is easy, but not always. A lot of managers have the bad habit of trying to negotiate estimates and it takes quite a bit of confidence and even stubborness to avoid telling someone what they clearly want to hear. That's the job but it can be one of the hardest parts of the job. Then for the next project, you know the pushback you're going to receive so (perhaps unconsciously) you have this bias toward a lower estimate. If you're not a regular employee the incentives are even worse. If one contractor tells you a week and the other tells you a month, which one will you hire? When you're billing for time and materials, and that's pretty normal, it hardly matters to the contractor if a deadline is missed because most clients know switching mid-project will only add to the delays.
  - quickthrower2 5y ago
    Yeah negotiating estimates with employees is odd. You are trying to predict something. Negotiating is to skew the prediction to be less accurate on average. Employee is not even doing it for fixed price so all the negotiating down does is lose accuracy. Some really shit jobs would expect weekend work to make the difference but with this job market: f that!
    - taneq 5y ago
      You’re not trying to make it more accurate, you’re trying to shift ownership of the resulting shambles to the individual employee.
      - quickthrower2 5y ago
        Yes exactly. Or they just don't trust the employee, either ethically (they'll slack off) or technically (they are doing it wrong, that's why it takes long). Or worse they are of the "they need to be challenged, keep 'em out of the comfort zone" mentality.

bartread 5y ago

Sort of, but that's not been the real value of Shape Up, at least not for us. We've found it's changed the conversation about what to build into one framed by investment and return, which has helped to take a lot of the emotion out of the discussion and decision-making process (and is also a much sounder basis for decision-making than, for example, how long things might take, or simply caving to the loudest voices[0]). So, yes, you could say it helps us manage disappointment but, whilst true, that's somewhat reductionist. What it's really enabled is an effective working relationship between our technology team and the other value-generating areas of the wider business. In turn, the primary value that's delivered is to ensure our development teams are working on projects that (are much more likely to) add real, strategic value as we build our platform and products, as opposed to just chasing individual client requirements - requirements that would deliver short-term cash, but which would tie us in knots and lead to dead ends that would destroy our ability to scale our business. (Of course, we don't do Shape Up in exactly the way described in the book: rather than cargo-culting, we've tailored the process to fit our business, which is a very different business to Basecamp. Happy to offer more detail if anyone is interested.) [0] It certainly gives us a way to manage and involve those voices though.

lukestevens 5y ago
> (Of course, we don't do Shape Up in exactly the way described in the book: rather than cargo-culting, we've tailored the process to fit our business, which is a very different business to Basecamp. Happy to offer more detail if anyone is interested.) Sure, would love to hear more about your use of Shape Up. What have you found that has worked in your context that goes beyond the initial framework, for example? :)
- bartread 5y ago
  No stress. Here are a handful: - As I mentioned, our business is very different to Basecamp's. We're a technology driven MR and insights consultancy that is increasingly platform and product focussed. As such we have four or five different customer/stakeholder groups, each with their own requirements. Our betting table is therefore larger, and includes representatives from each of these groups, as well as our product managers, and some technical representatives. This makes the meeting tougher to wrangle but does give everyone a voice. Like Basecamp, the CEO and I have final say over what the teams actually work on, but we've only overridden a betting table decision once. - Our pitches include an ROI estimation. It's not particularly detailed, and we originally used something like t-shirt sizing. We now just give an estimated range. This helps us to have a more dispassionate discussion about which work to prioritise. - We are about to implement a change to the way we shape pitches, to break this up into two phases which run across two cycles. The first phase will focus on clarity about the problem we're trying to solve, the value of solving it, and our investment appetite. We'll then make decisions about which pitches we want to take to the second phase, which is a kind of extended validation, and will be where more research is carried out, and proposed solutions are roughed out. This should help us more effectively manage workload around pitch preparation, and ensure pitches are ready for teams to start work on at the beginning of cycles where they are prioritised. - We have regular check-ins with business stakeholders throughout each project, and they are involved in decision-making around any changes of direction or scope, or trade-offs that need to be made. - We have strong guidance in place for the teams around where they should be throughout the cycle: e.g., when they need to stop adding functionality, and focus on delivery; derisking each project, which should happen early, when UX testing should occur, etc. - We do sometimes reprioritise our strategic roadmap to ensure that we are adding necessary functionality to our platform in order to bid for and service high value client projects; such projects still get oversight from the betting table and could, at least in theory, be deprioritised if there were serious objections. It's not all been plain sailing though. For example, we still struggle to appropriately shape small batch projects, and getting people outside of tech onboard with creating pitches is an uphill battle, though one we are slowly winning.
  - lukestevens 5y ago

lbj 5y ago

More generally I would say that you need to religiously manage expectations and to keep in mind that this is much easier going into a project than halfway through. Giving an estimate of "1 month" is easy. Giving "1 week" 4 times is very painful, which is why I always work off buffers.

jrumbut 5y ago
In a nice work environment giving an estimate of 1 month is easy, but not always. A lot of managers have the bad habit of trying to negotiate estimates and it takes quite a bit of confidence and even stubborness to avoid telling someone what they clearly want to hear. That's the job but it can be one of the hardest parts of the job. Then for the next project, you know the pushback you're going to receive so (perhaps unconsciously) you have this bias toward a lower estimate. If you're not a regular employee the incentives are even worse. If one contractor tells you a week and the other tells you a month, which one will you hire? When you're billing for time and materials, and that's pretty normal, it hardly matters to the contractor if a deadline is missed because most clients know switching mid-project will only add to the delays.
- quickthrower2 5y ago
  Yeah negotiating estimates with employees is odd. You are trying to predict something. Negotiating is to skew the prediction to be less accurate on average. Employee is not even doing it for fixed price so all the negotiating down does is lose accuracy. Some really shit jobs would expect weekend work to make the difference but with this job market: f that!
  - taneq 5y ago
    You’re not trying to make it more accurate, you’re trying to shift ownership of the resulting shambles to the individual employee.
    - quickthrower2 5y ago
      Yes exactly. Or they just don't trust the employee, either ethically (they'll slack off) or technically (they are doing it wrong, that's why it takes long). Or worse they are of the "they need to be challenged, keep 'em out of the comfort zone" mentality.