Live data from Hacker News

Scrum is fragile, not Agile

dennisweyland.net

281–290 of 329 posts

Re: Scrum is fragile, not Agile

#281

Earlier quoted context omitted.

What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"? And could you point me to examples of people losing their Scrum certifications for not living up to that standard?

This is the great con of scrum certification — you can always point to some team and say “well that’s not the official version of scrum”

Which is a really impressive con. Generally the point of certification is to make clear you're getting the official version. E.g., doctors and lawyers self-police because they know it's harmful to have quacks running loose. But somehow Scrum has been able to keep making money despite not bothering with that.

Re: Scrum is fragile, not Agile

#282

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…

It sounds like you're missing probably the most important part of agile which is "at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly".

In Scrum, it's retrospectives.

Continuous improvement is a theme that runs across agile, scrum, lean. Without giving feedback, how are you going to improve?

Re: Scrum is fragile, not Agile

#283

Are we still talking about these dated concepts? Agile is a mindset. Understand the mindset, absorb it, make it yours, and build the process that's working for you based on that mindset. Stop complaining about Scrum, it's just a tool, and tools deprecate.

Yep, I've never been in a team where the process was not a regular topic of debate. Once it stops being a topic of debate, it actually just means people are no longer adapting. I prefer a good dose of pragmatism here. Changing the rules all the time is very draining on team morale. Similarly not adapting to obvious process issues is equally demoralizing.

Since everyone is doing, or claims to be doing, agile, the whole notion is completely meaningless. Unless they are actively advertising to be doing some form of waterfall, you can safely assume there is some notion of iterations involved.

What matters more these days is whether the team is mature enough to have continuous deployment without process bureaucracy. Deployment fear is a good sign the process sucks. If you have a need for human gatekeepers, something is wrong with the test automation. Deploying often and with confidence is a good sign you are dealing with a smoothly running team.

Re: Scrum is fragile, not Agile

#284
I wonder what happened to so many developers that turned them so jaded and cynical towards scrum and project management. So far I've dealt with the good and bad of scrum with a good pinch of horrendous PMs in the mix, but I still came out of it with a positive view of the framework. It is hard to run it somewhat smooth and takes lots of motivated people to accomplish[1], but the result had a positive impact on my day-to-day work.

1 - Some people said that this can be a failing of scrum and I 100% agree.

Re: Scrum is fragile, not Agile

#285

Earlier quoted context omitted.

They did, and I replied "We don't know because we've never done this before, and we can only compare to the most similar work we've done, and any existing data." Before I could say more, they I interrupted: "You have to know, it's your job, or you don't know what your doing," or something along those lines. It was the most heated I've felt. I know what I'd reply with today, but I was younger and more naive then.

What would you reply today?

"Yeah, well I had sex with your wife!"

Or just offer over-inflated estimates since they won't accept something realistic anyway.

Re: Scrum is fragile, not Agile

#286

Earlier 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.

> good and bad - is the project and middle/upper management. Yep. People do not realize that the whole company has to adopt agile/scrum for it to work. It's a shift that many companies can not or will not make. They are tied to fixed deadline, fixed scope for various reasons.

I mostly agree with you but I wouldn’t go so far as to say the whole company has to adopt it. However you do certainly need the support from the wider company. I’ve seen scrum work really well despite waterfall being the predominant methodology in that business - there people were happy to embrace the preferred working styles of whichever team they had to liaise with. I’ve also worked in places where scrum failed badly despite the CEO pushing for it. Those places usually suffered from a blame culture that was also the CEOs doing and that blame culture meant that everyone was spending their time working against the best interest of any of the other teams. By “teams” I mean project managers, sales guys, support or operations teams (if they differ from your developers and/or DevOps), finance staff, directors/upper management and even your own paying clients (if you’re a hired service) etc.

I’ve noticed comments for and against scrum are often so focused on the technical aspects of the methodology that they overlook the human aspect. Which matters more in my opinion.

Re: Scrum is fragile, not Agile

#287

Earlier quoted context omitted.

The biggest problem with Scrum is it lacks any sort of design phase. You do the minimum. Oh, it doesn't work quite right? We'll fix it in the next sprint... The "spiral" model is closer to a true iterated waterfall. I've seen it used successfully in more mature companies.

You're confusing "investing in design" with "having a design phase". I agree many Agile teams underinvest in design. But so do many non-Agile teams. The problem isn't the lack of a formal phase. The problem is not taking it seriously.

You get what you measure and Scrum has no measure at all for design. I’m now curious to see some projects that Ken Schwaber worked on.

Re: Scrum is fragile, not Agile

#288
post #31

Earlier quoted context omitted.

Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product wo…

I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed. Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.

All straight out of the TDD playbook.

A lot of devs trap themselves by insisting they can write the tests after. Once managers know the code exists they want to use it, or move on to the next thing people are breathing down their necks for. And code written without tests is difficult to test so becomes a self fulfilling prophecy.

In fact it’s such a reliable mechanism for self sabotage that I look at carefully at people who bring this on themselves and try to figure out if it’s naïveté, learned helplessness, or malice.

Re: Scrum is fragile, not Agile

#289

Earlier quoted context omitted.

Have you seen any methodology work consistently when dealing with fixed deadlines? The reality when dealing with large contracts, as you mention, is that there are almost always timetables with expectations. This poses an inherant problem due to the unreliability of estimates, so either quality or features must be sacrificed if the timeline is in jeopardy. My only experience in such an environment was using some hybr…

Nope, never. I have seen more success in cases where teams estimate for 90% percent confidence instead of 50% confidence. By that I mean "it should almost never take longer than that" vs. "it will probably take that long." Unfortunately, to do that, you need enlightened business management that appreciates the difference between an estimate and a promise, as opposed to business management that pays lip service to the…

> "it should almost never take longer than that" vs. "it will probably take that long."

This sounds like a much better way to estimate. Do you have any links to content discussing this?

Re: Scrum is fragile, not Agile

#290

Earlier quoted context omitted.

Depends. Are we talking self-esteem/dignity points, or good doggie/loyalty points?

I'd guess career-progression points, or even keep-getting-a-paycheck points at worst.

This low-stakes exchange won't affect much, it's about putting Mr. Incomp in his place. Remember it's a PM we're talking about, not "the Boss."
Post reply on HN