Hot answers tagged

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


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


15

When Engineering Problems Become Project Management Problems One of the team members turns in code that is almost always bloated and inefficient, even though it technically works (although, from time to time it doesn't). This is only peripherally a project management issue. It is actually an engineering issue, but it bleeds into project management ...


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

If you are building a product for a client, your internal testing / QC work is not subject to negotiations. It is part of the work, part of the price, and there is no reduction in that area. If the client does not want to conduct UAT, that's their choice and risk to accept; however, there's secondary risk on the seller in this scenario. To mitigate the ...


13

“It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. Sherlock Holmes A logical corollary is that it is a capital mistake to devise risk mitigation strategies before stating a risk. There is no risk in your question. Your client wants to compress UAT. Before ...


9

It's great to hear that Code Reviews went smoothly and you are seeing results soon, you have seen it's effective and that means the junior programmer is keen to learn (All good stuff) Few things I would like to suggest which can be done at your end Good code samples from existing code base - You probably have some star quality code in your existing code ...


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

The Product Owner has responsibility for the backlog and the development team has responsibility for delivery. However, in Scrum we work as a team and there is nothing to stop the Product Owner discussing concerns over delivery with the development team. Just as there is nothing to stop the development team discussing concerns over the backlog with the ...


8

Modern testing is all about how you assist to "Accelerate the Achievement of Shippable Quality". Do your reviews help with accelerating? What metrics do you use to create proof of that? Testing helps with reducing risks, but at what cost? What is the return on investment. Overall I think the project managers question seems a very valid one. Wonder ...


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

We've struggled with the same issue on my team, while there's no replacement for a quality QA on the team, we've managed to get along by wearing multiple hats. This is our workflow: TDD the story until it's ready to integrate. Developer integrates and manually tests. Developer requests code review. 2nd dev reviews the code. 2nd dev pulls the changes local ...


7

This is a great question. Several years back I analysed the bugs reported in a team and found that over half of them came about as a result of misunderstanding of requirements. Some things that can help to reduce this problem include: Have the team (QA, devs, PM, etc.) jointly add details to a requirement, so that they share a common understanding Using an ...


7

What do you mean by "reviews" in this context? Many development teams do peer-reviews of code and analysis because they find that reviews improve productivity and quality. Many teams also make end-user reviews part of their Definition of Done for work. This is something the whole team should have an opinion on, not something you need to discuss ...


6

In addition to others, I also find this post disturbing. I've seen Project Managers want to place all sort of metrics on developers, but never on themselves, Product Managers, QA, management, etc. It takes more than software developers to release a project and get it right. Do you keep track of what was the root cause of the bug? Who has to work on their ...


6

Having gone through something similar myself, here are some considerations. I'll try not to get too wordy but there are some aspects of Scrum that need to be brought up. Making this sort of change can be extremely beneficial, but first and foremost needs buy-in from the developers. If they are not supporting changes it won't work, and Scrum should be run ...


6

This sounds like a good topic to bring up at the team's retrospective. There are lots of possible approaches, but the team should decide for themselves. Some things you might consider: The QA shows bugs to the Product Owner before they log them If a bug is not viewed as important by the Product Owner, resolve it as 'won't fix' Discuss as a team the types ...


6

Having worked in two regulated environments (aerospace and pharmaceutical/healthcare), I've seen the problem of needing independent quality assurance in a deliverable. A few things to consider: Build QA time into your Sprint. My current organization used to run two-week Sprints. We began on a Wednesday afternoon (some teams begin on Thursday morning) with ...


6

TL;DR While quality can be measured objectively, defining the domain-specific elements of quality for your organization isn’t something where you can rely on a standard dictionary definition. In fact, most of the issues you’ve identified aren’t intriniscally quality issues at all. They seem more like organizational issues. We’ll look at some of them in ...


6

I think it is a very fair question for the PM to ask. Evaluating the proposed effort against its benefits, costs, and risks is proper leadership and management. If you have a proposal for testing, you ought to be able to articulate value. If you cannot, then do you truly understand the work? Testing is risk mitigation, and PMs own the responsibility to ...


5

TL;DR Should I add something to "Client Obligations" about code style? You can do this, but you may be measuring the wrong thing. This smells like an X/Y problem: you have a problem to solve with the deliverables hand-off, have decided that coding style is the thing that will fix the problem, and are now trying to solve for "coding style" rather than the ...


5

Define Quality Through an Agile "Definition of Done" What level of quality are you expecting from this solution? While tempting, asking the question in this way is not useful because it doesn't lead to actionable or testable criteria. In addition, scope (and therefore to some extent quality) is the adjustable theory-of-constraint dimension in most agile ...


5

If I don't have the time to produce a Swiss precision watch, ... If I don't have the tools to produce a Swiss precision watch, ... If I cannot attract the people that can produce a Swiss precision watch,... ... I might end up offering sun dials. Likewise, my customer might not have the time to actually figure out the difference between a sundial and a ...


5

Defects are part of software development cycle. It certainly cannot be blamed on just a single person. The whole chain is responsible. Any found defect should be categorized and prioritized. Then it should be picked up by the responsible team, quality is a team effort not individual. Afterwards the original developer with the team should do a root-cause ...


5

Discuss in the Retrospective. There's a limit to how much advice can be obtained from strangers on the internet. Your Team is presumably aware of the problem, and Scrum prescribes a self-organizing Team. So discuss the issue and brainstorm/evaluate possible solutions during the Retrospective. That being said... Have QA be involved during the Planning ...


5

If there are two stakeholders who have different understandings of the requirement, then there may be more. What about how you interpret the requirement, from the perspective of a tester? Or how about the customer? Or even the end-users of the product? If the requirement is ambiguous to the point where two people who (in theory, anyway) are working closely ...


4

Focus on quality and estimates You identified four problems. Of those, I would view the following two as your main issues (long hours and missed deadlines are likely resulting from these): Quality of your code is dropping: When the quality is bad, you end up doing a lot of unplanned work. This results in long hours and missed deadlines not to forget the ...


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