Agile Arguments, Part 1 – The Kickoff


First, let me say that this post has nothing to do with recent events in my employment situation other than it was a the final small straw on the beleaguered camel’s back that is my patience with half-baked, poorly implemented and poorly-understood agile project management and practice.  Over the past 4-5 years, I’ve had a number of arguments with executive/management/business types over Agile software development (specifically eXtreme Programming) and how it works and how it delivers value.  I find myself having the same arguments, being asked the same questions, and retorting with the same retorts over and over again.  In an effort to help me codify my thoughts more, and to provide a forum for decision on the ‘Tough Questions Business Folks Like To Ask About Agile’ I’m going to start a series of unknown length to try to reach some sort of greater understanding.

I want to open the debate and invite non-technical people (including, and especially folks in executive/management roles) to participate. Only by hashing these issues out in a public forum, will we ever hope to achieve the trust and at least partial understanding necessary to have any hope of success on a project.  I’m tired of projects failing or being jeopardized due to lack of communication and trust. So this is my positive step forward to try to eliminate that problem.

Rules of Engagement – Open Spaces Blog Conference

I would like this debate to spread far and wide. Think of it as a form of an Open Spaces conference, but via Blogs and blog comments. Comments here are great, but I would REALLY like for others to pick off specific arguments and go deeper on their blog. If you declare a going-deeper side track on your blog, please let me know and I’ll link to it (if I don’t respond, it may be because your email went into my spam bucket, try again or contact one of the other Los Techies guys).  Please grab an argument and run with it.

This goes for all participants – developers, coaches, architects, business executives, project/product managers, testers, etc:  YOU MUST BEHAVE WITH DIGNITY AND RESPECT. Anyone caught being a jerk will have their comments deleted or their posts de-linked. We are all professionals and I expect it remain that way. Polite, intelligent, dissenting opinions will be preferred, highlighted and made top priority as it is the only way we will progress in this argument.

A good example of a code of conduct for us all might be this: A Simple Code

I will be sending out a link to this blog post to various business and stakeholders from previous projects that I’ve worked on and invite them to participate. I would ask that you do it too for anyone you’ve had controversy over with in the past.  If they don’t have a blog and don’t wish to comment, and ONLY IF THEY GIVE YOU EXPRESS PERMISSION, ask them if they can at least contribute something via email that you can reproduce here in the comments or in another blog post.

Remember, keep it clean. Keep it intelligent. Keep it progressing towards a resolution of understanding and trust.

Starter Arguments

There are a few arguments that I almost always hear whenever the word ‘agile’ comes up in a conversation, so I’d like to start with those because, obviously, they haven’t been adequately answer by the Agile community (or it hasn’t been answer loudly enough).

  • I can’t control costs with an Agile methodology project
    • I can’t control time with an Agile methodology project
      • I can’t control what ‘done’ is with an Agile methodology project
        • Agile is an excuse for doing no hard work up front and doing little work in the middle
          • Agile is an excuse to remove project controls to create ambiguity, and thus wiggle room for responsibility on the product development team
            • Using a story card as the main feature driver does not yield sufficient specificity of requirements and doesn’t lead to quality software
              • The use of story cards is a flawed tactic for deferring responsibility and results in irresponsibly late decisions on features
                • The use of story cards results in a rather worthless product of requirements such that no one ever knows what the requirements are
                  • The use of story cards prevent adequate product documentation</ul> I can go on and on with these, but I’m hoping this should be sufficient to get the ball rolling. I’ll pick a few and deal with them in my next post on this subject.
Ancient wisdom is inescapable, especially with project management