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


27

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

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

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


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

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


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

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


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

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

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


10

All work is probabilistic. It has an extremely improbable best case result, an extremely improbable worst case result, and an extremely probable most likely result. That probabilistic distribution is driven by both random and non-random variables and a PM, no matter how talented, can do absolutely nothing about the random variables and can likely affect ...


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

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

I will assume that the "push" approach is not only direct, but also immediate. (Like when someone comes up to you and says "hey, Joe, can we roll this later today?"). The "pull", on the other hand, is not only indirect, providing the queue as the go-between, but also delayed. Tasks might accumulate in the queue, waiting to be picked during the day, or ...


9

I think the most useful advice can actually be found in the comment on your linked Question. My manager was absolutely shocked to find out that we still had our stand up when he canceled it (a regular occurrence). My response to him was "The stand up isn't for you. It's for us. Whether you're here or not, we still need to sync up as a team. The Daily ...


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


8

Here's one source: https://project-management-knowledge.com/definitions/e/external-dependency/ Simply research "external dependencies in project scheduling." Your schedule will simply be incomplete if you do not have identified in your schedule the dependencies upon which your schedule is based. Your best argument is the word, "dependency.&...


7

This is why I prefer a product oriented WBS. Except when the deliverable is a service, the WBS should be based on the product itself, broken down to its components, and then underneath add activities and tasks. Where you load resources is up to you but I typically load them at the lowest level product WBS. Below this, I could not care less what changes ...


7

Crashing is simply the concept of throwing more resources--be it money, tools and machinery, humans, etc--at a work package in an attempt to decrease its overall duration. The general idea is, if you planned 10 days with one person to do a task, then applying a second person will decrease the duration to five days. The issue is, this does not work that ...


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


6

Assuming that all three projects have similar schedules, profit margins, strategic alignments, etc. (which I infer from your question). Which one has the highest risk? I prefer to work on the riskiest project first; the earlier I can refine that risk, the better my chance of successfully managing that risk. Which has the highest re-use value? For which ...


6

There is a finite number of things you can do to bring in your schedule. Can you crash it? This means can you throw more labor into it, which, in theory, will bring in your duration as well as explode your costs? Do you have some labor bandwith that will allow you to start packages that are scheduled down the road? This is fast tracking. It may ...


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