Hacker News Reader

Comment by syndicatedjelly | Hacker News Reader

That's great that you've been doing things a long time, but it's possible to criticize the current state of affairs without invoking the whole "well do you want to just do what we did in 1980 again" argument. What was it that you were doing back then that was so bad? Can we avoid doing that, as well as scrum, and do something else, perhaps?

View on HN

Yes, and please offer that rather than just come saying "Scrum Bad." Just for a point of reference, people had said "Waterfall Bad" for 25 years before an alternative was presented. It took another 15 years after that before the alternative became wide practiced. Now here we are 15 years after adopting the alternative and saying it's bad. Yes, these discussions and laments go back for decades.

So add something to them instead of saying that the problems of Scrum don't exist because of your own dubiously stated experience.

> saying that the problems of Scrum don't exist

What OP wrote: "Scrum definitely has its issues and can be abused"

I think a big problem is that people seem to think of development as either "waterfall" or "scrum", with a gradient between the two. Being strictly on either side is seen as bad, and being a blend of waterfall-agile is bad too. All I can think of is to throw both out the window and figure out a different set of metrics to prioritize, other than the business-driven Time-To-Deploy-And-We-Make-Profit.

I don't have a perfect solution, but the best one I've implemented so far works only in small teams, and is effectively Kanban-driven development. I try to stay close to The Toyota Way, which I learned while working in medical device (where they, like aerospace, draw a lot of inspiration from our industrial engineering forefathers).

I guess my solution is - create many small teams, let them implement "lightweight scrum" where the Kanban board is the main discussion point every day. What tasks are pending, what's next, what is stuck? And finally, let the small teams throw away anything they don't like, including the board, as long as they meet their deliverables defined by the broader team.

Is this too Scrum-y still? Maybe. But Scrum has lost its way and its time to just return to the basics and implement stuff that's worked for decades in other industries. Software Engineering had its chance to play around and re-invent the wheel, going all the way back to Fred Brooks Mythical Man-Month. The industry has had 50 years to get its shit together, which is an absolute eternity and inexcusable for how shitty a state of affairs we have now, in terms of program management philosophies. Frankly I'm interested in just using the original wheel at this point, where we assign tasks to teams and estimate them USING REAL TIME ESTIMATES (not story points like we are fucking fairy tales).

I care more about making high-quality software and less about management philosophies these days.

More about my rant here - https://www.ashwinsundar.com/story-points-stupid/

Ironically, the 1970 Waterfall paper proposed a better alternative (that was mostly ignored).

Many people in the 80s and early 90s tried that alternative. It worked very well for smaller projects, which frankly, was the point. Take the big project and break it into little projects and then utilize a strike team to implement each of the little projects. The approach was decent, and still is!, it's just combining a bunch of little projects into a big project and managing the overall big project is challenging. That's the rub - small projects don't need much management at all, medium projects benefit from existing methodologies (whether they're "good" or "bad"), but large projects are a challenge no matter what you do. You can make them less challenging, but they're still challenging.

Reply on news.ycombinator.com