In recent years the words “Agile”, “Scrum” became really popular. These methodologies gradually migrate from start-uppers’ toolkits to large companies like banks, insurance enterprises and retail establishments, i.e. businesses where classic Waterfall methodology has dominated for a long time. More than that, a new class of customers who wish to implement just Agile methodology in development and motivate their choice by “less bureaucracy” and “greater efficiency” reasons arises. Nonetheless, many of the people who try to persuade others to adopt such innovation have a little knowledge of pros and cons of particular methodologies and the real comprehension comes too late together with a painful first hand experience. That is why I would like to carefully compare these essentially different approaches and their ranges of application in this article.

As a preface let me cite a classic joke.

A Russian company and a German company decided to have a boat race. Both teams practiced hard and long to reach their peak performance before the race. On the big day of the race the Germans won by a kilometer. Afterwards, the Russian team became very discouraged and morally depressed. The Russian management decided that the reason for the crushing defeat had to be found. After many weeks of investigation they went to a conclusion that the German team had seven people rowing and one person steering, while the Russian one had one person rowing and seven people steering.

One would think, what has this to do with Agile and Waterfall?

Let us start with definitions.

Waterfall ‑ sequential development model with clearly distinct phases (requirements analysis, drafting, design, coding, testing, integration, publishing, maintenance), provided that the next phase may start only after the previous one has finished.

Common mistake: sequential model does not enable iterative procedure.

In fact, classic Waterfall concept does not govern phase durations. In other words, there is nothing hindering all the phases being crammed in a two week iteration which may be succeeded by another one consisting of the same phases.

Agile methodologies family: models which are primarily directed to iterative procedures; requirement shaping and implementation originate from continuous interaction between self-organized groups (teams) which include experts with different skills. The most renowned methodology built on the Agile principle is Scrum.

The basis of agile methodologies like Scrum is team concept. Decisions are made not by a person but by a team.

Common mistake: Agile has no responsibility areas. It is widely thought that since the Agile’s main unit is a team (which is true) and that team holds responsibility for the assigned work (which is also true), then there is no sense of making arrangements to set who should account for what. That is untrue indeed, since the absence of a person in charge does not lead to the absence of responsibility in general. Agile’s essence is a team internal agreement and not an absence of all agreements. Consequently, a team must assign its responsibility areas by itself and monitor how they are observed.

Waterfall and Scrum comparison

Let us try to compare pros and cons of both principles from the viewpoint of both developers and customers considering key phases of product development and writing down advantages and disadvantages of each approach. As an example of Agile-based methodology we will consider the most popular framework, Scrum.

Let me note that the Waterfall and Scrum variants which are compared here are spherical cows to some extent. In the real life, a decent management may balance most pros and cons of each methodology.

Requirements analysis

Waterfall: Requirements analysis is conducted by a business analyst and/or project manager before any discussions with developer team. A specification is made following basic requirements, which are received from a customer and/or users or derived from an independent product analysis, and is accomplished as normalized documentation in a format which is convenient for the customer and/or developer team.

Pros: Elaborated specifications, absence of team “sacred” knowledge, possibility to detect “bottlenecks” before the development phase begins, capability of agile approach to team composition and resources reallocation (interchangeability), and documentation availability for the project.

Cons: Necessity for a team to hold a person with analytical mindset, delays while development startup and product delivery for specification writing and coordination.

Scrum: Requirements analysis is conducted by a product owner together with a whole team (or in some cases, with a team part). Result is documented as user stories which contain high-level descriptions of business processes, user behavior and product acceptance criteria.

Pros: Opportunity to jump quickly to the development, whole team communication and feedback from a wide range of experts (designers, architects, testers, etc.) on early stages.

Cons: Absence of documentation as such, irreplaceability of team’s key persons because the team holds “sacred” product knowledge, and impossibility to detect “bottlenecks” before the development phase begins.

Design

Waterfall: Design is conducted by a business analyst (if available) together with a project manager and a designer; architects join if it becomes necessary. This phase’s products are: wireframes, designs, detailed datasheets, as well as a set of decomposed tasks which are ready to implement. Tasks are scored by respective experts and verified by a project head or team leaders.

Pros: Precise due dates estimation, comprehensible work plan, simple check procedures, opportunity to enable risk management and mitigation using preliminary analysis, and more atomic tasks tailored to match implementation.

Cons: More micromanagement, necessity to hold a special person, a project manager, who is responsible for the product delivery in a whole, inability to start development of any poorly elaborated functionality.

Scrum: Design is either skipped or conducted while user stories are prepared together with “Development” phase. User stories are estimated in so-called story points which show task complexity from the viewpoint of the whole team. Points are not verified and are subjective.

Pros: High stories estimation speed, whole team participation in scripts’ assessment, capability to estimate abstract user stories which violate SMART principle.

Cons: Lack of formal decomposition which is at the discretion of an expert and may be introduced immediately in the development phase, abstract estimates which do not allow realistic product delivery dates sensing, fundamental incapability of workflow control, absence of risk management (except for team internal discussions).

Development

Waterfall: Development is conducted using tasks which are set in advance. Changes during development are discouraged; it is necessary to get through all previous phases if a change is inevitable.

Pros: Predictability, given that planning is correct, a smoothly running process, inspecting capability at any given stage, risk mitigation (if only the team is strong or average), result and delivery dates forecasting possibility, and absence of special requirements for team members (strong soft skills).

Cons: High scope change cost within margins of an iteration, strict development phases planning necessity, inability to implement vaguely formulated tasks.

Scrum: Development is conducted using user stories (they may be supplied in advance or be created on the run during a sprint). Minor detail changes are encouraged during development, major changes in business requirements in stories are allowed, although discouraged.

Pros: Flexibility, capability to significantly change the development scope, ability to implement initially incomprehensible stories.

Cons: Lack of control (except for general one in teams) and/or its difficulty, inability of delivery dates forecasting (dates are updated on each sprint completion), inevitability of being involved in others’ work for each team member due to joint team responsibility.

Testing and integration

Waterfall: Testing is conducted by a test-plan prepared in advance.

Pros: Reducing regression bugs risk in the product (due to “code freeze” before testing), product quality improvement (quality means relative amount of critical bugs in published product).

Cons: Necessity of time allocation for both testing and debugging.

Classically, during the Testing phase developers are involved in another project or in development of the next product version. However they are required to timely fix critical or blocking errors in order to continue testing and eventually publish the product.

Scrum: In a classic Scrum this phase is not a separate one, testing and integration are conducted during sprints. Untested stories are considered unimplemented.

Pros: Faster delivery of new product functionalities due to lack of a separate testing phase, real-time tester’s involvement in product quality improvement.

Cons: Complexity of tester’s work (developers may process a story in the last day of a sprint, it reduces time available for a tester almost to zero), larger amount of critical errors in published product (regression errors, integration errors).

• It should be noted that the delivery will be “faster” only momentarily. Waterfall does not produce any delays with proper planning, but it is possible for the development start to be delayed due to primary specifications elaboration necessity.

Preliminary resume

Analysis, which is stated above, shows that both methodologies have their rights to exist and have their pros and cons. An important difference between them is that Waterfall is like a “German engine” with cogs in a machine, an organized process with responsibility areas clearly marked. You may interchange developers on the fly. Sure, there are “really important cogs” but the system will be functional.

In turn, Scrum is all about team work, every team member is crucially important. If a product owner poorly sorts out priorities, if a team could not detect potential risks during their sprint planning discussion and could not talk them over, if a tester is not involved in development processes from the very beginning, if a team lacks communication or leadership skills, or responsibility, it will inevitably lead to troubles. The most tragic thing is that classic Scrum has nobody to cope with these troubles, there is no project leader. In fact, a team governs itself. Contrary to common opinion, product owner does not govern anything, that person may be even a regular businessman outside the software development domain.

Another important Scrum development weak point for businesses is its fundamental unpredictability. Without a doubt, it is possible to reevaluate team’s performance on each sprint, but these estimates are shots in the dark because on the first severe risk rise all efforts will be gone (e.g. a new sprint requires 80% resources to front-end and the team consists of one front-end and one back-end). Moreover, the lack of clear understanding how the product works from the start, sooner or later, will lead to an urgency of refactoring, because a developer can not foresee business development (if one can, that one is not a developer) and blueprint the system appropriately, regardless of one’s proficiency.

Conclusions p.1

In reality, methodology choice depends on given data. If you

1. Do not know what you want at the output;
2. Are ready to be personally involved in the project 24/7;
3. Do not have any deadlines you have to meet;
4. Are ready to get less performance in favor to flexibility, then Scrum/Agile is your choice.

If something from the aforementioned is not your case, then you either need Waterfall or a hybrid model, or a classic version of Scrum is not for you.

As a separate point for the list above I may add that

5. You should be ready to have bugs in production. Scrum is an efficient framework for agile development, but due to lack of separate testing phase it has higher error rate. Its ideology essence is “to deliver a marginally functional product is more important than to make development clean”.

Conclusions p.2

Truth, as always, is somewhere in between. Correct methodology choice (regardless of either you work with in-house developers or use outsourcing) directly depends not only on how you feel comfortable to work, or how you think about work efficiency, but also on whether your team has necessary skills, on your cold eyed estimate of your own involvement and work, on goals that are set and on many other issues. This decision should be thought over before the active product development stage since the result is highly depends on it.

Here in 4XXI, using trial and error, we have come to a compromising alternative which combines advantages of both methodologies: phase existence, dedicated project manager (often one also is a product owner), iterativeness and uninterrupted connection with a client. I will discuss it in detail in later articles.