1. 7
  1.  

  2. 4

    A big realization for me has been that no methodology will ever fix the fact that business has unlimited demand for features, and a limited supply of features/week. I tried to write about this yesterday even: http://deliberate-software.com/development-disappointment-disorder/

    1. 3

      This is excellent and on the ball, IMO:

      Many so-called “agile” organizations have mistaken the process for the product. The daily “how confident are you this card will be done today?” The inevitable “pretty confident unless things don’t go as planned.” This is a bogus dance. This is project management theater. Even the notion of “delivering working software frequently” to maintain a healthy feedback channel is being corrupted. Rather than a brief reflection on progress toward the finish line, most end-of-sprint reviews fixate on “how well did we do compared to our guesses 2 weeks ago?”

      The truth is that we are running a marathon here, people. Treating it like a series of independent races, a chain of back-to-back “sprints” is not the way to win a marathon, nor is it the way to build software.

      At one place that billed itself agile I had to sit through planning and task breakdown sessions for sprints 3 months down the line

      1. 2

        I think that these processes allow the business to lose sight of the fact that engineers (like anyone else) don’t do their best work unless they’re motivated, and no one’s motivated to work on atomized features and “user stories” that come from the business. People want to build things that actually matter to them, and to do things that they’ll learn from, not work on the Jira tickets that get shoveled their way by some middle manager.

        It’s OK to have a business-driven workflow if you’re a consultant making $500+ per hour (hell, if I’m hourly, I’ll even sit in status meetings because it now makes me money if you waste my time) and picking and choosing projects, but corporate employees want some semblance of stability and investment in their careers.

        There are programmers who’ll let themselves be treated as business subordinates rather than expert professionals, but they’re never the good ones. Even if they’re talented, the ones who let themselves be jerked around tend not to develop new skills, so they don’t grow.

        Also, the two-week sprint/iteration is really stupid. I hope that dies soon.