Waterfall Development

‘Waterfall Development’ is another name for the more traditional approach to software development.

It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).

In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!

This approach is highly risky, often more costly and generally less efficient than more Agile approaches.

The main issues with this approach include:

• You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development)
• You leave the testing until the end, which means you’re leaving issue discovery until late in the day
• You don’t seek approval from the stakeholders until late in the day – their requirements might have changed
• You’re heavily reliant upon a plan, which you can/will often follow to the detriment of the end result
• You’re heavily reliant upon a project manager driving the way – the power of one

Iterative Waterfall Development

This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches.

The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features.

The most commonly occurring issue in this type of scenario (in my experience) is bottle necking.

For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing.

Another common symptom of this type of approach is over-commitment.  It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way.

You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined.

For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases.

It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development

This approach carries far less risk than Waterfall approaches.

We focus on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature.

With that said, we still plan our work in iterations and we will still release at the end of each iteration.

Lean Development

Lean is very similar to Scrum in the sense that we focus on features as opposed to groups of features – however Lean takes this one step further again.

In Lean Development, you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature. By doing this, you further isolate risk to a feature-level.

In these environments, you aim to eliminate ‘waste’ wherever possible – you therefore do nothing until you know it’s necessary or relevant.

In his blog post Your user acceptance testing is fixed – Is that a problem? – Shrini has quite correctly detailed the challenges of getting UAT done from the business and various ways how a UAT is compromised.

Forms of fixing UAT
Between Business and IT, UAT can be fixed in number of ways – some of these are reasonably business driven models given the constraints.
1. UAT will be performed by the members from IT team where business only reviews the results of the test. If the results are OK then UAT is ought to have been completed
2. UAT will be performed by a third party, such as someone from support staff. Business will review the results and accept the proposed changes if results are OK
3. Business will provide a prescribed set of test scripts that can either be used by anyone IT staff or support staff. Results will be verified by the Business.
4. UAT will be done like a demo to the users where IT staff will execute some pre-approved test scenarios related to proposed changes.
5. IT team will train the business in new features proposed to be introduced. Business users after training, test (use) the proposed software and accept the software

Why fixing user acceptance testing is bad thing?

Why bother to UAT after all? For IT, more often than not, it is a formality to be completed before they push the code to production.

In my opinion, it is the spirit and purpose of UAT that gets compromised. Typically, in spite of all best efforts, the depth and frequency of interactions between IT and business throughout the project remains low. When business users do not participate with full spirit in UAT, lots of things go unnoticed into production. This might results users (non participating ones especially) getting surprised when they see the product.

I certainly agree with his comments and his displeasure when UAT is compromised.

At one of the companies that I’ve worked for, we had taken the Agile approach where regular demos were conducted for business where they got the exact idea of what was being developed and does it meet their expectations. This made our life quite easier as towards the end when it was time for UAT, they had virtually tested the complete application except for the bits that were part of final iteration.

BUT in saying that Agile approach is not always possible and we sometimes do have to take the traditional ‘waterfall’ method where business gets to see the application right at the end. And when it’s time for UAT then they either don’t understand what UAT is or testing is their last priority due to other BAU (business as usual) committments. And that is when we have to come up with a compromise where we have to help them with testing by providing some high-level scripts or some training on the application.

I am not happy to say but it is quite common and in fact nowadays it is being taken for granted that business will get some support from test team to get the UAT done.

]]> http://geek4eva.com/2009/08/20/compromising-user-acceptance-testing/feed/ 0