How bad is it Doc?
-
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.
-
Eddy Vluggen wrote:
A myth often heard, and rarely seen.
As one who lived it, I can tell you it is possible. :^) I think the problem is people try to follow it religiously and the truth is you need to make small adaptations to work with your environment. Trying to follow it exactly as is will likely not work.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
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.
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...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt -
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
Funny how, if you think about it, it's not Agile that's the problem, it's your leadership and management. In other words, it's the people not using the processes correctly that is the problem. And ironically, it's those processes that are intended to specifically avoid the problems you are having! WTF is wrong with those idiots? Marc
Imperative to Functional Programming Succinctly Higher Order Programming
-
Eddy Vluggen wrote:
A myth often heard, and rarely seen.
As one who lived it, I can tell you it is possible. :^) I think the problem is people try to follow it religiously and the truth is you need to make small adaptations to work with your environment. Trying to follow it exactly as is will likely not work.
There are only 10 types of people in the world, those who understand binary and those who don't.
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.
-
Eddy Vluggen wrote:
A myth often heard, and rarely seen.
As one who lived it, I can tell you it is possible. :^) I think the problem is people try to follow it religiously and the truth is you need to make small adaptations to work with your environment. Trying to follow it exactly as is will likely not work.
There are only 10 types of people in the world, those who understand binary and those who don't.
In my experience, the real problem is that management doesn't change, but they expect the team to be agile. A team cannot function in agile unless management also buys into it... Things like: having a product owner, understanding that X points fit per sprint, tasks do not come into the sprint or carry over the sprint. The lack of a real backlog and user stories means management is failing. They cannot have any idea what a teams throughput is, compared to the expected work without both a prioritized backlog and a team velocity tracked over history. And thus, they cannot actually plan a release. Anyway, I think most management see 'agile' as a silver bullet which allows them to change priorities regularly and still expect everything to get done. But its not, its a tool for tracking expectations... through team empowerment (which means managers have less power). Managers simply build teams. Scrum masters lead teams (and protect them from management). Business owners set priorities. The team is the central power. If managers don't want to listen to their teams... then they can read about them in the exit interviews.
-
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...
Spot on! +24 billion points to you, good sir. :-D
-
In my experience, the real problem is that management doesn't change, but they expect the team to be agile. A team cannot function in agile unless management also buys into it... Things like: having a product owner, understanding that X points fit per sprint, tasks do not come into the sprint or carry over the sprint. The lack of a real backlog and user stories means management is failing. They cannot have any idea what a teams throughput is, compared to the expected work without both a prioritized backlog and a team velocity tracked over history. And thus, they cannot actually plan a release. Anyway, I think most management see 'agile' as a silver bullet which allows them to change priorities regularly and still expect everything to get done. But its not, its a tool for tracking expectations... through team empowerment (which means managers have less power). Managers simply build teams. Scrum masters lead teams (and protect them from management). Business owners set priorities. The team is the central power. If managers don't want to listen to their teams... then they can read about them in the exit interviews.
-
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:
Now our process is "agile". And by "agile" I mean
we'll tell everyone that our process agile and then explain what it means. Other than that, it's business as usual.
-
jeeves77 wrote:
Now our process is "agile". And by "agile" I mean
we'll tell everyone that our process agile and then explain what it means. Other than that, it's business as usual.
-
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:
an environment teetering on the edge of toxicity.
Sadly, it's done teetering. :( /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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
In all seriousness, the process your team is following is neither agile nor waterfall. It's non-existent. :(( /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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
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.
-
Funny how, if you think about it, it's not Agile that's the problem, it's your leadership and management. In other words, it's the people not using the processes correctly that is the problem. And ironically, it's those processes that are intended to specifically avoid the problems you are having! WTF is wrong with those idiots? Marc
Imperative to Functional Programming Succinctly Higher Order Programming
God, our CEO, decided we would go "agile", they got in a permanent trainer team as they (he) wants the entire culture, management, operations, devs, the lot to go agile. Trainer gets a bunch of devs together to explain the bones of the new environment. Says the idea is to have all the people involved in the project sitting near each other to encourage involvement, I fell off the chair laughing. We are scattered over 3 floors and that is just the dev team. That was 6 months ago, nothing has changed!
Never underestimate the power of human stupidity RAH
-
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...
Hear, hear!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
-
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
-
God, our CEO, decided we would go "agile", they got in a permanent trainer team as they (he) wants the entire culture, management, operations, devs, the lot to go agile. Trainer gets a bunch of devs together to explain the bones of the new environment. Says the idea is to have all the people involved in the project sitting near each other to encourage involvement, I fell off the chair laughing. We are scattered over 3 floors and that is just the dev team. That was 6 months ago, nothing has changed!
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
Trainer gets a bunch of devs together to explain the bones of the new environment.
I also had this experience, the only difference is (which was the reason it worked at the end) that the 'trainer' also pulled in management and at times had meetings with only the management level and higher. As has been said before the solution lies in not only training the developers but all the management and higher positions should also be trained in Agile workings and 'rules' etc. The person even trained business management in agile and as such they were in the weekly retros. I remember every Wednesday all the HODs will do a walk through of each team's board (That had all the iteration progress and stories etc.)
»»» Loading Signature «««· · · Please Wait · · ·:badger: :badger: :badger: -
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.
