We’re rewarding the question askers & reputations are being recalculated! Read more.
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 ...


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


40

Very short term solution: Based on my experience, there is always somebody who'll do anything for money. Money is the worst motivator ever, but if you are in trouble - such as losing a customer - you have to do something. If the money motivation works, think about the why and start thinking about hiring a new team, because they kind of put upon the situation ...


35

"but as we approach a deadline on a major product, we really should have all members dedicated to staying late to see it finished." If a PM is doing their job efficiently, this would be exactly the opposite of true. Your team should be working about the same amount of hours every week. If they have planned their project properly, and continually monitored ...


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


20

TL; DR Agile release planning is based on fixed-length, normed-capacity cycles that operate on dynamically-planned and dynamically-scoped features. In Scrum, fixed-date release planning must be handled by controlling scope to meet the deadlines, as you cannot have both fixed-date and fixed-scope deadlines simultaneously. This is rarely a practical problem, ...


18

Things that have prevented me doing any more than I'm contracted to do include: Habitual requests for extra time, if it happens every deadline, then the project manager is not pulling their weight. Lies. If you tell me you need it tomorrow, you'd better be using it tomorrow. If I ask you about it a week later, and you say you haven't looked at it, you can ...


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

No matter how many times I read this, this line slaps me across the face "we really should have all members dedicated to staying late to see it finished." It is dripping with false expectations. When an employee accepts a job, at least in North America, a 40 hour work week is standard. Some overtime is expected, but only in exceptional situations. ...


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

Research stories (called Spikes in Agile terms), should be: used sparingly kept short always be time-boxed Should we assign a time box (so many hours) for research stories or a regular point estimate? Regular point estimate cannot be used mainly due to following reasons: story points give out a measure of business value points are used to calculate ...


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


13

This is a classic management problem; trying to use a single body of resource to handle both time-based planning-driven work and ad-hoc unpredictable event-driven service requests. Unenlightened management love to get the fixed-plan project teams to "just do a little bit of support" as if time can be summoned magically out of nowhere. I have personally had ...


11

TL; DR Should we assign a time box (so many hours) for research stories or a regular point estimate? You should do both. A spike (or "spiked story") requires both a time-box and a level-of-effort estimate, and is always counted as work. Spikes Are Just Special User Stories As one source states: Like other stories, spikes are put in the backlog, ...


11

TL;DR In general, I recommend a "fudge factor" of 0.75 to baseline a new project, absent other data. This would mean 6 hours of project effort in an 8-hour day. I also recommend a more aggressive fudge factor of 0.4 to 0.6 for new teams to account for the overhead of team formation and process development. In the following sections, I describe some ...


10

I didn't use FogBugz although I did adopt the method itself in one team I worked with as I had all the needed data in my task tracking tool. First, the story We were splitting our stories, and later features, to so-called development tasks. For each of such tasks we were making estimates in real hours, meaning that we were trying to take into account all ...


10

When you review the schedule, have stakeholders with you and look for those items which have less value in comparison to the other items. There is a so called "iron triangle" in software development. It talks about money, scope and time. Let me take a quote from Jeff Atwood (co-creator of SO and SE): These three factors are all related. If you pull on ...


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


9

So you are using hours in a day but talking about duration. These are two different estimates and cover different things. You are on the right track, however, in terms of allocating the right utilization per resource. Full-time is something less than 8 hours a day. It can range from 35% to probably not higher than 75%. While productive work is less ...


9

You have historical data about your team The only tool you have in Scrum to help this situation is your velocity. I believe you know your velocity - how many story points you do in a sprint -, check the product backlog and do planning on each user story. Using these two, you'll have an estimation on a possible delivery date. delivery in weeks = ((number of ...


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


8

"Get closer to the team and solve their problems " Project Manager's key value addition comes from the fact that she is responsible for ensuring the project's success and in addition to reporting,estimating and highlighting , actually solving the team problems,suggesting/soliciting trade offs to ensure success,managing an efficient budget,keeping the team'...


8

The real value added by the Project Manager is the running ahead of the team making sure any potential roadblocks are removed before the team stumble on them. This could involve making sure other teams know when to expect your teams deliverables so they are ready, or it could mean making sure stakeholders know how things are going so they don't get suprises. ...


8

There are some answers about dealing with the immediate problem. You should also invest some time into making sure you're not in the same boat again. I notice you say: the realities of the industry dictate that sometimes we can not finish everything that needs to get done within that time frame. Some questions I'd be asking: Who set the release date ...


8

From everything I've read, switching to a Results Only Work Environment results in an upswing in productivity. It tends to result in more hours worked too, but that's not the goal per se. In a nutshell, ROWE means that you stop managing hours and work location and instead manage measurable objectives and let employees control their own time and decide for ...


8

The It depends pretty much answers all of your questions because they really depend on the context. My first advice is to change your questions by adding the why do I to the beginning. For example, "Why do I want to have one meeting per week?" Because I have to write a report once a week to my boss? Or, because I would like to know about the daily life of ...


8

I can think of only one reason why you would inform and alter the schedule of one supplier when another is late: dependency, in which case you would have integrated the schedules and everyone involved will see the variances and impacts accordingly. All projects produce variances. A variance free schedule is a fake one. I cannot imagine trying to ...


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