5 ms·

I love the honesty of this story and I wish it were told more often. I just kept nodding. You did touch on one concept that I almost added to the piece... "we a

I love the honesty of this story and I wish it were told more often. I just kept nodding. You did touch on one concept that I almost added to the piece... "we always do it like that". If this post continues to grow in popularity I think I will add an "after thought" with additional insights like what you shared. Thanks.

JimboOmega 13y ago
Another problem (symptom or cause? I'm not sure) was how we prioritized things. When I started, there was P1, which was only used if production was effectively down, P2, which meant it had to go in the next release, and P3 and on down. Of course everybody had issues they really wanted fixed - more than we could do. People realized that P3 bugs stood a good chance of missing the release - and might not get fixed for the better part of a year if they did. So almost all bugs started becoming P2. This obviously didn't work, so to supplement that, we had a system of "Shadow priority" - that is, there'd be P2 tickets that "important" managers really cared about and thus had to get done. This got a bit tiring because of the number of managers and their shifting priorities. I remember a spreadsheet where the rows highlighted in green were "true" P2s. Thus we created a new priority field, "relative importance", because everything was P2... And guess what, the process repeated; everything became high relative importance. By the time I left - and I did send an email complaining about this to my boss - I think we were up to 5 different places to look for priority, including a spreadsheet that would be shown at meetings but not circulated. The logic for figuring out priority was incredibly complicated, since certain types of priority overrode others. There might be P3s that were more important than P2s because they were the pet issue of a certain manager, for instance. There was a separate notion of "QA Priority" and "Manager Priority" (manager priority, on the spreadsheet, even had P0) Of course, what developers thought never was a big consideration. For the longest time, I just thought it was the inevitable result of bureaucracy, and yet, here I sit at a job where, for almost 5 months, we've had a backlog that we all are involved in creating; the priorities and rationale are explained to us... and best of all, the most important things are at the top! That's all I need to do, look at the top of the backlog. And somehow I spend almost no time waiting on requirements, and none waiting on "database" (which isn't even a team). Fixes I make get reviewed a week later at the absolute latest. I'm not sure why, exactly, this is. Clearly our situation is more desirable - so why did the old one happen at all? I don't feel like any of the teams at my old company were incompetent, evil, or stubborn. It was just the way we did things. (:With the possible exception of the sworn enemies of the dev team, ProdOps née SOC AKA the SysAdmins. But then, the inter-team rivalry was more of a symptom than an actual cause.)
- bdehaaff 13y ago
  You touch on another interesting area. How to rank the importance of features. I am careful to highlight our own work, but do a search for Aha! Scorecards and Aha! Scores. We introduced a way for teams to enter into their account their own key business metrics and then rank features against them. It's hard to game the system when you are asked to rank the importance of features against real business goals (sales, support, internationalization, mobile, etc.) and then forced to defend your rankings if there is disagreement.
  - JimboOmega 13y ago
    That is better than our old system, which was mostly ranked by "how important the manager who wants this is". Edit: Although I do think there needs to be a way to handle simple things - wait for it - simply. "Oh, this field is broken, I know why, I can fix it in 15 minutes" should be enough - no need to have people estimate with too many metrics. Going metrics crazy can slow things down pretty badly, too.
- hacknat 13y ago
  This is what I'm experiencing right now. We've basically done away with prioritization. We have no project managers anymore (we used to have 7), so any interested party can come to any dev to get anything done. We basically have no pipeline for allocating resources and it is amazing how many people try to fly under the prioritization radar of the product manager and VP of Engineering. There is, paradoxically, too much trust and too little at the same time, we aren't trusted to be part of stack ranking, but we're basically responsible for partaking of the orders that come down from on high in anyway we please, if you're a full-stack engineer it sucks.
  - bdehaaff 13y ago
    Yikes. Who vets what comes down the line vs the key business objectives? And who is looking out past three months to make sure you are building what will matter as the market shifts? I feel for you.

JimboOmega 13y ago

Another problem (symptom or cause? I'm not sure) was how we prioritized things. When I started, there was P1, which was only used if production was effectively down, P2, which meant it had to go in the next release, and P3 and on down. Of course everybody had issues they really wanted fixed - more than we could do. People realized that P3 bugs stood a good chance of missing the release - and might not get fixed for the better part of a year if they did. So almost all bugs started becoming P2. This obviously didn't work, so to supplement that, we had a system of "Shadow priority" - that is, there'd be P2 tickets that "important" managers really cared about and thus had to get done. This got a bit tiring because of the number of managers and their shifting priorities. I remember a spreadsheet where the rows highlighted in green were "true" P2s. Thus we created a new priority field, "relative importance", because everything was P2... And guess what, the process repeated; everything became high relative importance. By the time I left - and I did send an email complaining about this to my boss - I think we were up to 5 different places to look for priority, including a spreadsheet that would be shown at meetings but not circulated. The logic for figuring out priority was incredibly complicated, since certain types of priority overrode others. There might be P3s that were more important than P2s because they were the pet issue of a certain manager, for instance. There was a separate notion of "QA Priority" and "Manager Priority" (manager priority, on the spreadsheet, even had P0) Of course, what developers thought never was a big consideration. For the longest time, I just thought it was the inevitable result of bureaucracy, and yet, here I sit at a job where, for almost 5 months, we've had a backlog that we all are involved in creating; the priorities and rationale are explained to us... and best of all, the most important things are at the top! That's all I need to do, look at the top of the backlog. And somehow I spend almost no time waiting on requirements, and none waiting on "database" (which isn't even a team). Fixes I make get reviewed a week later at the absolute latest. I'm not sure why, exactly, this is. Clearly our situation is more desirable - so why did the old one happen at all? I don't feel like any of the teams at my old company were incompetent, evil, or stubborn. It was just the way we did things. (:With the possible exception of the sworn enemies of the dev team, ProdOps née SOC AKA the SysAdmins. But then, the inter-team rivalry was more of a symptom than an actual cause.)

bdehaaff 13y ago
You touch on another interesting area. How to rank the importance of features. I am careful to highlight our own work, but do a search for Aha! Scorecards and Aha! Scores. We introduced a way for teams to enter into their account their own key business metrics and then rank features against them. It's hard to game the system when you are asked to rank the importance of features against real business goals (sales, support, internationalization, mobile, etc.) and then forced to defend your rankings if there is disagreement.
- JimboOmega 13y ago
  That is better than our old system, which was mostly ranked by "how important the manager who wants this is". Edit: Although I do think there needs to be a way to handle simple things - wait for it - simply. "Oh, this field is broken, I know why, I can fix it in 15 minutes" should be enough - no need to have people estimate with too many metrics. Going metrics crazy can slow things down pretty badly, too.
hacknat 13y ago
This is what I'm experiencing right now. We've basically done away with prioritization. We have no project managers anymore (we used to have 7), so any interested party can come to any dev to get anything done. We basically have no pipeline for allocating resources and it is amazing how many people try to fly under the prioritization radar of the product manager and VP of Engineering. There is, paradoxically, too much trust and too little at the same time, we aren't trusted to be part of stack ranking, but we're basically responsible for partaking of the orders that come down from on high in anyway we please, if you're a full-stack engineer it sucks.
- bdehaaff 13y ago
  Yikes. Who vets what comes down the line vs the key business objectives? And who is looking out past three months to make sure you are building what will matter as the market shifts? I feel for you.