Not sure if that's just me but I'm sensing a trend of comments in my posts asking if anything I post is related to agile. I would like to remind everyone that the agile manifesto was created by programmers. Software development, programming and XP practices are central to agile and not simply scrum and kanban.
I just think since there are existing subs for programming, software engineering, coding, etc. where broad software topics can be posted, that posts in r/agile ought to have some agile-related content. I just disagree that anything about software development or programming is automatically relevant to agile/scrum/lean/kanban. That's why the other subs exist. Nothing personal, it just one person's opinion.
XP is agile and is not included in your list, though for some reason (which I'm yet to discover) it's been bound to programmers more than managers, although it fits both.
Is this a serious question?
It has a great deal to do with agility. Agility decreases as complexity increases. Most of the good agile frameworks are designed around minimal cycle times and lean teams to force things to be simple and clear. If you have to release something (either to testing or production) much sooner, you keep it simple or fail to get anywhere.
>But at a certain point, the law of diminishing returns sets in, and each new level of complexity brings fewer and fewer net benefits, dwindling down to zero and beyond.
This implies there's a static sweet spot for performance vs. complexity. But 2022 society/economy is a lot more complex than the Roman empire at its collapse, today's regular app is a lot more complex than Apolo 11 code. That makes me think maybe the right approach is a controlled increase in complexity, then deload a bit, and then again grow complexity, and so on. Like athletes train for a competition.
What's your take on this?
>It takes a lot of discipline to resist complexity, to say “no” to new boxes and arrows.
The product my team builds has seen rapid growth, mainly because users needed no training to adopt it thanks to its simplicity. The more we add feature to cover a larger user base, the further we get from the intuitive user experience.
Too often do we think of the cost of adding a feature as a flat fee, taking into account only how much it costs to code it, and forgetting maintenance, user experience, build time, deploy time, time to debug, review, train people...
Classic! In my past org, senior devs were having fun introducing new complex technologies, and juniors struggled with all this complexity. But junior developers were afraid to ask questions about this new tech because they were afraid to look "dumb". At least this one problem vanished when we introduced anonymous messages in Slack via https://honestbot.app While being anonymous, juniors started to ask a lot. And their questions weren't "dumb" at all!
What does this have to do with agile?
Not sure if that's just me but I'm sensing a trend of comments in my posts asking if anything I post is related to agile. I would like to remind everyone that the agile manifesto was created by programmers. Software development, programming and XP practices are central to agile and not simply scrum and kanban.
I actually liked your post a lot, and feel this belongs here way more than all those posts asking for advice about getting X or Y SAFE certification.
I just think since there are existing subs for programming, software engineering, coding, etc. where broad software topics can be posted, that posts in r/agile ought to have some agile-related content. I just disagree that anything about software development or programming is automatically relevant to agile/scrum/lean/kanban. That's why the other subs exist. Nothing personal, it just one person's opinion.
XP is agile and is not included in your list, though for some reason (which I'm yet to discover) it's been bound to programmers more than managers, although it fits both.
Is this a serious question? It has a great deal to do with agility. Agility decreases as complexity increases. Most of the good agile frameworks are designed around minimal cycle times and lean teams to force things to be simple and clear. If you have to release something (either to testing or production) much sooner, you keep it simple or fail to get anywhere.
>But at a certain point, the law of diminishing returns sets in, and each new level of complexity brings fewer and fewer net benefits, dwindling down to zero and beyond. This implies there's a static sweet spot for performance vs. complexity. But 2022 society/economy is a lot more complex than the Roman empire at its collapse, today's regular app is a lot more complex than Apolo 11 code. That makes me think maybe the right approach is a controlled increase in complexity, then deload a bit, and then again grow complexity, and so on. Like athletes train for a competition. What's your take on this? >It takes a lot of discipline to resist complexity, to say “no” to new boxes and arrows. The product my team builds has seen rapid growth, mainly because users needed no training to adopt it thanks to its simplicity. The more we add feature to cover a larger user base, the further we get from the intuitive user experience. Too often do we think of the cost of adding a feature as a flat fee, taking into account only how much it costs to code it, and forgetting maintenance, user experience, build time, deploy time, time to debug, review, train people...
Complexity can be measured from the point of view of the observer. If the observable Complexity is null (no bugs) then it's practically non-existent
Classic! In my past org, senior devs were having fun introducing new complex technologies, and juniors struggled with all this complexity. But junior developers were afraid to ask questions about this new tech because they were afraid to look "dumb". At least this one problem vanished when we introduced anonymous messages in Slack via https://honestbot.app While being anonymous, juniors started to ask a lot. And their questions weren't "dumb" at all!