Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 Staffordshire UNIVERSITY School of Computing Slide: 1 Prototyping Agile Software Development 3 Agile and Waterfall methodologies compared."— Presentation transcript:

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

2 2 Staffordshire UNIVERSITY School of Computing Slide: 2 Prototyping 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 3 Staffordshire UNIVERSITY School of Computing Slide: 3 Prototyping Agile and Waterfall – a Summary  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 4 Staffordshire UNIVERSITY School of Computing Slide: 4 Prototyping Agile and Waterfall – a Summary  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 5 Staffordshire UNIVERSITY School of Computing Slide: 5 Prototyping 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. Adaptive Predictive

6 6 Staffordshire UNIVERSITY School of Computing Slide: 6 Prototyping 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. Adaptive Predictive

7 7 Staffordshire UNIVERSITY School of Computing Slide: 7 Prototyping 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 8 Staffordshire UNIVERSITY School of Computing Slide: 8 Prototyping 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 9 Staffordshire UNIVERSITY School of Computing Slide: 9 Prototyping Waterfall methods are popular  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 10 Staffordshire UNIVERSITY School of Computing Slide: 10 Prototyping Waterfall methods are popular  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 11 Staffordshire UNIVERSITY School of Computing Slide: 11 Prototyping Comparison of Agile and Waterfall Methods  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 12 Staffordshire UNIVERSITY School of Computing Slide: 12 Prototyping Comparison of Agile and Waterfall Methods  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 13 Staffordshire UNIVERSITY School of Computing Slide: 13 Prototyping Comparison of Agile and Waterfall Methods  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 14 Staffordshire UNIVERSITY School of Computing Slide: 14 Prototyping Comparison of Agile and Waterfall Methods  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 15 Staffordshire UNIVERSITY School of Computing Slide: 15 Prototyping Comparison of Agile and Waterfall Methods Overview WaterfallAgile 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 16 Staffordshire UNIVERSITY School of Computing Slide: 16 Prototyping Comparison of Agile and Waterfall Methods Pros WaterfallAgile 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 17 Staffordshire UNIVERSITY School of Computing Slide: 17 Prototyping Comparison of Agile and Waterfall Methods Cons WaterfallAgile 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 18 Staffordshire UNIVERSITY School of Computing Slide: 18 Prototyping Comparison of Agile and Waterfall Methods FactorsWaterfallAgile SizeTailored for large projects and teamsOptimal 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) SkillsHighly 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 19 Staffordshire UNIVERSITY School of Computing Slide: 19 Prototyping Which methodology is “best” “Home Ground” WaterfallAgile High criticality Junior developers Requirements do not change often Large number of developers Culture that demands order Low criticality Senior developers Requirements change often Small number of developers Culture 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 20 Staffordshire UNIVERSITY School of Computing Slide: 20 Prototyping Waterfall beats Agile for visibility on projects  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 21 Staffordshire UNIVERSITY School of Computing Slide: 21 Prototyping Waterfall beats Agile for visibility on projects  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 22 Staffordshire UNIVERSITY School of Computing Slide: 22 Prototyping Waterfall beats Agile for visibility on projects  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 23 Staffordshire UNIVERSITY School of Computing Slide: 23 Prototyping Waterfall beats Agile for visibility on projects  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 24 Staffordshire UNIVERSITY School of Computing Slide: 24 Prototyping Waterfall beats Agile for visibility on projects  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 25 Staffordshire UNIVERSITY School of Computing Slide: 25 Prototyping References  %20comparison%20with%20other%20types%20of%20methodologies/id/ %20comparison%20with%20other%20types%20of%20methodologies/id/  for-Client_2D00_based-work-and-R1-teams.aspx. Published 05 March :39 by Rizwan Tayabali for-Client_2D00_based-work-and-R1-teams.aspx  a_Waterfall_Problem a_Waterfall_Problem 

26 26 Staffordshire UNIVERSITY School of Computing Slide: 26 Prototyping 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 27 Staffordshire UNIVERSITY School of Computing Slide: 27 Prototyping 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


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

Similar presentations


Ads by Google