Saturday, December 8, 2007

People over Process

In an earlier blog post, I mentioned some of the tenets of Agile development and how they applied to Business Intelligence projects. One of the tenets that is close to my heart is "Individual Interactions over Processes and Tools" Basically, what this tenet says to me is that any Agile process must be constructed to value the people more than the process. To me this just screams common sense, but I am truly amazed at how uncommon it seems to be these days.

My team is a fairly small team, but we've built a product over the last year that has already been sold and deployed into our customer base and has generated significant revenue. This despite the fact that many of the team members had never even heard of the technologies that I was asking them to master (Not to mention the fact that when we started the project, NONE of the technologies we employed were more than Beta). I honestly (and yes, I know I'm biased) don't know how you could be more successful with a project. Some think we got lucky, some think we just chose an easy path (this is the funniest as far as I'm concerned, I guarantee you that those who say this would have failed miserably given the same task) and there are those who think it was a combination of both...

In my spare time, I'm part of a process-improvement team who's charter is to construct an Agile process that will help us get products to market faster and more reliably. Part of the process is developing various work items and work product that can be defined and rolled out to a wide audience. I was in a meeting the other day that started off innocently enough, we were reviewing a specific work product type that we want to use across all Agile projects. I looked at the output and thought, "wow, I wouldn't have thought of this that way, but it looks pretty good, I like it and can use it".. By the end of the meeting, the work-product had been torn to shreds and all sorts of workflow and parent/child relationships were now included. All I could think of as I left the meeting was the fact that had I been forced to use this thing that was just constructed, there would be no way we'd have ever gotten off the starting line in my current project. This experience has caused me to come up with a set of 2 simple rules for any Agile project:

  1. The process should be minimally invasive, or even invisible
  2. When all else fails, see rule #1

If the tools surrounding a process are too rigid or too invasive, developers are NOT going to use them. Again, this is COMMON SENSE as far as I can tell....

Ok, I guess I'm done ranting for now....

No comments: