Back to the future: origins and directions of the “Agile Manifesto” – views of the originators

3.2.1 Survey

Research design. According to Yin (2009), the type of the research questions defines the usage of different research methods. The defined research questions are mainly “what”-questions which are used in exploratory studies. This class of research question are knowledge questions resulting in a clearer understanding of the phenomena (Easterbrook et al. 2008). According to Forza (2002), surveys can be divided into three different groups: exploratory surveys, descriptive surveys, and explanatory surveys.

Our study is founded on a qualitative and a descriptive survey design to obtain knowledge about the manifesto. The survey aims at describing and explaining the phenomenon of the manifesto by using a questionnaire for data collection. A characteristic of survey research is the selection of a representative sample from a well-defined population (Easterbrook et al. 2008). The sample selection is explicitly limited to the 17 original authors of the manifesto because we wanted to obtain first-hand information. With this selection, the sample size is sufficient to represent the population of interest.

The survey questions are classified as open questions according to Dresch et al. (2015). The number of questions is limited to five in order to shorten time to answer the questionnaire. This increases the respondent involvement and thus reduces the amount of missing data (Forza 2002). Furthermore, the participants are asked for permission to use the given answers and information anonymously in this publication.

Forza (2002) recommends conducting a pilot test of the questionnaire with colleagues, industry experts and target respondents. A pilot test was conducted with another researcher and an industry expert. The feedback they provided led to some modifications of the questionnaire to make the questions more comprehensible for the participants.

Execution. The survey was conducted in January and February 2017. We sent an invitation letter and the questionnaire to all contributors of the manifesto. In total, we received 11 answers.

In order to collect the data, we chose two different ways to get in touch with the original contributors and to send them the questionnaire. First, we searched for email addresses on the private blogs and homepages. We directly contacted Martin Fowler and Ron Jeffries via personal email. Both provided answers to the questionnaire. To get in contact with the other 15 participants, Researcher 1 signed up for a recruiter membership on LinkedIn³. With the recruiter profile, it was possible to get in contact with the original contributors and to send them the questionnaire via LinkedIn. The recruiter membership contract was canceled after one month. Within that month, we received answers from 9 participants.

In most of the responses, the items of the questionnaire were directly answered. The length of the provided answers varied from one sentence per question to multiple pages to answer the complete questionnaire.

We were invited by one participant to a Skype™ call to discuss the questions face-to-face. The following interview was a one-hour Skype™ conference in which two researchers and one contributor participated. The interview was recorded by both researchers, and the meeting minutes were subsequently combined.

Two other participants from the study referred to the ongoing project “Agile Uprising Agile Manifesto Review” conducted by Ryan Lockard and James Gifford (2016) (cf. Section 3.2.2).

Data analysis. The collected qualitative data was analyzed using categorization and data coding. According to the classification of Stol et al. (2016), the coding concepts of Straussian Grounded Theory were used. We used the presented three coding phases: open coding, axial coding, and selective coding (Stol et al. 2016; Corbin and Strauss 1990). The interpretive process of open coding generates categories and concepts by breaking down the data analytically. The written answers were chunked into small, logically related phrases and tagged with a code. Each code represents a certain theme, whereas the codes form a hierarchy of codes and sub-codes in the axial coding. In the selective coding, the central categories were defined. This leads to the final result, a formalized body of knowledge (Runeson and Höst 2009). To analyze, categorize and sort the collected data, we used the tagging and coding functionality in the reference management and citation tool Citavi.

3.2.2 Interview study

The interview study was mainly conducted by Ryan Lockard and James Gifford as part of the “manifesto authors review” in a podcast (Lockard 2016) for the Agile Uprising network. The network focuses on the advancement of the agile mindset and global professional networking between leading agilists. The network purely focuses on the advancements of the agile craft removing external influences from sponsors, partners and other organizations (Lockard 2016).

Research design. Since October 2016, Ryan Lockard and James Gifford have performed an interview study (Lockard 2016), asking the original contributors about the reasons for participating in the meeting that ended up with the manifesto.

The study has been designed as an exploratory semi-structured interview. For the interviews, an interview guide has been designed. This guide has been developed in an iterative way. It was pilot-tested and adjusted to the problems which have arisen. The structure of the guide is divided into three parts: (1) before the meeting, (2) at the meeting and (3) afterwards (cf. Appendix A)

Execution. The interview study took place from October 2016 till March 2017. Getting in touch with the contributors was an iterative process. Ryan Lockard and James Gifford first contacted three of them, namely John Kern, Alistair Cockburn and Bob Martin. In the interview, they asked them to share the idea of the podcast with other contributors. This way, another batch of three contributors to continue was created. In total, 14 contributors were interviewed. Two of them have been interviewed in person (John Kern and Alistair Cockburn), the others have been interviewed via Skype™. Skype™ sessions and face-to-face interviews were recorded and afterwards published in the uprising podcast channel.

Data analysis. The data analysis was conducted by Researcher 1 and Researcher 2 by coding the meeting minutes. The coding process followed the coding concept presented in Section 3.2.1. The results have been analyzed according to the research questions.

3.2.3 Workshop

After having answered the questionnaire, Arie van Bennekum invited Researcher 1 and Researcher 2 for a 1-day workshop to discuss the origins and future directions of the manifesto. He furthermore suggested, to discuss the future of the agile movement in general. He organized a workshop to discuss these topics in detail.

The workshop took place in Oktober 2017 in Rotterdam, Netherlands. The workshop was separated in two sessions of 2, 5 h each. In the first session, Researcher 1 and Researcher 2 presented the results from the survey and discussed the findings with Arie van Bennekum. In the second session, Arie van Bennekum presented his view on the future of the agile movement and the importance of agile transformation. Researcher 1 and Researcher 2 wrote meeting minutes and merged them after the workshop.

The data analysis was done by Researcher 1 and Researcher 2, according to the previously identified codes from the data analysis of the survey.

3.2.4 Secondary data

Some participants of the survey referred to previously held presentations at conferences, and interviews about the manifesto in previous publications. We used this information as a secondary data source. Therefore, we also transcribed the talk “Agile is Dead” from the conference “GOTO Amsterdam” given by Dave Thomas (2017) in 2015. Furthermore, we included an interview with Kent Beck (2011) from 2011. To analyze, categorize and sort the collected data, we used the tagging and coding functionality in the reference management and citation tool Citavi. The secondary data sets are limited to the recommendations given by the survey participants.

4.1.1 Dynamic Systems Development Method (DSDM)

DSDM, first published in February 1995, is an agile framework developed and supported by the DSDM Consortium for dynamic, non-predictable projects. It focuses on early delivery in an iterative development process with close customer collaboration. Nowadays, it also includes project management (the Agile PM Framework). It consists of seven phases, for instance preparation of a project and deployment to the customer. One practice of DSDM is “time-boxing”. The project is sliced into time-boxes which could themselves be sliced into smaller time-boxes. Requirements are prioritized per time-box (DSDM Consortium 2018). DSDM has its origin in the RUGs, the “Rapid Application Development user groups”. Therefore, the Intellectual Property of DSDM is a community owned Intellectual Property.

Arie van Bennekum mentions that at the time they were “writing the manifesto, the other guys receive DSDM as quite heavy, [and] it did not get that much attention in the US” (Lockard and Cleff 2016). This is also apparent in Mike Beedle’s statement that he “didn’t know DSDM” (Lockard and Gifford 2016a) at that time. Also Jeff Sutherland mentions that he “did not know anything about DSDM, [and] [...] just met Arie the first time at the meeting” (Lockard and Gifford 2017a). Alistair Cockburn remembers that “Arie van Bennekum had to describe DSDM” at the beginning of the meeting.

4.1.2 Test Driven Development (TDD)

TDD helps to control the software development process by using tests. The procedure is cyclic and starts by writing a test, which consequently fails in the first attempt due to missing code. In the next step, the developer implements as much code as necessary in order to fulfill the test criteria. Afterwards, code and tests get refactored. Kent Beck presented this incremental method in detail in 2003 (Beck 2003). TDD was part of the XP practice of test-first, which was already presented in 1999 (Copeland 2001).

James Grenning states that people “are somehow religious about” (Lockard and Gifford 2017b) TDD. As he points out, it “is more like being an engineer. It’s a problem solving technique one should use when it is appropriate” (Lockard and Gifford 2017b). Ron Jeffries mentions that for refactoring it is necessary to implement the TDD principles and to be able to ship it within one increment (Lockard et al. 2017). Bob Martin refers to his first pair programming and Test Driven Development session with Kent Beck. He admits that he has “never seen something like this before, [...] [and he has] never seen anybody writing code in this crazy, nutty, high-speed style” (Lockard and Gifford 2016).

4.1.3 Adaptive Software Development (ASD)

In 2000, Jim Highsmith published his book “Adaptive Software Development” (Highsmith 2000). He mentions that he was writing the “book and there was a chapter in there, about complexity theorem and systems” (Lockard and Gifford 2017c). He remembers that he “started looking into that, as a way of really [...] become more adaptive. That’s where adaptive software development came from.” (Lockard and Gifford 2017c). ASD provides a collaborative approach to manage complex systems by an adaptive culture in which change and uncertainty are assumed to be the natural state. ASD builds a frame containing only a few guidelines. It consists of speculating, collaborating and learning. Speculating includes the planning process and collaborating aims towards implementation. Teamwork is one key characteristic of the collaborating phase. Learning cycles ensure quality and help in integrating so-called “learning loops”.

4.1.4 Design Driven Development (D3), Refactoring

D3 aims at creating innovative requirements to build better solutions. It is based on the following assumptions: Design fulfillment is very important for success. Design is an event randomly occurring during the conception process. This is the key to innovation. The best design is always the result of continuous facilitation and refinement. In 1999, Martin Fowler published his book “Refactoring” (Fowler 1999) to improve the design of any existing code. He states that badly designed software can be reworked into a good one by refactoring the code continuously. He provides principles of refactoring which go hand in hand by setting up required tests to validate the refactored code (Lockard 2017).

Martin Fowler concludes that “there are still the very basics of refactoring which are not understood by people” (Lockard 2017). He is disappointed with that fact because, for him, it “was the most mind-blowing thing” (Lockard 2017).

4.1.5 Scrum

Scrum itself is not a software development technique, but a framework for managing various kinds of projects. Scrum provides the separation of the whole project into sprints (Schwaber 2004). A sprint is a defined period of time in which to implement a given set of requirements and make them ready for potential delivery. It consists of several core activities, artifacts and roles which need to be extended by suitable practices. The core activities describe meetings during the sprints, like a daily Scrum or a retrospective (Schwaber 2004). The widely used artifacts comprising a product backlog consist of all requirements which have not been implemented of the project, the sprint backlog which defines all tasks for the ongoing sprint, and a product increment which is the sum of all already finished product-backlog-elements (Schwaber 2004). There are mainly three roles involved: the Product Owner defining the requirements, the development team fulfilling the Product Owner’s requests and the Scrum Master helping to create a good atmosphere for the team and to preserve agility (Schwaber 2004).

Ron Jeffries mentions that“Jeff Sutherland had used Scrum since the middle 80s” (Lockard et al. 2017). Jeff Sutherland mentions that he “hired Ken [Schwaber] for a huge banking project” (Lockard and Gifford 2017a) and “wrote a paper 1995 [with him] to kick it off”(Lockard and Gifford 2017a). He emphasizes that he was “driving Scrum before, starting from 1993” (Lockard and Gifford 2017a). His intention was to “teach the style of Scrum to help the people to improve and accelerate” (Lockard and Gifford 2017a). Mike Beedle was the first adopter of the Scrum method. He mentions that using Scrum “was like a miracle drug”(Lockard and Gifford 2016a). He remembers that they had a “project which was nearly three years late but [...] saved the project with Scrum” (Lockard and Gifford 2016a). Arie van Bennekum points out that nowadays people do often not “know that there were more agile methods than Scrum” (Lockard and Cleff 2016).

4.1.6 Crystal

Crystal, developed by Alistair Cockburn, is a family of software development methods in agile development. Each “member of this family” usually has a color, with the basic variant being called “Crystal Clear”. Crystal is based on a couple of principles like passive knowledge transfer, continuous delivery, frequent releases and automated testing. Crystal is configured for one project and needs to be adapted for another one. Cockburn (2005)

Alistair Cockburn came up with crystal in the 90s. He mentions that he realized that “different projects need different things and [...] [it is necessary to] characterize a situation which calls for a certain type of a behavior” (Lockard 2016b). To distinguish the situations, he “used crystal as a way to separate them out” (Lockard 2016b) and assigned different colors to them. However, Jeff Sutherland mentions that he “never had any exposure to Crystal” (Lockard and Gifford 2017a). In contrast, Mike Beedle states that he had “heard about crystal from Alistair” (Lockard and Gifford 2016a). He further admits that there were only “few instances of crystal” (Lockard and Gifford 2016a). In addition, Ron Jeffries maintains that “Crystal never seemed as a method that is competing in any way” (Lockard et al. 2017).

4.1.7 Extreme Programming (XP)

In 2000, Kent Beck published his first edition of his book “Extreme Programming explained” (Beck 2000), which marked the starting point for the success of XP. In XP, several practices are described. The most famous and widespread one is pair programming, besides small releases and continuous integration.

Ron Jeffries remembers that Kent Beck invited him “to help coaching, which turned out to be the first Extreme Programming installation”(Lockard et al. 2017). He mentions that it was the effort of Kent Beck who put together the development process, defined “what should be done, and named it Extreme Programming”(Lockard et al. 2017). He further argues that one reason why XP became well-known is based on the fact that Kent Beck did not brand mark it (Lockard et al. 2017).

Bob Martin got in touch with XP, when he“stumbled across Kent Beck’s writings on Extreme Programming” (Lockard and Gifford 2016). He recognizes that “this is great, except for that ridiculous testing thing, the whole notion of test first, that’s nonsense, but the rest of it, the rest of it sounds pretty good” (Lockard and Gifford 2016). Bob Martin recalls that they “made a mistake in the early days of XP, when we put that high emphasize on pair programming”(Lockard and Gifford 2016). He emphasizes that“in realistic agile teams it happen less 50% of all time” (Lockard and Gifford 2016).

4.1.8 Pragmatic programming

In their book “The Pragmatic Programmer: From Journeyman to Master” (Hunt and Thomas 2000), Dave Thomas and Andy Hunt defined software development as a craft. They give special insights into the topic, and tips based on their experience. First, they advise the programmer to care about the craft. A lot of tips represent what later reappears in the agile methodologies. Two examples are tip 16 ”Use prototype to learn” and tip 62 ”Test early, test often, test automatically” (Hunt and Thomas 2000). Finally, they outline a pragmatic way for the efficient, profitable development of high-quality products based on easily understandable tips.

Andy Hunt and Dave Thomas were looking at pragmatic programming which “is considered not really as a methodology but just more common sense” [Anonymous]. The word “methodology was a bit of a dirty word at the time and we were understandably cautious” [Anonymous]. They both “felt the role as the Pragmatic Programmers was to help defend the interests of the ordinary developer” [Anonymous].

4.1.9 Modeling languages

Steve (Stephen) Mellor created a modeling language that was the forerunner to UML (Shlaer and Mellor 1988). To model components, sequence diagrams, collaboration diagrams, state-transition diagrams, and a combination of state charts and activity diagrams are used. The modeling language then seamlessly translated the component models into code. Code components are compiled into an executable component that is deployed (Mellor and Balcer 2002).

James Grenning remembers that “Steve was model driven, so he really wanted to build a model and then we can convert them out into code” (Lockard and Gifford 2017b). He further points out that “the abstraction that Steve brought in was executing. It doesn’t matter if it is code or model or whatever” (Lockard and Gifford 2017b).

Steve Mellor emphasizes that it is essential “to think about a model is some high-level abstract view of something that takes away certain details, such as processors, data structures, that kind of stuff” (Lockard and Gifford 2017). He identifies the “underlying reason why peoples say [that models are bad] [...], because they think that models are just sketches and then you write code. And that was not the view that I took, not at all. The model was in fact the code, it just had an abstractive way, sort of relevance need to be filled out separately, not added, but filled out worked on separately” (Lockard and Gifford 2017).

4.1.10 Feature Driven Development (FDD)

FDD was first described by Jeff De Luca. The FDD process was influenced by Peter Coad and Jon Kern through their collaboration in writing the book “Java modeling in color with UML” (Coad et al. 1999). The process of FDD is model driven, and in the development, this is done in short iterations. The process is built on a core set of best practices. The main idea is to decompose complex functions until each sub-problem is small enough to be called a feature.

Speaking about his role in the meeting, John Kern mentions that he “was nobody, but Peter Coad was, [and the reason why he participated] is because [...][he] was working with Peter Coad, publishing books on Feature Driven Development” (Lockard 2016a).

4.2.1 The manifesto was a “big deal”

Alistair Cockburn (2016b) compares the meeting in Snowbird and the creation of the manifesto to the NATO Conference of software engineering in 1968. However, most of the authors in 2001 thought that their manifesto would not be as successful as it has since become. Jim Highsmith (2017c) admits that the success of the manifesto for agile software development took off faster than all authors of the manifesto anticipated. Mike Beedle (2016a) adds that he never foresaw the adaption of agile development practices in other contexts such as leadership or sales. As he recognizes in retrospect, the implications of the manifesto were getting out of control. It took James Grenning (2017b) a couple of years to realize that it was such a “big deal”. He mentions that none of the original authors actually thought that somebody would care about the manifesto. Steve Mellor emphasizes that in retrospect “it makes sense, [but] at that time, I was surprised” (Lockard and Gifford 2017). In hindsight, he mentions “that the manifesto galvanizes [...][those], who wanted to [...] code and not to document [and] who wanted [...] to talk to users separately from the structures of the organization. And as a result, this become a thing” (Lockard and Gifford 2017).

4.2.2 The need for changing the wording of the manifesto

The manifesto’s wording is universal. This is one reason that led to the tremendous success of the manifesto and makes it still applicable and successful today [Anonymous]. One participant mentions that “in total, everybody is still pretty happy with the manifesto”[Anonymous]. As the participant points out, the concepts behind the manifesto remain solid. Bob Martin concludes that “the original values and the original ideas have survived” (Lockard and Gifford 2016). Nevertheless, Andy Hunt (2016b) emphasizes that it is crucial to follow the statements as written in the manifesto in order to generate successful software development. Bob Martin points out that the manifesto is not a “living document” (Lockard and Gifford 2016). He also emphasizes that he would not change anything in the original wording of the manifesto. He admits that there may be new concepts and adjustments for industry, but the manifesto is understood as a document in time and not an ongoing recipe. In retrospect, Ron Jeffries would add one more sentence to the manifesto. At the end he would write:“And we really mean it, particular working software” (Lockard and Gifford 2017a). Furthermore, Arie van Bennekum would like to change the wording of the manifesto by replacing the word “software with solutions” (Lockard and Cleff 2016).

4.2.3 The difference between “doing agile” and “being agile”

Bob Martin mentions that many organizations think they are “doing agile” when they are not (Lockard and Gifford 2016). Arie van Bennekum points out that there is a huge difference between “doing agile” and “being agile”. He defines “doing” as “just some rituals but without significant change to support the real agile approach as end-to-end, business integration, value focus, and team empowerment” (Hohl 2017). In contrast, he defines that “being agile means [that] the individual, team, [and] organization have changed” (Hohl 2017). This is “when they overcome the old paradigms” (Hohl 2017). These old paradigms hinder an agile approach and the agile transformation. Impediments are“often hidden in management layers and bureaucracy” (Hohl 2017).

4.2.4 Common misinterpretations of the agile manifesto

Bob Martin (2016) discovers the problem that the adoption and the understanding of the agile manifesto is different. Bob Martin (2016) points out that the misinterpretation and false implementation of agile is caused by politics, imagination, and economic interest. Martin Fowler (2017) identifies missing support from the business side due to missing knowledge. He mentions that this leads to the unpleasant effect that the agile ideas are often misinterpreted. Furthermore, misinterpretation leads to pressure on the programmers instead of creating a motivating and productive working environment. Forcing programmers to change is not possible and will end up in developers resignation [Anonymous]. Bob Martin (2016) remembers that they also made a mistake in the early days of XP when they put high emphasis on pair programming by pushing it too hard. He emphasizes that the time for developing software in pairs should be kept at a reasonable amount of time (Lockard and Gifford 2016). In realistically minded agile teams, it is always a trade-off between specific needs and context. Another participant mentioned that a a context-specific selection of practices is necessary [Anonymous]. Andy Hunt adds that “the rationale behind many of the practices is how to get quick and reliable feedback on what you are doing”(Lockard and Gifford 2016b). Even though there is a lot of misinterpretation identified, Bob Martin (2016) positively argues that the idea behind the manifesto is still valid.

4.2.5 Poor implementation of agile

When Kent Beck invented XP, he intended to make the world safer for programmers. Ron Jeffries believes that nowadays, “agile is not making the world safer for programmers” (Lockard et al. 2017). One participant [Anonymous] identifies management pressure as one reason for a lot of careless software “craftsmanship” on the developer’s level. Jeff Sutherland points out that there is a “lot of sloppy software craftsmanship [because of] management pressure” (Lockard and Gifford 2017a). This often creates a huge mess since the agile approach is not tailored to the specific context. Jeff Sutherland (2017a) mentions that there are many teams outside without working software. According to Arie van Bennekum, often “teams deliver [software] and then use the following sprint for test” (Hohl 2017). In addition, Mike Beedle is disappointed because many people “maybe just have misunderstood [the concepts of agile] and doing [it] on the cheap” (Lockard and Gifford 2016a). The problem he points out is that “people want solutions and people want an execution plan” (Lockard and Gifford 2016a). Organizations which want to retain their hierarchy often try to introduce Scrum by the book to speed up development [Anonymous]. Furthermore, Mike Beedle states that“agile is about the understanding, what makes sense” (Lockard and Gifford 2016a). John Kern emphasizes to view agile methods and practices in a more differentiated manner. He states: “I hope the hack that someone building software that can kill you is not following the same process as someone designing some start up bullshit webpage. Please tell me not to follow the same methodology. Whatever it is. To me that’s the difference. Rightsizing the mind-set and be as agile as you could be in your work. Fail safe better be developed with a much more strict process.” (Lockard 2016a)

Another possible reason why agile is poorly implemented is identified by Ron Jeffries (2017). He claims that agile has “become a management approach”, and it is sold at the highest management levels. Arie van Bennekum emphasizes that agile “has not only become a management approach” (Hohl 2017). He points out the unpleasant fact that agile is “used by managers because they score points at the board of directors, shareholders and others who have no idea, but have heard the word and trend” (Hohl 2017). Brian Marick (2016c) mentions that before the agile movement, traditional programmers and the management were separated. He mentions that “in agile [...] both cultures come together” (Lockard and Gifford 2016c). However, “today they split again” (Lockard and Gifford 2016c). This trend can be seen at “agile conferences, where the programmers do not go to the conferences anymore” (Lockard and Gifford 2016c).

4.2.6 A lot of people claim to be agile

Ron Jeffries (2017) thinks that the “blood has been squeezed out of agile”. Since “agile” is so popular, everyone wants to ride along. Another participant [Anonymous] emphasizes this by stating that a lot of people believe they are doing agile with a 3-h stand-up meeting and a backlog. According to Andy Hunt (2016b), this is how they pretend to be agile. Mike Beedle (2016a) and Arie van Bennekum (2017) conclude that agile approaches often do not work, because the only reason to implement them is that “it is fashionable to be agile”. They Lockard and Gifford (2016a); Lockard and Cleff (2016) identify the problem of too many people professing to know about agile and that many people misinterpret the basic claim of the manifesto. They mentioned the example of documentation.

The manifesto does not prohibit documents or processes. The users should just value them less than individuals or working software. Mike Beedle (2016a) mentions that even Scrum is based on processes and has a backlog, which is a document. Arie van Bennekum mentions that it is important to say that “there is no basic issue against documentation” (Hohl 2017)”. He points out that the“basic issue is [the use of] documents [which is] one of the old paradigms” (Hohl 2017). He recommends the use of “Information Radiators”. “Information Radiators do cover information and can be perceived as documentation or a document” (Hohl 2017). From his point of view, the way to document like this leads to the fact that the document or documentation“is not the hindering product as in old processes” (Hohl 2017).

4.2.7 Preserve the agile origin

Martin Fowler (2017) mentions that a lot of people actively working in an agile way are not satisfied. Furthermore, Ron Jeffries (2017) believes“that all good ideas get watered down in their fashion. Over time, when the idea is getting popular, it is just watered down the ripples lower and lower. Some people get it, some people not” (Lockard et al. 2017). The original manifesto is developer-focused. Martin Fowler (2017) mentions that “the real benefits are [...] [still on the] technical level”. Therefore, the manifesto does not claim to support executives and business owners [Anonymous].

4.2.8 Agile certifications and agile coaches

What comes along with the spreading of the agile ideas are certifications like the Scrum Master. Bob Martin denotes the idea of certification introduced by Ken Schwaber as a “great service [...] [and] marketing scheme that just opened the flood gates” (Lockard and Gifford 2016) for the agile movement. Its drawback is a massive number of people who attend a 2-day “agile” course. In the end, they get a certification which makes them agile in their opinion (Lockard and Gifford 2016). There is a big issue with certified agile coaches who are unable to overcome stereotypical thinking [Anonymous]. According to Arie van Bennekum (2016), the agile movement was getting so big that there was a need for coaches to help organizations to overcome the old paradigms and replace them by new ones in order to be agile. He also mentions certifications by non-profit organizations as a benefit (Lockard and Cleff 2016). According to Brian Marick (2016c), Agile and Scrum are a “brand rather than a mindset”, and the craft of software development has been lost.

4.2.9 New agile trends arise

Since 2001, the original ideas of the manifesto have become more and more commercialized and different trends have arisen. New trends like Scrum of Scrums (SoS) or the Scaled Agile Framework (SAFe) are common talk. Ron Jeffries mentions that “the agile ideas are [...] often adopt[ed] as roots” (Lockard et al. 2017), which forces the development into frameworks like SAFe. According to Ron Jeffries, “it is depressive” (Lockard et al. 2017), because programmers “have to do [the same] stuff every week” (Lockard et al. 2017). He further calls this the “dark scrum” (Lockard et al. 2017). Arie van Bennekum points out that “scaling Agile is [...] a non-issue” (Lockard and Cleff 2016). He elucidates that the success of the agile scaling frameworks resulted from the misbelief that “there was no full delivery method in the time when the agile manifesto came out” (Lockard and Cleff 2016). He mentions that“there was DSDM, including full delivery of needed business value and the required business change” (Lockard and Cleff 2016). As he defines,“Agile is about delivering better business value earlier with a better internal quality” (Hohl 2017). Sticking to the old paradigms and processes will not help. He points out that “being Agile makes you [and your company] future-proof” (Hohl 2017). Mike Beedle confirms this, saying that “the rate of change in the world has so increased” (Lockard and Gifford 2016a). He furthermore points out that“this is a world of rapid change” which needs“new way[s] of management techniques” (Lockard and Gifford 2016a).

4.2.10 Take aways for research question 2:

Martin Fowler mentions that it is important to remember the“long list of people, who were pushing agile in that time” (Lockard 2017).

4.3.1 Take aways for research question 3:

4.4.1 Scrum is not the end of the road for being agile

Steve Mellor had “been expecting agile to reach the top of the hype curve, for a good 5 years now. And there are two hype curves, the marketing hype curve, and a very similar curve which has to do with the underlying technology” (Lockard and Gifford 2017). Andy Hunt states that “Scrum is not the end of the road for being agile, neither XP” (Lockard and Gifford 2016b). Mike Beedle (2016a) identifies the agile ideas as a good starting point for further improvements. In a changing world, the evolution of agile software development is still going on. Brian Marick mentions that “the agile train keeps moving” (Lockard and Gifford 2016c).

4.4.2 Stay flexible and deliver high quality outcomes

Ron Jeffries (2017) hopes that the future of agile comprises continuous innovation and pushing the boundaries. As Arie van Bennekum emphasizes, “one of the characteristic of Agile is continuous improvement and learning. This means agile will not, cannot, stay as it is” (Hohl 2017). Organizations want to become more agile, especially from the business view. Increasing business agility will go on for many years, combined with flexible leadership. Nevertheless, all ideas such as short cycles or a closer collaboration with the customer are based on agile (Lockard and Gifford 2017c). According to one participant, the used agile method itself is not important [Anonymous]. One should focus on selecting the right principles. What helps most, should be used. In addition, Ron Jeffries (2017) would like to return to some values, such as retaining some of the elements from XP that are mostly forgotten in the average installation.

The rapid change in agile adoptions is seen as a problem by another participant. If organizations spontaneously restructure the development process towards an agile development, appoint a Scrum Master and develop differently, this will not work (Lockard and Gifford 2016b). Ron Jeffries (2017) claims that it is the first priority to focus on automatic and reliable software releases. Andy Hunt adds that, “if you cannot get software automatically and reliably out of your pipeline for continuous delivery, if you cannot do this mechanically, then all the other stuff like talking to users and so on does not matter” (Lockard and Gifford 2016b). In contrast, Jon Kern states: “I don’t have to suffer doing stupid stuff and focus on delivering value more quickly. Respecting each other, the client, sustainable pace, I think that will make a better environment. I hope we made it not suck as much as it might.” (Lockard 2016a)

One participant claims that the level of abstraction slowly increases [Anonymous]. As a consequence, software should become less “precious”. Many of the ills come from the mistaken notion that because the software code was hard to implement, it should be protected against changes [Anonymous]. Instead, it is important to realize that software is ephemeral. He recommends focusing on writing software that is easy to replace.

4.4.3 Be professional

As one participant denotes there is a need for professionalism and software “craftsmanship”. People should be proud of the job they do, tackling it with more personal responsibility and self-respect. “We don’t have to be hackers, we don’t have to be horrible coders by disappointing people every time we release software. We can be professionals. And that is the attitude I want to see, pushed out from snowbird, from the agile community, into the industry at large, I think we have a really big problem there” (Lockard and Gifford 2016). Furthermore, one participant [Anonymous] hopes that over time more people will discover the principles of agile and benefit from them. He predicts that agile ideas will permeate business, but he is aware of the fact that this is a slow and uncertain process. Furthermore, Brian Marick (2016c) adds his opinion on the tendency in agile projects to select methods. The ensuing homogeneity is detrimental for the working process. He argues that there is probably untapped potential for making an explicit goal, instead of figuring out, how to make everyone the same. Different people work more productively together [Anonymous].

4.4.4 Take aways for research question 4: