The Stack Overflow podcast is back! Listen to an interview with our new CEO.
76

And not only are they suppose to correct them, they are suppose to correct them on their own time without impacting plans. This is your problem. Why don't your plans include the time for fixing bugs that you know will be there? We all know it's impossible to write perfect code. We all know that bugs inevitably creep in. Expecting engineers to fix their ...


51

Just as a side note to the other good answers - developers tend to have minds that look at process and (un)consciously find ways to game it. What you are training your developers to do here is to not raise tickets for defects they find when they are developing (as either they, or possibly worse for them, one of their colleagues) would then have to work late ...


45

Over the last year we've become pretty hardcore in adopting the principal that an engineers must fix their own defects (those found internally and those that escape to the end users). Not only are they supposed to correct them, they are supposed to correct them on their own time without impacting plans. Let me ask you a question. Whenever a plan changes, do ...


27

This is a troubling post. Your company is penalizing its workers for what is a normal and expected occurrence--performance variability. The whole reason to "punish" someone is for a behavior change, to replace a maladaptive behavior with an adaptive one. In this case your punishment will yield nothing because we do not have the capacity of reducing ...


18

While in most projects, the work can expand to fill up some or most of the 'extraneous' time, for many products things are simply done when they're done. In software development, when the product is feature-complete and all (sufficiently important) bugs have been dealt with, you're ready to release. The problem with software development is that there are a ...


17

Aside from the main issue you are asking about, there's also something a little concerning about this part: "defects (those found internally and those that escape to the end users)" I don't see anything about QA being asked to create the missing tests on their own time. This (assuming this is correct) along with your main concern demonstrates to me that ...


16

Parkinson's Law and Student Syndrome. These two concepts I believe truly impacts our work. There's validity in "challenging" the team by constraining the planning values that the team thinks they need to do the job. But it takes sophisticated analysis to understand that coming in late and over budget on an optimistic planning value could be indeed more ...


15

They should absolutely be doing QA. In fact, in the ideal agile team there are no specific roles. Agile development is quite the opposite of the "throw it over the wall" mentality of development vs. QA. Clearly the problem is: if a feature is not Done, should people get off the story and do something else? And if QA is not irrelevant (in other words, it ...


15

The short answer: No, it isn't! The not-as-short answer: Your company has come up with the idea that the existence of bugs is a professional failure on the part of the developer. This is not true. All code contains bugs. Quality code contains fewer bugs. Your developers are doing quality work for you when they find and fix bugs. This is them doing their ...


15

Kick the ball upstairs immediately You have a project that is going to fail. You don't have any way of solving this. If you just tried various things and let the three months pass, you will end up with an angry customer and angry bosses. Instead contact the person/people who can actually solve the problem, while there is still time to act. Who that is ...


10

I don't think PM methodology is relevant, more what your company's accounting practices are. I have worked with companies that do consider PM as a billable resource and track hours etc to pass those costs on to the client transparently. I have also dealt with subcontractors where PM effort is rolled into overhead so it isn't as transparent. I have also ...


10

Framework Overhead All frameworks entail some amount of process overhead. Some of that overhead is in the form of hours worked by the project manager, but some of it is a byproduct of delivering on framework controls and artifacts. The latter form of overhead is often significantly larger, since it tends to impact everyone on the project rather than being ...


10

Your Capacity Planning and Prioritization Processes Need Re-Engineering You appear to be attempting to solve the wrong problem by treating this as an individual-availability issue. This is most likely because you have a weirdly-matrixed organization that isn't based around project teams or team capacity planning, but apparently based on the notoriously ...


9

I worked in teams that had anything from 1 tester per 1 developer through 1 tester per 10+ developers to no testers at all. Each of these was able to release software of expected quality (not each did but that's a different story). The short answer is of course it depends. However looking through the answers that are already here I found much about cost, ...


9

In a truly agile environment, does the PO go to the level of saying things like, "OK, we have 40 person hours of work for Arthur and 32 person hours of work for Candace, and since they're each supposed to be half-time on this project, they should finish that work by the end of the next sprint." ?? Well, in a Scrum environment, or in any other ...


9

TL; DR It really sounds like the Scrum Master and the Product Owner have both bought into the velocity and utilization trap. Break the cycle. Dissecting the Product Owner Role The PO wants to know how many hours programmer X has available during each sprint and exactly what he will do with them. Not his business in a Scrum shop. He is part of the Scrum ...


9

Should developers do QA? I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or ...


9

Context switching is expensive, however Scrum may not be the correct framework for the situation you are describing. You may want to consider transitioning to a Kanban framework. Kanban is more accepting of interruptions and is focused on getting a few things done continuously rather than batching work into boxes of time (iterations). But I think you are ...


9

Is it a good idea to try and use Parkinson's Law to increase productivity. No. (Disclaimer: I'm going to assume you're talking about software projects, not rock breaking or something) Read an extract from the relevent chapter in the book Peopleware (actually, read the whole book, it's great). To summarise, you shoudn't treat your staff as if they were lazy ...


9

"Hardcore" indeed. I don't have much to add to the other good answers, but I'll relate an experience of my own as a developer. I worked for a company in which the culture was similar to what you are describing, in that there was heavy pressure to work long hours and weekends without pay fixing stuff that we'd been required to produce in unreasonably short ...


9

Don't do this. Speaking as a developer, this sounds great. We get to rewrite that horrible old spaghetti code from scratch! We get to paid to learn a new language! There's a mandate for quality, so we can actually get the time needed to write good code! ...Oh, and there's the fact that this project will take a year or five. Speaking from a business ...


8

What's Wrong with Your Team's Processes When the deadline is tight and when there are not enough QA people, the Product Owner asks developers to join in with QA to meet the deadline. Your process problems are legion. Let me count at least some of the ways: Your Product Owner should never, ever be assigning work to the team. Your "developers" and "QA ...


8

I've always heard (and experienced) it as "Adding more developers to a late project will make it later." Every new developer requires ramp-up time to be familiarized with the project's architecture, domain, etc. This requires time not only of the new developer, but of a mentor as well. So, your initial velocity will be slowed down. Eventually, though, it (...


8

If this is an interview question, I'm fairly certain that what they were looking for was how you handle being presented an impossible scenario. Effectively what they asked you was this: You have a project that will be 2/3 done at the end of the project. You may change nothing. What do you do? They want to see how you handle the situation.


7

Focus on Project Control Your entire question is based on a faulty premise, e.g. that specifications and contractual requirements are equivalent to process or quality control. They are not. What you need to define for any project, whether it's in-sourced or out-sourced, is a set of project controls that allow you to continuously inspect your project and ...


7

TL;DR If you're still thinking in terms of strongly-defined roles rather than cross-functional teams, then you're not making a successful transition to an agile process. Agile teams may need all of the skills you've listed, but each of those roles is actually the responsibility of the whole team rather than of individuals, and it is up to the team to ...


7

This practice is good way to drive out your best and brightest, leaving you with a skeleton crew of your bottom performers. I have developed software for generation 4&5 fighter jets and managed software-intensive programs for the USN: PMP Certification, multiple graduate engineering degrees, Eagle scout, yada yada, yada. The original posts leads me to ...


7

If I've interpreted correctly, your Question is how to convert Story Point estimations for User Stories into time-estimations for each individual developer. My answer? Don't. The only possible reason I can think for why you would need individual estimates is for individual KPIs (Key Performance Indicators). Which, in my experience, are themselves harmful. ...


7

It sounds like the idea you're concerned about is a rather over-simplified version of the point raised by Fred Brooks in the (rightly) famous essay The Mythical Man-Month. What Brooks pointed out is that you cannot just treat developer man-months as an infinitely elastic resource -- so doubling the number of developers does not halve delivery time. There ...


7

So there are usually several parameters on a project that can vary: Budget Schedule Scope Risk Resources Quality You've ruled out three of them, so think abut what the others can do: Sacrifice quality. Blow out the budget. Increase the risk of not finishing (or some other risk).


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