Some Agile Development Commentary
I’ve written several posts in the past regarding agile development and how we’re leveraging some of it’s benefits internally at the present time. There is a solid post up at Tyner Blain, in which Scott provides some good feedback on a post written by fellow blogger Mishkin Berteig.
There’s a story a friend of mine (who works within a very large organization as a project manager) shared with me a while back. He was sitting in a meeting with a client and his top project team. A piece of QA within the release process for their code had broken down their process, preventing them from essentially, getting shit done.
That’s generally bad.
My good friend recognized something very critical though - why was backend regression testing (the piece of QA in question) occurring for the UX component of the software? They had nothing to do with one another, but were on the schedule and continued to be done.
The response from those around the table was basically, “that’s just how we do things.” Yikes! That answer, right there, can sum up a lot of what’s wrong within long, severely drawn-out release cycles.
We’re trying to get a v1.0 out the door, and will probably end up doing so this week. Now, we’ve been working on this (from the ground up) for the last, say, 2 1/2 months. That’s an incredibly short period of time to a) define a product b) get it through a development cycle c) market it, and d) release it. If, at any time, my response to a question had been, “that’s just the way it’s done” and thus prevented us from completing a key piece of the PDLC faster, I’d have expected I’d be fired partway through the process.
These types of excuses can be directly tied back to a few things:
- Egos - people want to cover their own asses
- Straight-up stupidity and fear - people don’t understand their role / job and are afraid to say, “I don’t know”
- Fear imposed by higher-ups - VPs and directors with no clue and way too much leeway to say, “my way or the high way”
- Silo’d, non product-centric organizations - those that define the company around roles instead of products
That last one is very important and one I remember touching on before. Agility isn’t just about having senior-level developers you can trust with flexible requirements, but it’s about everyone caring and contributing to the products themselves.
Who cares if someone is “in marketing” or “in legal?” Why does that matter? Their sole function is to solve pain for your customers and build great product. That’s why it’s so critical to commit to product management and not make it a half-assed effort just because everyone else is doing it. Get them in the center to do what they do - ensure the planning is place and crap makes sense, and then execute.
I digressed quite a bit, and it’s got nothing to do with how Scott’s post is written. The difference between using waterfall and using agile approaches is very simple - at least in my mind. If you have a complex, workflow-intensive product (like a banking or insurance-level application), you should be planning your PDLC’s using waterfall methods. If not, plan your whole PDLC using agile. No question.
Of course, that’s not to say, product groups within the overall (probably silo’d) organization that make up the individual feature teams or “product” teams if your suite is broken down that way (a la Microsoft) can’t use agile. They should. It would probably help them work faster and more closely together.
Sorry, Scott — I started out by intending to respond to some of your key points, but kinda got off on a tangent.
August 14th, 2007 at 8:30 am
No worries, Adam. I don’t think that workflow-centric products preclude agile development. They may cause you to do incremental _development_ on the elements of the workflow, until a single use case is completed for delivery/release. But the execution tactics of agile processes do not need to be abandoned.
You may need to get feedback on a “completed” step in the process within the context of “prototypes” of other steps. But you don’t have to wait until it is all done to get feedback.
One of your points is one that I intend to make in the discussion on that article - that cognitive dissonance doesn’t neccessarily happen for the participants, it can happen for the “powers that be” who make someone feel that taking an agile approach is career-threatening.