Please register to participate in our discussions with 2 million other members - it's free and quick! Some forums can only be seen by registered members. After you create your account, you'll be able to customize options and access all our 15,000 new posts/day with fewer ads.
I'm not sure how you don't understand how prioritization isn't needed for sprints. You need it because you need to properly allocate work. For one is making sure each user story fits the actual sprint. The biggest issue with Waterfall is that task were way too monolithic. If you have a super monolithic task for a 2 week sprint, to me it sounds like it was a failure during your grooming. I don't know much about Kanban. But from what I understand Kanban seems to work better for support an/or DevOps, since I've heard it's more interrupt driven.
I don't think you read my post correctly. I said "I don't see how prioritization REQUIRES sprints." Do you think every team that doesn't follow a sprint model, doesn't have priorities?
No, sounds wrong. First of all, it's called Agile. I'm not going to rehash the Agile manifesto but the methodology is based around correcting inefficiencies within the waterfall method. In fact, if anyone has any issues during a sprint, they can bring it up during the daily scrum meeting to get it corrected right away.
Nothing in Agile increases anyone's workload per we. It makes everyone stay on their toes with no dawdling. Any claims of being overworked would indicate that the stories are being incorrectly sized during grooming. This is easily corrected and no systematic issue should last any longer than two weeks or until the next sprint. Correct the sizing issue and excessive overtime goes away.
That is not my understanding that Sprint is Agile. But that was not the point of my argument. My point was that the Sprint model would be easy to abuse by having immovable deadlines to extract as much work as possible out of people. Certainly if a system is used in an ideal manner then it could be used well. However, a lot of these systems are used as management tools to just make people work harder and put in that all-important unpaid overtime work.
I LOVE the sprint model. But only when its done correctly. And it allows people who are GOOD at running teams with it to very accurately predict deliverable dates, and allow hard choices on features. Add a last minute feature? Here is the points, and how it will impact delivery dates. And no those dates are not changeable. This is the delivery date based on 40 hour work weeks, and while you can get more productivity by doing overtime for a week or two, after that it negatively impacts things.
For planning its amazing. Slippage is seem quickly at the start and you can deal with it then when its easy.
But it requires your manager to push back on things-if they want a new feature it COSTS. If they want something done by X date-what will they give up. And those sprint point velocities? They are based on whats accomplished historically, not wishes or unicorn farts.
Good management makes sprints work. Bad management causes issues. Things your manager shouldn't say are: "Can you change how many points that is, we're in a rush" for example.
That is not my understanding that Sprint is Agile. But that was not the point of my argument. My point was that the Sprint model would be easy to abuse by having immovable deadlines to extract as much work as possible out of people. Certainly if a system is used in an ideal manner then it could be used well. However, a lot of these systems are used as management tools to just make people work harder and put in that all-important unpaid overtime work.
You don't know how it works. They can't extract any more work than what is planned and sized in a sprint. They don't needlessly pack sprints with an unreasonable amount of work. They would spread the work out to subsequent sprints.
You don't know how it works. They can't extract any more work than what is planned and sized in a sprint. They don't needlessly pack sprints with an unreasonable amount of work. They would spread the work out to subsequent sprints.
I do know how it works. That is if it is done in an honest manner. But I have seen quite a bit of this kind of manipulation in my 35 year IT career. Management is still the entity that runs the show and can tweak the system or the people any way it sees fit. Management frequently wants to "get its money's worth" out of its salaried employees who are not paid anything extra for overtime. I have had 5 IT jobs in my career. The management in all 5 of my jobs needed to see their employees falling over each other, working days, nights, and weekends trying to meet aggressive deadlines.
There are no absolutes. I am sure that there are companies that use this honestly. But there are those that don't.
Just because your team is dysfunctional doesn't mean the methodology is flawed. You seem to have a marked bias against offshore and/or Indian colleagues. They are not your problem. I've seen good and bad employees of all nationalities.
To be honest with you, I get the frustration. I've worked with countless offshore teams over the years. I think my current job is the only job that doesn't have an offshore team. It's not so much an issue with Indian employees. It's more of an issue with Indian management. They're big volume freaks, and typically in India anytime you can show that you're doing something high volume, you're mostly ok. Even if you absolutely suck, volume is all that matters to Indian management. I know this because I worked for 2 Indian firms in the past as well. So things like speed, shortcuts, a ton of lines of code, tons of commits a day are all metrics that Indian management go gaga over. Because volume is the most important thing, the quality of software tends to be really bad. There are some really good offshore developers, but they cost a pretty penny and a lot of companies aren't willing to pay it. So they often have a team full of mid level guys or freshers. And also communication in Indian culture is awful. But that's a whole different topic. As much as it is a developer to work with shoddy dev teams, I feel sorry for my previous managers. They're literally caught in the middle. They really can't manage the offshore teams (a lot of time different company altogether), so they can't fire them either.
To be honest with you, I get the frustration. I've worked with countless offshore teams over the years. I think my current job is the only job that doesn't have an offshore team. It's not so much an issue with Indian employees. It's more of an issue with Indian management. They're big volume freaks, and typically in India anytime you can show that you're doing something high volume, you're mostly ok. Even if you absolutely suck, volume is all that matters to Indian management. I know this because I worked for 2 Indian firms in the past as well. So things like speed, shortcuts, a ton of lines of code, tons of commits a day are all metrics that Indian management go gaga over. Because volume is the most important thing, the quality of software tends to be really bad. There are some really good offshore developers, but they cost a pretty penny and a lot of companies aren't willing to pay it. So they often have a team full of mid level guys or freshers. And also communication in Indian culture is awful. But that's a whole different topic. As much as it is a developer to work with shoddy dev teams, I feel sorry for my previous managers. They're literally caught in the middle. They really can't manage the offshore teams (a lot of time different company altogether), so they can't fire them either.
You've never witnessed dysfunctional American management? Otherwise, you can't ascribe the quality of management to them being Indian. There can be poor management in the US and offshore.
Maybe where YOU work...but where I work, our scrum master is a lazy, mouth-breathing moron. Our dev manager barely knows our names. Most of the stateside team are south Asian contractors who don't get to work until 5 minutes before the standup. The offshore team toils overnight and usually burns down far fewer hours than a reasonable person would assume they would because they're always "blocked" with nobody to clear the blocks for them since neither our dev manager or our scrum master has any regular communication with them. They leave it to a south Asian contractor working here in the building who speaks the same language to eliminate "communication issues."
It's a total train wreck.
From the looks of it, this project would have been a train wreck either way.
I have worked for 3.5 years in a well managed Agile project. This was the best managed project ever in my 11 years of experience. No rush to.meet deadlines, no last minute stress for other than a handful of occasions.
And the project was run on an onsite- offshore model.
I just read this and it's kind of funny. No, I'm not in software development, but our management has caught this whole Agile bug. Everything is Agile this and scrum that. Sprint? We're running a marathon as a series of random sprints on everything we do. Been that way since they caught this Agile bug a couple years ago. Everyone is exhausted and has reached the pretty much don't care point. Turnover is through the roof in an organization that used to have pride in the longevity and depth of knowledge in the workforce.
It's like living in a Dilbert cartoon every day where the Point Haired Boss has read some trade publication and learned a new word without knowing what it means. The only good thing is there will be a new, shiny, flavor of the month soon and they'll drop Agile and we'll be something else.
Please register to post and access all features of our very popular forum. It is free and quick. Over $68,000 in prizes has already been given out to active posters on our forum. Additional giveaways are planned.
Detailed information about all U.S. cities, counties, and zip codes on our site: City-data.com.