4 ms·

I used to feel bad. I don't anymore. I make my own share of mistakes. I firmly admit that, but it's really easy for others in the business to blame the devel

by kemiller2002 7y ago

I used to feel bad. I don't anymore. I make my own share of mistakes. I firmly admit that, but it's really easy for others in the business to blame the developers for defects in software. "Well, you made them." Yes, I did, but I am not the one who didn't allow time for us to properly check things, or created the work culture where people are on edge about getting things done. I'm not perfect, but I'm done with other people blaming me and making me feel totally responsible for being in a position where I can't effectively do my job.

wonderwonder 7y ago
My department is velocity driven (agile) meaning we have to complete a certain number of points each week. Quality loses its importance when quantity is the main driver for being employed.
- rmah 7y ago
  So why not just assign your stories more points to cover the time need for higher quality output?
- levythe 7y ago
  I wonder how two different teams can be so different in culture saying they do the same thing. My team looks at velocity only as an indicator of how much we think we can reasonably take on looking ahead and as a warning sign if things are falling apart.
- kemiller2002 7y ago
  That's a tough one. Most people either don't understand or refuse to acknowledge that velocity is not a measure of how much you can accomplish. It's not a goal of work. It's a speed limit. The team's velocity signifies that its the maximum amount of work they can reasonably accomplish while adhering to certain quality standards. Organizations like to ignore this, because it makes them feel like they are making people more productive. The question I ask when confronted with situations like this is, "Do you want to lessen the quality of the code base for increased productivity?" This honestly makes people a little upset, because they know the answer they want to say vs. the answer they should say. Once someone says no to this question, they open themselves up to negotiating over the amount of work to accomplish within a given period of time.
  - latchkey 7y ago
    > It's a speed limit. Spot on. Sounds like in the OP's case, people are putting a weight on the current velocity numbers and not looking at when features will be ready. Usually means the stories are too big. Velocity over time is what you use to predict when future features will arrive. Yoyo velocity likely means the stories are too big or too small. If velocity drops and those features just move down the road. It should be clear as to why velocity drops (someone goes on vacation) or the story isn't broken down enough and takes too long. Usually, in a velocity driven workflow, you don't need to lessen quality of code because developers point their stories and they should factor in testing into those points. If the stories are too big, break them into smaller stories so there is more accepted work each week. Like what we learned in math class... break a bigger problem into smaller problems...

wonderwonder 7y ago

My department is velocity driven (agile) meaning we have to complete a certain number of points each week. Quality loses its importance when quantity is the main driver for being employed.

rmah 7y ago
So why not just assign your stories more points to cover the time need for higher quality output?
levythe 7y ago
I wonder how two different teams can be so different in culture saying they do the same thing. My team looks at velocity only as an indicator of how much we think we can reasonably take on looking ahead and as a warning sign if things are falling apart.
kemiller2002 7y ago
That's a tough one. Most people either don't understand or refuse to acknowledge that velocity is not a measure of how much you can accomplish. It's not a goal of work. It's a speed limit. The team's velocity signifies that its the maximum amount of work they can reasonably accomplish while adhering to certain quality standards. Organizations like to ignore this, because it makes them feel like they are making people more productive. The question I ask when confronted with situations like this is, "Do you want to lessen the quality of the code base for increased productivity?" This honestly makes people a little upset, because they know the answer they want to say vs. the answer they should say. Once someone says no to this question, they open themselves up to negotiating over the amount of work to accomplish within a given period of time.
- latchkey 7y ago
  > It's a speed limit. Spot on. Sounds like in the OP's case, people are putting a weight on the current velocity numbers and not looking at when features will be ready. Usually means the stories are too big. Velocity over time is what you use to predict when future features will arrive. Yoyo velocity likely means the stories are too big or too small. If velocity drops and those features just move down the road. It should be clear as to why velocity drops (someone goes on vacation) or the story isn't broken down enough and takes too long. Usually, in a velocity driven workflow, you don't need to lessen quality of code because developers point their stories and they should factor in testing into those points. If the stories are too big, break them into smaller stories so there is more accepted work each week. Like what we learned in math class... break a bigger problem into smaller problems...