3 ms·

Seems as though this is rephrasing the old adage from small-a-agile "Individuals and interactions over processes and tools". Until we normalize asking "who is p

Seems as though this is rephrasing the old adage from small-a-agile "Individuals and interactions over processes and tools". Until we normalize asking "who is problem?" rather than "what's wrong with our process?" we're doomed to miss the mark. Excising counterproductive individuals will make any process work well. Discussing methodologies in isolation from individuals is a waste of time.

AnimalMuppet 4y ago
Interesting, but I'm not sure I agree. Your approach could easily degenerate into hunting for the scapegoat-for-this-reporting-cycle. But I will say that agile (real agile, not agile-in-name-only) demands quite a bit of discipline and maturity from your people. If you don't have the people for it, it won't work.
- HardlyCurious 4y ago
  Any methodology that requires discipline to work is a bad methodology. Trying hard ALWAYS works. That is how work got done before agile existed. The goal is to find a methodology that brings ease. So you can stop putting effort into the organization and meta work and instead put more effort into the work that actually brings value.
- thegrimmest 4y ago
  I think the costs of avoiding individual-oriented conversations are higher. Asking "which process is the problem" is rarely the issue. I can think of two sane guardrails that are usually applied for large-scale collaboration: 1) your team's code must have a clear, sane, documented interface/API 2) all teams should have a homogenous intake process for requests for change Everything else becomes a matter of either priority or performance. These areas are where changes have real impact, so it's better to focus the conversation there. > agile demands quite a bit of discipline I'd say small-a-agile requires more discipline from managers rather than staff/line employees. Namely, discipline to refrain from imposing significant process overhead on their teams so they have a better feeling of control and predictability. Manager-driven, observability-oriented process changes seldom give managers more actual control. Instead, managers should embrace the uncertainty that comes with software development, demand only to see real progress on working code in short intervals (no milestones, delivery dates, etc.), and set ambitious goals for their teams only in these intervals.

AnimalMuppet 4y ago

Interesting, but I'm not sure I agree. Your approach could easily degenerate into hunting for the scapegoat-for-this-reporting-cycle. But I will say that agile (real agile, not agile-in-name-only) demands quite a bit of discipline and maturity from your people. If you don't have the people for it, it won't work.

HardlyCurious 4y ago
Any methodology that requires discipline to work is a bad methodology. Trying hard ALWAYS works. That is how work got done before agile existed. The goal is to find a methodology that brings ease. So you can stop putting effort into the organization and meta work and instead put more effort into the work that actually brings value.
thegrimmest 4y ago
I think the costs of avoiding individual-oriented conversations are higher. Asking "which process is the problem" is rarely the issue. I can think of two sane guardrails that are usually applied for large-scale collaboration: 1) your team's code must have a clear, sane, documented interface/API 2) all teams should have a homogenous intake process for requests for change Everything else becomes a matter of either priority or performance. These areas are where changes have real impact, so it's better to focus the conversation there. > agile demands quite a bit of discipline I'd say small-a-agile requires more discipline from managers rather than staff/line employees. Namely, discipline to refrain from imposing significant process overhead on their teams so they have a better feeling of control and predictability. Manager-driven, observability-oriented process changes seldom give managers more actual control. Instead, managers should embrace the uncertainty that comes with software development, demand only to see real progress on working code in short intervals (no milestones, delivery dates, etc.), and set ambitious goals for their teams only in these intervals.