Research question 1: influences and intentions
What influences and intentions led to the manifesto for agile software development?
In 1999, Kent Beck invited to a special conference he called the XP leadership conference. Bob (Robert) Martin, Martin Fowler, Ron Jeffries, Ward Cunningham, Kent Beck and several others attended this conference (Lockard and Gifford 2016). At the conference, they talked about lightweight processes, realizing that they needed to set up another meeting in order to focus on a broader approach for better software development (Lockard et al. 2017).
In 2001, they set up a meeting to find more effective development methods. They wanted to search for common ground (Lockard and Cleff 2016; Lockard and Gifford 2016b). Some of the participants had developed their own working methods and lightweight processes. Highsmith (2017c) did consulting and trainings in structured methodologies and realized that his way of working varied from what he taught. Hunt (2016b) realized that all his clients were working exactly the same (wrong) way and had the same problems in their projects, such as dissatisfied customers or broken deadlines. At that time, Thomas and Hunt published their book “The Pragmatic Programmer: From Journeyman to Master” (Hunt and Thomas 2000).
When the original contributors of the manifesto met in 2001, they tried to identify areas the used methodologies had in common (Lockard and Gifford 2017b). At the beginning of the meeting in 2001, everyone gave a short presentation of his development practice. The echoes of the participants in the manifesto and the principles are still perceptible. Jeffries (2017) describes it as a general feeling that they had similar methodologies, and gave them a higher-level guideline to follow. Highsmith (2017c) mentions that the success of the manifesto is based on the fact that they focused on the similarities of the methodologies for software development. In his opinion, this is the reason why agile is still valid. It is not based on processes but on values and principles.
The results of our study are shown in Fig 1. It visualizes the practices and methods that had an influence on the manifesto for agile software development. Arie van Bennekum pointed out, “they all share two common treats: the aim to diminish bureaucracy and a focus on valuable deliverables” (Lockard and Cleff 2016). The following section discribes the methods which had an influence on the agile manifesto. The statements of the originators shall help to sharpen the reader’s understanding that there are more methods than SCRUM and XP.
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.
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).
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”.
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).
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).
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).
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).
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].
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).
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).
Research question 2: Today’s views on the manifesto
What do the original authors think about the manifesto today?
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).
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).
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).
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.
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).
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).
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].
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.
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).
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).
Further important takeaways for current view on the agile manifesto:
-
The success of the manifesto for agile software development took off faster than all authors of the manifesto anticipated.
-
The majority of the authors would not change the wording of the manifesto.
-
It is a difference between “doing agile” and “being agile”.
-
Agile methods and practices are often poorly implemented.
-
A lot of people claim to be agile, because it is fashionable to “be agile”.
-
It is important to preserve the origin of the agile manifesto.
-
Agile certifications and agile coaches, both a blessing and a curse.
-
A world of rapid change needs new ways of management techniques.
Research question 3: views on future of the agile manifesto
What do the original authors think about the manifesto’s future?
As we figured out, there are two different views on the future of the manifesto. One supports the adaption of the manifesto to different domains in and outside the area of software engineering. The other one takes a critical stance on it. This latter viewpoint is based on the ongoing commercialization of selling “agile” and a loss of the sharpness of the core ideas. In addition, one participant emphasizes the first sentence of the manifesto where the very first line says “We are uncovering better ways of developing software by doing it and helping others do it” (Beck et al. 2001). What Steve Mellor likes to see in future directions of the manifesto is the awareness on “how they could make their process, their abstraction in turning more towards reality” (Lockard and Gifford 2017).
One participant mentions that the manifesto sets a standard of values and principles most people ignore. He does not see any sense in updating it. Arie van Bennekum refers to the fact that “too many people use the word without understanding” (Hohl 2017). Furthermore he mentions that “too many of so called agile experts did not read the manifesto or investigate other methods then Scrum” (Hohl 2017). For the future of agile software development, Jeff Sutherland states that he does not “know any better ways to do software than scrum” (Lockard and Gifford 2017a), but he is not focusing on the future trends right now.
However, there have been some thoughts about a rework or version 2 of the manifesto. Bob Martin (2016) does not believe that any of the original authors are interested in doing that. In 2011, though, Kent Beck published his “beyond agile manifesto” (Denning 2011):
In 2011 Kent Beck proposed that even a great manifesto needs to evolve and that this might be the next step:
|
Team vision and discipline over individuals and interactions (over processes and tools)
|
Validated learning over working software (over comprehensive documentation)
|
Customer discovery over customer collaboration (over contract negotiation)
|
Initiating change over responding to change (over following a plan)
|
The importance of team vision and discipline is also acknowledged by Arie van Bennekum. He points out that “the success in agile comes with the quality and discipline you apply using the agile rituals and concept” (Hohl 2017). Ron Jeffries (2017) mentions the loss of the sharpness of the core ideas by spreading agile and selling it to large enterprises.
Take aways for research question 3:
-
Two different views on the future of the manifesto exist.
-
Some authors stop focusing on the future trends of the agile manifest.
-
Some authors support the distribution of the agile mindset into new fields of application.
Research question 4: the future directions of agile software development
What do the original authors think about the future of agile software development?
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).
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.
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].
Take aways for research question 4:
-
The agile train keeps moving, Scrum is not the end of the road.
-
Maintain flexibility, stop doing stupid stuff and focus on delivering value more quickly.
-
Be professional.