I still find it strange that companies unfamiliar with Agile automatically view it as being a methodology that pays no heed to process or ensuring quality of output. From my experience the quality is actually a lot better, the timescales set are achieved more readily and everyone involved has a much greater understanding of the product and its development status at any one time.
At present I´m working on a project where I´ve had to split the test team into two due to several companies working to build a complex product together. One team is performing agile QA in a sprint team, the other is working ´the old way´.
It´s very interesting to note that all the worry and uncertainty is coming from the team working with the traditional model due to the fact that timeframes having been guesstimated months ago about environments, data and functionality that no-one knew about then. As time marches on we appear to be spending more time in meetings discussing what we once thought was gospel, has now changed due to various perfectly valid reasons and so how can we accommodate this into the table-filling project plan? To me it´s like trying to map out the projected state of the universe after being on earth for 40 minutes!
The sprint team obviously still has problems during the development of the app but they nail problems quicker during iterations, they know very clearly what´s coming up and can give really accurate times for delivery (or accurate times for delay). And everyone can tell you about all parts of the product – there´s no team building a module in a silo, oblivious of what the rest of the project team is doing because they don´t integrate their part until 4 months down the line.
There is a perception that using an agile methodology means starting to write code before knowing what the product is, and as a result the QA people can only click a few buttons in a demo, shrug their shoulders and say “Yeah, looks fine to me I suppose”. What´s important to note here is that perception is shared amongst people who have not worked in an agile environment or, most probably, have worked in a poorly organised agile environment. To those people I ask that they maintain an open mind to change within project management and place some trust in the fact that there is a huge agile community out there producing fantastic software, in incredibly short timeframes, and with very high quality.
One of the problems I’ve seen selling Agile is that it initially feels to managers that they’re giving up control, when they actually have more control, and that it’s less predictable, when in fact we only give up long-term time estimate because they are lies anyway.
I often compare Agile vs Waterfall to a rocket vs a jet plane. The rocket can go a lot faster, but once you light those solid booster engines, you’re going wherever you’re pointed. If that happens to be a good place when you get there, then great. But in the real world, the slower-moving-but-steerable jet plane is going to get you where you need to be at the end.
So it really comes down to what’s more important; having a guess at where you will be at then end and when that might be, or knowing that at the end you will have what you need, and that it will most likely be sooner than with Waterfall.
Waterfall is more expensive and rigid, without any leeway to change and confirm your product as it will be developing. Waterfall lacks the responsibility and participation of users or project’s sponsors, while in Agile this is a must. What happens if during analysis something was misinterpreted or changes take place from the company or outside boundaries! We are in huge… huge trouble. Agile can adopt to these changes.
Agile does not mean no documentation, rules and what so ever. It is a way of prioritizing and doing things in collaboration with your sponsor to meet business objectives better with less expense.
What are your thoughts?
