Skip to main content
added 160 characters in body
Source Link
Bryan Oakley
  • 25.4k
  • 5
  • 66
  • 89

Strictly from a scrum perspective, it sounds like what you're doing wrong is that you're not working with the client. You need to work together with the client to come to an understanding of what they needneed and not just what they want. Do they need a series of quick fixes, or do they need a stable, maintainable system that will serve them in the long term? They needThat can be hard to determine, but quality is as much of a requirement as a background color or performance benchmark. The customer needs to be aware that stability and maintainability aren't free, and has to be engineered into the product.

If they say it is the former, you are doing nothing wrong -- assuming you're explaining to them in the sprint reviews that you're cutting engineering corners to meet their goals.

If they say it is the latter, then what you're doing wrong is that you're not giving them what they want.

One of the cornerstones of Scrum is transparency. If you're doing scrum, you should be doing sprint reviews with the customer. In those reviews, are you telling the customer that you're cutting corners in order to deliver software faster? If not, you should be. You need to be 100% clear with your customer about the ramifications of your design choices, to give them a chance to make an informed decision as to whether you are delivering your software with an appropriate level of quality.

Strictly from a scrum perspective, it sounds like what you're doing wrong is that you're not working with the client. You need to work together with the client to come to an understanding of what they need. Do they need a series of quick fixes, or do they need a stable, maintainable system that will serve them in the long term? They need to be aware that stability and maintainability aren't free, and has to be engineered into the product.

If they say it is the former, you are doing nothing wrong -- assuming you're explaining to them in the sprint reviews that you're cutting engineering corners to meet their goals.

If they say it is the latter, then what you're doing wrong is that you're not giving them what they want.

One of the cornerstones of Scrum is transparency. If you're doing scrum, you should be doing sprint reviews with the customer. In those reviews, are you telling the customer that you're cutting corners in order to deliver software faster? If not, you should be. You need to be 100% clear with your customer about the ramifications of your design choices, to give them a chance to make an informed decision as to whether you are delivering your software with an appropriate level of quality.

Strictly from a scrum perspective, it sounds like what you're doing wrong is that you're not working with the client. You need to work together with the client to come to an understanding of what they need and not just what they want. Do they need a series of quick fixes, or do they need a stable, maintainable system that will serve them in the long term? That can be hard to determine, but quality is as much of a requirement as a background color or performance benchmark. The customer needs to be aware that stability and maintainability aren't free, and has to be engineered into the product.

If they say it is the former, you are doing nothing wrong -- assuming you're explaining to them in the sprint reviews that you're cutting engineering corners to meet their goals.

If they say it is the latter, then what you're doing wrong is that you're not giving them what they want.

One of the cornerstones of Scrum is transparency. If you're doing scrum, you should be doing sprint reviews with the customer. In those reviews, are you telling the customer that you're cutting corners in order to deliver software faster? If not, you should be. You need to be 100% clear with your customer about the ramifications of your design choices, to give them a chance to make an informed decision as to whether you are delivering your software with an appropriate level of quality.

added 492 characters in body
Source Link
Bryan Oakley
  • 25.4k
  • 5
  • 66
  • 89

Strictly from a scrum perspective, it sounds like what you're doing wrong is that you're not working with the client. You need to work together with the client to come to an understanding of what they need. Do they need a series of quick fixes, or do they need a stable, maintainable system that will serve them in the long term? They need to be aware that stability and maintainability aren't free, and has to be engineered into the product.

If they say it is the former, you are doing nothing wrong -- assuming you're explaining to them in the sprint reviews that you're cutting engineering corners to meet their goals.

If they say it is the latter, then what you're doing wrong is that you're not giving them what they want.

One of the cornerstones of Scrum is transparency. If you're doing scrum, you should be doing sprint reviews with the customer. In those reviews, are you telling the customer that you're cutting corners in order to deliver software faster? If not, you should be. You need to be 100% clear with your customer about the ramifications of your design choices, to give them a chance to make an informed decision as to whether you are delivering your software with an appropriate level of quality.

Strictly from a scrum perspective, it sounds like what you're doing wrong is that you're not working with the client. You need to work together with the client to come to an understanding of what they need. Do they need a series of quick fixes, or do they need a stable, maintainable system that will serve them in the long term? They need to be aware that stability and maintainability aren't free, and has to be engineered into the product.

If they say it is the former, you are doing nothing wrong -- assuming you're explaining to them in the sprint reviews that you're cutting engineering corners to meet their goals.

If they say it is the latter, then what you're doing wrong is that you're not giving them what they want.

Strictly from a scrum perspective, it sounds like what you're doing wrong is that you're not working with the client. You need to work together with the client to come to an understanding of what they need. Do they need a series of quick fixes, or do they need a stable, maintainable system that will serve them in the long term? They need to be aware that stability and maintainability aren't free, and has to be engineered into the product.

If they say it is the former, you are doing nothing wrong -- assuming you're explaining to them in the sprint reviews that you're cutting engineering corners to meet their goals.

If they say it is the latter, then what you're doing wrong is that you're not giving them what they want.

One of the cornerstones of Scrum is transparency. If you're doing scrum, you should be doing sprint reviews with the customer. In those reviews, are you telling the customer that you're cutting corners in order to deliver software faster? If not, you should be. You need to be 100% clear with your customer about the ramifications of your design choices, to give them a chance to make an informed decision as to whether you are delivering your software with an appropriate level of quality.

Source Link
Bryan Oakley
  • 25.4k
  • 5
  • 66
  • 89

Strictly from a scrum perspective, it sounds like what you're doing wrong is that you're not working with the client. You need to work together with the client to come to an understanding of what they need. Do they need a series of quick fixes, or do they need a stable, maintainable system that will serve them in the long term? They need to be aware that stability and maintainability aren't free, and has to be engineered into the product.

If they say it is the former, you are doing nothing wrong -- assuming you're explaining to them in the sprint reviews that you're cutting engineering corners to meet their goals.

If they say it is the latter, then what you're doing wrong is that you're not giving them what they want.