5 ms·

Well in addition to the four values there are also 12 principles of the agile manifesto. And agile leaves plenty of room to deal with the issues mentioned. The

Well in addition to the four values there are also 12 principles of the agile manifesto. And agile leaves plenty of room to deal with the issues mentioned. The actual problem with agile, as I’ve seen first hand, is that teams adopt Scrum as if it’s some Agile Silver Bullet. If you just do what you’re told by the CSM, then projects will go better. This is especially true when there is a power imbalance, developer problems are swept under the carpet, and retros are discouraged or non existent. It’s nonsense. Like all practices, there are all sorts of problems intrinsic to Scrum that need to be considered carefully and resolved. How do you manage a large backlog? How do you deal with unexpected complexity discovered at the very start of a sprint? Where are the overall project goals documented - and how do we measure against them? This is not to say that these problems can’t be dealt with in scrum. The Agile Manifesto leaves plenty of room for resolving them, but Scrum is being taught by many as the One True Way, and if you dare suggest changes or deficiencies in the process then you just Don’t Get It. It’s the rigidity of these practices that has become the problem - the way I’ve seen Scrum implemented in several large projects is effectively waterfall with a scrum veneer. When you’ve been shipping software for more than the length of your adult life, it gets tiresome to have someone with a dodgy certification in agile project management explain how to ship.

calvinmorrison 3y ago
The backlog helps solve problems above my team not for my team. I tick tok between sprint planning and kickoffs with developers. My superiors need to prioritize and literally rank the stuff they need done. Otherwise everything is a priority and nothing gets done.
- doctor_eval 3y ago
  Well, as the Manifesto says, "Business people and developers must work together daily throughout the project." But Scrum's approach to this is overly simplistic (product owners?), backlog reprioritisation is not part of Scrum, and in any case you really ought to have some control over priorities because doing certain stories in the wrong order will reduce productivity. The problem that I'm pointing out is that Scrum has become synonymous with Agile in many quarters, and yet it is far from a complete solution to software project management. It's not that Scrum is no good, it's that it's not enough (or, in some cases, too much). When I've been forced to use some BigCo's rigid version of "Scrum", it's always been a nightmare. Of course it was, because rigid is the opposite of agile.
dasil003 3y ago
The reason this happens is because most people just want to know what to do next, and not have to fret over higher order problems which A) require deeper expertise and reflection to analyze and B) they may not have the agency and influence to improve anyway. This leaves the door open to the snake oil salesmen ("agile" consultants) who promise the One True Way™. The reality is that well-tuned processes can reduce cognitive load in day-to-day work, freeing up mental cycles for higher level problems. But process also adds overhead and rigidity, so it needs to be tuned to the environment at hand and reevaluated regularly. This can't be done be done by a drive-by consultant or a detached manager, it requires boots on the ground context and applied expertise to relate the day-to-day reality to the highest order business goals. Anything short of that is MBAs and juniors clinging to an arbitrary process as justification for why they are delivering adequate, but not exceptional results.
- doctor_eval 3y ago
  Yes, I agree with everything you've written. The problem is not processes like Scrum, it's the fact that many of the people who are in roles that are ostensibly responsible for "fret[ting] over higher order problems" actually don't care about that. They get paid regardless of how productive everyone else is, and in my experience they get paid more if they implement "best practices"... which are practices designed by marketing teams to sell CSM courses.
- avereveard 3y ago
  The reason this happens is that management is secretly hoping that using a process will allow them to do get by with junior developers because the software complexity will be magically handled by "The Process" I honestly don't blame them for trying to industrialise software production, I blame the engineers which is probably the only white collar profession that don't care about being in control of their own field narrative
  - steveBK123 3y ago
    This was readily apparent at my last shop when we had a range of junior (months out of college) and seniors (20+ years experience), and the expectation was simply that seniors were to clear more tickets/points per sprint. We didn't allocate more architectural tasks to seniors, or pair them with juniors, or give them long running slices of work across sprints.. we just were like "more points please". We ended up with under-engaged seniors all leaving, and juniors being given tasks they couldn't accomplish.

calvinmorrison 3y ago

The backlog helps solve problems above my team not for my team. I tick tok between sprint planning and kickoffs with developers. My superiors need to prioritize and literally rank the stuff they need done. Otherwise everything is a priority and nothing gets done.

doctor_eval 3y ago
Well, as the Manifesto says, "Business people and developers must work together daily throughout the project." But Scrum's approach to this is overly simplistic (product owners?), backlog reprioritisation is not part of Scrum, and in any case you really ought to have some control over priorities because doing certain stories in the wrong order will reduce productivity. The problem that I'm pointing out is that Scrum has become synonymous with Agile in many quarters, and yet it is far from a complete solution to software project management. It's not that Scrum is no good, it's that it's not enough (or, in some cases, too much). When I've been forced to use some BigCo's rigid version of "Scrum", it's always been a nightmare. Of course it was, because rigid is the opposite of agile.

dasil003 3y ago

The reason this happens is because most people just want to know what to do next, and not have to fret over higher order problems which A) require deeper expertise and reflection to analyze and B) they may not have the agency and influence to improve anyway. This leaves the door open to the snake oil salesmen ("agile" consultants) who promise the One True Way™. The reality is that well-tuned processes can reduce cognitive load in day-to-day work, freeing up mental cycles for higher level problems. But process also adds overhead and rigidity, so it needs to be tuned to the environment at hand and reevaluated regularly. This can't be done be done by a drive-by consultant or a detached manager, it requires boots on the ground context and applied expertise to relate the day-to-day reality to the highest order business goals. Anything short of that is MBAs and juniors clinging to an arbitrary process as justification for why they are delivering adequate, but not exceptional results.

doctor_eval 3y ago
Yes, I agree with everything you've written. The problem is not processes like Scrum, it's the fact that many of the people who are in roles that are ostensibly responsible for "fret[ting] over higher order problems" actually don't care about that. They get paid regardless of how productive everyone else is, and in my experience they get paid more if they implement "best practices"... which are practices designed by marketing teams to sell CSM courses.
avereveard 3y ago
The reason this happens is that management is secretly hoping that using a process will allow them to do get by with junior developers because the software complexity will be magically handled by "The Process" I honestly don't blame them for trying to industrialise software production, I blame the engineers which is probably the only white collar profession that don't care about being in control of their own field narrative
- steveBK123 3y ago
  This was readily apparent at my last shop when we had a range of junior (months out of college) and seniors (20+ years experience), and the expectation was simply that seniors were to clear more tickets/points per sprint. We didn't allocate more architectural tasks to seniors, or pair them with juniors, or give them long running slices of work across sprints.. we just were like "more points please". We ended up with under-engaged seniors all leaving, and juniors being given tasks they couldn't accomplish.