201–210 of 223 posts
Earlier quoted context omitted.
Counterexamples: John Lennon, Sting, Eric Clapton, Neil Young, Phil Collins, Lou Reed...
They're the exceptions to the rule, the converse happens far more often.
Then, development becomes ticket driven instead of engineered.
I have seen scrum used successfully where an engineering process was placed in front of the backlog ala Feature Driven Development.
There is a ticketing system, but it is kept separate from the work planning system.
Earlier quoted context omitted.
> One of the one hand, the development team getting to control the estimate helps to control the workload. I think that's a kind of waterfall strawman. In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.
> In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise. I studied engineering in university and profs had plenty of stories about bosses sending business analysts to look at similar projects, generating a time estimate from those projects, and then send that estimate to the engineers as their deadline for completing the project. It being insane doesn't stop people.
So if you take an estimate and turn it into a deadline, in the perfect case, the deadlines can only be made 50% of the time.
Of course, in practice there is bias, there are things you forgot to include in the estimate.
Earlier quoted context omitted.
> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) This has benefits and downsides. One of the one hand, the development team getting to control the estimate helps to control the workload. On the other, I agree. Why are we pulling estimates of effort out of thin air? Why are we being asked how long it will take to do work in sections of code we have never seen? Planning…
If you have no idea what the task list is before the planning meeting I'd say you definitely need to get your process changed. That's astonishing.
Still estimates are considered extremely important...
Earlier quoted context omitted.
1) Communicating is part of the job 2) Don't think about it in terms of 'failure'. You're just doing work. Sometimes the route is direct, sometimes it's not. 3) 'Time boxing' really has to be done, because products are not made in a vacuum. Time is money and it's a huge constraint. So everything really does have to be boxed up and parameterized by 'time' in the most reasonable means possible that doesn't screw everyt…
1) They were disputing scrums, not necessarily communication. 2) It's hard to not think of something as failure, if it's treated as failure, which is often the case. This is like telling someone who's being mistreated in a relationship to not think of it as abuse, just think of it as your way of life. 3) Time boxing may be important if a number of different types of schedule conflicts may arise, but I think it can pl…
We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because i…
>that ideal software development is just a continuous production This ! Can't agree more... Scrum always made me feel like a production-line-worker making shoes... No craft nor space to discovery/explore problem solving. Urg and all those damn meetings and pulling numbers out of thin air ! What a waste of time those meetings were !
Earlier quoted context omitted.
The only potential result of a competently run scrum process is exactly that - a process that was designed by the team. If you are stuck in some weird cargo cult that doesn’t allow the team to iteratively change the process, you should call bullshit.
If scrum is any process designed by the team the term is worthless. Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile. Scrum is just flawed from the foundations for anything but very routine work where you can somewhat estimate subtasks duration with any accuracy. But if your job is that easy you hardly need any fancy process anyway.
SCRUM is a handful of tactics that a team can start off with to design and implement the “right” process for a given team. For example, I’ve been on several teams where through the use of retrospectives, daily stand ups were abandoned and replaced with other means to keep the team in sync.
> Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile.
That sucks, but sadly this is the most common case. Very few organizations actually want agility, as they are culturally and practically top-down hierarchies that require command-and-control structures to function. These consultants are generally brought in by middle-management who are grasping at straws without any real buy in from the c-suite.
> Scrum is just flawed from the foundations for anything but very routine work where you can somewhat estimate subtasks duration with any accuracy. But if your job is that easy you hardly need any fancy process anyway.
I couldn’t disagree more. For “routine” work that is predictable, what value does agility provide? It’s either done correctly or not. Agility is only useful in dynamic environments when outcomes are hard to predict and there is limited prior art to reference.
We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because i…
>idea that ideal software development is just a continuous production of small improvements to the code. Many of us do believe this. Absolutely. >It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. But on the flip side, if you get it wrong you waste an inc…
I think it is empirically not true, if you look at your Github history for example, sometimes you produce less change and sometimes a lot more. It corresponds to the fact (or at least a feeling) that some things are clear and can be easily done while some require some thinking or experimentation before they can be done.
And it's even less true if you restrict the requirement to only functional changes to the code (not just refactorings or productivity improvements or code reduction with preservation of the functionality). These things have to be mentally planned even more and that requires even longer periods of apparent inactivity.
> The smaller the steps you take, the smaller the risk you step in the wrong direction.
I don't think that's how it works. Risks are risks, whether you're taking small steps or not. If you don't know if your DB will break at 1000 users, it's a risk regardless how small steps you take to introduce the DB to your code.
Personally, I prefer to attack the biggest known risks first (for example, make prototype, measure it). But that flies in the face of other Scrum requirements, like getting some feature completely done in smaller chunks.
We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because i…
> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss. Curious about that point because for many engineering tasks the variance in the estimates is so big that I wonder whether any formal way of estimation actually works. I did some analyses on the correlation between estimate and actual development time in a project I worked in and the correlation was…
I agree that it is a legitimate concern, I certainly do not advocate a position that software cannot be estimated or planned at all. I think it can be, but only up to certain time granularity, where the attempt to gain understanding for a sensible estimate (and describing what needs to be done) becomes essentially comparable to writing the code in the first place.
I actually have an underdeveloped idea how we could have a completely formal approach to tackle uncertainty in SW development, but it is purely theoretical so far (using a combination of functional programming and information theory).
We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because i…