Let me start this post off with the clear thought I’m going to attempt to discuss below. I say attempt because, god knows, I can very easily get lost in the writing and it easily becomes stream of consciousness. So, if you nod off while reading my blog, don’t feel bad. Because, I might be nodding off while writing it. But, I digress.
OK, the thought.
There is a MAJOR difference between doing something QUICKLY, and doing something quickly that’s of HIGH-QUALITY.
As you’re reading this post, remember the fundamental project management equation, which applies to product / project / program managers alike regardless of if you are working within an eXtreme or waterfall methodology.
scope + cost + schedule = quality
There’s been a lot of focus put on “speed” and “iterations” with the whole web two dot d’oh! craze going on these days, and I wanted to touch a little bit on that.
I don’t mean to rain on everyone’s “just get it up & out there parade,” but there’s still a need for attention to detail and quality. It seems to me that no one pointed out to the agile pushers (me being one of those folks) that while doing things iteratively and quickly is nice, it requires experience.
I’m going to go back to the age-old analogy of building a house. If you were having a house built and hired contractors to do things, not necessarily iteratively (because I don’t know how you could put up a house and then continuously improve it), but quickly and of high-quality, would you want kids that were just out of carpentry school doing it? No freakin’ way.
That doesn’t mean you need dinosaurs up there laying shingles on your roof, because they would arguably cause just as many problems as the people without any experience, but you still need that knowledge of having done this before to get it done properly.
I can’t talk too much, because I myself don’t have 15 or 20 years under my belt, but I have been in software (Web applications specifically) development for close to 7 years, so I do know some things about creating applications and working with customers / users to improve them.
Don’t expect to hire cheap labor, who hasn’t done the work you want to do and expect to move at lightening-speed AND get something up there that will propel you to the level of greatness. It just doesn’t happen that way. Again, one of the major elements to be successful at agile development is you actually need developers that know what they are doing to get things done in that fashion.
…and developers that get one iteration shipped and are chomping at the bit to tweak existing things and continuously improve what they produced so it’s the best it can be, while at the same time making the product more exciting by adding enhancements coming in from the market.
Another component that may get lost in this “agile” development way of thinking is actual accountability. It’s easy to lose the team and control, especially when the experience isn’t there, in the midst of, “we’re just going to get this done and up and then refine.” Quality needs to be minded, and those involved have to be held accountable for what they own. It’s still a project, folks. Don’t lose sight of that. Just because you’re not creating 1,000 page requirements documents and maybe you are writing your project plan on note cards doesn’t mean these fundamentals get thrown out the door.
