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


30

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


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


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

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

Does Scrum take into account interruptions? Scrum does not. The Scrum team does. Scrum teams are self-organized and plan their own work. If part of that work consists of fixing urgent bugs from production or handling requests from other teams, then the team needs to find a way to organize around that, how exactly depends on the context: they might ...


14

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


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

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

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


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

Yes, a project manager is responsible for completing a project on time. However, "on time" is a date that will often move during the life of the project, and it is the agreed date that the PM should be measured against - not necessarily the original date. The initial date may be agreed by all concerned, however requirements may change, issues are ...


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


8

No, it doesn't mean "Compulsory daily meetings with non-technical people" In the then prevailing Waterfall model of development, requirements were gathered, written-down and signed off in the first phase of the project. After this, the development team will go through analysis, design, development and testing sequentially with no interaction with ...


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


7

TL;DR The Scrum framework certainly addresses capacity planning and scheduling, although it's not prescriptive about how the Scrum Team should manage the issues you describe. The implementation details are left as emergent properties of the framework's inspection and adaptation cycles. From a purely practical perspective, you need to reduce your planned ...


6

I don't have an answer beyond the very simple - you must either De-scope the projects Limit the support Extend project timelines Increase resource Note that I said the answer is simple, getting management buy-in or understanding is considerably more difficult. Since you have indicated that none of them are available I would suggest you only have one ...


6

I've been very successful as a program manager and now agile coach, in Silicon Valley, for over fifteen years based on a completely non-technical background. I've faced this argument many times in the earlier stages of my program management career. My technical skills are at a basic advanced computer user and I've never coded. When faced with these ...


6

If you don't pad the estimate, you'll be forced to manage risks. Padding the estimate is merely a coarse strategic reserve of time. Not sure how you do the pad, but I understand it is common to inflate by some margin (e.g. 20%) The alternative is to estimate each work package and explicitly discuss the worst, best, and probable case. Then sum those up ...


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