Is Agile or Waterfall the best? The answer is not binary!

White Paper Is Agile or Waterfall the best? The answer is not binary! About this White Paper This paper examines two popular approaches for the management of software development and asks the question; Is there a third way? Author Roger Fance Principal Consultant UXC Consulting

Table of Contents Executive Summary... 1 Introduction... 2 History and Characteristics of the Waterfall Model... 2 History and Characteristics of Agile Software Development... 3 Advantages and disadvantages of Waterfall and Agile... 4 Other approaches... 5 Conclusion... 5 About the Author... 6

Executive Summary This paper compares and contrasts two different and popular approaches for managing software development; Waterfall and Agile. People are often polarised in their views about the benefits and limitations of these approaches. In this paper, we look at the history and characteristics of Waterfall and Agile, compare their advantages and disadvantages and pose the question; is there a third way? 1

Introduction All too often in life, people form a strong view on a subject, heavily invest energy and emotion, take up cudgels and fight to the death, sometimes literally, to defend their position or impose their opinion. Reason, logic, facts, situation or circumstance are ineffective at deflecting those from their cause. Religion, politics and tribalism are frequently at the forefront of these behaviours. There are countless examples where people hold passionate, faith-based or intransigent views to the detriment of finding creative, practical, quick and cost-effective solutions to specific problems. We often find evangelistic fervour when it comes to supporting Waterfall or Agile Interestingly, we often find evangelistic fervour when it comes to supporting Waterfall or Agile software development methodologies and their associated project management techniques. For some, the Waterfall Model is oldfashioned, inflexible or unrealistic. For others, Agile practices are a passing fad encouraging ill-disciplined cowboys to develop software in an uncontrolled and unaccountable environment. So, what exactly are these approaches? Why are views so polarised? Are there only two, mutually exclusive choices? Before we answer these questions, let s have a look at the history of Waterfall and Agile. History and Characteristics of the Waterfall Model The Waterfall Model was first described in a paper in 1970 by Winston R. Royce, a Lockheed aeronautical engineer. His paper, Managing the Development of Large Software Systems, described a stepwise approach starting with system requirements and moving through the phases of software requirements, analysis, program design, coding, testing and operations. These phases have been reordered, renamed and refined over the years, although the basic concept remains the same. Whilst believing in the concept, Royce recognised that the approach was risky and invited failure. He advocated techniques to reduce risk including iterations (a feature of Agile!) between adjoining phases, high-level upfront design before detailed requirements were complete and very detailed and enforced documentation along all steps in the process. Figure 1: An example of a Waterfall software process model 2

Through misinterpretation, this model which came to be known as Waterfall due to the illustrations in the paper that showed steps down through the phases was taken up the US Department of Defence in its standard STD 2167 and later the Europeans. Before long, it became the defacto software development standard. A project management body of knowledge, such as PMBOK and a project management methodology such as PRINCE2 explicitly follow a phased/staged approach and therefore closely support the Waterfall model. History and Characteristics of Agile Software Development Agile software development has a surprisingly long history too, dating back as far as 1957, even though there is a lingering perception by many that it is new thinking to address the perceived shortcomings of traditional practices. A number of different agile practices initially inspired from a variety of sources, including notably, lean manufacturing at Toyota in the 1990s, coalesced into the Agile Manifesto in 2001 when a group of software developers came together to discuss lightweight development methods such as Scrum, Extreme Programming and Feature Driven Development which had also evolved throughout the 1990s. Through misinterpretation, this model came to be known as Waterfall due to the illustrations in the paper that showed steps down through the phases The Agile Manifesto describes four themes and twelve underlying principles for software development. Working software, adaptability to change, personal interactions and collaboration are more highly valued than prescriptive processes, documentation, contracts, tools or plans. Incremental delivery of the highest business value first or reduction of the highest risk as quickly as possible through iterative development of software are at the foundation of the Agile concept. Twelve principles of Agile Software development described in the Agile Manifesto 1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2 Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage. 3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4 Business people and developers must work together daily throughout the project. 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7 Working software is the primary measure of progress. 8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9 Continuous attention to technical excellence and good design enhances agility. 10 Simplicity the art of maximising the amount of work not done is essential. 3

11 The best architectures, requirements, and designs emerge from selforganising teams. 12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. In 2004, the Agile Manifesto was supported by the Declaration of Interdependence due to growing recognition that there was also a need for a broader statement addressing project management and general leadership. The statement, empathetic to the principles and practices behind Agile thinking, focused on value, customers, individuals, teams, uncertainty and context. Agile acknowledges requirements uncertainty or rapidly changing market conditions by working in short iterations to deliver incremental business value Advantages and disadvantages of Waterfall and Agile So, what are the benefits and limitations of each approach? Well, waterfall is easy to understand and communicate to a range of stakeholders. There is natural appeal in its simple, linear, structured approach which usually combines formal phase gating; preventing the project progressing until key stakeholders are satisfied the previous phase has been properly completed. Greater time spent in requirements and design is seen to reduce later coding and testing costs. Waterfall planning is predictive and can therefore inform the development of longer term business plans and road maps, although longer time frames also engender greater uncertainty. Waterfall is perceived to be more disciplined than Agile, but this is highly contentious as Agile enforces more discipline than is immediately obvious. On the downside, Waterfall is a less adaptable to changing business requirements which occur when, at the outset, business people do not know exactly what they need or a changing market compels a change of direction. There is also greater emphasis and effort devoted to following prescriptive process or transient project control documentation which contributes little or no value to the required business goals. Agile acknowledges requirements uncertainty or rapidly changing market conditions by working in short iterations to deliver incremental business value. Each iteration includes planning, requirements analysis, design, coding, unit testing and acceptance testing to deliver production-ready code representing a sub-set of the overall solution. This is facilitated by small, cross-functional teams that combine the complementary skills and experience of business and IT people. These teams are self-disciplined and self-organised although they take their business priority direction from the key business stakeholder. Project Managers often take on the role of servant-leaders, facilitating information exchange, protecting the team from interference and removing progress blockers rather than directing the team. Agile has its weaknesses too. There is a heavy reliance on close business involvement, ideally on a daily basis. This places a great burden on business people who have to also juggle their daily operational responsibilities. Teams are more efficient if they are small, co-located and have the right physical working environment which is often hard to achieve in large, geographicallyseparated organisations. It can be a lot harder to scale up and control Agile teams for larger software development efforts or to integrate them with other areas of a business that do not operate using these techniques. Agile is not very effective in integration projects or particularly valuable where requirements are well understood and stable. 4

It is important to be agile and not just do Agile. In other words, the chosen Agile methodology should not be adhered to rigidly if circumstances demand change. Individuals, teams and organisations should be flexible enough to modify their approach to suit changing conditions. In the world of Agile, this principle is known as Inspect and Adapt. It is important to be agile and not just do Agile Figure 2: An example of an Agile software development approach using the Scrum methodology Other approaches In recent years, work has been done to combine the best of predictive and phased approaches with adaptive and iterative approaches forming hybrid methodologies such as the Rational Unified Process (RUP) or the lightweight Agile Unified Process (AUP). More detailed examination of these methods will form the basis of a future White Paper. Applying these methodologies or adapting in-house development methodologies and project management practices to the business circumstances are the third way. The answer to the question Is Agile or Waterfall the best is not binary! Conclusion There are a number of approaches for managing software development; two of these have been examined in this Paper. Company culture, individual personalities, the nature of the project and a range of other factors should be taken into account when choosing a software development and associated project management method. Pragmatism should always trump idealism in the pursuit of delivering real business value. 5

About the Author Roger Fance is a Principal Consultant at UXC Consulting. He has 28 years international experience in Professional Services, Financial Services, Government, Telco and ICT Vendors working on both business and IT programmes and projects using a range of different approaches and methodologies. As a Certified ScrumMaster, PRINCE2 Practitioner, MSP Advanced Practitioner and holding a Diploma of Project Management, he also heads the UXC Consulting Agile Centre of Excellence which supports clients and staff with Agile knowledge and training resources. PRINCE2 is a registered trade mark of the Cabinet Office. PMBOK is a registered mark of Project Management Institute, Inc. 6

Adelaide Office Level 12, 45 Grenfell Street Adelaide SA 5000 Phone: +61 8 8231 6999 Brisbane Office Level 5, 196 Wharf Street Spring Hill QLD 4000 Phone: +61 7 3831 2933 Canberra Office 4a Whyalla Street Fyshwick ACT 2609 Phone: +61 2 6222 6500 Melbourne Office Level 15, 575 Bourke Street Melbourne VIC 3000 Phone: +61 3 8623 1300 Perth Office Level 2, 30 Richardson Street West Perth WA 6005 Phone: +61 8 9321 3166 Sydney Office Level 4, 31 Market Street Sydney NSW 2000 Phone: +61 2 8297 4600 Malaysian Office Level 20 Menara Standard Chartered No. 30 Jalan Sultan Ismail 50250 Kuala Lumpur Phone: +60 3 2117 5197 Singapore Office Penthouse Level Suntec Tower Three 8 Temasek Boulevard Singapore 038988 Phone: +65 6866 3632 www.uxcconsulting.com.au 1300 678 426 Local decision making, national capabilities and global best practice allows UXC Consulting to be flexible in its approach; be relevant to your needs; and provide highly skilled advisors to deliver best practice service outcomes. World class brands coming together: GQ-AAS Lucid IT Opticon Planpower info@uxcconsulting.com.au @UXCConsulting www.linkedin.com/company/uxc-consulting Version 1.0