95

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?

Vorac
  • 7,073
  • 7
  • 38
  • 58
  • 1
    Does this answer your question? [How should I behave as a developer in a project that's headed for failure?](https://softwareengineering.stackexchange.com/questions/197650/how-should-i-behave-as-a-developer-in-a-project-thats-headed-for-failure) <-- reasonable solution is to realise that you are in the [death march](https://softwareengineering.stackexchange.com/a/197685/31260) and act accordingly – gnat Sep 11 '20 at 09:25
  • 2
    ...and this applies not only to developers, to anyone in involved team, QA, technical writers, devops, tech leads, managers etc. Death march impacts all of them, not only developers – gnat Sep 11 '20 at 09:37
  • 1
    For what it's worth, the company should expect it to cost money if a law changes. If the law changed 6 months after release, they'd expect to need to pay to change it. **The same is true before release** even if the cost ends up being less. They should be happy they get to spend less on this unexpected change, not unhappy they have to spend more than they originally thought. – corsiKa Sep 11 '20 at 18:23
  • 16
    Mandatory read: [the mythical man-month](https://en.wikipedia.org/wiki/The_Mythical_Man-Month) and [Hofstadter's law](https://en.wikipedia.org/wiki/Hofstadter%27s_law) – Basile Starynkevitch Sep 12 '20 at 08:00
  • 20
    What makes you think there is a solution given the facts stated? – Martin Maat Sep 12 '20 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 '20 at 21:54
  • One man can create an army in 9 months and 17 years, but it will take the help of more than one woman. Plan early, structure correctly, don't get caught with your pants down. If you wait until the very last moment to find out if you're going to lose you can find out faster and with the least expenditure, but if you build it they may never come. – Rob Sep 13 '20 at 12: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 '20 at 01: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 '20 at 08:32
  • 4
    @Rounin I'm pretty sure Steve means diverse in skill sets – Kevin Van Dyck Sep 14 '20 at 08:56
  • 1
    @Rob - If that one man is making an army in 9 months and 17 years, I suspect he's getting caught with his pants down pretty frequently. (Oh, the hazards of mixing your metaphors...) – Dave Sherohman Sep 14 '20 at 09:07
  • 1
    @DaveSherohman I hope we can assume that was a poorly thought out joke, we can't offer you explicit details about the minute. You need to think it out before commenting, if it was 10 months instead you'd have an army of approximately one month olds. While you could speed up the process by a couple of years you've made the argument that waiting several more has its benefits too. --- By definition, being in a compromising position with people you trust isn't the same as the opposite situation. – Rob Sep 14 '20 at 10:34
  • @KevinVanDyck, indeed, I meant diverse in skill and experience. The more people on a team, the more likely someone's experience (or hobby interest, or inspiration) covers the situation. Whereas if you reduce the team, say all the way down to one person, the project may never finish as one person becomes intellectually overwhelmed with mistakes and learning curves. In a team with more, someone is likely to sound the alarm before significant effort is invested in a mistake, and tasks can be delegated to those who already know them (or those already in-the-know can teach and supervise others).1/2 – Steve Sep 14 '20 at 18:04
  • I think Brooks iirc does cover this sort of situation, because his purpose is not just to emphasise the diseconomies of large teams, but to emphasise that virtually all "man-month" arithmetic leads to folly in software management.(2/2) – Steve Sep 14 '20 at 18:12

8 Answers8

136

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.

Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318
  • 1
    Windows used to follow release model #2, back in the days of Windows NT, Windows 95, Windows 3.1, Windows 3.0. – shoover Sep 11 '20 at 19:38
  • I know that there are some teams that do a hybrid of 3/4, where the team starts at 3 but any minor requirements change or unforeseen event is used to renegotiate the end date. So that it's essentially 4 but with sign-off from stakeholders. – Mark Rogers Sep 12 '20 at 00:45
  • 26
    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 '20 at 06:55
  • 2
    @DocBrown Also known as "lying to the customer". End result is that the customer can never be sure what they're getting, so they don't trust the dev team. And some customers, believe it or not, are smart enough to figure out they're being lied to, which lowers trust even further. Good luck having a good relationship with a client who doesn't trust you! – Ian Kemp Sep 12 '20 at 22:15
  • 4
    @IanKemp: you are 100% misinterpreting what I wrote. – Doc Brown Sep 12 '20 at 22:35
  • 11
    ... 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 '20 at 22:53
  • 1
    @DocBrown: Maybe I'm misunderstanding, but I think you meant to write "from a more detailed level of abstraction, it is **#1**": fixed date, flexible features. – ruakh Sep 13 '20 at 08:56
  • 1
    I wouldn't say even sprints are #3. They are basically still #1—you plan something you should be able to do in the sprint, but if don't make it for whatever reason, you usually just update the plan for the next sprint. – Jan Hudec Sep 13 '20 at 11:30
  • @ruakh: you are right, I meant #1, not #2. Thanks. – Doc Brown Sep 13 '20 at 15:09
  • 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 '20 at 15:35
  • 2
    @DocBrown If I may distill what you're saying down to a Rule of Thumb: every feature has a 2 hour, 2 day, and 2 week version. – Schwern Sep 13 '20 at 22:52
  • 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 '20 at 22:56
  • Might be worth pointing out in your description of sprints that even in this short setup the methodologies have a process for "We're not going to make it", so even in 2 week bursts you can get the planning wrong. – Erik Sep 14 '20 at 07:16
  • 1
    “Another reason to be agile” -> I fail to see why “agile” would be of any help in a 6-months project one month from delivery where the entire legal basis of the whole project suddenly changes and what’s been done during 5 months become irrelevant. – Jivan Sep 14 '20 at 08:08
  • 2
    @Jivan: I know there are other methodologies, but let's take Waterfall as an example: In Waterfall, you would just continue developing for another month *exactly* what had been specified 5 months ago, and you would deliver to the client a *completely useless* product. With Agile, you would have already delivered 20-40 partially working products during those 5 months, which means the client would have already gotten some benefit out of it. Also, Agile would allow you to react quickly to the changing requirements, whereas many other methodologies are built on the foundation that requirements … – Jörg W Mittag Sep 14 '20 at 08:26
  • … must not ever be changed until the product is delivered. – Jörg W Mittag Sep 14 '20 at 08:26
  • 1
    @Schwern Agile does not mean "no design" or "no specs". For large features that span multiple sprints, there will necessarily be some sort of initial design effort to ensure that you aren't building something that is not extensible or reusable. Regarding specs, the point is that the client **signs off** on the spec so that once you've delivered the work covered by said spec, any further change they want to it is **new work**. That means responsibility for changes sits either with dev (bugs/non-conformity) or client (new work), not in an interminable no-man's land of he-said she-said. – Ian Kemp Sep 14 '20 at 11:30
  • @Schwern Further, specs force the client to think about what they are requesting, which generally results in a concise, well-constrained definition of work to be delivered as opposed to "how long is a piece of string". That results in something that can be delivered within a sprint, which shows the client that you actually do deliver, which impresses on them that specs work, which encourages them to write better specs... End result is that clients and dev **trust** each other, which means client is far more understanding when it comes to defects and paying for fixing them. – Ian Kemp Sep 14 '20 at 11:39
  • 2
    There seems to be inconsistency in advocating for small 5-10 man teams and when blaming lead dev getting hit by a bus on PM. The question never mentioned anything about a bus factor being to small but it's reasonable to assume that the lead dev has the most impact on the project (hence the title), so even with all of the best practices, losing them can be 20-40% productivity loss (for a 5 dev team), if not more. – Dan M. Sep 14 '20 at 12:33
  • @IanKemp: You're ignoring the premise of the question. Even if your experienced project manager made a pristine plan 6 months ago, **things have now changed**, the old plan is no longer viable. That is the basis of the question: how to handle a _change_ in plans. DocBrown isn't suggesting that you never do anything that isn't asked from the get go for every project by default; but rather than when you need to loosen some constraints, it's helpful to know that (and which) bells and whistles can be dropped/shortened without violating the agreement (both feature and date), when possible. – Flater Oct 14 '20 at 09:41
  • @IanKemp: If the customer's acceptance of the release depends so heavily on a certain bell and whistle, then it's a proper feature, not a bell and whistle, and it therefore should've been enshrined in the agreement that was made _before_ development started. Again, that's not to say that your company doesn't do any UI work that isn't explicitly asked, but when push comes to shove and you either have to break the agreement or stop doing something that's outside of the agreement, the latter is much more preferred. – Flater Oct 14 '20 at 09:45
28

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.

Joe
  • 389
  • 2
  • 3
  • 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 '20 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 '20 at 08: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 '20 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 '20 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 '20 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.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • 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 '20 at 11:23
  • @Steve: I hardly believe that an eight months project has its MVP at eight months. Much more frequent is the situation where nobody bothered to be Agile, nobody cared about the deployment in the middle of the project, and a few weeks before the deadline, the team starts asking questions they should have asked months ago. Regarding the fundamental faults in the design, it happens; this is where lawyers step in, and this is where the subject stops to be technical. – Arseni Mourzenko Sep 11 '20 at 11:35
  • 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 '20 at 12:12
  • 1
    I agree. The only technical point I'm not convinced about is the idea that the average project has appreciable value in parts - it often seems to be an article of faith that such parts always exist, even when the system has not been designed in phases or as optional modules. – Steve Sep 11 '20 at 12:30
  • @Steve: *“The only technical point I'm not convinced about is the idea that the average project has appreciable value in parts”*: wouldn't you be interested in creating a separate question specifically on this topic? I would be glad to provide my own answer on this subject there. It could also be interesting to include in the question a concrete example of an application, just like I did above with the example of an e-commerce website. – Arseni Mourzenko Sep 11 '20 at 12:46
  • @JörgWMittag, I always thought it was just so the Agilists could renegotiate as they go along. What they call "a finished product every week" is what clients consider "a part-complete product that has no business value". And when the Agilists realise the part-product has a fundamental fault (in terms of the final goal), they threaten the client that he either coughs up for the tremendous remedial work, or they part ways and he's lumbered with the "finished" product delivered so far. It's really a way of imposing risk on clients, without the Agilist being up-front about what those risks are. – Steve Sep 11 '20 at 12:55
  • 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 '20 at 13:05
  • @ArseniMourzenko, it could indeed be an interesting question, but I'm wondering how to structure it in a way that can be answered, rather than which either opens a conversation, or covers the issue so comprehensively as to make the question rhetorical. – Steve Sep 11 '20 at 13:13
  • @ArseniMourzenko, but you beg the very question, which is the existence of a part-product which brings value. And I mean value as would be perceived by a commissioner of a development project, who would have regard to all the circumstances (including, usually, the value and functionality of an existing system which is being replaced), and would have business common sense (for example, a Hello World application would be considered of no business value, regardless of the infrastructure it showcases). As you say I think this might blatantly open a can of worms. – Steve Sep 11 '20 at 13:20
  • @Steve: I see your point. Anyway, usually customers conceive a finished product as one thing, and through Agile, they quickly discover that *not only what they concieved is completely different from what they actually need* (and this is *very* important), and that most features are more about an ideal application from their dreams rather than an MVP. – Arseni Mourzenko Sep 11 '20 at 13:26
  • 1
    @Steve: If you are right and the customer derives no value from having a partial product before the final release date, then there is still no harm in doing it: without it, the customer would get no value during the 8 months and then the full value after 8 months. With delivering partial products, the customer gets no value during the 8 months and then the full value after 8 months. However, what happens if you are wrong? Then, without delivering interim releases, the customer gets no value during the 8 months, and the full value after 8 months. *With* interim releases, though, the customer … – Jörg W Mittag Sep 11 '20 at 13:34
  • … *still* gets the full value after 8 months, but gets *additional* partial value already during the 8 months. An important part of the partial value that the customer gets is the chance to play around with a simplified version of the product, and e.g. discover that the feature the customer specified on paper is actually a lot less useful in practice, or should work differently, or is actually more important than originally thought. It turns out that predicting the future is really hard, so the earlier the customer can give feedback the better. – Jörg W Mittag Sep 11 '20 at 13:36
  • 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 '20 at 13:41
  • @JörgWMittag, definitely I agree with you about letting the client see and use the functionality, and watching them use the functionality. It can be enormously useful for clarifying requirements. As Arseni says, often clients do not have a clear idea of what they need at the outset. – Steve Sep 11 '20 at 14:06
  • Typo in paragraph 3, part in bold - sending a rapid "fist delivery" to your customer is not best practice these days. – Lawrence Sep 12 '20 at 15:54
  • @Steve Chopping up apparently monolithic projects into deliverable pieces is a skill. And when we talk about "value" we don't mean only business value. There is value to putting something in the customer's hands to better refine the requirements. For example, a UI prototype that works with a fixed set of fake data which lets the customer provide feedback about the UI. Or maybe there's a component which transforms data, you can build that and the customer can begin testing if the transformations are correct against real data. – Schwern Sep 13 '20 at 23:03
  • *"There is value to putting something in the customer's hands to better refine the requirements"* - but that still presupposes the work will be finished. A client is not usually paying good money just to be left with a prototype or to have his requirements clarified. Agilists attempt to cast these intermediary products as something "finished", when they are nothing of the sort - they are artifacts of ongoing work, in which there will be little to no commercial value unless the project is completed, and whose only real practical use is in helping to bring that project to completion. (1/2) – Steve Sep 14 '20 at 00:49
  • @Schwern, as for "chopping up", if it takes skill then it costs money, and a client may be prepared to accept a monolith if it leads to a significantly simpler architecture and cheaper delivery. And as I say, even if things can be chopped, the presence of an existing battle-tested system that already does everything except the last say 10% of the new system's work, may mean that the new system is virtually worthless (at least in an ROI sense) unless that last 10% is delivered. I'm convinced Agilists routinely misrepresent the typical circumstances in this respect. (2/2) – Steve Sep 14 '20 at 01:02
  • 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 '20 at 02:38
  • @Schwern, you're sounding like an Agilist yourself. What I describe is not "waterfall" - it can have all the iterative trappings of Agile - it's just that the presence of the existing system renders worthless anything but (more or less) the whole delivery, because it's that last increment that has huge additional value. It's not a fault with the process. It is also another common trait for Agilists to claim that everybody else is doing it wrong, rather than to accept that it has shortcomings in the real world, or that there are problems which it does not solve (or even aggravates). (1/2) – Steve Sep 14 '20 at 10:35
  • The best analogy I can muster is the idea of a company that already has a 10 storey building. They decide they need 20 stories. So they knock the 10 down, and start on the 20, with the appropriate foundations and strength in the lower floors which the old building did not have. It's common sense that if the building stops at 9 floors, the project is an utter disaster. At 10 floors, the firm is back to where it started at great expense, and with overbuilt foundations. It does not matter that the builder is working modularly and incrementally - stopping short delivers no value. (2/2) – Steve Sep 14 '20 at 10:44
  • 1
    @Steve If you view software as a one building, floor built upon floor, I can see why you've reached your conclusions. Software can instead be built like a bunch of factories shipping things around to each other. Again, I encourage you to ask some questions about your situations and see how others would approach them. – Schwern Sep 14 '20 at 20:29
  • @Schwern, it doesn't have to be one building. It can be your "bunch of factories". I was simply choosing a metaphor which incorporates two key features - one is that additional functionality cannot simply be accreted further, and two is that the presence of some existing working setup means that any replacement can only have value if it exceeds what already exists. I already know how the Agilist would approach things - it's precisely that approach which I'm attempting to explain is flawed! (1/2) – Steve Sep 15 '20 at 02:13
  • Specifically, I'm addressing the claim that a half-finished project delivers value for money. I say half-finished projects usually deliver no value for money whatsoever. The Agilist responds that a properly Agile project always delivers value for money for each stage, and therefore it must have been done wrong. I respond that some projects simply don't have value in parts, and I give the example where an existing system is present which is already capable of doing the majority of the desired work, but cannot withstand any further incremental additions. That's where we're up to with this. (2/2) – Steve Sep 15 '20 at 02:25
  • @Steve: you may be interested in [an article](https://blog.pelicandd.com/article/167/) I've written on this subject, and **specifically the three examples** at the end of the article. If you want to discuss the subject, you can contact me in person (see my profile for the contact info). – Arseni Mourzenko Sep 16 '20 at 12:08
  • @ArseniMourzenko, I wonder if we can open a chat room here, to preserve the ability of others to participate collectively and the public usefulness of the resulting discussion? I'd also quite like to discuss further, and have points to make particularly about your e-commerce example, but don't want to feel that I'm thrashing the point. I should also be clear (in case it appears otherwise), my point is not to undermine the very tenets of Agile or to argue for a specific alternative, but to limit the many extravagant or silver-bullet claims which are made of Agile. – Steve Sep 16 '20 at 19:42
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.
B-K
  • 103
  • 3
Ian
  • 4,594
  • 18
  • 28
  • +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 '20 at 20:06
  • @emragins I think the key is not to try to maximise the new staff productivity. – Ian Sep 14 '20 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 '20 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.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • 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 '20 at 11:15
  • I can't imagine that addendum being very helpful, but it's your answer not mine! – Steve Sep 11 '20 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 '20 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 '20 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 '20 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.
Christophe
  • 74,672
  • 10
  • 115
  • 187
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.

Eriks Klotins
  • 175
  • 2
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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
  • 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 '20 at 08: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 '20 at 08: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 '20 at 08:45
  • @Manziel: I meant "not *necessarily* negative returns". I absolutely agree it is a very real risk. – JacquesB Sep 15 '20 at 09:13