How bad is it Doc?
-
There are issues and issues - some you can fix by staying, and some you can't. But when management expect you to spend all your spare time working in order to meet deadlines like that, it's not a good sign, and they don't generally listen and respond well to criticism. In fact, it's a good way to get your card marked as the first to go when they want to reduce headcount (and they will, because they can get twice the work out of each of you for no extra pay - so halve the workforce!) And I'd rather leave at a time of my choosing than at a time of theirs, because it's a lot easier to get a job when you have a job. Ask glennPattonPUB!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
OriginalGriff wrote:
and they don't generally listen and respond well to criticism
FTFY
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Leave. It's not going to get better. And if you start regularly doing evenings and weekends to meet artificial and manipulated deadlines, they will start to expect it. And then rely on it - and finally insist on it. Elephant that!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Concur.
-
Pualee wrote:
A team cannot function in agile unless management also buys into it...
:thumbsup:
There are only 10 types of people in the world, those who understand binary and those who don't.
This is not about agile. This is about stupid.
-
This is not about agile. This is about stupid.
:thumbsup:
Wrong is evil and must be defeated. - Jeff Ello Any organization is like a tree full of monkeys. The monkeys on top look down and see a tree full of smiling faces. The monkeys on the bottom look up and see nothing but assholes.
-
It's possible, but then you were at a place where a majority of the developers and 100% of the management was competent. But guess what, under those circumstances most methods would have worked.
Wrong is evil and must be defeated. - Jeff Ello Any organization is like a tree full of monkeys. The monkeys on top look down and see a tree full of smiling faces. The monkeys on the bottom look up and see nothing but assholes.
-
This is not about agile. This is about stupid.
-
I think I work in an environment teetering on the edge of toxicity. Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise. Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw. But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices: - Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter - User Stories? I hear the term often, but the team has never actually seen one - Estimation and Planning, we do this sporadically but it has been a while since the last one - Tasks are added to the sprint EVERY day - Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner - Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner - There is no official product owner and the tasks above typically come from the leaders or their suboordinates - Retrospectives, i think we've had one of those. - Backlog grooming, thats where you add more tasks right? - Conversations like this happen often: Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw) Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority? Mgmt: Both... (along with a WTF are you asking expression) Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days? Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training) Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in? Mgmt: Wherever you can. Theres always nights and weekends right? - Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it... I could write a novel, but nonetheless. I once wond
-
I think I work in an environment teetering on the edge of toxicity. Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise. Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw. But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices: - Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter - User Stories? I hear the term often, but the team has never actually seen one - Estimation and Planning, we do this sporadically but it has been a while since the last one - Tasks are added to the sprint EVERY day - Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner - Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner - There is no official product owner and the tasks above typically come from the leaders or their suboordinates - Retrospectives, i think we've had one of those. - Backlog grooming, thats where you add more tasks right? - Conversations like this happen often: Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw) Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority? Mgmt: Both... (along with a WTF are you asking expression) Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days? Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training) Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in? Mgmt: Wherever you can. Theres always nights and weekends right? - Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it... I could write a novel, but nonetheless. I once wond
It could be MUCH worse. You could not have a job at all, like myself ... but I'm not here for a sympathy party. I've occupied positions of management as well as positions of programmer (in all various forms). When in a programming position (the nature of which was senior enough to allow me to actually communicate with "management") I took the position of educator. You see, people can become management, usually, not so much because of skill, but because of perseverance. In effect, they were so insecure with their capabilities that when their previous boss finally said "WTF", realized he/she could get a better job somewhere else, and told the current company to FOAD, it is possible that his blooming idiot of a mentor actually made it into management. (Obviously, this is a hypothetical situation ... but it has happened to me several times ... with a couple of different outcomes). In any event, if you ever want to dethrone your resident idiot (RI), you need proof. Therefore, you too must embrace the role of educator. First, every time you talk to the RI and he/she (IT) publicly proclaims their idiocy, make a note of it (or multiple its). Then, in your spare time, (usually on weekends or Holidays ;-), write an article that first, documents the fact that IT said what IT said and then describe, with references, why IT is misinformed ... most importantly, document why this particular misconception is hurting your team's productivity and thereby the profitability of the company). With the last being the most salient point. Remember, your actual audience, is the RI's BOSS. Therefore, you cannot speak too much tech ... but enough to illustrate that the RI is actually an RI. Keep the NATURE of this documentation a TOTAL secret. Communicate only with the RI, via email, with the express understanding that you are trying to HELP IT. However, never forget, you are in a hostile environment. You may think you have friends but there is always that one, insecure "helmut head", that is looking to make his/her way into your position via your decaying corpse. Don't give them any ammunition with which they can expedite your demise. There are two possible outcomes: 1) Your RI is not really an RI at all ... they will take your advice, incorporate it into their management style and graduate from RI to the BEST friend you will EVER have in management. Not to mention, you will have the beginnings of a great tutorial to be used by the next IT hiring on-board. 2) Your RI is really a "BIG"
-
I think I work in an environment teetering on the edge of toxicity. Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise. Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw. But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices: - Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter - User Stories? I hear the term often, but the team has never actually seen one - Estimation and Planning, we do this sporadically but it has been a while since the last one - Tasks are added to the sprint EVERY day - Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner - Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner - There is no official product owner and the tasks above typically come from the leaders or their suboordinates - Retrospectives, i think we've had one of those. - Backlog grooming, thats where you add more tasks right? - Conversations like this happen often: Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw) Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority? Mgmt: Both... (along with a WTF are you asking expression) Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days? Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training) Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in? Mgmt: Wherever you can. Theres always nights and weekends right? - Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it... I could write a novel, but nonetheless. I once wond
jeeves77 wrote:
I could write a novel, but nonetheless. I once wondered what it was like to work on a dysfunctional team, but now I think I know.
It could always be worse right? Right?!!Father had a saying "Leave while you still have something nice to say about the place". Mike
-
Leave. It's not going to get better. And if you start regularly doing evenings and weekends to meet artificial and manipulated deadlines, they will start to expect it. And then rely on it - and finally insist on it. Elephant that!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
:thumbsup: Exactly righ. It will never get better. Been there too many times...
-
Leave. It's not going to get better. And if you start regularly doing evenings and weekends to meet artificial and manipulated deadlines, they will start to expect it. And then rely on it - and finally insist on it. Elephant that!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Concur.
-
I think I work in an environment teetering on the edge of toxicity. Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise. Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw. But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices: - Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter - User Stories? I hear the term often, but the team has never actually seen one - Estimation and Planning, we do this sporadically but it has been a while since the last one - Tasks are added to the sprint EVERY day - Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner - Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner - There is no official product owner and the tasks above typically come from the leaders or their suboordinates - Retrospectives, i think we've had one of those. - Backlog grooming, thats where you add more tasks right? - Conversations like this happen often: Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw) Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority? Mgmt: Both... (along with a WTF are you asking expression) Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days? Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training) Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in? Mgmt: Wherever you can. Theres always nights and weekends right? - Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it... I could write a novel, but nonetheless. I once wond
The trouble with the word "agile" is that many people interpret it as meaning "Hey, we just do whatever we feel like doing, and the poor suckers who work for us have to live with it!" What your company appears to be doing is so far away from agile that they should rename it arthritis. Interestingly, the cure for most of the symptoms of the disease you appear to be suffering from would be to adopt agile methods -- the real ones.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I think I work in an environment teetering on the edge of toxicity. Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise. Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw. But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices: - Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter - User Stories? I hear the term often, but the team has never actually seen one - Estimation and Planning, we do this sporadically but it has been a while since the last one - Tasks are added to the sprint EVERY day - Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner - Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner - There is no official product owner and the tasks above typically come from the leaders or their suboordinates - Retrospectives, i think we've had one of those. - Backlog grooming, thats where you add more tasks right? - Conversations like this happen often: Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw) Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority? Mgmt: Both... (along with a WTF are you asking expression) Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days? Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training) Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in? Mgmt: Wherever you can. Theres always nights and weekends right? - Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it... I could write a novel, but nonetheless. I once wond
I'll wait for the novel...or the movie, whichever comes first. But I think the movie's already been done. I have a red stapler, is that a bad thing?
-
Simon O'Riordan from UK wrote:
This is about stupid.
Deciding that based on the little information you have... :doh:
There are only 10 types of people in the world, those who understand binary and those who don't.
Same amount as you mate.
-
Leave. It's not going to get better. And if you start regularly doing evenings and weekends to meet artificial and manipulated deadlines, they will start to expect it. And then rely on it - and finally insist on it. Elephant that!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
This. That might be a great environment for some--some people get off on working themselves to a frazzle. However from jeeves' rant, he's clearly not one of them. He needs to find something else to do. I think one clear thing (from the way jeeves framed it) is that these truly are artificial deadlines. Sure, there are occasions when, due to regulatory changes or something like that, a date truly is a must-not-miss, and we need to put in extra effort. Because some sales drone told a (potential) client that "hey, this feature will be in our next release"? DFC. Sales drone needs to address what is clearly his problem then. (Or, we can consciously choose to reallocate resources or shift priorities, that's O.K. However, if everything is top priority, then nothing is).
-
I think I work in an environment teetering on the edge of toxicity. Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise. Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw. But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices: - Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter - User Stories? I hear the term often, but the team has never actually seen one - Estimation and Planning, we do this sporadically but it has been a while since the last one - Tasks are added to the sprint EVERY day - Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner - Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner - There is no official product owner and the tasks above typically come from the leaders or their suboordinates - Retrospectives, i think we've had one of those. - Backlog grooming, thats where you add more tasks right? - Conversations like this happen often: Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw) Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority? Mgmt: Both... (along with a WTF are you asking expression) Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days? Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training) Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in? Mgmt: Wherever you can. Theres always nights and weekends right? - Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it... I could write a novel, but nonetheless. I once wond
Yeah, it reminds of a few interviews where when I ask them to describe their agile process, they say, well, we have a weekly staff meeting that lasts about an hour and a half, but we call it a scrum so therefore we're agile, (right?)
-
I think I work in an environment teetering on the edge of toxicity. Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise. Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw. But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices: - Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter - User Stories? I hear the term often, but the team has never actually seen one - Estimation and Planning, we do this sporadically but it has been a while since the last one - Tasks are added to the sprint EVERY day - Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner - Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner - There is no official product owner and the tasks above typically come from the leaders or their suboordinates - Retrospectives, i think we've had one of those. - Backlog grooming, thats where you add more tasks right? - Conversations like this happen often: Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw) Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority? Mgmt: Both... (along with a WTF are you asking expression) Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days? Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training) Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in? Mgmt: Wherever you can. Theres always nights and weekends right? - Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it... I could write a novel, but nonetheless. I once wond
-
It could be MUCH worse. You could not have a job at all, like myself ... but I'm not here for a sympathy party. I've occupied positions of management as well as positions of programmer (in all various forms). When in a programming position (the nature of which was senior enough to allow me to actually communicate with "management") I took the position of educator. You see, people can become management, usually, not so much because of skill, but because of perseverance. In effect, they were so insecure with their capabilities that when their previous boss finally said "WTF", realized he/she could get a better job somewhere else, and told the current company to FOAD, it is possible that his blooming idiot of a mentor actually made it into management. (Obviously, this is a hypothetical situation ... but it has happened to me several times ... with a couple of different outcomes). In any event, if you ever want to dethrone your resident idiot (RI), you need proof. Therefore, you too must embrace the role of educator. First, every time you talk to the RI and he/she (IT) publicly proclaims their idiocy, make a note of it (or multiple its). Then, in your spare time, (usually on weekends or Holidays ;-), write an article that first, documents the fact that IT said what IT said and then describe, with references, why IT is misinformed ... most importantly, document why this particular misconception is hurting your team's productivity and thereby the profitability of the company). With the last being the most salient point. Remember, your actual audience, is the RI's BOSS. Therefore, you cannot speak too much tech ... but enough to illustrate that the RI is actually an RI. Keep the NATURE of this documentation a TOTAL secret. Communicate only with the RI, via email, with the express understanding that you are trying to HELP IT. However, never forget, you are in a hostile environment. You may think you have friends but there is always that one, insecure "helmut head", that is looking to make his/her way into your position via your decaying corpse. Don't give them any ammunition with which they can expedite your demise. There are two possible outcomes: 1) Your RI is not really an RI at all ... they will take your advice, incorporate it into their management style and graduate from RI to the BEST friend you will EVER have in management. Not to mention, you will have the beginnings of a great tutorial to be used by the next IT hiring on-board. 2) Your RI is really a "BIG"
excellent point. At the time I am reading this I am contemplating if I should jump ship in a similar situation. Your comments are weighing heavily as to whether this is the right thing to do. I will weigh any incoming offers on their merit and not on how jacked up my current process is, and I will make a wiser choice. Thanks.
-
I think I work in an environment teetering on the edge of toxicity. Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise. Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw. But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices: - Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter - User Stories? I hear the term often, but the team has never actually seen one - Estimation and Planning, we do this sporadically but it has been a while since the last one - Tasks are added to the sprint EVERY day - Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner - Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner - There is no official product owner and the tasks above typically come from the leaders or their suboordinates - Retrospectives, i think we've had one of those. - Backlog grooming, thats where you add more tasks right? - Conversations like this happen often: Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw) Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority? Mgmt: Both... (along with a WTF are you asking expression) Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days? Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training) Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in? Mgmt: Wherever you can. Theres always nights and weekends right? - Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it... I could write a novel, but nonetheless. I once wond
I always want to throw up when I hear words like "agile", "sprint", "scrum", "burndown", "waterfall" and all the other trendy management buzzwords. Because it really means it's the currently fashionable form of crippling clusterf***. I'm glad I rarely have to work at places that do that. I prefer to work on projects by creating and following a list of tasks as well as possible, modifying them if necessary, keeping management and others who are affected apprised with quick status updates when there's anything worth reporting, and being trusted (through experience) to finish whatever needs doing in a reasonable amount of time, and having the finished application do what it's supposed to. And all the while communicating in real English words.
-
I think I work in an environment teetering on the edge of toxicity. Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise. Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw. But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices: - Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter - User Stories? I hear the term often, but the team has never actually seen one - Estimation and Planning, we do this sporadically but it has been a while since the last one - Tasks are added to the sprint EVERY day - Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner - Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner - There is no official product owner and the tasks above typically come from the leaders or their suboordinates - Retrospectives, i think we've had one of those. - Backlog grooming, thats where you add more tasks right? - Conversations like this happen often: Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw) Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority? Mgmt: Both... (along with a WTF are you asking expression) Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days? Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training) Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in? Mgmt: Wherever you can. Theres always nights and weekends right? - Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it... I could write a novel, but nonetheless. I once wond
