If scrum metrics are used to identify low performers then that's so bad it's not even wrong. The whole point of agile estimates is to teach the team to estimate and pay attention to it. It's a learning tool for the team.
Why do some developers consider Agile development to be nonsense?
61–70 of 147 posts
Re: Why do some developers consider Agile development to be nonsense?
#62Earlier quoted context omitted.
"Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.
It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?
If you are doing Scrum, the development team should be doing something like over 2 weeks:
Daily standup: 15 mins x 10 days = 150 minutes = 2.5 hours Backlog grooming: 0.5 - 1 hour Sprint planning: 0.5 - 1 hour Retrospective: 1 hour Demo: 1 hour
So about 5.5 - 6.5 hours of meetings over 2 weeks. If you're really militant, you can probably take it down to 4 hours, but I don't think you can get much lower than that without dispensing with formal Scrum.
It doesn't seem unreasonable to me to have 6.5 hours of meetings over 2 weeks.
Re: Why do some developers consider Agile development to be nonsense?
#63Earlier quoted context omitted.
It's not meant to be for that. It's meant to be let people know whats going on, because someone might know something that would save you time. I.e Collaboration.
I've been in a lot of standups and that's never come up. (Yes, I know, the plural of anecdote is not data.)
As a different anecpoint, that happens quite regularly for me.
Re: Why do some developers consider Agile development to be nonsense?
#64Earlier quoted context omitted.
Taking on a new development process in the middle of a project is much harder than starting on a new one. In particular, as you mentioned there's an issue of legacy bugs. There's mounds of information available suggesting strategies for taking care of this, but ultimately you'll be in an unfortunate transition while you're still handling legacy bugs that makes it hard to move forward. Most of my experience with agile…
> The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do. That sounds great on paper. However, every implemen…
Well, then, to give you a piece of anecdotal evidence; my experience where I currently am is that we never talk about how long it'll take, unless it's so small and trivial we can say "Give me an hour and I should have a first pass in place". Even then we're not saying it's ~done~, just that we're familiar enough with the code that we can get some prototypal code in place in a time frame. When actually estimating tasks, it's purely point based, and then those can and do vary with how much time they actually eat up, but tend to average out just fine.
Re: Why do some developers consider Agile development to be nonsense?
#65This matches my experience. We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's been about six months now and productivity has basically ground to a halt as we spend more and more meeting time endlessly sorting tasks into different little arbitrary piles instead of actually making forward progress. It's made communication with the non-softwar…
Taking on a new development process in the middle of a project is much harder than starting on a new one. In particular, as you mentioned there's an issue of legacy bugs. There's mounds of information available suggesting strategies for taking care of this, but ultimately you'll be in an unfortunate transition while you're still handling legacy bugs that makes it hard to move forward. Most of my experience with agile…
Legacy bugs? What the hell are legacy bugs?! What about, you know, normal bugs. Normal, unforeseen problems that happen all the time that you can't account for. Do you just add 25% time to any project to cover for those? I'm not sure how that solves the issue when you have to slice everything up into tiny chunks, where a few chunks could contain all of the unknown unknowns.
It's good to realize the known unknowns, but it's the other kind that will get you.
Re: Why do some developers consider Agile development to be nonsense?
#66Experienced engineers have seen a lot of "magic bullets" both on the process side and the product side. Generally they turn out to not be a substitute for hiring good people and getting good leaders to define a quality product and focus the team on what is important both short and long term.
+1. Attempts to Taylorise clue shall forever be with us.
Re: Why do some developers consider Agile development to be nonsense?
#67"Agile and Scrum, however, single out and humiliate anyone who works for 2 weeks and doesn't have something to show for it."
Holy crap, how wrong can some orgs go? The team should own the process. If there is R&D that does not match with scrum then the team should have a) a r&d framework or agreement in place b) the authority to say this is r&d.
The process does not own the team. The team owns the process.
Re: Why do some developers consider Agile development to be nonsense?
#68Earlier quoted context omitted.
It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?
I've been in standups that lasted an hour a day. That'll destroy your morale pretty damned quick.
They are doing it wrong. 8 people should not take an hour to say: What did I do yesterday, what am I doing today, is there anything blocking me?
There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch".
The standup is 10-15 minutes. If it is longer, it needs to be stopped. Period. Non-negotiable.
Re: Why do some developers consider Agile development to be nonsense?
#69Earlier quoted context omitted.
It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?
If you are doing Scrum, the development team should be doing something like over 2 weeks: Daily standup: 15 mins x 10 days = 150 minutes = 2.5 hours Backlog grooming: 0.5 - 1 hour Sprint planning: 0.5 - 1 hour Retrospective: 1 hour Demo: 1 hour So about 5.5 - 6.5 hours of meetings over 2 weeks. If you're really militant, you can probably take it down to 4 hours, but I don't think you can get much lower than that with…
Your backlog grooming is a bit to long. You should only be grooming 10-20 tasks.
Re: Why do some developers consider Agile development to be nonsense?
#70To go through some of the points I fundamentally disagree with:
"There is no place for an actual senior engineer on a Scrum team" - There absolutely is, who is peer reviewing the code, working with the BAs to design the architecture, identifying the technical dependencies in the backlog? Scrum is not a methodology for writing code, it is for getting a series of tasks done. All the things a senior dev needs to do on top of code can be broken into tasks, Scrum adds a weekly "is this still the most important set of things to be doing?" meeting into the mix.
"It's aggressively short-term, by design" - The whole post talks about 6 week projects. Scrum is terrible for that as it imposes far too many meetings. Scrum works for the complex space where you say "12-36 months" as your gut feel estimate. It is a reaction to the waterfall world where you'd discover 2 years in you weren't building what the business wanted.
"It has no regard for the programmers' career needs or desires" - Stories make for excellent opportunities for juniors to "own" bits of work from initiation to completion. Old school projects provided very little opportunity for juniors to work on requirements gathering and thus a big chicken and egg problem for promotion. It also offers plenty of opportunity to interact with your customers, which is almost always a good way to get promoted.
"The story points are there to track productivity" - Oh noes the people paying you want to know how long the project is going to take to be done. The talk of many status meetings seems decidedly anti-Scrum and is an excellent example of the sort of thing that people should be screaming about in retrospectives.
"It punishes R&D" - Ironically it can be a really useful opportunity to conduct R&D. Scrum makes you have something measurable and a time frame in which to conduct it, which makes for an easier sell than an open ended request. I think what annoys some is when they get shut down too quickly, or are forced into taking a less technically interesting approach that delivers enough business value. Scrum isn't there for pure research into the theoretical, but then no-one is claiming it is.
Killing businesses - Much like every tabloid headline everything can kill you. Value destroying mergers exist in abundance, and poor leadership/management is a real killer. Plenty of companies do very well out of Scrum, especially when they are in a cost centre environment.
I might sound rather "no true Scotsman" when it comes to Scrum but there are only a few things you need to do to be "doing Scrum". What it does give you is a powerful question to ask, and a regularly mechanism to raise it via the retrospective - "why are we doing X when it isn't in Scrum?".