|
"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.
|
|
|
|
|
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.
|
|
|
|
|
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. 
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.
|
|
|
|
|
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.
|
|
|
|
|
RyanDev wrote: i believe most places have managers willing to do what is right.
Again, I ask, where are these places?
Aside from myself and one manager I had in my long career (and they fired him), all have been insecure, egotistical tyrants, who view any criticisms (doesn't matter if it is posed as a suggestion) as a direct challenge to their authority.
Most prefer to rule by fear and intimidation, the rest, indifference, they're the manager, you aren't.
The one great manager I had that was willing to listen and work with you, was fired though the actions of the other sharks in the pool.
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: Most prefer to rule by fear and intimidation, the rest, indifference, they're the manager, you aren't.
Hm. What did you do to try and change things?
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
RyanDev wrote: What did you do to try and change things?
You're missing the point. These people are thick as a brick.
There was one instance where the manager espoused this weird idea of how she wanted source code control to be used. Myself and the eleven others on the team tried to explain to her that was not how source code worked. Her reply, "That's how it will work here!"
So the weight of opinion/knowledge was totally ignored.
Another time I had written a universal sortation package in FORTH (the company standard), it handled infinite diverter types with infinite geometries, and a new manager came in and decreed all programs were to be written in 'C', to be more "commercial." I tried to explain the program could not be converted. FORTH allows you to modify the compiler as the program compiles. I wasn't playing games, but creating a dynamic preprocessor that generated data structures and populated them with values, depending on the code.
No matter, the decision was made, logic had no bearing on it, even after I tried to walk him through the code to show how it worked. He admitted he didn't understand half of what I said (I'll estimates less than a third), but his mind was made up.
Before you say I failed because I befuddled him, he didn't understand the concepts of how our systems worked, he was using what I call "Management By Magazine Article Logic" in that he had heard 'C' was a more popular language and that is what he was basing his decision on.
So he threw away a program that solved all their problems, past, present, and future.
I could write a book giving you more examples.
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.
|
|
|
|
|
jeeves77 wrote: Theres always nights and weekends right?
At this moment I would leave for good...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
