Keywords

1 Introduction

In almost every project, some type of methodology or combination of methodologies is followed, although we may not be aware of it [1]. A methodology is a structured approach to solving a problem [2].

In software development, two types of methodologies are mainly used – traditional and Agile [3]. Traditional (or rigorous) methodologies are often voluminous and are based on the assumption that the processes involved in building an IS/ICT can be described, planned, managed and measured – one of the most widely used traditional methodologies is Waterfall [4], where one phase needs to be finished before moving to another phase. Agile methodologies, where several phases run at the same time, are based on unpredictability and responsiveness to rapidly changing requirements. Therefore, the main difference between these methodologies is in the ability to adapt to changes [4].

Many companies are using the so called “hybrid approach” to maximize benefits from both methodologies [5]. Kuhrmann et al. [6] defined the hybrid approach as any combination of Agile and traditional approaches that an organizational unit adopts and adapts to its own needs.

One of these hybrid approaches is the Water-Scrum-Fall described by West [7]. There are no specific guidelines for Water-Scrum-Fall, so the implementation of the methodology itself can vary from company to company. Furthermore, organizations often end with following Water-Scrum-Fall unintentionally without recognizing it [7].

The aim of our research was to describe the reality of Water-Scrum-Fall. We focused on large corporate companies (with more than 5000 employees) within the Czech market that are more inclined to use this approach [6]. In this paper, the following research questions are addressed: 1) What does Water-Scrum-Fall phases consist of in selected companies in the Czech market? 2) Which roles are part of the Water-Scrum-Fall phases in selected companies in the Czech market?

Our research helps to shape the definition of Water-Scum-Fall and brings real-life examples. Additionally, our research can help organizations with adoption of the hybrid-approaches that improve the agility of organizations [9].

2 Related Work

In this section we present related literature that represent the current state of art. The intention is to introduce the reader into the context and the current state of art.

Kuhrmann et al. [6] focused on development approaches used in practice and triggers for hybrid approaches. Kuhrmann et al. [6] described that large and very large companies as well as start-ups tend to use hybrid methodologies for better risk management. The reasoning behind the change to hybrid methodologies can have various drivers [8]. Hartman et al. [9] described that companies are using hybrid methodologies as a step towards agile organization.

Studies [6, 8, 10] are discussing how companies that switched to using hybrid methodology reached similar results. The methodology was developed, adapted and improved over time and based on gained experience. Only around 20% of companies switched to hybrid methodologies based on a plan and newly created processes [6, 8].

Water-Scrum-Fall is a term that was coined by West [7]. West described the three phases of Water-Scrum-Fall. The first (Water) and third phase (Fall) are based on the Waterfall model [11]. In Water - upstream project planning takes place, and plans for time, budget, and scope management are set up. Additionally, user requirements and system requirements are created. Next, the development phase (Scrum) is based on Scrum [12]. In Scrum phase – design, development and implementation is done in iterative steps by the development team. Fall - when the development team has implemented all requirements, the solution is delivered using the traditional procedure based on establishing quality control gates to reduce the frequency of software releases [7].

Reiff and Schlegel [13] described Water-Scrum-Fall as a good introduction for companies that have been using the traditional approach and are now moving towards Agile. They concluded that organizations with well-structured processes with systematic milestones are suitable for the implementation of a hybrid approach. The maximization of project success was mentioned as one of the main advantages.

Butgereit [14] discussed five lessons learned during the implementation of Water-Scrum-Fall for a project in South Africa. These lessons were incorporated in the interview guide for our research.

In the research conducted by PMI [15], about 20% of respondents stated that they are using hybrid methodologies. Menčík et al. [16] focused on the state of Agile in the Czech Republic, in which 16 companies out of 209 marked the combination of Waterfall and Scrum as their used methodology. However, the primary focus of the study [16] was on Agile adoption.

Overall, there is little known about the real-life implementations of Water-Scrum-Fall, and calls for additional empirical research were made [8, 13].

3 Research Method

This section describes study context, data collection process, and analysis. Our study was based on an exploratory multiple-case study [17]. Eight interviews in four companies were conducted, and the results were analyzed using thematic analysis.

Context.

For the selection of participants, purposive snowballing sampling was used [18]. Snowball sampling involves asking participants for recommendations of acquaintances who might qualify for participation, leading to “referral chains”. The snowballing gave us access to four companies and 8 participants. Each company has over 5000 employees and belongs to highly-regulated sectors.

All companies were using Waterfall before including Agile practices, which moved them to a currently prevailing hybrid approach. Company A has been using this approach for approximately 7 years, company B for 4 years, and companies C and D for over 3 years.

During the study, in companies A, B, and D participants were involved with small projects and sub-projects of a bigger product. In company C participants worked on continuous product development. A, B, and D had the teams fluid, always rebuild around specific project. The team from company C was stable. We were not able to get many insights to the current projects the participants were involved with, but for A and B process automation was mentioned. The team from C was working on implementation of the changes to better comply with GDPR. When interviewing participants from the same company, people from different roles or departments and teams were selected. The background of each participant is presented in Table 1.

Table 1. Participants in the study
Full size table

Data Collection.

Interview Protocol was created per [19] and used to guide the semi-structured interview. For the interviews, each participant was first asked about their background and context. Then, seven main themes were defined, each consisting of questions adhering to their sub-themes.

An overview of the main themes and their sub-themes is given below in Table 2.

Table 2. Themes for interview
Full size table

Interviews were done through the video conferencing tools Google Meet or Microsoft Teams, recorded, and transcribed verbatim. The interview lengths ranged from 23 to 50 min.

Data Analysis.

Thematic analysis [20] was used to analyze the data. The transcripts were subsequently coded in QDA Miner Lite. First, the central themes were chosen, of which there are seven in total. The identified central themes were: Size, Duration; “Water”, Scrum, “Fall”, Project success rate, Evaluation, and Future. Next, for each central theme we identified sub-themes. Sub-themes emerged during the data analysis. The themes and sub-themes are described in Table 3.

Table 3. Thematic analysis themes and identified sub-themes
Full size table

4 Results

In this section, we present distillate for each investigated theme, supported by evidence gathered during the interviews in the form of quotations. Every quote is referenced to the corresponding participant from Table 1. All the interviewees confirmed that their organizations attempted to become agile. None of the interviewees explicitly said that they are following Water-Scrum-Fall. However, the results showed that Water-Scrum-Fall was the reality.

Size, Duration.

The duration of projects varied from 3 months to a few years. On average, the projects are about 6 months long. “Year is probably the longest time, but usually six months is optimal.” [P1] The teams are rather small and usually consisted of 5 people in order to maintain easy communication. “The less people, the better. Ideally, we’re talking about maybe a team of five people.” [P5]

“Water”.

After project initiation, requirement gatherings usually take up to 3 months. “It can be anywhere from one to three months.” [P8] Roles such as customer, analyst and architect are involved. “So first the business brief is written, then it goes to the analyst and architect.” [P4] There is always at least one document that is created that contains very detailed specifications of the software to be developed, including flowcharts and server specifications. “[…] there has to be a document that is called the Business Specification and Solution Blueprint, and it actually describes what exactly needs to be done, in great detail.” [P8]

Scrum.

The development follows the Scrum methodology [12], which is being locally modified. Often the project manager is involved, acting as both project manager and Scrum Master. “[…] so we do not have a Scrum Master. Basically I do it, because I do the meetings, but otherwise I don’t really do anything physical in terms of projects.” [P1] The customer acts as the Product Owner, a role that is not always followed correctly. “The role that we struggle with a little bit is Product Owner, often he is formally defined, but people are still learning how to use it.” [P2] The development team consists of analysts, testers and developers, “[…] we also have Subject Matter Experts, which is somewhere between a tester and an analyst.” [P6]

The largest modifications can be observed in Scrum events, especially in Daily stand-ups and retrospectives. Daily stand-ups vary in their length, and most importantly, they are not always done on a daily basis. “We have stand-ups once every two days - Monday, Wednesday, Friday - and it lasts about 30 min.” [P6] As for retrospectives, if the team does not feel the need to conduct them, or if there is not enough feedback, they are often skipped or dealt with in other events, such as during the daily stand-up. “We don’t have a retrospective, probably we haven’t even noticed the need to have one yet.” [P3]

“Fall”.

Documentation is usually written after the software (or at least the first version) is developed, and is usually created by updating the detailed specification document that was prepared during the Analysis phase. “[…] of course not everything will be created at the moment when it should be created, but at the latest during the phase Administrative Close it will be finished.” [P2] There is always some sort of user acceptance before deployment; in some cases, the acceptance is based on acceptance criteria, and in other cases the acceptance is done by the Product Owner. As far as the timing of deployment is concerned, usually the development team itself can’t influence the timing. In all selected companies there are explicit “release windows” when deployment can happen. Release windows are set by the Release Manager. “The releases are company-wide, so they’re once a month, meaning it’s not after every sprint.” [P7]

Project Success Rate.

In selected companies, projects are considered very successful. P4, P2 and P8 stated that almost 100% of their projects are delivered on time and on budget; however, these attributes are moved by change requests, so the latest deadline is often different to the originally-expected one. Additionally, a certain user resistance was encountered. Users try to use the new solution minimally or avoid using the solution completely. “Users tend to boycott anything new.” [P3]

Evaluation.

One of the disadvantages is that a large change can affect the entire project plan. “When the projects are for a year, it’s very hard to hit a specific month if you have a change that wasn’t planned for.” [P5] Another disadvantage was connected to the mindset associated with Agile – people involved in projects were not able to be self-organized. “They have to be proactive. There are high demands on human qualities.” [P1] Participants articulated the unpreparedness for change in the company as a whole. “That organization has to be ready for it, and our organization as a whole is not ready for it. […] we have a methodology for that, but it just doesn’t work 100%.” [P4] Yet, the teams seemed to benefit from the introduction of the Scrum phase. “[…] it’s more fun and more lively, more active, if I see some results in 14 days.” [P7]

Future.

All companies in the study are using Water-Scrum-Fall, except for company C, which is already switching towards the agile way of working. However, the transition phase was described as “painful” and “chaotic” by both participants P6 and P7. In company A, we observed an approach which could be called Water-SAFe-Fall. There were many projects with approximately 100 people involved. Company A wants to transform to an agile company using SAFe, but the structure and culture are not prepared for the transformation yet. “So I think there is still a big pitfall and a big piece of work that especially the big corporations have to do, and that is to prepare the culture, the mentality of that big environment so that agile can work in it.” [P2] Companies B and D are not planning to change current methodology anytime soon.

4.1 Roles, Events, Artifacts in Water-Scrum-Fall

Based on the conducted interviews, we have enhanced the Water-Scrum-Fall figure presented by Reiff and Schlegel [13] with discovered roles, events and artifacts. The result is visible in Fig. 1. Additionally, we have added the “Post-completion” phase, as all the participants mentioned team participation in increased support after the release. Furthermore, in this phase the teams are gathering feedback for their solutions. “[…] after they are using the product for some time we come and ask “Are you happy with the solution, do you need anything more?” [P2] The intention is to identify “[…] if there is a need to change anything, or support the change anyhow, so that the solution could be used correctly” [P3]. In case changes are needed, the process has to be restarted from the Water phase.

Fig. 1.
figure 1

Reality of Water-Scrum-Fall

Full size image

5 Discussion

Gathering insights into Scrum-Water-Fall from large companies in the Czech Republic, we collected a data set containing qualitative data from four large companies through interviews with eight participants.

The examined companies tend to move towards agile methodologies. Aligned with Hartman et al. [9] findings, companies mix traditional approaches with agile methodologies as the first step towards an agile organization. Generally, the hybrid model was very similar in all companies. We saw the difference in the Scrum phase where tailoring of the Scrum roles and events occurred.

Participants reported struggles with combining traditional detailed up-front planning and detailed analysis [4] with the ability to adapt to changes, which is connected with Agile [4]. “[…] there has to be a document that is called the Business Specification and Solution Blueprint, and it actually describes what exactly needs to be done, in great detail.” [P8] The specification “Water” phase is followed by the actual development “Scrum” phase. Teams are following modified versions of Scrum [12]. The focus on team synchronization (daily stand-ups) and continuous improvement (retrospectives) is minimized or omitted. “We don’t have a retrospective, probably we haven’t even noticed the need to have one yet.” [P3] None of the participants mentioned sprint reviews, close collaboration with the customers, or another feedback loop to be happening during the development phase. Some form of acceptance testing is conducted only at the end of development during the “Fall” phase, and the actual feedback from end-users is gathered in the Post-completion phase.

The poor Scrum implementations suggest that respective teams haven’t been properly familiarized with or educated about the ideas and benefits of agile methodologies. Still, even the partial implementation seemed to bring positive effects on the team. We accompany poor implementations with missing senior roles, like scrum masters, to educate teams and organizations in proper agile practices. “[…] so we do not have a Scrum Master. Basically I do it, because I do the meetings, but otherwise I don’t really do anything physical in terms of projects.” [P1].

West’s [7] assertion that Water-Scrum-Fall is a reality for many organizations today, whether intentionally or unintentionally, was confirmed in our research. Similarly the results confirmed improvement in project success rate, described as one of the benefits of hybrid approaches in [13]. However, participants considered only delivery on time and on budget as the success factors. The evaluation of the solution usefulness is typically happening in the post-completion phase, and for potential changes the Water-Scrum-Fall has to be restarted. This limits the agility in the software development.

All examined organizations come from domains that are subject to regulations and domain standards. These constraints often force them to work in a way that is not purely agile but may require traditional processes. Hence, Water-Scrum-Fall could be the answer. Still, it seems that companies would like to achieve additional benefits reported with agile approaches but are not willing to perform big changes [6]. “That organization has to be ready for it, and our organization as a whole is not ready for it. […] we have a methodology for that, but it just doesn’t work 100%.” [P4] The discovered reality of Water-Scrum-Fall suggests that organizations just bring in some of the prescribed events and roles from Scrum [12], but tailor the methodology to fit their existing approaches, which results in the similar Water-Scrum-Fall as before.

Conclusion.

Our study revealed that Water-Scrum-Fall was a reality in the examined organizations and described the content of phases and roles in large companies in the Czech Republic. Modified agile methodologies are used in Water-Scrum-Fall. Hybrid approaches still require rigorous analysis before the development is started, which strongly limits the agility in following development. Customer involvement or feedback loop is omitted in the development process. We accompany poor implementations with the unpreparedness of companies to fully adopt Agile and missing senior roles, like scrum masters, to educate teams and organizations in proper agile practices.

Limitations.

The general limitation of qualitative research is difficulty in generalizing. Additionally, our sample was influenced by snowball sampling, which basically located a source of potential participants who are convenient in their proximity and willingness to participate. Still, it brings in-depth view of the research area. Our study was conducted only in companies participating in the Czech market, therefore, it may be impacted by local bias. Despite the limited number of participants, we believe that our study provides valuable insights into real-life Water-Scrum-Fall implementations.

Future Work.

More empirical research is needed to confirm findings from this study in different environments, companies of different sizes, and from various sectors.