The death of agile?

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”.

Comments

• Anonymous
  March 14, 2014
  The comment has been removed

• Anonymous
  March 18, 2014
  The most difficult thing I see teams struggling with is "time." For some reason, when you are wasting your internal developer's time...that time is "Free." Meetings balloon and multiply, emails pile up, sticky notes start covering walls...daily stand ups...test driven development...automation...pair programming...extreme programming etc etc etc. It never ends. Take that same company and put them with a vendor who says "Well, we could do what you just asked but that will cost you $75,000 more than the budget. 100% of the time, that dumb thing or process which would make the project late and go way over budget gets dropped. That never happens on internal teams. Internally, if you don't want to do something which is an obvious waste of time you are not a team player, you are lazy and get stack ranked at the bottom. That is why Agile fails more than any other reason. Someone needs to be the "hey guys, this actually burns more money than it is worth and makes us late."

• Anonymous
  March 19, 2014
  The comment has been removed