191–200 of 292 posts
3 weeks of clearly defined goals and progressive load, followed by a "deload" week where you're not sitting around doing nothing, but you're lifting lighter weights to let your body recover.
Makes sense to me, because whether you're lifting weights or working on software, stress is stress and probably follows the same patterns of progressive overload and recovery.
Earlier quoted context omitted.
The business wants to know how much feature X is going to cost and when they can expect it. They need to know that, because they need to decide if it's worth it in the first place, or because they need to plan follow-up actions for when the feature will be done. If the developer doesn't make estimates, you're just forcing other people to make their own estimates, that they'll hold you to.
Another bit of wisdom I got from Kent Beck is that there are three basic controls to every project... schedule, scope, and resources. You can only control two of them. And resources are generally fixed at the beginning of the project(1), so most projects are either scope-bound (we must have all these features), or schedule-bound (we must hit this hard date). If you're feature-bound, estimation failure means you'll be…
Schedule-Bound development (or Deadline Driven Development) can actually work well with minimal estimation as long as you are truly building MVP (minimum viable product), you have to ruthlessly slash features and only build the core features that are going to deliver the most bang for the buck.
Not easily done.
Earlier quoted context omitted.
Only issue being that the estimates one gets from poorly planned sprints are probably less reliable than just asking the devs how long the project will take and going with it.
Good estimates come from watching people deliver over time and scientifically comparing empirical performance to subjective estimates, not asking them to predict. Joel Spolsky has a great blog post on Painless Software Schedules.
Earlier quoted context omitted.
Its never the wrong socialism. Maybe actual agile as imagined is incompatible with captialsim and human nature?
Would you prefer the centralized planning model of waterfall? Of course none of these systems are perfect, but it's been a major step in a better direction for everyone involved.
I want a process that reacts to the situation, in favour of the product, in favour of longterm goals - who actively resists people who try to gamble it for whatever reason. Agile is not that.
Earlier quoted context omitted.
I agree. I didnt read that as an invitation to take 5 days off every month, therefore advocating 60 additional holidays in a year. I saw it more as an opportunity to catch up on "other stuff". Maybe a tool you wanted to work on to make your work life easier, or leave a little early to wrap up taxes, or do some PoCs etc. to see whether a refactoring idea you have is actually feasible or not.
Yes, this is more along the lines of what I'm talking about. I'm advocating common sense over religious adherence. Do what works for you. I am saying there's a lot of burnout in the tech industry and it's at least partly a process problem. Maybe it's just me and I'm "doing it wrong", but I think it speaks to the issue that the suggestion of "taking it easy a week out of every month" is met with cries of "This is madn…
https://en.wikipedia.org/wiki/Kanban_(development) https://en.m.wikipedia.org/wiki/The_Toyota_Way
But lets reenvent the agile wheel a thousand times. We have no other problems to solve.
Where do I find a company implementing this brand of agile..?
Earlier quoted context omitted.
It's not impossible to estimate roughly how long something will take. If you consistently get it wrong, either: 1. You're not breaking down the work into small enough chunks to properly think about how long it will take 2. You are probably consistently under (or rarely over) estimating and should be able to fix that. For me, I have to triple my estimates, it always takes 3 times longer than I think it would To claim…
Advocating process solutions over people solutions is precisely non-agile. If people are burning out, then you need to address that. Estimation is hard. Accurate estimation is even harder. Doing it in the face of noon stationary scope is a fools game. Who is in charge of estimating how long it will take to correctly break down a problem into accurately estimable sizes?
If something costs 15k instead of 10k, that's understandable, if you estimated 10k and it ultimately costs 1.5 million to develop, obviously not.