Nothing can replace Will and Wisdom
Scrum is fragile, not Agile
241–250 of 329 posts
Re: Scrum is fragile, not Agile
#242Earlier quoted context omitted.
If you can say more than a minute, but less than a decade, you've already got SOME idea of the timeframe for a task. Granted that sort of estimate would get you called to HR for insubordination. But can you pull the bounds in from either direction at all? I say this as someone just moving into project planning and management. From that perspective you start to see that some level of estimation s critical. My preferen…
One manager I’ve worked with had the brilliant notion of “x2+1” time of what the dev says. Anecdotally this has worked out remarkably well throughout my career - from single dev to cto - even stuff that I _new_ was going to take for example 2 days, if done properly ended up in like 5. Didn’t matter if I was doing the estimate or someone else. At some point I just gave up and started doing the “my gut says 3 hours, so…
I remember sitting in a meeting with the team discussing how we regularly failed to meet the our estimates and how this was bad.
I made exactly this suggestion and was laughed out of the room.
Granted this was for large and small estimates, but I still don't think it's the worst idea.
Re: Scrum is fragile, not Agile
#243Re: Scrum is fragile, not Agile
#244Earlier quoted context omitted.
Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects. You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration." That caused so many…
For every example of scrum operating badly there are examples of scrum working well. The common denominator in all of those situations - good and bad - is the project and middle/upper management.
In business process analysis, when a process is dependent on individual people, you don't have a mature process but an ad hoc process.
In other words, Scrum methodology in itself is not mature as a methodology and depends on individual fiat, just like any project that doesn't have any process at all.
The only tangible benefit to Scrum might be paying lip service to development departments while firmly retaining the status quo.
Re: Scrum is fragile, not Agile
#245He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…
Scrum is badly misunderstood and maybe that's a failing in and of itself but it's really a victim of the developers who sold it as a magical process. Scrum simply can't be implemented as a purely developer process. The backlog exists as a rolling contract between dev and product owners and sponsors. The most common failure I see is when project leadership agrees to a fixed scope and timeline then tries to execute in…
>Scrum simply can't be implemented as a purely developer process.
aka, WaterAgileFall.
Re: Scrum is fragile, not Agile
#246Earlier quoted context omitted.
The rationale is that if you minimize latency, throughput has to be maximum too, so optimizing latency is enough. In practice latency is the goto target for optimizing actual processes. It's the most linked with all the risks. But software development is not an actual process.
> The rationale is that if you minimize latency, throughput has to be maximum too Exactly. And it's quite wrong even without taking the growth of complexity into account — as every engineer knows, or should know. Getting every task done as quickly as possible requires a lot of context switching, which is murder on throughput. When you add in the effects of complexity growth (aka technical debt, though I think "comple…
It is basically correct, as the math does add up. As yourself pointed, if throughput isn't optimized, latency goes to hell. Thus minimized latency leads to optimized throughput.
The problem is that except on the bare minimum, latency is a bad proxy on development projects. So the idea is perfectly correct, yet it's useless.
Re: Scrum is fragile, not Agile
#247> "We are simply caught in a rat race and not able to make a short break in order to look at and learn from all the things that happened around us, maybe even before our time."
But isn't that exactly what Scrum wants you to do? After every sprint, you spend some time to reflect, look at how you're working, look at the bigger picture, etc.
Scrum is by no means perfect; it's a tool, not the infallible silver bullet the author wants it to be. If you misuse the tool, you're still going to get wrong results, but that's the same with every other method.
The real question is: is there a better way to do it that can easily and reliably be implemented by large corporations? I think the popularity of Scrum is probably due to it being more successful than what was used before.
It might not be truly Agile, but for large corporations, being truly Agile may be a bit much to ask. They need reliability and reproduceability, and that means they're always going to need some focus on processes and procedures, and can't always rely on people who might leave or have something happen to them. Not that Scrum is always a good fit for those processes and procedures, but it does help make it appealing for large companies, and at least it puts a good part of the process in the hands of the people who will be using it.
tl;dr: Scrum is not perfect, but what is?
Re: Scrum is fragile, not Agile
#248Earlier quoted context omitted.
For every example of scrum operating badly there are examples of scrum working well. The common denominator in all of those situations - good and bad - is the project and middle/upper management.
In business process analysis, when a process is dependent on individual people, you don't have a mature process but an ad hoc process. In other words, Scrum methodology in itself is not mature as a methodology and depends on individual fiat, just like any project that doesn't have any process at all. The only tangible benefit to Scrum might be paying lip service to development departments while firmly retaining the s…
Scrum is no more or less dependant on individual people as any other methodology.
The rest of your post is just warping your initial conjecture to arrive at conclusions you'd already decided upon. I neither agree with those conclusions nor the chain of twisted logic you used to arrive that.
I'm not going to stand on a soapbox and sing for the glory of scrums. People - like yourself it seems - can get very tribal when talking about such things. Which is as weird to read as it is pointless for you to argue. In my experience leading different teams using different methodologies, the thing that really makes the big noticeable impact is people and not methodologies. If you work in a blame culture or have colleagues in your team who don't follow process - then whatever process you put in place will be undermined at every opportunity regardless of it's methodology. However if you work in an environment where people respect one another and want to collaborate in getting work done, then you pick a methodology that works best for the day to day work (eg project work or support operations) and for the way people like their work organised. All the rest of the arguments are superfluous.
Re: Scrum is fragile, not Agile
#249He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…
> On average, the first priority of managers and execs is maintaining the power structures that make them a big deal. But true Agile processes are about empowering teams to self-organize around serving users.
But that doesn't explain the success of Scrum, because Scrum does away with the power structure of managers, and should empower the teams. "We're doing Scrum now" is the big stick I see scrum masters use to beat back Business managers to keep them from interfering with and micromanaging the team.
At least, that's what they should be doing when management interferes too much. And then address this higher up with whoever decided that we're doing scrum now, and explain to them what that means, if necessary.
There's no excuse to tolerate micromanaging managers in a Scrum process. They don't belong there. Kick them out.
Re: Scrum is fragile, not Agile
#250Earlier quoted context omitted.
I have almost never seen Scrum sold as magical by developers . Executives? Yes. Consultants? Yes. But developers? I agree that fixed-scope contacts cause a lot of problems for Agile approaches. However, they also cause a lot of problems for non-Agile approaches. If I have to deal with supposedly fixed-scope situation, I'm going with and Agile approach. There are two basic cases. One is that scope is truly fixed (whic…
> I have almost never seen Scrum sold as magical by developers. Executives? Yes. Consultants? Yes. But developers? In many places, especially smaller ones, project managers are also developers (or lead developers etc), and they often drink the Scrum kool-aid.
Seconded. I've also seen it promoted by developers who are in what one could call a "honeymoon period" of their careers. First or second job, probably learned programming at university so every task is an interesting challenge, SCRUM is their first agile methodology, they don't have enough broad knowledge about programming and the industry to become disillusioned and cynical. I've had such people evangelize SCRUM to me, with pride in their eyes, like it was the best thing since sliced bread.