77

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 ...


52

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 ...


28

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 ...


17

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 ...


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 ...


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

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 ...


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

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. ...


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

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).


6

What you're seeing is how TFS currently works. I've logged this with the Product Team a couple of times, and I've heard a couple of ways it might be solved in the future, but for now your tasks found and solved on the same day are not reflected. The funny thing is that the burndown will still be correct. Any hours found and resolved on the same day have a ...


6

How should PM keep its software team or at least core members unchanged until the delivery of the project? You shouldn't...nor could you. People leave. They die. They get sick. The only certain thing about your people is they are uncertain. And your project should be planned with that in mind. In other words, create a project capability that does ...


6

The ratio depends on the company and how software and project management oriented the management team is. In my experience, the majority of staff in an agile software team were testers, because the corporation focused on user experience and prior to delivering the final product to the customer, they needed to ensure that the product was "bug free" and that ...


6

Saakyan, no human resource is ever 100% productive. Non productive time, including necessary work but not tied to a specific task as well as simple down time, always exist and should exist because of the inherent benefits of rest. The range of productive time you should be using could be as low 50% but likely never higher than 75%. Also, other things that ...


6

There is only one way to "persuade" some party that they tools they are providing are insufficient for your needs. That is- you need to demonstrate the ways that the tools do not allow you to fulfil the requirements of the project. If they counter by showing you ways that allow the tools to meet your needs then clearly the tools are sufficient for your ...


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