147

Stop doing the 80 hour weeks. This is positive reinforcement. Because they are getting the product on time with expected costs, they are going to continue doing it, regardless of what it does to you. If they cannot budget time properly, then that's management's fault. Not yours. Let them miss a few deadlines.


135

You seem to assume the primary objective of project management is to produce exact estimates. This is not the case. The primary objective of project management is the same as for developers: To deliver value for the product owner. A product using a lot of slow manual processes rather than automation might in theory be easier to estimate (although I doubt ...


125

I think one of the main advantages is that humans and developers specifically are actually pretty bad at estimating time. Think of the nature of development too -- it's not some linear progression from start to finish. It's often "write 90% of the code in 10 minutes and then tear your hair out debugging for 17 hours." That's pretty hard to estimate in the ...


111

Read Bob Martin's "Clean Coder" (and "Clean Code" while you're at it). The following is from memory but I strongly suggest you buy your own copy. What you need to do is a three point weighted average. You do three estimates for each piece of work: a best case scenario - assuming everything goes right (a) a worst case scenario - assuming everything goes ...


96

In general, is there a way to push back on this? If not for this release, what about in future? Of course, there is: Let them fail badly with this approach. Nothing teaches as well as failing. Make an estimation yourself before you start and show it to them. Then do your best, write good code, stop compensating for their stupidity with your free time, ...


70

So my code is late too. No, it is not your code, it is the code of you and the senior. You are working as a team, you have a shared responsibility, and when you two miss a deadline, it is the fault of both of you. So make sure the one who makes the deadlines notices that. If that person sees that as a problem, too, he will surely talk to both of you ...


67

If the salesmen are also the ones who are in charge, you can say, "Ok, I can go with your schedule. Which features or responsibilities would you like me to sacrifice in order to make your deadline?" That way you're not saying "no" to the people in charge but you're not committing to impossible things. The decision is in their hands how to run the business. ...


58

If you're using Fibonacci numbers (or something similar), it limits the number of options when estimating a story. I worked with a group that used low numbers only: 1, 2, 3, 5, 8, and 13. We had a reference story that was a 5. This enabled us to easily make snap decisions on a story's complexity while doing Planning Poker. The other side effect was that ...


53

I recommend not distributing it to project members at all. Appoint or elect a treasurer, open an account and deposit the money to earn simple interest. If you distribute donated funds between developers, at least one will become disenfranchised as the project grows. Instead, consider the other possibilities for the funds: Swag. Print up some T shirts to ...


52

This generally occurs because of a perverse incentive - the salespeople are being paid on commission, while the production staff is paid on salary. The salespeople have several levers to work with: features, cost, and delivery date. They have a strong disincentive to lower the cost, because this generally lowers their commission, so they tend to ratchet UP ...


48

You could ask him/her to estimate how long it would take for her to access some far away location in an uninhabited corner of the world. As an extreme example, let's choose some lesser known peak in the Himalayas, where very few (if any) people have ever climbed on. She would need an awful lot of preparation plus practice before even starting the journey, ...


47

In my experience Sales people think that everything is a negotiation where you meet eachother somewhere in the middle. That's basically how they work. They try to sell a product to a client and ask high, the client offers low and in the end a price both parties agree on becomes the agreement. They also take this mentality to the workfloor. They assume you'...


41

I suspect that my coworkers don't see the personal benefit, since they're not often involved in project scheduling. That's fixable. Make them involved in scheduling.


39

You are right - copy-paste works great, and DRY has no point when your task is to produce a program for which either the copied template or the copy will not have to be maintained or evolved in the future. When those two software components have a completely different life cycle, then coupling them together by refactoring common code into a common lib which ...


34

My recommendation: You either include testing time in the ticket, or add a ticket to represent the testing task itself. Any other approach causes you to underestimate the real work needed. While developer time is often a bottleneck, in my experience, there are many teams constrained on test. Assuming the limiting resource is one or the other without ...


32

Two choices really: Quit, or grow a backbone. I think I don't have to explain much about quitting.. that one is obvious. If you can neither take it nor dare to change it, it's the only way to go forward. If you do want to change this, then it is your responsibility to stand up against this. This does need "a backbone", because you will be going against ...


30

This might be a good moment to introduce a quasi-agile approach. If instead of estimating in terms of hours/days you allocated a fibonacci type scale & gave each task a value based on how big it is: 0 - instant 0.5 - quick win 1 - simple change 2 - a couple of simple changes 3 - more challenging 5 - will require some thinking about 8 - a significant ...


27

In a good team, you should have a queue of development tasks assigned to you in an issue tracker. That way, while you are waiting for a reviewer, you could (should) work on next task waiting in that queue. Once you get used to work in that fashion, this will open an opportunity to have your changes reviewed in "batches", thus decreasing delays. If you don'...


26

The development team must be consulted on these decisions or you will never get out of that cycle. If you aren't managing the team, then one of your line managers needs to advocate for the development team. If they are part of the problem, then you may want to consider other employment options. Generally speaking, Sales shouldn't be committing to anything ...


26

Do not show them their fault! Try to argue better what changes you make, give them more detailed estimates. Make a suggestion like "We can do this in your X hours instead of mine Y hours, if we will give software testing to outsource". Or "We can do this faster, if we exclude this part of requested functionality".


26

The trick is not to avoid there being blanks. The trick is to fill in those blanks as early as possible in the process of development. You are correct that, if developers make assumptions, they will invariably be wrong and that will cost time redeveloping the software later. But, equally, if business people are expected to do a full up-front design when ...


24

Unless you are estimating something very similar to that which you and your co-workers have done before, +/-10% is ridiculously optimistic. Your management either doesn't have a lot of experience with software, or they're not aware of Large Limits to Software Estimation. That paper has some accompanying supporting material, and a lot of punditry can be ...


24

Best thing to do is not to throw the new developer into the fire, but instead carve out some functionality and/or bug fixes that the developer should have no trouble jumping in to. Find an area that needs work that doesn't require a person to know the entire architecture, requirements and code-base all at once. Maybe have him or her work on documentation ...


24

It would be better to say "I think that can be done". or "I'll check and get back to you". I've had times where I've said no or counter proposed something. If the customer wants "a browser based application that works without ever being connected to the internet and uses tactile feedback", it probably is possible. But it is expensive and it would be more ...


24

It's to enable estimation to get better over time, without the estimators all having to adjust their estimation. Rather than everyone involved in the estimate having to think like "OK.. looks like 2 man days.. but last sprint we underestimated everything, so maybe it's really 2.5 man days. Or 3?", they carry on the same as always. "5 story points!" Then, ...


24

First, congratulations on your contract! Ok, enough celebrating, let's get down to business. ;) I've been a consultant for over 15 years -- here's my advice. In project management, what you are talking about it "contingency" planning -- and you absolutely should do it, else you are likely to disappoint your client (and make yourself unhappy throughout the ...


23

You answer the question honestly. You tell them it's a difficult problem, the solution is not obvious, and you are not sure how long it will take to resolve. Promise to update them on your progress every [time frame], so they know you're working on it, and of course, actually send them the updates.


21

Joel Spolsky wrote an article on Evidence Based Scheduling that may help you find some arguments. You have to convince your co-workers that better estimation skills can help them produce better software. Here are some points in favor of tracking task time: If you have an arbitrary management-set deadline, good estimations will tell you what you can ...


Only top voted, non community-wiki answers of a minimum length are eligible