Agile on "Worse Than Failure"
May 28, 2007
For the past couple years, give or take, I’ve been reading a particular blog on a fairly regular basis. It was originally called “WTF” (yes, it stood for what you’re thinking) but recently changed its name to “Worse Than Failure.” The blog chronicles the really stupid things we see in the software development industry. Originally, the blog primarily showed horrible code samples; not just bad code, but stupid code. For even average developers, reading the blog was a source of jovial entertainment. You would often find yourself slapping the side of your head in disbelief and thinking, “How could anyone code it that way?!”
Ever since the name change, maybe slightly before that, the blog branched out into stories about software development, not just code. There’s still the occasional code sample, but most posts are commentaries of specific events, bad management, and development processes.
One post in particular caught my attention: The Great Pyramid of Agile. The post talks about why Agile is the current popular software development fad. Although I don’t think the pyramid analogy was a good one, the article itself is spot-on.
I’ve worked in several different SDLCs. As a development manager, director, or CTO, I’ve implemented a few different SDLCs in my groups or departments. I’ve used “waterfall,” XP, and something that was SCRUM-ish, although we never called it that. It wasn’t until my last job (a job I recently left) that I was forced by non-technical executive mandate to “investigate” (i.e. implement) full-on SCRUM. The experience was horrible.
So why was it so horrible? Well, I love being successful, and I love leading successful teams, so when anyone (or anything) prevents me or my team from being successful, I get upset. Why did SCRUM prevent us from being successful? Well, I believe it had nothing to do with SCRUM itself. The failure was because we had stupid people (and people who were not stupid but had no backbone) trying to collaborate to implement a “strict” process of SCRUM, despite the fact that one of the points of the Agile Manifesto is people over process. Anything that deviated from “textbook” SCRUM was often ridiculed.
Ultimately, it came down to one thing: we had too many stupid people entrenched in the system. I was fond of saying, “Changing your methodology doesn’t fix stupid people.” At this point, you might be asking, “Hey Gryphon, define stupid and defend your assertion that SCRUM failed because of stupid people.” Dictionary.com defines stupid as having a lack of “ordinary quickness and keenness of mind.” Other phrases it uses include “pointless,” “inane,” and “tediously dull, especially due to lack of meaning or sense.”
Imagine a small team comprised of business folk, developers/engineers, project managers, and so forth. Imagine someone in that group who hardly ever did his job, failed to live up to even the lowest of expectations, and was a constant drain on the team. If this person were to be fired and not replaced, the team would not suffer; in fact, it would probably be more productive. Such a person, in my opinion, could be called “pointless.”
Imagine you’re a developer who spends well over 50% of your week in unproductive meetings that could be summarized for you in a few short, simple emails from the project leader, and imagine that this project leader refused to make any changes to process. Imagine the project leader couldn’t come up with new ideas to improve process or efficiency. I think it’s reasonable to say that the project leader is inane, “lacking sense, significance, or ideas.”
Yes, I realize that it’s mean to call someone or a group of people stupid, but that doesn’t make it incorrect; it just makes it socially unacceptable. If you have enough stupid people in a team, any methodology will fail. If you’re a business owner (VP, SVP, CEO, etc.) who believes there’s a failure of efficiency, you don’t fix that problem by implementing a methodology. You fix the problem by firing the stupid people. Even better, avoid hiring stupid people in the first place.
The blog post on WTF reads:
Good people can build good software no matter what methodology they use. We don’t need a weight-loss pill for thin people; we need to solve the real problem behind failure in our industry. The bar for "acceptable" is far too low. We need to focus on improving the skills of the less-than-good in our industry.
Amen, amen, frackin’ amen! Improving the hiring process, making it very difficult to get hired at a company, will typically lead to less stupid people in system. (Note that over the long-term, such a company or department needs to be wary not to think too highly of itself or else generate overconfidence, which breeds sloth toward following best practices, which results in problems similar to having a system infected with stupid people.)
Personally, I think the “best methodology” is to have an arsenal of flexible methodologies in your company’s tool belt, then pick the best methodology for the problem (or project) at hand. I love Perl, but Perl isn’t always the best language with which to code a solution. I can use Word to create a graphic and Photoshop to author a letter, but that’s stupid. Use the right tool for the job. I tend to prefer “waterfall” for large, first-version applications and systems. Then I like to follow-up with a blend of XP and SCRUM-ish principles for iterative development of existing systems or new, small systems that have a life expectancy of under a year or two. But even this plan will fail if I’m too rigid or hire stupid people.
The WTF blog reads, “Remember, the fact that a system that makes it to production does not mean it's a success.” Success is when the system gets into production on time, on budget, meets (or exceeds) the needs of the user (including usability), generates a positive ROI, and has a low level of on-going maintenance exclusive of feature additions. That’s difficult. Every stupid person on your team makes it that much more difficult to be successful. Following a fad isn’t going to fix things.
