|
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. 
|
|
|
|
|
|
 Exactly righ. It will never get better. Been there too many times...
|
|
|
|
|
|
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).
|
|
|
|
|
jeeves77 wrote: Theres always nights and weekends right?
Yes, but you ain't in it 
Bastard Programmer from Hell 
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.
|
|
|
|
|
RyanDev wrote: These principles can work very well for certain teams.
A myth often heard, and rarely seen.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
"100% of the management was competent"
You're funny. I like you 
|
|
|
|
|
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.
|
|
|
|
|
Pualee wrote: A team cannot function in agile unless management also buys into it...
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.
|
|
|
|
|
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.
|
|
|
|
|
Simon O'Riordan from UK wrote: This is about stupid.
Deciding that based on the little information you have... 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
|
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 incentives. Product Owner had an incentive NOT to add crap to the Sprint in the middle. He also had the incentive of faster turnaround and more complete code. We all had incentive of getting him out of our hair, and free meals a couple times a week, not to mention that we now had a very nice defined amount of work that we could stab at throughout the week and a good metric of how we were doing.
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.
|
|
|
|
|
_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
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.
|
|
|
|
|
_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 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
