4 ms·

Deadlines are a proxy for dependencies The deadline is important because of scheduling, and whoever needs to use your thing has a certain stretch of time where

by 8note 3y ago

Deadlines are a proxy for dependencies The deadline is important because of scheduling, and whoever needs to use your thing has a certain stretch of time where they can implement their part. I've been liking to instead model the dependencies explicitly, and make the project plan a dag rather than a gannt charts. You could make a gannt charts from it, if you add all the estimates, and define the available parallelism, but the reason for doing some piece of work is whatever depends on it, and you can follow the dag up to the end feature

doctor_eval 3y ago
Don't disagree, but deadlines are a very indirect and poor proxy which focuses on time rather than deliverables. > whoever needs to use your thing has a certain stretch of time where they can implement their part But the idea that timelines are critical to a project's progress must be a myth, because software projects are almost always delivered late. The dependency is always on the feature or deliverable, not on the date. The depending team will work out how to cope because that's what happens every day in most software shops anyway. I'm not saying that deadlines and timelines are bad. I'm just saying that they should not be the core organising principle for delivering a project.
- dasil003 3y ago
  Bad PMs and biz stakeholders are often the straw men for why deadlines are unreasonable or don't work. But if you take a high performing team with good cross-functional trust, deadlines serve a very valid function as a forcing function to make decisions, cut scope, and otherwise make progress towards shipping. Without them, it's all too easy for time spent to balloon for a million different small but justifiable reasons. And sometimes (not all the time), it does make sense for a deadline to be the core organizing principle, see this Mary Poppendieck talk for an interesting example: https://www.infoq.com/presentations/tyranny-of-plan/ https://www.infoq.com/presentations/tyranny-of-plan/
  - doctor_eval 3y ago
    I enjoyed that video some time ago, but I really didn't get the takeaway about timelines. Maybe I didn't watch it through. Anyway, I do agree with you that deadlines can serve a purpose, but this doesn't mean that deadlines are the core organising principle. Typically the sorts of deadline you're alluding to are actually milestones. We're not saying "this feature must be delivered in 3 days", we're saying "we want to launch in 2 months, what do we need to do to get there?". In this case the milestone gives us a goal, but it's not the organising principal. We're not trying to guess how long individual features are going to take, and nor should we; there's plenty of research that shows that this doesn't work in practice. So while I think deadlines can be a useful project management tool, they're not the only tool, and they certainly should not be the primary one. Nevertheless, it's very common to see projects managed using "firm" estimates and "hard" deadlines, and inappropriate pressure put on teams to achieve goals, such as low-cost accurate estimation, that are impossible. Considering that estimation is both expensive and inaccurate, deadline based management is just never going to work. So I think instead we should be more concerned about team productivity, because a productive team (by definition) gets more done in less time overall, which is ultimately cheaper and more rewarding than being forced to work against poor quality time estimates. And you can't maintain productivity if you're constantly cutting quality corners to meet some artificial deadline due to the way the project is managed.
    - namaria 3y ago
      It's not too different from that situation where someone says "how can I do X" but when you drill down on why they think they want it, there are better things they should be focusing on. Deadlines are about synchronizing different groups. The problem is opaque/arbitrary deadlines. "Why we need it by then" and "What exactly is needed by then" are very important conversations. Pushing for speed at all costs is bound to destroy morale and quality.
      - doctor_eval 3y ago
        I do largely agree with you, except here: > Deadlines are about synchronizing different groups If we agree that software frequently runs late (and this is backed up by plenty of research) then deadlines necessarily won’t succeed in this role. Instead, we should be identifying the points where synchronisation will be possible, and using these as triggers. For example, we could say, “when this set of features F is running with performance P and is passing tests T then we have 2 months to develop a marketing campaign”. As an enterprise product developer, I’ve been involved in maybe 100 software projects in three industries and I’ve pretty much never seen a situation that actually needed time based synchronisation. The projects launch when they are ready - deadline or not. While my projects were typically small (3-6 months) they were key infra for the businesses I was serving. Deadlines definitely serve a purpose but given that software is almost always late, using them as a sync point is just asking for failure.
cudgy 3y ago
“whoever needs to use your thing has a certain stretch of time where they can implement their part.” This can be ameliorated many times by attempting to mock something that covers the most likely interaction between the dependencies. For example, you are waiting for an API to provide some data to you: create an agreed upon JSON format that you will expect to receive and use that to mockup the interface till it’s complete. This allows both sides to move forward more independently till both are complete and ready for integration.
- doctor_eval 3y ago
  I think as well that this is a problem that Kanban solves quite well. Instead of having a team sitting around waiting for another team, ideally you have people who can take a bit of work from a board and be productive even if their primary project is stalled. This is (part of) how I've run my last few projects and it's been very successful from a productivity perspective. The problems I've had with this is getting management to understand that productivity and developer quality-of-life is important. They want road maps, god damn it, because reasons. And they say they won't hold us to the road map, but then they do. And at the same time, the road map captures productivity because now you're doing what the road map says instead of being productive. But building software is often like building a tunnel. You don't know what you're going to be drilling through until you've drilled through it.
mdekkers 3y ago
> I've been liking to instead model the dependencies explicitly, and make the project plan a dag rather than a gannt charts. Thats called an Event Chain Diagram and it is the bit that comes after doing a CPA, with or without a PERT. I strongly believe that Microsoft Project is the reason for the incredibly poor quality of project management we generally see in our field. I spent a few years working in organisations where project planning is done properly, by real Project Managers, that understand how to deal with uncertainties around time and effort required to deliver a thing. That was actually glorious and I’m no longer able to tolerate the clowns that saturate our field
- doctor_eval 3y ago
  > I’m no longer able to tolerate the clowns that saturate our field I looked up Event Chain Diagrams and it is probably overkill for the scale of projects I typically work on. Nevertheless it's much more reasonable than the kind of MS-Project based things I've been forced into working with over the years. Perhaps the worst part of this journey for me has been that I've supposedly been in positions of authority when this has happened. The gravitational pull of what is essentially waterfall project management is so hard that refusing to do it expends significant political capital. So the clowns are out in force even in my little patch, and I laughed out loud when I read your comment.
lelanthran 3y ago
You're describing a crippled form of PERT charts, which I favour over gantt charts anyway.

by 8note 3y ago

doctor_eval 3y ago

Don't disagree, but deadlines are a very indirect and poor proxy which focuses on time rather than deliverables. > whoever needs to use your thing has a certain stretch of time where they can implement their part But the idea that timelines are critical to a project's progress must be a myth, because software projects are almost always delivered late. The dependency is always on the feature or deliverable, not on the date. The depending team will work out how to cope because that's what happens every day in most software shops anyway. I'm not saying that deadlines and timelines are bad. I'm just saying that they should not be the core organising principle for delivering a project.

dasil003 3y ago
Bad PMs and biz stakeholders are often the straw men for why deadlines are unreasonable or don't work. But if you take a high performing team with good cross-functional trust, deadlines serve a very valid function as a forcing function to make decisions, cut scope, and otherwise make progress towards shipping. Without them, it's all too easy for time spent to balloon for a million different small but justifiable reasons. And sometimes (not all the time), it does make sense for a deadline to be the core organizing principle, see this Mary Poppendieck talk for an interesting example: https://www.infoq.com/presentations/tyranny-of-plan/ https://www.infoq.com/presentations/tyranny-of-plan/
- doctor_eval 3y ago
  I enjoyed that video some time ago, but I really didn't get the takeaway about timelines. Maybe I didn't watch it through. Anyway, I do agree with you that deadlines can serve a purpose, but this doesn't mean that deadlines are the core organising principle. Typically the sorts of deadline you're alluding to are actually milestones. We're not saying "this feature must be delivered in 3 days", we're saying "we want to launch in 2 months, what do we need to do to get there?". In this case the milestone gives us a goal, but it's not the organising principal. We're not trying to guess how long individual features are going to take, and nor should we; there's plenty of research that shows that this doesn't work in practice. So while I think deadlines can be a useful project management tool, they're not the only tool, and they certainly should not be the primary one. Nevertheless, it's very common to see projects managed using "firm" estimates and "hard" deadlines, and inappropriate pressure put on teams to achieve goals, such as low-cost accurate estimation, that are impossible. Considering that estimation is both expensive and inaccurate, deadline based management is just never going to work. So I think instead we should be more concerned about team productivity, because a productive team (by definition) gets more done in less time overall, which is ultimately cheaper and more rewarding than being forced to work against poor quality time estimates. And you can't maintain productivity if you're constantly cutting quality corners to meet some artificial deadline due to the way the project is managed.
  - namaria 3y ago
    It's not too different from that situation where someone says "how can I do X" but when you drill down on why they think they want it, there are better things they should be focusing on. Deadlines are about synchronizing different groups. The problem is opaque/arbitrary deadlines. "Why we need it by then" and "What exactly is needed by then" are very important conversations. Pushing for speed at all costs is bound to destroy morale and quality.
    - doctor_eval 3y ago
      I do largely agree with you, except here: > Deadlines are about synchronizing different groups If we agree that software frequently runs late (and this is backed up by plenty of research) then deadlines necessarily won’t succeed in this role. Instead, we should be identifying the points where synchronisation will be possible, and using these as triggers. For example, we could say, “when this set of features F is running with performance P and is passing tests T then we have 2 months to develop a marketing campaign”. As an enterprise product developer, I’ve been involved in maybe 100 software projects in three industries and I’ve pretty much never seen a situation that actually needed time based synchronisation. The projects launch when they are ready - deadline or not. While my projects were typically small (3-6 months) they were key infra for the businesses I was serving. Deadlines definitely serve a purpose but given that software is almost always late, using them as a sync point is just asking for failure.

cudgy 3y ago

“whoever needs to use your thing has a certain stretch of time where they can implement their part.” This can be ameliorated many times by attempting to mock something that covers the most likely interaction between the dependencies. For example, you are waiting for an API to provide some data to you: create an agreed upon JSON format that you will expect to receive and use that to mockup the interface till it’s complete. This allows both sides to move forward more independently till both are complete and ready for integration.

doctor_eval 3y ago
I think as well that this is a problem that Kanban solves quite well. Instead of having a team sitting around waiting for another team, ideally you have people who can take a bit of work from a board and be productive even if their primary project is stalled. This is (part of) how I've run my last few projects and it's been very successful from a productivity perspective. The problems I've had with this is getting management to understand that productivity and developer quality-of-life is important. They want road maps, god damn it, because reasons. And they say they won't hold us to the road map, but then they do. And at the same time, the road map captures productivity because now you're doing what the road map says instead of being productive. But building software is often like building a tunnel. You don't know what you're going to be drilling through until you've drilled through it.

mdekkers 3y ago

> I've been liking to instead model the dependencies explicitly, and make the project plan a dag rather than a gannt charts. Thats called an Event Chain Diagram and it is the bit that comes after doing a CPA, with or without a PERT. I strongly believe that Microsoft Project is the reason for the incredibly poor quality of project management we generally see in our field. I spent a few years working in organisations where project planning is done properly, by real Project Managers, that understand how to deal with uncertainties around time and effort required to deliver a thing. That was actually glorious and I’m no longer able to tolerate the clowns that saturate our field

doctor_eval 3y ago
> I’m no longer able to tolerate the clowns that saturate our field I looked up Event Chain Diagrams and it is probably overkill for the scale of projects I typically work on. Nevertheless it's much more reasonable than the kind of MS-Project based things I've been forced into working with over the years. Perhaps the worst part of this journey for me has been that I've supposedly been in positions of authority when this has happened. The gravitational pull of what is essentially waterfall project management is so hard that refusing to do it expends significant political capital. So the clowns are out in force even in my little patch, and I laughed out loud when I read your comment.

lelanthran 3y ago

You're describing a crippled form of PERT charts, which I favour over gantt charts anyway.