Team Composition and Framework Disagreement

We are developing a software product, and we release a major version twice a year. The team has 2-3 developers and a product team that provides support and other services. I am in charge of development, and currently my boss and I disagree about the planning approach.

  • He wants us to plan up front before any coding and select a fixed date with month and day for a scheduled release (about 6 month later). Then we should build a plan for the entire release, with all backlog items given precise times for completion, fixed dates for each item, which person will be assigned to each item, etc. Then we should implement everything, then perform all the tests at the end, and finally debug.
  • I tried to convince him to work with milestones instead. For example, instead of choosing a precise date, we would aim a period (e.g "by the end of autumn" or "by the month of October"); split the development lifecycle into milestones (maybe you can call them "sprints"); make smaller plans for each milestone that would implement it, push it into a staging environment, and perform tests on staging while the team starts the next milestone. Then, before the last milestone, determine the precise release date. Allow 2-3 weeks after all tests pass and before the public release to let internal people and VIP users play with the release candidate.

Other Important Considerations

  1. We are a tiny team. When one developer has to work on something else, which is frequently, we lose 30 to 50% of our development resources during this time, and the planning is turned upside down.
  2. The backlog tasks are subject to changes in end users expectations, support tickets from previous releases, unexpected opportunities, etc. Thus a mega-planning covering the whole release over 6 months appears very difficult to maintain. We tried using that and we failed.

Restating the Question

My global feeling is that following the boss' approach would make us target an arbitrary date, and the other approach would make us aim for a specific quality level. What options do we have to address these different points of view about how to best manage the project?

  • Do you have any agency in this? In other words, are you managing the project or are you just it's statistician? If you said "and here, I will plan for 3 weeks of buffer because we know from experience other tasks will come up" is that realistic, or will that be shot down by your boss?
    – nvoigt
    Commented Nov 7, 2023 at 8:27
  • Have you tried to find out why your boss wants to have the planning done that way and what, for him, the important bits are? When you did the planning his way the last time and you needed to re-plan, what did he want you to skimp on? Could you change the delivery date or the feature set to be delivered or did you need to squeeze the testing time (and thus compromise on quality)? Commented Nov 7, 2023 at 10:03
  • This question feels like it's more of a workplace problem than a project management problem. I will try to answer it as a PM issue, but if it's just a personality conflict or an organizational issue then you may need to address it as such on The Workplace instead of here, where the focus is on the practice and profession of project management.
    – Todd A. Jacobs
    Commented Nov 7, 2023 at 11:35
  • @BartvanIngenSchenau that is the strange thing. Nobody is waiting for the very precise date of release... Commented Nov 7, 2023 at 14:26
  • @nvoigt it's really difficult to answer, because he could react one way, then the opposite next time. This also means I did not understand him really. Communication may be the core issue... Commented Nov 7, 2023 at 14:29

1 Answer 1



I am in charge of development, and currently my boss and I disagree about the planning approach.

Either you're in charge or you're not. If you're in charge, that means you are responsible for how you implement your process, and will be held accountable for the outcome. If your "boss" is telling you how to implement the development process, then you aren't in charge. It's just that simple. The two of you need to have a conversation about that before you discuss anything else.

The only measure of successful project management is whether the currently-expected outcome is optimal for the situation. You can't guarantee successful delivery, no matter the framework. However, you can create transparency and visibility throughout the project life cycle to support data-based decision-making about the net present value of continuing the project, with or without changes to the plan or one of its constraints. Focus on communicating about those things, rather than on who is right in a more abstract sense.


Aside from the issue above, you are fundamentally disagreeing about whether to:

  1. do big, upfront design (BUFD, a.k.a. BDUF) using traditional waterfall planning based on a fixed schedule with fixed scope; or
  2. perform some sort of incremental or iterative development using milestones (implying fixed scope) with schedule being your flexible constraint.

Aside from the methodology or framework where there can be many considerations regarding which is "best," the core issue is that you are fundamentally disagreeing over which constraints are going to be flexible. The first item above forces either cost or quality to be the adjustable constraints, while your approach makes time (or "schedule") and potentially scope the flexible vertices. Consider the following triangle, where quality is an implied slider.

The Project Management Triangle: Cost, Scope, Time, and Implied Quality

The Project Management Triangle (Public Domain)

Each project exists within a context, so which constraints should be flexible is situational. It's ultimately a business decision, although process should certainly be a part of the discussion. As an example, if you are in a business such as a startup where there's a fixed burn rate and you have a contractual obligation to deliver a product by a certain date, then schedule must be fixed although (by definition) at least one other vertex must therefore be adjustable to meet a fixed schedule.

Your preferred approach is more iterative, and aligns with the Manifesto for Agile Software Development which values "[r]esponding to change over following a plan" in order to adjust for inevitable changes in the project due to the cone of uncertainty that make BUFD and waterfall planning pragmatically unsuitable for most software projects.

In that sense, you're both right, and you're both wrong. There's no "one true way" to do this, but you're talking past each other in terms of why one process is better than the other for your situation, and discussing the trade-offs in a collaborative rather than an adversarial fashion.


Statistically, more than 68% of IT projects fail. While the failure rate is anecdotally better for agile projects, the more important and more provable point is that product development using iterative and incremental processes are usually:

  1. More adaptable to changing requirements.
  2. Offer opportunities for inspection and adaptation throughout the process, rather than only at the end.
  3. Provide a predictable delivery cadence of working features, which not only ensures better stakeholder alignment but also helps ensure that the project is building something fit for purpose.
  4. Include test-first design principles, enabling quality to remain higher than a "test at the end" approach which frequently uncovers more bugs or creates last-minute work that can throw off the schedule regardless of how meticulous the planning is.
  5. Enables the organization to release earlier than planned if the product is sufficiently valuable without waiting until the end of the original schedule; or to pivot for market fit or abandon the project with lower sunk costs than is usually possible with BUFD waterfall projects.

In short, from the point of view of delivering a high-quality product with a predictable cadence of usable (or at least inspectable) increments is much higher with frameworks that support agility than those that don't. That's why agile frameworks like Scrum, the Kanban Method, Lean Manufacturing, and others are often considered better choices in modern software development, especially when emergent design is an acceptable option.

However, there are domains where BUFD is still necessary. For example, spacecraft or medical equipment frequently require fixed specifications or designs that can't be easily changed once development is underway. Voyager, on its way out of the solar system, can't be changed post facto. Likewise, a medical device like a pacemaker must meet exacting tolerances where design, specifications, or quality beyond the research phase must essentially be fixed.

Which to Use When

Here are some very high-level considerations to select between the approaches.

  1. Use iterative and incremental development when emergent design, just-in-time and just-enough planning, and adjustments to scope or schedule offer adaptability.
  2. Use waterfall or BUFD when the design implementation is fully known up front and the risk of change is low (e.g. in machining or assembly lines), or when schedule must be fixed but scope, cost, or quality can be adjusted to meet a predetermined schedule.

These are certainly oversimplifications. Entire books are written on this subject, so an exhaustive answer is not possible. However, this is a reasonable approximation of the two schools of thought you and your boss are currently expressing to one another without using the project or business terms of art that would support either position.

Communication is Key

Since you are both currently talking past one another, and both of you want to be "right," your problem is communication. Neither of you is right in an absolute sense. Rather, you could both be right, or both be wrong with the optimal solution somewhere in the middle. The solution (as is usually the case in project management) is to expand the dialogue to cover:

  1. The business reasons underlying the choice of framework, methodology, or fixed targets.
  2. A collaborative discussion about the pros and cons of each possible approach.
  3. The acceptance of risk by leadership (NB: In this case that's not you!) for mandating a process that isn't suited to the problem domain, or for the risks inherent in any business or project management process no matter how well-managed.

Agile frameworks usually do a better job of managing the risks for #3, but overall the question is more about the trade-offs intrinsic to each process and the RACI matrix of your organization's decision-making. While perhaps not politically palatable, you should never accept accountability for delivering a successful project when you have no control over budget, schedule, or scope. In such cases, the best you can do is track progress and report variances from the original plan up to your leadership, explain the source of the variances, and provide options for them to choose from in terms of how the project's constraints can be adjusted to fit the facts or to terminate a project that can no longer deliver a useful outcome.

  • 1
    Thank you very much for your outstanding answer. I totally agree, especially about the communication concern. We meet tomorrow ; I will make him read this as a discussion basis. And thanks for having spend time to edit my question, sorry for my approximate english. Your answer is really useful. Commented Nov 7, 2023 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.