Hacker News new | past | comments | ask | show | jobs | submit login

> "Conclusion

If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies. It’s a hard pill to swallow, but there just aren’t many companies doing it right. Luckily, I am guessing it is easier to teach business to a programmer than the other way around. Think of it this way: it HAS to be better than doing Scrum!"

===

My previous comment on the subject still seems appropriate.

https://news.ycombinator.com/item?id=41080195

The big problem is "How do I connect the money to the work". In large corporations, this becomes project -> plan -> work. The project gets a budget based on the plan, then you do the work based on the plan. The problem is the link between plan and work. As you work, you learn. That is the primary activity of software development. Learning is a menace to planning. As you learn, you have to replan, but your budget was based on the original project plan.

You can talk about engineering and culture and whatever you want, but if you're working for money, the problem remains of connecting the work to money and the money to the work.

I'm reminded of the Oxygen Catastrophe - https://en.wikipedia.org/wiki/Great_Oxidation_Event - we need oxygen to live, but it also kills.




> Learning is a menace to planning

Ooh, that's a cool thought that the more learning needed, the more planning is hard. True, and I haven't put that together before.


Scaled Agile Framework (SAFe) deals with that by funding value streams instead of projects.

https://scaledagileframework.com/lean-budgets/


Yes, SAFe does attempt to deal with this issue, but it's like moving food around on your plate - it's still there, and management still wants to tie activities to budget.

Whatever framework or philosophy or concept you use, it gets implemented by people in an organization.

If that organization is new and growing, it is graded by things like active user growth (top line); if that organization is established, it is graded by profit (bottom line).

The journey from top line to bottom line is where all the complications come in.

So I think the author is correct in their conclusion [0], but not in depth.

0. Engineers will tend to be sad in established orgs [cost centers], and happy in new orgs [product development].


SAFe, as I have seen it practiced is just waterfall by a different name.


It it certainly possible for incompetent managers to misuse SAFe, as with any other methodology. I've seen that if actually implemented as written it tends to work pretty well in large enterprises, at least in the sense of being the least bad option that allows product delivery with the level of consistency and reliability necessary to meet external commitments. Comparisons to "waterfall" are a rather silly strawman.

Do you have a specific criticism of the SAFe budgeting model, or a specific alternative to propose?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: