The death of agile?

  • Article

Mike’s got some great points about how agile goes wrong. I’ve seen them all.

  • The skills and talents of individual programmers are the main determinant of software quality. No amount of management, methodology, or high-level architecture astronautism can compensate for a poor quality team.
  • The motivation and empowerment of programmers has a direct and strong relationship to the quality of  the software.
  • Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver.
  • The consequences of poor design decisions multiply rapidly.
  • It will usually take multiple attempts to arrive at a viable design.
  • You  should make it easy to throw away code and start again.
  • Latency kills. Short feedback loops to measurable outcomes create good software.
  • Estimates are guess-timates; they are mostly useless. There is a geometric relationship between the length of an estimate and its inaccuracy.
  • Software does not scale. Software teams do not scale. Architecture should be as much about enabling small teams to work on small components as the technical requirements of the software.
    Coconut Headphones: Why Agile Has Failed

Agree 100%!

However, there are some reasons, in my experience, why developers contribute to this problem as much as non-developers. A lot of it comes down to the team quality bullet above, but…

  1. Developers generally don’t want to follow a process or manage others to follow one, regardless how minimalist, which results in a lack of predictability.
  2. The people who are paying for the software development always want predictability.
  3. Without funding, usually there’s no project and no software gets developed. (We all gotta eat. =)
  4. There are a HUGE number of skill sets that software developers typically do not have that need to be worked into any non-trivial project, often skills that are so much more rare that they have to be shared: UX designers, content writers, media producers, marketing people (yes, often marketing has to begin before the product is done), and the list goes on.
  5. Architecture is also such an abused word that we should stop using it, too. Most architects (regardless their alleged discipline) that I’ve worked with or observed are stretched too thin between too many projects, only allowed to participate in the formative stages of the project before being shuffled off to the next, or insufficiently technical for their advice to have any merit.

Unless highly technical people step into the “project management” and “architecture” roles and develop the credibility with the technical teams AND the people paying for the work, we need to get to a place where predictability can be had while including nontechnical folks to “run the process”.