94

Imagine a project is assigned to a team, deadline is estimated as 8 months. After 6 months it becomes apparent the project will most certainly not be complete on time(e.g a law changes or a hidden monumental hurdle is discovered, the lead dev gets hit by a bus, etc.). But the project is important (e.g. lose an important client on failure or have to pay reparations).

One solution we all agree is horrible is adding more developers, especially new to the company. They will need at least a month to get up to speed and occupy the rest of the team during that time.

One solution we all agree is awesome is prevention. But such situations do happen.

What is a reasonable solution in such a situation for the manager of the team, provided they have plenty of leverage for additional people, funding, client negotiation etc?

  • 16
    Mandatory read: the mythical man-month and Hofstadter's law – Basile Starynkevitch Sep 12 at 8:00
  • 20
    What makes you think there is a solution given the facts stated? – Martin Maat Sep 12 at 20:44
  • 4
    See: "If one woman can deliver a baby in nine months, then nine women can deliver a baby in one month." – Rounin Sep 12 at 21:54
  • 5
    @Rounin, I would also beware of the contrary hazard, that when a man and a women can deliver a baby in nine months, it does not necessarily follow that either of them can deliver a baby alone in 18 months, or at all. Diverse teams can often achieve more than the sum of their individual productivity. – Steve Sep 14 at 1:19
  • 4
    @Steve I tend to lean towards favouring meritocracy over diversity in situations where advancing both is not possible. But you have just made the very best argument I've ever read for favouring diversity over meritocracy when advancing both is not possible. – Rounin Sep 14 at 8:32
133

We have historically seen over and over again that there are two working and two non-working ways of combining the two fundamental constraints on software releases: dates and features.

  1. Fixed date, flexible features, aka "release what's ready": you release at a pre-determined date, but you only release what is working. This is a model that is successfully used by Ubuntu, Windows, Linux, and many others.
  2. Fixed features, flexible date, aka "release when ready" or "It's done when it's done": you determine the set of features beforehand, and then you simply work until the features are finished. Some Open Source projects work this way.
  3. Fixed date and features.
  4. Flexible date and features.

#1 and #2 have been shown to work well in many different projects. For example, both Ubuntu and Windows are released with a fixed 6-month cadence with whatever features are ready in time for the release. If you make the cadence fast enough, even if a feature misses the release, customers don't have to wait a very long time for the next release.

Linux actually uses an interesting staging of the two: as soon as there is a new release, there is a fixed-time "merge window" of two weeks, during which new features are added. When this merge window closes, the set of merged features up to that point is fixed, and a "stabilization period" starts, during which the fixed set of features is stabilized, any bugs fixed, etc. This process takes as long as it takes, there is no deadline. When everything is stable, a new release is made, and the process starts anew. It turns out that this actually leads to a fairly stable release cadence of 6-8 weeks, but the point is that this cadence is not enforced, it emerges naturally.

Note that this does not invalidate my assertion that #3 doesn't work: Linux development does not fix dates and features. They do #1, then make a cutoff point and switch over to #2.

#3 is always a big problem, especially with a larger feature list and longer timeframes. It is pretty much impossible to predict the future (many have tried), so your estimates are almost always off. Either you have finished all the features and are sitting around bored twiddling your thumbs, or, more likely, you bump up against the deadline and frantically try to finish all the features in a hellish death march.

It does work if you keep the feature list and timeframe short enough. E.g. this is essentially what a Sprint is in Agile Methodologies: a fixed set of features in a fixed timeframe. However, the timeframes are reasonably short (typically a Sprint is one week or two), and it is ensured that there is rapid and immediate feedback and adjustment. You generally have a Sprint Retrospective after every Sprint, where you gather all the problems and successes of the Sprint and incorporate what you have learned into the next Sprint. And of course there is a Sprint Planning Meeting where the team discusses the next Sprint with the customer and agrees on a set of features to be implemented during that week.

Weekly (or two-weekly) Sprint Retrospectives are still not fast enough feedback, though, so there is also a Daily Standup Meeting with essentially the same goals as the Sprint Retrospective, except being able to react even faster: check whether the previous day's goals were met, and if they weren't, figure out what the problem was and fix it. (Note, I wrote "what" the problem was, not "who"!)

It is also very important that every Sprint ends with the release of a working product, so that the customer can immediately start using the new features, play around with them, get a feel for them, and give feedback for the next Sprint what is good, what isn't, what should be changed, etc.

#4 almost always leads to never-ending releases with feature creep. Debian 3 and Windows Longhorn were famous examples that interestingly happened around the same time. Neither of the two had a fixed release date, and neither of the two had a fixed set of features. Longhorn took 5 years, Debian 3.1 took 3. In both cases, what happened was that they didn't want to cut features because the long release meant that people would have to wait even longer for the features to appear in the next release. But because of not cutting features the release date slipped even further, so they added even more features because otherwise users would have to wait even longer, but that made the release date slip, and so on and so forth. An even more famous example might be ECMAScript 4.

So, what can you actually do in your situation? Well, you are currently in situation #3, and that simply does not work. You have to turn your situation #3 either into a #1 or a #2 by either relaxing the release date or dropping features. There simply is nothing else you can do.

The damage was done 6 months ago, and it cannot be magically fixed. You are in the situation where the amount of features cannot be delivered in the amount of time, and one of the two has to give.

IFF you can manage to move the release, then you might have the chance to grow the team, but the thing is that once you get 5-10 members, you really won't get any faster. You'd then have to break this into two or more projects, each with its own feature set, release date, and team, but then you also have to coordinate those, and define stable interfaces between both the projects and the software deliverables.

Note that in terms of culpability, the three scenarios presented in the question are very different:

  • If the applicable law changes, then it is perfectly possible to deliver the agree-upon features at the agreed-upon time. It's just that the agreed-upon features are useless for the customer. (Another good reason to be Agile.) In this case, it is actually in the customer's interest to re-negotiate the project, because if you just stuck to the agreed contract, they would have to pay for a completely useless result. So, this is essentially either a completely new project or a requirements change for the existing project, and both mean new prices and new timelines.
  • If the lead developer gets hit by a bus, the culpability is squarely on the project manager. Making sure that the bus factor is > 1 is pretty much a core responsibility of the PM. Practices that can improve the bus factor are for example Collective Code Ownership, Pair Programming, Promiscuous Pairing, Mob Programming, Code Reviews.
  • The "monumental hurdle" is a bit squishy. The question doesn't really define what kind of hurdle it is. If it turns out that the supplier massively underestimated the complexity, then it's obviously their fault. This can be mitigated by Spiking or Prototyping, for example.

However, regardless of who screwed up, we are still in the same place: we have an agreed set of features that cannot be delivered in the agreed time, so there is absolutely no way around the fact that one of the two has to give. There simply is no "non-horrible" solution.

| improve this answer | |
  • 24
    For several projects, it is not uncommon to pretend #3 to the customer, but make use of the fact feature specs from a contract often leave room for details. An experienced project manager decides about how these details are filled to match the schedule. So from a higher level of abstraction, the project goes for 3, but from a more detailed level of abstraction, it is #2. – Doc Brown Sep 12 at 6:55
  • 4
    @IanKemp: you are 100% misinterpreting what I wrote. – Doc Brown Sep 12 at 22:35
  • 10
    ... for example, if a customer orders a certain interactive feature for a certain date, but leaves out the details how the UI should look like, an experienced project manager will make sure the dev team won't add any unneccessary "bells and whistles" to the UI, and invests not more than the avaiiable time. There is no "lying" in this. – Doc Brown Sep 12 at 22:53
  • 4
    @DocBrown An actually experienced project manager will ensure there's a specification that defines how the UI should look before starting work. Because whatever the PM or developers think is a sufficient UI, will not be for the client. And guess who the client will blame when the UI isn't what they wanted and it takes another 2 sprints of back-and-forth to settle on something? Ding ding ding, that's right, the PM. And guess how that affects the client's trust. – Ian Kemp Sep 13 at 15:35
  • 5
    @IanKemp You're describing Waterfall/Big Design Up Front. An experienced PM knows no matter what the spec says the customer will want to make changes as soon as they start using the thing. An experienced PM controls the customer's expectations and engages them with the iterations so they can provide feedback and guidance as the UI is developed. – Schwern Sep 13 at 22:56
27

Although I agree with the others on the need to work with the customer and things like that, if you for some reason really think you need to hire new people -- don't hire developers.

What you need to do is talk to the developers, and find out what other tasks and burdens you can take off their plate so they can be more productive:

  • If they have a long commute, maybe put them up in a hotel nearby so they're less stressed out. Or hire a car service to bring them to/from the office if they have a family
  • Coordinate getting food for them so they have less to worry about
  • Reduce the number and/or lengths of meetings that they have to attend
  • Make sure that management is available for whatever signoff is needed on changes, rather than their losing momentum as they have to wait a day.
  • If they're both writing new code and supporting older stuff, have someone else take over the support tasks. (or at least triage them, so not all of it goes to the developer).

The goal is to not add more people, but to make your existing developers as productive as you can for the crunch time leading up to the deadline.

But don't just do it for them without asking, as you need to explain to the developers that you value them and their work. It might even be counterproductive if someone's slow lunch or commute is when they reflect on their problems and come up with creative solutions ... so you have to also give them the flexibility to cancel things if they don't feel they're working.

If you do bring in new developers, there's no time to get them up to speed on the project, so you'd be better off pairing them up with the programmers. There likely wouldn't be sufficient time to get the new hires up to speed on the project for true "pair programming", but they could serve a number of functions -- like an executive assistant, screening calls and/or visitors, getting snacks or running errands for the person, for 'teddy bear debugging' with a little extra feedback, as a typist for the experienced programmer to instruct, or even as just someone else to review code as it's being written.

You could hire non-programmers for the job, but typing skills won't amount to much if they don't know the programming language, even with an IDE. It's also important to find personalities that mesh well -- you don't want someone slowing the main programmer down asking 'why did you do (X)' and driving them crazy. You may need to have a pool of potential minions so the programmers can rotate through until they find one that they work well with.

And if a programmer doesn't want a shadow/minion/pair/intern/assistant whatever you want to call it, don't force one on them ... but it's possible that they might change their mind if they see it working well for others in their group.

| improve this answer | |
  • Of course, when you work for the US federal government, just hiring someone is a 1-2 month process, so if you're 2 months out from the deadline, you're SOL. – Joe Sep 11 at 20:46
  • 1
    Interesting, and with some support from Brooks' Mythical Man Month, but at the same time I don't think I've heard this tried successfully. – pjc50 Sep 14 at 8:51
  • @pjc50 : I admit, it's mostly conjecture. But I've been a developer for 25+ years, and I've done my share of 'crunch' for deadlines and crisis recoveries, including doing the 16-hour-days-going-home-every-other-day. But even things like shifting people's schedules so they're coming in at non-rush hour times, and/or they're working when they're more productive (early morning, late at night ... and some of that's just not being around when upper management is coming in and asking you every hour 'how things are going') – Joe Sep 14 at 23:20
  • But I had a manager during one of the crisis times (university mail server RAID had a cascading failure, and we spent 16 days (friday night to an early monday morning) 'til we finally had to write it off. (SIMS, the Sun Internet Mail Service stopped writing out backups at 2GB with no warning that it had stopped, so we had no full backups, and couldn't restore). But Mark screened us from upper level management so we could focus on our work vs. answering the same stupid questions and losing our place, and such. I've never had that level of support from places where I had a deadline crunch. – Joe Sep 14 at 23:23
  • The last time that I did long hours for a deadline crunch after telling management repeatedly that we weren't going to make it, I agreed to work long hours for comp time and then 12 days straight of 14-16 hr days (Monday to a Friday), and at the end they gave me 2 days of comp time for working the weekend. I quit shortly after that. – Joe Sep 14 at 23:26
16

The problem is elsewhere. The problem is the fact that you have one deadline for an eight months project.

Instead, the project should be a collaboration between you and your customer. It means that instead of working on a fixed set of requirements and attempt to deliver something eight months later, you'll be working on a dynamic set of requirements which could and will change on regular basis, while the customer discovers, through regular deployments, how the product appears to be in reality. How regular? It may be every two or three weeks, or it may be several times per day.

This also means that your first delivery should be done quite rapidly. Maybe not the first two weeks, but still, within a month from the beginning of the project, you should be able to show something to your customer. It won't have a lot of functionality, but it should have something. For some projects where infrastructure may be complex, showing a simple Hello World is already a great step.

Once you do your first delivery, the next key moment is the minimum viable product, or MVP. This is when you deliver something which doesn't contain all the features the customer expects, but is still something the customer could use if something goes completely wrong (the team cannot continue to work on this project, or the customer is out of money).

For instance, for an e-commerce website, an MVP should include the possibility to browse for products and actually order them, but it may not include the ability to create custom lists of favorite products, or share products, or give reviews, or ask for a refund through the web interface.

With this approach, when you finally get to your sixth month and something bad happens, it's still a problem, but not an extremely important one. After all, your MVP is already delivered months ago; for months, you added on regular basis the new features that the customer prioritized (i.e. the features that matter the most). All you need, then, is to inform the customer about the problem, and let him prioritize the features, if needed.

a law changes or a hidden monumental hurdle is discovered

If a change in legislation implies the change in the requirements, it belongs to the customer to inform you that the requirements are now different, and pay extra. Such situation happens frequently in financial sector, healthcare, or accounting.

In a case of a hurdle, where you need to redo a substantial part of the project, you need to discuss it with the customer to find an agreement. Sometimes, the discussion will involve the presence of the lawyers; but this is beyond the scope of this site.

| improve this answer | |
  • 1
    As with candied_orange's answer, you don't seem to meet the OPs circumstances head-on. The "minimum" product may be virtually the whole product as far as the client is concerned, or the threshold just may not yet have been reached. The OP gives no indication that the client will tolerate what has so far been delivered. Secondly, the OP alludes to two situations that likely require existing work to be redone - a change of law, or the discovery of a "monumental hurdle" (most commonly, a fundamental fault in the design and conception of the application). – Steve Sep 11 at 11:23
  • 1
    Note that fundamental faults in the design are typically only discovered in the finished product which is one of the reasons why those Agile Extremists insist on delivering a finished product every week. – Jörg W Mittag Sep 11 at 12:12
  • 2
    @Steve: it's quite the opposite. What you're missing is the notion of MVP I talked about in my answer. Essentially, you produce very early in the lifespan of the product something which already brings value, although not something which contains all the possible features. From the moment you delivered the MVP in production, you're only adding new stuff to something which already can produce value, or even is producing value. Anyway, we're drifting from the original question, and I invite you to create a dedicated question on this interesting subject (or contact me in person if you want). – Arseni Mourzenko Sep 11 at 13:05
  • 4
    An extreme example is actually in the OP's question: if the applicable law changes and the software cannot be used after the law changes, then the customer actually gets zero value from delivering the final product at the agreed-upon date. The only way in which the customer would derive any value at all, would be to deliver a partial product before the law changes. – Jörg W Mittag Sep 11 at 13:41
  • 2
    @Steve Sounds like you've had bad experiences with people claiming to be "agile". Unfortunately that is not uncommon. If you build a system and leave the most critical piece for last, if your design is worthless unless it's 100% completed, if your iterative releases have no commercial value... that's not agile, that's waterfall with sprints, but folks will claim they're "agile". I'd encourage you to ask questions about your various scenarios and how they should be handled, and you'll get answers showing how to do it right. – Schwern Sep 14 at 2:38
14

Having additional developers trying to understand the project and writing code will clearly require a large learning overhead for the new developers, and take time from the current developers to help the new developers become fully productive.

But what are the current developers doing that someone else could do?

What if the "someone else" was not required to be kept productive, but only did something when it could help the current developers?

For example,

Are the current developers having to:

  • Build their own PCs
  • Spend time filling in time sheets
  • Take their car to the garage to be fixed
  • Investigate database performance problems when they don't already know the tools to use?
  • Write CSS that works on all browsers
  • Fix spelling errors in UIs
  • Investigate why the network is being slow
  • Answer the phone when the manager is in a meeting and yet another agent calls.
  • Etc.
| improve this answer | |
  • +1 for thinking outside the typical box and giving an answer that helps maximize your existing developers' productivity. On that note, "too many meetings" also tends to get in the way of productivity. – emragins Sep 14 at 20:06
  • @emragins I think the key is not to try to maximise the new staff productivity. – Ian Sep 14 at 21:39
  • On one occasion we had severe pressure, I needed to accept a furniture delivery at home, and the result was that my bosses wife got my house keys and took delivery. Since deliveries can come any time in a day, that was one extra day of work. She was not happy, but my boss was. Same boss also paid for fifty liters of beer on one occassion to get me out of something where I really should have been for legal purposes, but that donation fixed the problem. One Saturday extra work. – gnasher729 Sep 15 at 15:36
5

If "on time" is the only option then cut features until "on time" is confidently achievable. Add people only after this deployment. Have them work on the cut features if they're really that important.

If "on time" is flexible then stop using arbitrary deadlines to motivate people.

If none of that works then you need a different project. The sooner you tell people this the better.

| improve this answer | |
  • As he refers to 'law changes, a hidden monumental hurdle, or the death of the lead developer', there almost certainly isn't the option to just pare back features, because two of these cases imply a fundamental rethinking and rework of what has already taken 6 months, and the third implies the loss of an experienced worker who may have been providing the majority of the expertise, analysis, and vision for the project. Also, "on time" likely means the delivery of a fixed list of features, not delivery of whatever the provider deigns to deliver, otherwise "reparations" could never occur. – Steve Sep 11 at 11:15
  • I can't imagine that addendum being very helpful, but it's your answer not mine! – Steve Sep 11 at 11:29
  • I'd probably suggest soliciting more information from the OP, to clarify whether he is facing a specific problem (and how things went wrong), or just asking abstractly for a silver bullet for all failed projects. But as it stands, firstly there's enough information in the question to suggest that features cannot just be pared without sustaining a penalty (so your para 1 is out), and secondly there may only be "flexibility" in the agreed deadline if the client can be convinced a good reason has emerged, so it's not necessarily arbitrary (so para 2 is out). So this answer is misconceived imo. – Steve Sep 11 at 11:47
  • 2
    @Steve we don’t like answers (or questions) that only serve the op here. If you simply want to argue that my answer is misconceived I invite you to downvote. Comments are for constructive criticism. – candied_orange Sep 11 at 11:51
  • I have criticised constructively, by pointing out where your answer is misconceived, and then I suggested referring to the OP for a clearer picture of his situation so that the answer could then be shored up. You drew me further (in now-deleted comments) by asking what I thought of your facetious addendum, and what suggestions I had for improvement, and I've given them. – Steve Sep 11 at 11:59
4

You may hire 10 more developers if you want, but the onboarding time will delay their effective contribution, the increased team size will increase coordination effort afterward, and moreover the initial problem, might be amplified if you need to reallocate scarce time of current team for knowledge transfer.

There’s no magic solution here: you will not deliver what is expected in time. You need to acknowledge this change of perspective rather than trying to stick to an impossible plan. Share this reality and start to elaborate with the stakeholders a realistic solution:

  • Can the deadline be postponed? Believe it or not, most deadlines are arbitrary. and allow for some flexibility. If you need to reinforce the team, take into account the potential delays to find a candidate and the onboarding effort to propose a realistic deadline.
  • Can the scope for the deadline be reduced? Agree on the features that must absolutely be ready in time, and a new transition strategy that takes into account the temporary unavailability of the postponed features. Caution: this option might be more costly because additional work might be required (e.g. an interim interface with a legacy system?).
  • Or is it mission impossible? If neither deadline nor scope can be questioned, you have to ask yourself if it’s worth to screw your health with a huge stress. Maybe you should think about offering your resignation. Maybe making such a decisive step could even help stakeholders to realize the seriousness of the situation and reconsider the previous options.
| improve this answer | |
2

From some not so pleasant past experiences with large projects:

  1. It is always better to have intermediate deadlines (sprints or so) to deliver results. This allows the supplier to adjust any estimates to reality, e.g. if you divide the project into 10 deliveries and the first two gets delayed by a week, it is reasonable to expect that the final deadline will shift by 10 weeks. The impact on one week's delay is smaller than a 10-week delay and allows both parties to revise their plans. Delivering in multiple releases demonstrates the customer what they are getting and adjust expectations.

  2. The customer may push you to agree on a fixed deadline/scope/quality/cost and refuse to revise it. However, you have to have the guts to turn them down. Basically, to tell them that we either revise the plan to fit reality (e.g. a key resource disappearing, a law change, or estimates slipping) now or stop the project immediately. It is better to kill off a hopeless project half-way than wait until the final minute to realize that the objectives will not be achieved.

  3. A monumental challenge can be only solved with a monumental force. Project manager's job is to avoid the buildup of monumental challenges. A project having one key person is a problem. Unclear responsibilities of what party is responsible if laws change is a problem. A buildup of TD is a problem. As others have pointed out, it is reasonable to involve the customer in the project in a collaborative manner. Thus, these issues become shared challenges with shared solutions.

| improve this answer | |
0

It has become received wisdom that "Adding more manpower to a late project will make it later". But it is an oversimplification, the outcome depends on multiple factors:

  • How experienced are the developers you have available? There is a big difference between adding junior developers who needs a lot of guidance and adding experienced developers who are able to research and figure things out on their own and get up to speed quickly.
  • How well specified and documented is the project? Does all knowledge only exist inside the heads of the current developers, or can new developers work form documentation?
  • How complex and interdependent is project? Is it possible to partition into more separate development tasks?
  • What is the quality of the existing code? Is it modular with low coupling, or is it a big ball of spaghetti?

You will get diminishing returns by adding more developers, but that does not mean you necessarily will get no or negative returns. It might very well be worth the investment if the cost of delivering late is high.

Still, adding more developers is not the only solution. The major levers are:

  • Reduce scope (remove features or postpone them to a later release)
  • Add time (that is, move the deadline back)
  • Add developers
  • Overtime

Each have its risks. For example overtime will give a short-term boost, but will have diminishing returns. Adding developers is the opposite - it will be a short term decrease in productivity but long term benefit.

Reducing scope is absolutely the safest and least risky approach. If you go through the requirements, it may turn out some of features are not as critical as first thought. When negotiation with customers it is often easier to talk about postponing features rather than dropping them. Then reconsider for the next release.

You might want to combine multiple, e.g. reduce scope and postpone the deadline.

Importantly, you need to examine the reason for the slip in the first place. You mention a lead developer getting hit by a bus. This is an unpredictable event which is unlikely to happen again. But in the real world, the most common reason for late projects are:

  • Scope creep
  • Incomplete/vague specifications
  • Overoptimistic time estimates
  • Many bugs and regressions

If you suffer from scope creep, adding more time or more developers will not help. It will likely just increase the rate of scope creep. So you need to manage that before anything else.

Incomplete specifications makes it very hard to manage a time-bounded project. Some agile projects does away with specifications altogether, but notably these does not have fixed scope or fixed deadline. If you have a fixed scope and deadline, you also need a spec.

If the delay is because some tasks turned out to be more time consuming than expected, then you should expect that other yet unfinished tasks will also overrun the estimates.

| improve this answer | |
  • 1
    You are disregarding communications which is the main issue behind this rule. Brooke assumes that communications will increase quadratically with the number of team members, no matter how hard you try (good leadership, hiring experienced devs, etc). Therefore adding more people can actually decrease the overall performance of the whole team – Manziel Sep 15 at 8:05
  • @Manziel: I'm saying it is an oversimplification. If the amount of communication increased quadratically with developers, then it would not be possible to have large projects at all. But clearly it is possible - some project have hundreds of developers. You just need to manage how and how fast you add developers. – JacquesB Sep 15 at 8:15
  • Definitely it is possible to have large projects if well organized. I also think that the change of tools and methodologies has raised the maximum team size since the rule was developed. But I wanted to question this quote: "You will get diminishing returns by adding more developers, but that does not mean you will get no or negative return.". If you do not organize well (which is likely on a project already late), it can happen that additional developers will have negative return – Manziel Sep 15 at 8:45
  • @Manziel: I meant "not necessarily negative returns". I absolutely agree it is a very real risk. – JacquesB Sep 15 at 9:13

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