Agile Software Development 3 Agile and Waterfall methodologies compared

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

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.

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.

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

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

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.

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.

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.

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.

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.”

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.

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.

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.

Comparison of Agile and Waterfall Methods 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

Comparison of Agile and Waterfall Methods 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

Comparison of Agile and Waterfall Methods 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

Comparison of Agile and Waterfall Methods 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

Which methodology is “best” 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: “Home Ground” Waterfall Agile 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

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.

Waterfall beats Agile for visibility on projects Then, you can measure how long it takes to actually complete the tasks in several dimensions: First, in terms of calendar dates: when the task was started and when it was completed. Secondly, you can measure in terms of duration: the number of days it took to complete. Thirdly, in terms of actual hours: the amount of people hours worth of effort it took to complete the task.

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.

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.

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.

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/

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

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