How bad is it Doc?
-
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
-
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
I'm retired, and as such, I can, from experience, confidently say that "work sucks." Its near-universal. Only the degree of suck changes. Your particular suck that would have me thinking suicide was the nights and weekends suck. I don't do that well. My only truly good job was a volunteer thing with the Army in Iraq, where we DID do the nights and weekends thing but I knew that going in and there wasn't anything else to do anyway. I'm retired and loving it, and your major thrust in life should be saving large amounts of $$$$ to buy an annuity with that can never ever be exhausted, and retire as early and possible. Right now, I'm contemplating renewing an old hobby since another one seems to be ending, and that is ham radio. Did the November SSB Sweepstakes last weekend, and could become a contester, dunno. But retirement is where its at, the sooner the better and the more inexhaustible supplies of money the better. I've an actual pension that's not going away (I worked for the Navy (not _in_ the Navy, but a civilian engineer)) an annuity from a large insurance company, and a little SS. The next antenna (its like boating - you always need a bigger boat... or antenna) is $7K, top of the line, on a telescoping fold-over tower that is $17K. If my other expensive hobby, road rallying, dies as expected, the savings from that will likely actually allow me to achieve that antenna / tower combination. But find something you can endure and then get the H out of it and retired at the earliest possibility.
-
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
Been there, done that. $635 for 5 minute visit by cardiac specialist was straw that broke the camel's back. I quit the scene 30 years ago and slipped into the consulting stream making sure supplier and client are talking to each other. Granted, finding $30M projects is a little more difficult these days.
-
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
"Good. Quick. Cheap. Pick any two." That is woven into the very fabric of reality. If we ever get a Theory of Everything, it will predict that. Another fundamental feature of the universe is that "management is constitutionally incapable of accepting the last three words." (The ToE will predict that also.) And finally, the last law of the universe is, "programmers are spineless enablers who cannot say 'no,' no matter how insane the situation. They just say yes until they leave, are fired, end up in the psych-ward, or die." Now if you'll excuse me, Nurse Ratched is here with my meds.....
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
-
I have worked in a couple of teams that used varying levels of "Agile Practices". The one that followed it pretty close to the book but still allowed a little wiggle room worked the best. We got scads more work done and put working software out on time and often ahead of time because of it. I think that part of this is due to our culture. At the beginning of the Agile/Scrum effort, the software team had been consistently late on a particular project. This was mostly due to scope creep. I am working on the Product page, and the person who eventually become the Scrum Product Owner would come by wondering why the Contact page wasn't finished, and tell me to work on that instead, a couple days later it would reverse. When we implemented we decided to have a little fun with it. A jar was set up and any time the product owner wanted something changed in the middle of the sprint, it cost him 10 bucks per complexity point. If there was something that was actually an emergency that was forgivable, but raiding the sprint was forbidden and he would pay dearly for it. Secondly, we padded our meetings out and planned the hell out of things. Our Beginning of Sprint planning meeting would routinely last 3 hours and was complete with Youtube video breaks and brunch from a rotating list of sources. We were allowed to name the sprints all manner of offensive things. Thirdly, we locked down permissions on the issue tracker for the Product Owner. He could create items. He could flesh them out and add screenshots and stuff. He could not create tasks, and could not assign it to anyone, or put a complexity to it. We were the developers, we decided complexity. We decided who did what. So far as the group was concerned, the Product Owner was only the source of features and issues. We had the support of our VP of Technology and that gave us the leverage to institute the changes above. The first sprint or two, we delivered on time and a medium amount of work. after that, we kept increasing the amount of work until we felt like we had reached a good limit, and it turned out we were probably getting twice as much done ahead of time. Now, I will admit that the Product Owner did not like being shutdown. He fancied himself a developer, but was not one. But once we started really moving along, he conceded that this was better, and started treating the team to a lunch at an establishment of our choice at End Of Sprint. I think the big problem with a lot of teams is that they don't get everyone on board with inc
-
I have worked in a couple of teams that used varying levels of "Agile Practices". The one that followed it pretty close to the book but still allowed a little wiggle room worked the best. We got scads more work done and put working software out on time and often ahead of time because of it. I think that part of this is due to our culture. At the beginning of the Agile/Scrum effort, the software team had been consistently late on a particular project. This was mostly due to scope creep. I am working on the Product page, and the person who eventually become the Scrum Product Owner would come by wondering why the Contact page wasn't finished, and tell me to work on that instead, a couple days later it would reverse. When we implemented we decided to have a little fun with it. A jar was set up and any time the product owner wanted something changed in the middle of the sprint, it cost him 10 bucks per complexity point. If there was something that was actually an emergency that was forgivable, but raiding the sprint was forbidden and he would pay dearly for it. Secondly, we padded our meetings out and planned the hell out of things. Our Beginning of Sprint planning meeting would routinely last 3 hours and was complete with Youtube video breaks and brunch from a rotating list of sources. We were allowed to name the sprints all manner of offensive things. Thirdly, we locked down permissions on the issue tracker for the Product Owner. He could create items. He could flesh them out and add screenshots and stuff. He could not create tasks, and could not assign it to anyone, or put a complexity to it. We were the developers, we decided complexity. We decided who did what. So far as the group was concerned, the Product Owner was only the source of features and issues. We had the support of our VP of Technology and that gave us the leverage to institute the changes above. The first sprint or two, we delivered on time and a medium amount of work. after that, we kept increasing the amount of work until we felt like we had reached a good limit, and it turned out we were probably getting twice as much done ahead of time. Now, I will admit that the Product Owner did not like being shutdown. He fancied himself a developer, but was not one. But once we started really moving along, he conceded that this was better, and started treating the team to a lunch at an establishment of our choice at End Of Sprint. I think the big problem with a lot of teams is that they don't get everyone on board with inc
_CodeWarrior wrote:
If executed well and with a bit of fun, Agile and Scrum can be a very powerful methodology in some teams and on some projects.
Reads like an ad, and not a very good one. Its success can not be predicted, as with a procedure could. Forgive me, but I heard the ad too often. It is merely a waterfall in a month, and if you cannot do the most important steps from the waterfall, it fails. Specs should be clear (call them stories!) and be frozen for the month (woaah!). Plannings should be flexible, and have some base in reality. Aw, and you need a domain-expert to validate your assumptions. Anyting with a successrate below 40% is called alternative medicine. That's where I put Agile/SCRUM.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
_CodeWarrior wrote:
If executed well and with a bit of fun, Agile and Scrum can be a very powerful methodology in some teams and on some projects.
Reads like an ad, and not a very good one. Its success can not be predicted, as with a procedure could. Forgive me, but I heard the ad too often. It is merely a waterfall in a month, and if you cannot do the most important steps from the waterfall, it fails. Specs should be clear (call them stories!) and be frozen for the month (woaah!). Plannings should be flexible, and have some base in reality. Aw, and you need a domain-expert to validate your assumptions. Anyting with a successrate below 40% is called alternative medicine. That's where I put Agile/SCRUM.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I suppose it did read a bit like an ad, but then, when people have experienced something that they felt was good and they are trying to convince others that the particular experience was good, and it might work for them, they tend to proselytize a bit and it comes off sounding ad-ish. I am not really sure what you are getting at with you middle paragraph. Yes, I suppose it does boil down to a sort of waterfall in a month except the initial specs came out long before the start of the 2-week sprint, and we weren't building the whole application in one fell swoop.
Quote:
Specs should be clear (call them stories!) and be frozen for the month (woaah!).
I am not even sure what I am supposed to take away from this. Is that sarcasm ("woaah!")? Our specs were frozen for two weeks and we made sure that we had everything we could think of speced out. One thing I hated was implementing one way and having to go back and change it due to misinterpretations or omissions in the spec. And it would seem to me that having the specs frozen during the sprint would be a good thing. Do you enjoy having someone come back and change the size of this and the color of that and the placement of this other thing several times a day?
Quote:
Aw, and you need a domain-expert to validate your assumptions.
What assumptions? And who is this domain expert you speak of? I just don't understand your sarcasm.
-
I suppose it did read a bit like an ad, but then, when people have experienced something that they felt was good and they are trying to convince others that the particular experience was good, and it might work for them, they tend to proselytize a bit and it comes off sounding ad-ish. I am not really sure what you are getting at with you middle paragraph. Yes, I suppose it does boil down to a sort of waterfall in a month except the initial specs came out long before the start of the 2-week sprint, and we weren't building the whole application in one fell swoop.
Quote:
Specs should be clear (call them stories!) and be frozen for the month (woaah!).
I am not even sure what I am supposed to take away from this. Is that sarcasm ("woaah!")? Our specs were frozen for two weeks and we made sure that we had everything we could think of speced out. One thing I hated was implementing one way and having to go back and change it due to misinterpretations or omissions in the spec. And it would seem to me that having the specs frozen during the sprint would be a good thing. Do you enjoy having someone come back and change the size of this and the color of that and the placement of this other thing several times a day?
Quote:
Aw, and you need a domain-expert to validate your assumptions.
What assumptions? And who is this domain expert you speak of? I just don't understand your sarcasm.
_CodeWarrior wrote:
I am not even sure what I am supposed to take away from this.
Nothing :)
_CodeWarrior wrote:
Is that sarcasm ("woaah!")
Yes, seeing the same old in a new packaging, with a new price-tag.
_CodeWarrior wrote:
And who is this domain expert you speak of?
Depending on your crew they'll be called "stakeholders" (where not every stakeholder is a domain-expert), and will be invited to the group by the product owner.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
jeeves77 wrote:
I once wondered what it was like to work on a dysfunctional team, but now I think I know.
This is a perfect opportunity for you to get things going in the right direction. No workplace is perfect and people that leave a job just because there are issues are never happy because every workplace has issues. Study up on Agile and SCRUM. These principles can work very well for certain teams. Then start suggesting improvements. If no one is willing to listen then perhaps it's time to start looking elsewhere. But imagine the job satisfaction you'll have if you can make a big impact on the process.
There are only 10 types of people in the world, those who understand binary and those who don't.
True but only if(upper_managment_recognizes_current_direction_is_wrong && is_willing_to_support_change) cause_change; else leave; ;)
-
True but only if(upper_managment_recognizes_current_direction_is_wrong && is_willing_to_support_change) cause_change; else leave; ;)
Member 11002765 wrote:
else leave
I say that is a cowardice response. Not saying you are a coward but I think people quit too easily without actually trying to improve things. Yes, you need management on board but don't' fall for the cliches which say management will never change. :^)
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Member 11002765 wrote:
else leave
I say that is a cowardice response. Not saying you are a coward but I think people quit too easily without actually trying to improve things. Yes, you need management on board but don't' fall for the cliches which say management will never change. :^)
There are only 10 types of people in the world, those who understand binary and those who don't.
Great comment! I agree that there are things that a person can change that doesn't require management being on board but, for the most part, without management buy-in, the scope of that change is very limited. Pretty much limited to changing yourself and your personal practices. As far as the cliche of "management will never change", I didn't state, or imply that management wouldn't change. From personal experience, I know that they can and are often willing to change. The fact that they can is inherent in the "if/else" statement. If I thought that they couldn't change then I would have simply stated "leave". Also from personal experience, to have long-lasting, institutionalized change in a sizable organization, management has to be a part of that change.
-
Great comment! I agree that there are things that a person can change that doesn't require management being on board but, for the most part, without management buy-in, the scope of that change is very limited. Pretty much limited to changing yourself and your personal practices. As far as the cliche of "management will never change", I didn't state, or imply that management wouldn't change. From personal experience, I know that they can and are often willing to change. The fact that they can is inherent in the "if/else" statement. If I thought that they couldn't change then I would have simply stated "leave". Also from personal experience, to have long-lasting, institutionalized change in a sizable organization, management has to be a part of that change.
Member 11002765 wrote:
without management buy-in, the scope of that change is very limited
Agreed. I just think too many people assume management won't change or don't know how to approach management about changing and just quit without ever trying.
Member 11002765 wrote:
I didn't state, or imply that management wouldn't change.
I know. I guess my response was more generalized and in response to many of the other posts where quitting was the first suggestion.
Member 11002765 wrote:
to have long-lasting, institutionalized change in a sizable organization, management has to be a part of that change.
No doubt. :thumbsup:
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Member 11002765 wrote:
else leave
I say that is a cowardice response. Not saying you are a coward but I think people quit too easily without actually trying to improve things. Yes, you need management on board but don't' fall for the cliches which say management will never change. :^)
There are only 10 types of people in the world, those who understand binary and those who don't.
RyanDev wrote:
don't' fall for the cliches which say management will never change
Where are these places? I've never seen one. Management doesn't need to change, you're the one with the problem, is the attitude I've always gotten.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
RyanDev wrote:
don't' fall for the cliches which say management will never change
Where are these places? I've never seen one. Management doesn't need to change, you're the one with the problem, is the attitude I've always gotten.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
BrainiacV wrote:
Where are these places?
i believe most places have managers willing to do what is right. Sometimes it requires you to figure out how to speak their language. Perhaps I'm just being naive, but in my experience you can get change if you work on it.
There are only 10 types of people in the world, those who understand binary and those who don't.
