Archive for July, 2011
i love having conversations with people about the benefits of being agile, but i suppose i have been drinking the cool-aid for too long…
even in moments where the reality sinks in that the ‘agile’ pill might just be too much for an organization to swallow at this moment in time, here i go again, trying to break up the medicine and feed it to people incrementally.
part of my conviction is selfishness. The promise is that if taken to heart, quality is shared across the project team, everyone helps test, requirements are more clear and testers get a seat at the table and often they get to eat/test first (okay, that was a corny joke). What Test Manager would not enjoy this?
but then i find myself thinking, am i making promises on things that can’t be delivered, i mean is it really true that requirements can be written in this new weird format, that acceptance test plans can be written before or during requirements creation with practical examples, that estimation actually gets better over time and that we have the data to prove it, that regression testing of highly complex, tightly integrated systems can be automated by using good software engineering principles?
now, i have never worked for NASA, I don’t have a PhD in Mathematics/Computer Science, i’m only a half decent developer (and even that is part time) but I tend to favor simplicity. In other words, it’s never made sense to me to wait for a project to be delivered in BULK with all its complexical splendor (not a word, just made that up) and try to test it, usually under time constraints. Even in the event that the project did what it was supposed to do when it was released, generates revenue, etc.. etc..the business owners still say it took wayyyyy too long. They don’t get why it takes that long to provide value. Well dammit, I don’t either.
if we took the time to think about the delivery mechanism. The process in which ideas become working software we might find that much of the productivity is lost in the time between hand offs and lack of communication. if i can’t read your requirements, we have a failure to communicate, if I don’t understand the design, we are not communicating, if the code doesn’t have an interface to test, we aren’t communicating, if you ask for a test estimate AFTER development has already written the code we are not communicating AND now it’s going to take me some time to get up to speed, oh but I bet you still want an estimate, don’t you??
BUT, i’m preaching to the choir here aren’t I? (thanks for listening)
So, what i have decided to do when faced with such odds, is to follow the same principles that I preach and become more agile myself.
I have a vision of working on software that I am proud of (this is why the good engineers join your company btw), of delivering high-quality software continuously with business value. That vision doesn’t change because of the project delivery methodology, in fact, arguably its part of our job to make the case, a compelling and convincing argument of this vision, and provide the roadmap to help get there.
if you can’t convince people to see your vision, your probably not selling it well AND If you can’t convince people to follow your vision, your probably not a leader after all