1 Staffordshire UNIVERSITY School of Computing Slide: 1 Prototyping Agile Software Development 3 Agile and Waterfall methodologies compared

1

StaffordshireUNIVERSITYSchool of Computing

Slide: 1Prototyping

Agile Software Development 3

Agile and Waterfall

methodologies compared

2


Slide: 2Prototyping

Agenda

Agile and Waterfall – a Summary

Some Comparisons

Waterfall methods are popular

Comparison of Agile and Waterfall Methods

Which methodology is “best”

Waterfall beats Agile for visibility on projects

Tutorial Tasks

3


Slide: 3Prototyping


To summarise the difference between waterfall and agile approaches, the classic waterfall methodology stands for predictability, while agile methodology stands for adaptability.

Waterfall’s defined stages allow for thorough planning, especially for logical design, implementation and deployment, while the agile methodology offers a sound choice for software development and especially web design projects.

4


Slide: 4Prototyping


It is both possible and safe to build a paper airplane without a detailed plan; it would be foolish to spend 20 minutes writing the instructions and then spend 20 seconds building the plane.

However, building a passenger airliner without detailed, upfront design would be a long and expensive process involving a lot of rework that you would otherwise have avoided.

5


Slide: 5Prototyping

Some Comparisons

Agile methods are often characterised as being at the opposite end of a spectrum from "plan-driven" or "disciplined" methodologies.

This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined."

A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive." Agile methods exist on the "adaptive" side of this continuum.

<--Agile--> <--Iterative--> <--Waterfall-->

<----|-------------|----------------|----->

Adaptive Predictive

6


Slide: 6Prototyping

Some Comparisons

Agile methods are often characterised as being at the opposite end of a spectrum from "plan-driven" or "disciplined" methodologies.

This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined."

A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive." Agile methods exist on the "adaptive" side of this continuum.

<--Agile--> <--Iterative--> <--Waterfall-->

<----|-------------|----------------|----->

Adaptive Predictive

7


Slide: 7Prototyping

Some Comparisons

Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well.

An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date.

An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month.

When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

8


Slide: 8Prototyping

Some Comparisons

Predictive methods, in contrast, focus on planning the future in detail.

A predictive team can report exactly what features and tasks are planned for the entire length of the development process.

Predictive teams have difficulty changing direction. The plan is typically optimised for the original destination and changing direction can cause completed work to be thrown away and done over differently.

Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.

9


Slide: 9Prototyping


In some eyes the waterfall is discredited, but this model is still in common use.

The waterfall model is the most predictive of the methodologies, stepping through requirements capture, analysis, design, coding, and testing in a strict, pre-planned sequence.

Progress is generally measured in terms of deliverable artefacts - requirement specifications, design documents, test plans, code reviews and the like.

The waterfall model can result in a substantial integration and testing effort toward the end of the cycle, a time period typically extending from several months to several years.

10


Slide: 10Prototyping


The size and difficulty of this integration and testing effort is one cause of waterfall project failure.

Agile methods, in contrast, produce completely developed and tested features (but a very small set subset of the whole) every few weeks or months.

The emphasis is on obtaining a crude but executable system early, and continually improving it.

Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration. Other teams work on activities simultaneously.

11




Waterfall is the standard process oriented methodology employed by most (particularly large) organisations that need rigorous procedural control and auditability.

It is particularly relevant for client side work because it involves a step by step process with a “relay race” approach involving up front analysis costing and estimation, and an incremental project life cycle with different skills being employed at different periods, thus allowing resource to be managed more easily.

It is also easier to certify and compare against standards, and the focus on documentation means that there are easy reference points and improved knowledge transfer among the people involved.

“Organisations like to work this way, and people get comfortable with it because it can allow them to point fingers when things go wrong, and can remove the need to change and be flexible.”

12




Agile comes at projects from a completely different angle, placing the onus firmly on people rather than process.

It does away with documentation that does not add immediate value to the project development, and to be successful requires all team members to be more cross functional and work together in a fluid supportive way, dependent on a high level of goal congruence and motivation.

It is a trust based approach that is not easy to tick off against quality standards, but much easier to measure against return on investment.

13




It provides high visibility on outputs and relevance, and allows for much greater client side involvement and ultimately satisfaction, and delivers greater recognition for team achievement.

However the lack of documentation raises risk in areas of knowledge transfer, trust is fragile across organisations, and Agile does not necessarily deliver whole projects any faster.

Organisations are rarely set up to cope with Agile requirements, but professionals like to work this way because it allows them to control the way they work and they don't have to waste time on non-core activity that detracts from delivery.

14




The point to note is that client based work, particularly for clients with limited or no Agile experience, and/or delivery with novice or limited experience Agile teams, has both pros and cons.

In the rush to sell or implement Agile against Waterfall, the cons are often ignored, but these must be recognised and mitigated against if you want your Agile project to really be successful.

The following is a brief outline of both the pros and cons of Waterfall and Agile methodologies.

15




Overview

Waterfall Agile

Relay race approach Good for clear, well defined & fixed requirements System specs Functional requirements Software requirements Analysis Design Coding Testing Operations

Holistic rugby approach Good for projects with unknowns Cross functionality Parallel working Working together User “stories” rather than detailed Requirement Specs Ongoing Analysis and Design Coding and testing in tandem

16




Pros

Waterfall Agile

Audit Structured management Budget and schedule predictability Control Scale Skills Specialisation Documentation = knowledge transferability Familiarity / often part of organisational culture Structural support from other departments

Early ROI Flexibility Team control Better understanding of both bigger picture and immediate priorities Better delivery Higher visibility More client involvement

17




Cons

Waterfall Agile

Late ROI Embeds rigidity Hierarchical control Lack of client involvement Big delivery surprises late in the project Too much documentation Poor visibility Poor long-term goal coherence Difficult to control output relevance over life-cycle Protracted delivery Reduced personal involvement Higher risk of failure

High learning curve Early process surprises New ways of working Resistance to evolving information More regular dependency on client involvement Harder to manage third party dependencies Harder to manage resource Requires much tighter team working Requires greater cross functionality within teams

18




Factors Waterfall Agile

Size Tailored for large projects and teams Optimal for small projects and teams; reliance on tacit knowledge

Mission-critical projects

Long history of use in such implementations

Untested; general lack of documentation

Stability and complexity of existing SW

Structured baselines used; suitable for more static and complex environments environment (typically Brownfield)

Continuous refactoring used; suitable for dynamic and simple environments (typically Greenfield)

Skills Highly skilled individuals needed in early phases; designed to cope with many lower-skilled resources in later phases

Continuous involvement of highly skilled individuals; difficult to cope with many lower skilled resources

Suitable organization culture

Roles well defined; procedures in place

Chaotic; dynamic; empowered

19




“Home Ground”

Waterfall Agile

High criticalityJunior developersRequirements do not change oftenLarge number of developersCulture that demands order

Low criticalitySenior developersRequirements change oftenSmall number of developersCulture that thrives on chaos

Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive (agile) and predictive (waterfall) methods.

The authors suggest that each side of the continuum has its own home ground as follows:

20




Different project management techniques impact the type of information you can collect on projects and therefore the level of visibility you have on your processes - both for single projects as well as for reports across all projects.

One of the advantages of a more classic, Waterfall approach, is that time is a variable that can shift and be measured.

21




Then, you can measure how long it takes to actually complete the tasks in several dimensions:

1. First, in terms of calendar dates: when the task was started and when it was completed.

2. Secondly, you can measure in terms of duration: the number of days it took to complete.

3. Thirdly, in terms of actual hours: the amount of people hours worth of effort it took to complete the task.

22




When measured and kept over time it creates a robust data set that can be used to improve estimates on projects.

If you bill by the hour or by project, this data can help improve your pricing and profitability by providing visibility into the actual time it takes to do the tasks or projects you are charging for.

If you bid on projects, this same data will improve your understanding of the variables you can look at when pricing your bid.

23




In a more Agile project management approach, time is generally held constant and it is the functionality or amount of work that shifts.

The amount of work that can be accomplished shifts according to the time allocated, the skill set of the team and the complexity of the work involved.

This can provide a benefit for the project manager - they don’t have to worry about schedules and effort estimates in the same way as a Waterfall approach.

It also makes it easier to track progress and shut out distractions for the team.

24




However, it comes at a price of reduced visibility and decreased data for management to use to make strategic decisions.

The variables often left to management for decision making them become ones of:

hiring more people,

working on the team’s skill set,

firing people, or

limiting project scope to the constraints of the team’s historic performance over a fixed period of time.

25



References

http://www.experiencefestival.com/a/agile%20software%20development%20-%20comparison%20with%20other%20types%20of%20methodologies/id/605892

http://consultingblogs.emc.com/rizwantayabali/archive/2007/03/05/Waterfall-vs-Agile-for-Client_2D00_based-work-and-R1-teams.aspx. Published 05 March 2007 13:39 by Rizwan Tayabali

http://www.cio.com/article/409814/Brownfield_Development_An_Agile_Approach_to_a_Waterfall_Problem

http://www.vertabase.com/blog/waterfall-beats-agile-for-visibility-on-projects/

26



Tutorial Tasks

Find several authoritative information sources that support each methodology

Summarise the strengths of each methodology and the circumstances in which they would be used

Research different tools and techniques to support each methodology

Explore the project environments that will allow each methodology to struggle or thrive

27



Agenda


Some Comparisons





Tutorial Tasks

Documents

1 Staffordshire UNIVERSITY School of Computing Slide: 1 Prototyping Agile Software Development 3 Agile and Waterfall methodologies compared