| By Pak-Tjun Chin,
on 13-11-2008 15:42
|
Views : 158  |
Favoured : 20 |
Agile projects are not necessary less expensive (or quicker to implement) that Waterfall projects
During the early phases of an Agile project that i worked on, every stakeholder that I spoke to, from the project manager, business stakeholders, support manager, etc asked me the same question, 'So this is an Agile project, eh? It should be cheaper/quicker, right?!!'. Well, I am sorry to disappoint you, as I disappointed those people I spoke to then; it is neither about cost nor schedule. Don't get wrong, cost and schedule are important in determining the viability of a project, but being Agile is all about delivering a project that exceeds, if not meets, the customer's expectations. If it costs more or takes longer to get it right, so be it.
A good testing team that not only understands, but embraces iterative testing, is gold
I am not sure about you, but I found it extremely hard to get good Agile testers in the market that truly understood iterative testing. In an Agile project I worked in earlier this year, the test manager, whom was hired on the basis of being knowledgeable in Agile testing techniques, could not understand why the development team was promptly incorporating business change requests into the application. He complained that his team had to then modify their regression test suite over and over again. My comment to him was that rather than develop and document all test cases up front, sit down with the developers, work out the stories/features that are to be delivered for that iteration, and then work out the test coverage and test cases for that iteration.
Co-location, co-location, co-location
A co-located project team does wonders in cutting down on meeting times. Time is gold, and the last thing the project team needs is to attend meetings after meetings that are mostly meaningless in nature. When co-located, questions, problems, news can be quickly disseminated amongst team members. Quick daily stand-ups would be able to give a pretty good snapshot of where everyone is at .
No supportive and collaborative business stakeholders, no Agile projects
Let's all face it, without our business stakeholders coming to us looking for a technology solution to a business problem, we would all be out of a job. And really, our mission in life is to be able to understand what the business really wants, and not what we think they need. Business on the other hand, cannot just wash their hands off a project after delivering the business case and then expect to come back during User Acceptance Testing to find everything hunky-dory. It's really a two-way street. A close collaboration between business and developers need to be forged, working hand-in-hand to achieve a common goal, a quality outcome! I was extremely fortunate to have worked with supportive and collaborative business stakeholders in the past. I recall that Blackberry messages to them will never go un-answered, be it when it's in the middle of the night, weekends or when they are half-way round the world.
Testing 1, 2, 3
I found that a number of Agile projects that I worked in never saw that light of day, of if ever, it was few and far between. I believe that it was the mentality of the development team that if it could not be done right in the first iteration, try, and try again in subsequent iterations. Testing? What's testing?!!! Yes, I have worked in so-called Agile projects whereby very little testing was done on delivered code prior to systems integration testing. There was a lack of unit test coverage on code, an absense of a continuous build environment, a lack of understanding of environment factors that may affect the deployment of the application, etc. And then, the same developers would be wondering why so may defects were encountered later on, or why the application could not be deployed. The development team need to really make a proactive stance to deliver quality code that works. Elemetary, my friend, is it not?!
Last update: 25-11-2008 13:56
|
