This paper aims to investigate the extent to which newly agile organizations followed 2001’s Agile Manifesto, especially in terms of the 12 principles of the agile approach, as included in the Manifesto.
The authors conducted in-depth case studies of groups in three large business organizations that had recently adopted agile. Two researchers spent one day at each site, attending daily standups and conducting interviews with managers, developers and customers.
Across the three organizations, developers were faithful to two agile principles: the primacy of delivering valuable software continually and regular reflections on the process with an eye toward improvement. The developers were uniformly unfaithful to the principle that requires face-to-face communication. Each organization varied in their adherence to the remaining nine principles. Obstacles to faithful adoption included the experience of the organization with agile, the extent to which the industry was regulated and the extent to which developers and customers were physically dispersed.
While past research on agile development is extensive, this paper examines perspectives on the method and its adoption through the lens of the original Agile Manifesto and its 12 principles. The principles were grouped into three broader categories – software delivery, people and process – to provide additional insights and to sharpen the analysis.
George, J., Scheibe, K., Townsend, A. and Mennecke, B. (2018), "The amorphous nature of agile: no one size fits all", Journal of Systems and Information Technology, Vol. 20 No. 2, pp. 241-260. https://doi.org/10.1108/JSIT-11-2017-0118Download as .RIS
Emerald Publishing Limited
Copyright © 2018, Emerald Publishing Limited
Agile is dead (Kern, 2016). According to some observers, the popular approach to software development has now been replaced with newer approaches to development, such as DevOps and Bimodal IT. The earliest craftsman-like approaches to development were replaced with engineering-based approaches, typically referred to as waterfall, and the engineering focus was replaced with agile methodologies. We knew agile would also be superseded eventually. Even the term “agile” has been so inappropriately used that, to many observers, it has lost its original meaning (Conboy, 2009; Kern, 2016).
However, the demise of agile might surprise the 94 per cent of organizations that practice agile, as identified in a recent survey (VersionOne.com, 2017). A total of 44 per cent of the respondents considered themselves extremely knowledgeable about agile development practices. In total, 50 per cent of respondents worked in organizations where the majority of their development teams used an agile approach. Agile methods seem to be firmly entrenched. And while 28 per cent have been using agile for five years or more, many companies are very recent converts – 15 per cent of respondents had less than one year of experience.
What does it mean to be an agile developer now? How is the agile approach defined and implemented in practice? The agile approach to systems development was formalized in 2001’s “Agile Manifesto” (Beck et al., 2001; Fowler and Highsmith, 2001). The Manifesto resulted from a meeting of 17 methodology visionaries, who met at the Snowbird ski resort to discuss the “need for an alternative to documentation driven, heavyweight software development processes (http://agilemanifesto.org/history.html).” Short and succinct, the Manifesto consisted of four foundational statements: We value:
individuals and interactions over processes and tools;
working software over comprehensive documentation;
customer collaboration over contract negotiation; and
responding to change over following a plan.
The Manifesto also articulated 12 agile principles (Categorizing the 12 Principles of the Agile Approach). We wanted to find out the extent to which agile is defined by the Manifesto, its four foundational statements, and its 12 principles, and the extent to which its principles are followed or altered for local use. Our goal is not to duplicate Conboy’s (2009) work, in which he defined information systems development agility and created a taxonomy of it. Instead, our goal is to investigate how practitioners define agile and the environmental factors that influence how agile is shaped in the workplace. Recent research has shown that some agile practices are routinely subverted, so much so that several agile anti-patterns – such as extra-long sprints or team members being reassigned without the input of the rest of the team – have been identified (Eloranta et al., 2016; Scrum.org, 2018; Wolpers, 2018). However, the literature on anti-patterns seeks to identify them and estimate their frequency. It does not investigate how or why they came about. For our study, we formulated two research questions:
How is agile defined in practice?
What environmental factors shape agile practices?
To address these questions, we conducted in-depth visits to three organizations with offices in the Midwest USA. All said they practiced agile, but each had its own local perspective. To compare and contrast these three localized versions of agile, we focus on the 12 agile principles identified in the Manifesto consolidated into three core areas: software delivery, people and process. We explore each organization’s story of how it came to adopt and use agile. We then show where these companies tended to be faithful to agile and where they tended to diverge. We end with a summary of our findings and managerial implications.
The agile literature
Agile development methods, including Scrum (Schwaber, 1997), eXtreme Programming (Beck, 1999) and others, have been the subject of academic inquiry since 2001 (Dingsøyr et al., 2012). Much of that literature has been devoted to the factors that make agile successful. For example, agile success requires strong executive support and committed managers (Chow and Cao, 2008; Ahimbisibwe et al., 2015). Success requires managers to shift from command-and-control to leadership-and-collaboration (Nerur et al., 2005; Conboy et al., 2011). Where management support and understanding of agile practices have been lacking, adoption and success have suffered (Senapathi and Srinivasan, 2012). Agile success also depends on project champions (Conboy and Morgan, 2011; Chesbrough and Crowther, 2006) and the competence, expertise and motivation of capable teams genuinely working together (Chow and Cao, 2008; Ahimbisibwe et al., 2015). Agile needs effective communication (McHugh et al., 2012), even though such communication can prove challenging where teams are not co-located and where cross-cultural issues exist (Lindvall et al., 2004; Alzoubi et al., 2016). Effective communication in the form of knowledge transfer in a Scrum environment is related to lean documentation, cross-functional teams, client consultation and feedback and project meetings (Terje Karlsen et al., 2011). Differing motives for adopting agile methods result in different configurations of project management and software development agile practices, which are related to performance (Tripp and Armstrong, 2016). Different agile practices affect agile teams in different ways, which in turn affects successful software development (Recker et al., 2017).
While much has been learned about agile methods and what makes them successful, in practice agile development has taken many forms, suggesting that no single set of success factors applies across organizations, projects and development teams. Agile exists as a range of options, from faithful “by the book” implementations to highly customized (Wang et al., 2012; Cram and Newell, 2016). A number of agile systems represent hybrids, of either agile and waterfall (Boehm, 2002), different iterations of agile methodologies (Mishra and Mishra, 2011) or of agile and software configuration management practices (Durrani et al., 2014). To understand the variation in agile implementation in the workplace, we start with a baseline view of agile methods, returning to the Manifesto and its principles.
The 12 principles
Although the four foundational statements of the Agile Manifesto are well known, the 12 principles are less known (based on a Google Scholar search in March 2018, the Manifesto has been cited three times as often as the principles). A survey conducted in 2010 found widespread support for the principles, where 49 per cent of respondents reported that the principles are important because they guide teams new to agile, and 65 per cent agreed that the principles should guide the choice of agile practices (Williams, 2012). In the Manifesto, the principles are listed in no discernable order. However, we find that these can be readily categorized into three groups of four, defined by software delivery, people and process (Categorizing the 12 Principles of the Agile Approach).
(1*) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
(3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
(7) Working software is the primary measure of progress.
(4) Business people and developers work together daily throughout the project.
(5) Build projects around motivated individuals, give them the environment and support they need and trust them to get the job done.
(6) The most efficient and effective method of conveying information with and within a development team is face-to-face (FtF) conversation.
(11) The best architectures, requirements and designs emerge from self-organizing teams.
(8) Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
(9) Continuous attention to technical excellence and good design enhances agility.
(10) Simplicity – the art of maximizing the amount of work not done – is essential.
(12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
*Numbers refer to original ordering of the principles in the Agile Manifesto.
Improved software, in terms of faster delivery and higher quality, is the reason the agile approach exists. All four of the principles under “software delivery” reflect this essential concept. The primary measure of success is working software delivered continuously and quickly. The bane of traditional software development methods, changing customer requirements, is welcomed under the agile approach.
Key to agility is a focus on “people.” The best approaches involve small self-organizing teams, built around talented and highly motivated individuals. Information is best conveyed on a daily basis, FtF within teams and with customers. Customers are important contributors.
The “process” itself is lean, sustainable, with a constantly maintained pace, highly focused on technical excellence and good design. Yet design is not a separate activity – it is tightly integrated into the overall process. A focus on simplicity prevents costly rework. And as the team works, it reflects on its methods and progress, resulting in process improvements.
While some teams are able to adhere to these principles, others are not, and it is those places we were interested in investigating. Even within the adherence to the Manifesto and its principles, there are multiple approaches. We report here on the agile experiences of three different for-profit organizations. In our on-site interviews at each organization, we explored their histories with agile, their current practices and likely future directions.
We were approached by four companies in 2015 about reviewing the agile development methodologies used in their IT organizations. We planned visits to all four companies within the same general timeframe, to take a comparative snapshot of their agile approaches. The site visits occurred from May through July, 2015. All authors were actively involved in collecting data for this study. Two researchers visited each site, and each researcher visited two companies.
While no a priori theory was tested, the study was informed by the Manifesto, and in particular, by its 12 principles. The authors created an interview protocol prior to site visits to determine how agile was introduced to and practiced at each company. The questions reflected our interests in how agile was perceived at multiple stakeholder levels: top managers, IT managers, project managers, team members and customers, so questions were crafted specifically for each group. Questions covered the history of agile adoption, current agile practices, experiences with prior methods and perceptions about what various stakeholders believed about agile. (A copy of the protocol is available from the authors.) Table I lists the interview sessions held at each location, along with the roles of those interviewed. All of the individuals quoted in the text are listed by their identifying title. Most interview sessions involved at least two informants, and many involved entire project teams. All interviews were recorded and transcribed. A brief report was prepared for each company, and these were reviewed by lead contacts and others at each site. Changes to the reports were made on the basis of the feedback received. One company quit the study, so we report on the remaining three.
The agile story in three organizations
Company A is a publicly traded global investment manager that provides retirement plans, non-medical insurance coverage and employee stock ownership plans, among other services. In 2014, the firm had more than $400bn in assets under management and approximately 9,000 employees worldwide. Company A uses a mixture of development methodologies, and the division we interviewed has completely transitioned to a scaled agile methodology to convert elements of an existing legacy platform to the cloud. The division has 25 Scrum teams with 60 per cent of the teams located at corporate and 40 per cent in India. In addition to our interviews, we were able to observe two backlog grooming meetings and a daily standup. The division we visited works in a series of Program Increments (PI). Each PI has five two-week sprints. There are three separate groups working synchronized PIs.
Origins of agile at Company A.
Company A is a relatively new adopter of agile. They began implementing agile three years prior to our visit, and had moved to using a scaled, agile framework (SAFe) in the preceding year. The initial introduction to agile was Scrum-based and met some resistance from line IT workers tasked to work on agile teams. Despite this early resistance, IT leaders and upper management determined that agile was appropriate for the division and chose SAFe methodology to address their needs. The general impression from our informants was very positive:
We’re just an infant, to be honest. I don’t even feel like an expert. So, I run a lot of projects, been involved in a lot of projects, and I believe this process works. It just effectively manages pieces and parts of the work that need to be done and gets them appropriately prioritized and delivers in the order that the business needs them. I think it’s a great process. – Product Manager
Over the past three years, Company A’s division has increasingly moved toward agile:
We started at project level, we introduced a few more projects to the point where we had about half of our portfolio working in agile and kind of hit a tipping point, to say, ‘okay, now let’s introduce this concept of running our whole portfolio as an agile construct.’ – Associate Vice President
The increased transparency and visibility have been major advantages. One program manager stated that he believes the adoption of agile added structure that waterfall failed to bring.
The Company chose to use SAFe because of their size, history and need for some structure. At times, the teams have deviated from some of the SAFe guidelines when necessary. Their perspective has been to take what works well, and adapt when appropriate, but it has provided rails for the division to run:
There’s a thought out there that is kind of anti-SAFe, because it introduces some structure and process, and agile being very, ‘do what’s right in front of you, wait until tomorrow when you know more to do something else,’… maybe that works in a smaller entrepreneurial kind of setting. I think in our environment, we’re part of a big organization, we’ve got a lot of history in how we were doing our work. We needed some structure, some framework to manage the change, manage the process to where we wanted to be. – Associate Vice President
There has been great upper management support enabling a smooth transition toward agile. One IT manager put it this way:
When we introduced SAFe, going back to (the question) was there resistance? It was actually amazing. One of the things that our CIO strongly believes in […]is strong business and IT relationships. And, that was pre-agile. So, as we were doing projects we have IT engagement in our strategic portfolio group […] so, when we were kicking off agile we weren’t meeting our business partners. We weren’t being introduced as an IT business relationship. That relationship already existed. So, we were having free, open dialogue throughout the whole process, and we were really kicking it off together. – IT Manager
Status of agile at Company A.
In addition to the Scrum method of agile, Company A has been using paired programming, test-driven development, acceptance test-driven development, small frequent releases, and has moved toward single branch development strategies. However, it is cognizant of the possibility of building to the test instead of the necessary requirements:
There’s always that concern, that’s kind of something that I’ve struggled with test driven development. You have the argument of the guy who builds a single story house and without thinking ahead, now they want another floor added on, but the support structure is not there. So, there’s always that consideration. So, there’s still that element of design that comes into play too […] And we did decide rather than just do test-driven development, we decided to actually go and create an actual design for it. We’ve given some thought towards the future. So, it hasn’t been purely test-driven development. And, I don’t think anybody really in the organization has done pure test-driven development, at this point. – Scrum Master
In addition, it acknowledges that there are many cultural changes necessary as it moves in the direction of the technical aspects of agile development. It has not only selected some teams to experiment with different agile technical methodologies but also allowed an organic component to remain culturally. Thus, when one team sees what another is doing, it may copy. The company has tried to not be heavy handed in specifics. It recognizes that the tool is just a means to the end.
When asked about their experience moving to agile, employees commonly responded that they loved it, or that they would never want to go back to before agile. One informant in quality assurance put it this way:
I’ve worked here for 30 years […] So, I have seen a lot of things in my time, a lot of different methodologies. I was on the first team within [Division] that tried agile. If they told me I had to go back to waterfall, I’d quit […] So, yes, I love it. – QA engineer
Future of agile at Company A.
There are some challenges that come with agile. One business partner (customer) described a disconnect between sprint demos and production. She said:
I’ve seen how the work is broken down into stories, how they get attached to sprints. Most often I attend the demos at the end of the two-week sprints. I’m normally notified when something is going to transfer to production. There’s a little bit of a disconnect between a sprint and what the team has been working on, when that actually is going to go to production, for example, they don’t always match up. – Customer
However, another customer described her experience very differently. She was actively involved in communications with the development teams, would participate in the product demos and would applaud (part of the agile culture) not because it was expected but because she would see the value of what was being rolled out and how it would directly benefit her business team.
Agile has been so successful in this division that other divisions are reaching out and asking what this division is doing and how can they get there too. Even non-IT teams have become interested:
I have learned that our marketing team, which isn’t IT resources at all, they are now following agile for their work. So, they’re planning their work in two week sprints, you know, loosely, they don’t have the product owner, Scrum master, developers, whatever, but they have started integrating that for their teams. – Customer
Something Company A acknowledges needing improvement is measuring success. This problem is related to previously not being able to measure success in traditional waterfall methods. In addition, as it has moved from traditional methodologies to agile, it has become less rigid in thinking:
Our methodologies before were very checkbox in nature, so, ‘I have to do this before I can do this and before I can do this.’ Which lends itself to waiting to be told what to do. And with agile […] I think we’re not looking for how to do it the same every time. What we’re looking for is the opportunities to constantly improve, and what we’ve seen is a slow shift in the staff mentality to say, ‘yeah, my shackles are really off’…And what we’re saying now is, as a team, across discipline lines, throughout the gamut of your process, your design/develop/code/deploy, you’re all in it together. Go figure it out, make it efficient, make it effective. – IT Manager
Another challenge that Company A faces is how to evaluate employees. The agile environment encourages collaboration, and Company A recognizes the need to develop an evaluation system that is aligned with their agile movement:
Today, a lot of the higher performers […] they’re the heroes, and in agile we’re not looking for heroes […] because that changes your culture, too. If this hero is always coming and saving the team, then there is something wrong on the team. – Project Manager
Company A and agile principles.
Company A is strongly pursuing agile through SAFe, and this is most clearly articulated through the software delivery principles described in the Agile Manifesto. They delivered regular software releases and sought feedback from their customer. While this opens the door for many changes during the development process, Company A’s two-week sprints and desire to satisfy the customer have managed the requirement changes effectively. The development team has always believed that working software is most important, and the adoption of agile has empowered the teams to truly focus on product delivery.
The principles concerning people and teams were not as strongly practiced by Company A. The development teams were given autonomy to choose the tools and techniques to get their jobs done. However, customers were not regularly and intimately involved in all stages of the process. Finally, the teams were geographically dispersed, and even those who were local often telecommuted and did not meet FtF.
Company A was also mixed in its faithfulness to the process-related principles. True, two-week sprints were the norm, and it performed retrospectives to reflect on ways to improve, but it was often the case that the teams were forced to deliver from a waterfall style design approach instead of a pure test-driven design. Finally, it indicated that the drive toward simplicity was a function of the needs of the stakeholders and often did not happen.
Company B is a large, multinational corporation, earning over $30bn in revenue in 2014. As a services company, one of its specializations is the development of information systems for clients. However, it also develops information systems for internal use. The company relies on developers in its Asian offices for coding for both internal systems and client systems. The group interviewed is a division of the larger Company B group, which has about 4,000-5,000 employees and reports to the corporate CIO. This group, which we will call Internal Apps (IA), was the only one following an agile path at the time of the visit.
Origins of agile at Company B.
Company B has a corporate-wide systems development process, based on the waterfall approach, which is used for developing systems for both external clients and internal uses. A Scrum-based agile approach was first introduced in the IA group, by its senior manager (SM). In 2011, IA was working on an internal knowledge-based management system (KBMS), which would, among other things, allow employees to find others in the company who had a desired expertise. The original estimate for development of the KBMS was 14 months, which the SM found unsatisfactory. The SM unilaterally decided to move to a Scrum-based approach. He summarized his thinking at the time as:
[…] we attempted to deliver a project [the traditional] way. And, it went about the way they’d all been going, not so well […] I just sent an email and said, ‘I don’t even want to talk about this […] you guys are going to figure out what we can do in three months.’ And then all of a sudden we realized we were in agile […] it was just like, ‘We’re sucking right now, the delivery, timing, cost, everything about us just stinks. We have to do something different.’ – Senior Manager
The client liaison in the IA group (who coordinated the efforts of the clients and worked with the SM and the Scrum teams directly) recalled the moment when the SM decided to try agile:
[…] we were classically waterfall, we wanted to rebuild our profile application – our Company B people application came back with a nine-month estimate in waterfall, and the SM said, ‘This is ridiculous, let’s just start breaking it into sprints and just see how long it would take.’ – Client Liaison
The actual development effort for the KBMS using agile took three months and was seen as successful. This was the group’s first try at Scrum. The SM decided to expand the use of agile in IA, and the group developed many similar tools using Scrum.
At the time of our visit, the Scrum team responsible for the KBMS was called the “Young Guns (YG).” The original team that worked on the project was called the “Smoking Guns (SG).” The YG team was being introduced to the agile approach by taking on the continuing development efforts for the KBMS, while working in close contact with the SG team. The SG team had moved on to work on the development of an internal social networking system. Both teams participated in the daily standup that started the work day of our visit.
Status of agile at Company B.
The agile approach used in IA is almost pure Scrum (Schwaber, 1997). Scrum is the most common agile method used (58 per cent of respondents use Scrum [VersionOne.com, 2017]). Rather than build their own guide to agile, the approach taken by the IA Scrum teams comes from the main source, Scrum.org:
In the industry there is already a Scrum guide, why build something for Company B? […] We were following the Scrum guide, the one that’s built by Scrum.org. – A Young Gun
The Scrum teams use very little technology. They rely primarily on Microsoft’s Team Foundation Server (TFS), a part of Visual Studio. They also hold team meetings using Microsoft’s Skype for Business and SharePoint.
There are two exceptions to how IA implemented Scrum:
The move to Scrum was initiated by management (the SM) and implemented in a top-down fashion, rather than a bottom-up approach.
Almost all team meetings are virtual. In fact, the former corporate CIO had mandated work from home for four days per week.
When the research teams met with both Scrum teams, the teams specially arranged to come into the office, and that was a rare occurrence. Moreover, client representatives tended to live elsewhere. Client representatives that we spoke with lived in South Carolina, IL, and Argentina. How the IA group makes agile work with distributed teams was described by the SM:
In [Asia], where the bulk of our development team is, they have to come to the office. But, here, these guys will talk about, you know, ‘We come to the office, we have a great time, but we don’t get jack done,’ right? ‘We have to go home to get stuff done.’
But, I mean, they will be, they just get on a conference call, and are just on there for hours and hours and hours and hours at a time, when necessary. Then they all hang up and they all go do whatever they need to do. – Senior Manager
The agile effort had been started by management (the SM), but it had since been embraced by the developers. The two Scrum masters we talked with dismissed the traditional waterfall process, which they had both worked with for years:
Back in the waterfall days, I’m not afraid during the first three months, but then on the latter part, towards the end, you are terrified you’re not going to meet this, and how are you going to explain it? That is the biggest factor and it’s so stressful. – Scrum Master
As the effort had started with management, there continued to be ample management support in IA, both from the SM and the client liaison. The client liaison stated she believed the teams had the resources they needed to do their jobs:
So, I feel like at this point we’re getting what we need. Like, I think some people will say, ‘Well, you need a tool for verification,’ and it’s like, ‘Scrum, [Skype], and email are doing pretty good for us.’ Like, I think you could maybe come up with a tool, but I don’t feel like we’re missing this huge thing that would save us hours of time. – Client Liaison
Customer involvement was extensive. The client located in South Carolina provided the funding for the KB system. He and his group had been collecting requirements for the system for 8-10 years. Their goal was to continue improving the system. The team in Argentina existed only to support IA on their agile projects working on individual user stories and scoping them for sprints. The Argentina team, interestingly enough, had organized themselves along the lines of a Scrum team, even though they were not doing any development work:
Sometimes we have what we call our own Scrums. As the development team has their Scrum meetings and they have their Scrum master and other things, we have our own Scrum, where sometimes we test things together, if there are stories that are related, one to the other, or anything like that. From a process perspective, we review all together those stories and if there’s some things we need to do we double check things with different testers or anything. – Customer Representative in Argentina
Future of agile at Company B.
As for the future of Scrum at Company B, the SM says that other groups in Company B and the corporate CIO are aware of the continued success IA has had with Scrum. One way that others have observed the success of agile approaches is through two highly public corporate “hackathon” events that the SG team entered and won (quality product in a limited time):
I think, from the [corporate CIO’s] perspective, we were saying we were agile, we could do things quickly, innovatively, what he got was a quality deliverable in a very short period of time. And all the sudden he began ringing the bell loudly that we need to be more agile, we need to be more […] I think that was what turned in his mind that it could actually be done. – Senior Manager
According to the SM, other Company B groups want to move to agile. The CIO has indicated an interest in implementing more agile company-wide. Moving toward agile has also required a culture change in the Asian offices. Traditionally, the Asian developers were organized into large project teams, as was customary under a waterfall approach, and their work culture frowned on project managers doing any coding. Both of those tendencies had to be overcome in reorganizing the developers into smaller Scrum teams with Scrum masters producing code, as well as managing projects.
We had no indications that our informants believed that the Scrum-influenced processes produced better systems or saved money. However, they were emphatic that their process generated working, relevant systems on a timely basis. The main selling point for agile in IA was how it reduced the time from requirements gathering to working and tested code. Of the holy trinity of budget, schedule and functionality, the emphasis seemed to be on the latter two:
I think from an agile methodology perspective, I guess I just feel like — it’s not that I have more control, it’s just that I appreciate that I can get changes out to my end users faster than I used to. – Product Owner
The Scrum masters, the SM and the members of the SG team were all much happier with agile than they were with waterfall-based approach to development. No one indicated that they wanted to return to using the official corporate development approach.
Company B and agile principles.
The IA group had clearly committed to the software delivery principles described in the Manifesto’s 12 principles: Their highest priority was the continuous delivery of quality software; they relied on two-week sprints; and working software was their primary measure of progress. The Scrum masters in IA had completely repudiated the waterfall approach and had fully embraced agile. The IA group at Company B had also faithfully embraced the agile principles related to people, with one exception. While customer representatives were heavily involved in development, and while the teams depended heavily on Scrum masters who were seen as geniuses, agile developers at Company B did not rely on FtF conversations as the primary means to communicate. Some teams were located in Asia, making FtF conversation impossible. Even within the USA, team members rarely met FtF, as they were required to work at home most of the week. Customer representatives were located globally, making other means of communication necessary. As for the third cluster of principles, devoted to process, the IA developers at Company B were explicitly faithful to two principles: continuous attention to technical excellence and good design (described as “a quality deliverable in a very short period of time” by the Senior Manager), and a commitment to a regular focus on reflection followed by adjustments in behavior.
Company C is a large, multi-national manufacturing corporation. IT development is done in-house for both engineering/manufacturing and for organizational/administrative (Admin) functions. Agile has been used extensively in the engineering/manufacturing areas, but the use of agile in the Admin functions began only a few years ago. Stakeholders involved in two large projects, Project S and Project P, discussed their current use of agile as well as the processes by which agile methodologies were adopted. Project S involved the implementation of a customer relationship management system, developed by an outside vendor and implemented with the help of the vendor’s consulting arm. The system was being developed for sales representatives, and the vendor’s consultants acted as Scrum masters. Project P involved the internal development of a single document control system that would replace three existing systems. The system would potentially touch every employee of Company C. An outside consultant was acting as the Scrum master for the project. Both projects were active during our visit, and while some of our informants were aware of both projects, those who were involved with these projects worked for only one or the other.
Origins of agile at Company C.
Company C has traditionally used a waterfall approach for developing Admin information systems. Several project teams adopted a Scrum-based agile methodology a few years prior to the site visit. Agile appears to have been introduced independently in different parts of the organization over time. One set of informants indicated that the introduction of agile occurred when Company C began a project with a large technology company. That company’s development team pointed out that the waterfall methodologies used at Company C would be inconsistent with developing applications for their devices. The project was broken up into segments based on “screens” that corresponded to the sprints. From there, Company C spread the approaches out to other projects. The idea was to get the customers involved earlier:
So, I ran a project — it existed on the PC for many, many years and it was the bread and butter for one of our divisions with the management. And we needed to move that to the [tablet] for many reasons. And when we did that project, I distinctly remember, as the PM, being in that meeting and kind of showing the plan and [the representatives from the large technology company] looking at it going, ‘You’re not going to be successful. Just looking at what you’re trying to do over that period of time, you can’t do it that way. You have to think differently about how you’d like to implement this.’ So, we started incorporating agile components and I say that agile is always a journey, but for us, specifically, that item was for us to kind of start breaking it down into smaller chunks, and that’s what we really did as a first pass. It wasn’t to deliver things faster or more effectively, it was the fact that if we could focus on portions of the application and kind of get the engagement properly from the business on there, we would see some benefits, and we did see that. – Senior Manager
A senior management informant indicated that the biggest push for agile in Project S came from a senior vice president who saw the benefits at a previous employer and pushed it “top-down.” Other stakeholders indicated that three individuals were chiefly responsible for introducing and promoting agile. A project manager noted that he had first learned about agile by attending a Scrum course at a local project management institute location.
The informants indicated that the introduction of agile was much siloed, so while they started with agile around the time of the introduction of the first (tablet), it was not widespread early on. They reported that its use was scoped around specific projects. Teams often “picked up components” of a project (i.e. work on a module or project phase), and then when they were done, a new team would pick up the next phase of the project. As a result, one team might use agile faithfully, whereas the next would not, resulting in an inconsistent use of the method. However, when agile was applied to Projects S and P, it use was scaled up, leading to a Center of Excellence for Agile:
Now with the [Project S] platform, we will have a Center of Excellence that there will be a core platform team that every single corridor will execute as one Scrum team. […] The way we’ve done it with an IS, for the most part has been very project-specific and it was just for that project you dropped it and a whole new team started again and you may have taken components or not, so it’s a little different that way. – Senior Manager
Status of agile at Company C.
The agile approaches used in Company C varied from one group to another. One of the informants described the process that they themselves used as “agile-like”:
The one project that we did that agile-like methodology we have a go-no-go meeting before we went live with many members of the business as well as IT senior management, and we always go through the process of, ‘Ok, are all of our IT boxes checked? Do we have all of our documentation done?’ All of that. – IT Manager
One informant indicated that they really were doing a mini-waterfall approach:
So, we’re doing some principles of agile that help the project, but essentially we’re really doing some mini-waterfall process, so we’re doing some things like, we’re having a daily Scrum meeting to talk through what’s going on with various work space in the project, but we’re really doing a iterative development of so much of the work to see it to a certain level, so it’s toward our customers and then do a little bit more work and change what we’ve already done in that process to slowly but surely delivering as product. – Technical Lead
Project teams used technology such as Microsoft Project and Excel spreadsheets to represent project tasks and deliverables. They held FtF meetings and used a high-quality video conferencing system to support meetings with remote members or customers.
There were several exceptions to classic Scrum implementation that characterized Company C’s use of agile, such as some members of development teams working remotely, sprints varying from two to five weeks, lack of commitment to projects because team members worked on multiple projects simultaneously, sprints lacking functional deliverables and requirements for significant amounts of approved documentation. Most documentation efforts were related to testing. The organization has documentation specialists who focus on documentation generation.
When first implemented at Company C, no formal in-house training was made available to developers in the Admin group. Subsequently, some developers took formal training and shared insights with other developers:
When I went to training a few months ago, I went to a full four-day training for agile, out in [state name withheld] at our office out there and actually the business set it up because they wanted to get trained on it. – Project S Informant
In general, project members seemed to like the process, but they struggled with the fit (or lack thereof) of their particular hybrid of agile. For example, our project developer informants reported that they found the current approaches to be frustrating because of the constant requirements and code changes caused by more frequent interactions with customers. The informants recognized that changes occurred with waterfall too, but the perception was that changes were more frequent with agile.
Documentation was a big challenge for project members and managers. The company must document because of the nature of its business. While agile does not emphasize documentation, the company must have documentation completed, approved and signed off before software could go live:
I don’t think we’re there yet. I think for my project– we couldn’t do that really fast sprint because – we had a really tight timeline, too, but – it was really difficult to get all of our documentation completed to be a full move to the next sprint […] – IT Manager
Customers praised the processes used by the developers. They liked being involved throughout the process, rather than just at the beginning and end. Users were happy with Scrum-like techniques as indicated by the fact they routinely attended meetings, even though they were not required to do so:
And they couldn’t say enough positive about our methodology – having them involved and owning, having part ownership in the result was a key to the success, and they couldn’t say enough about how we did it and the actual end result. So, to me – that’s how we measure success. – IT Manager
But measures of success were not standard. Often, the way success was operationalized was by how closely the outcomes matched the requirements stated in the front of the project. Also, a major source of success was the fact that there were fewer defects in projects by release time. The managers indicated that it was hard measuring “success” in a two-to-three week sprint.
The senior manager noted that an important challenge was the “ambiguity” that came with agile. Members and managers did not have a view of the “full” plan that could be scoped from the beginning. In other words, focus was a problem. The project manager noted that they occasionally stepped out of the project, met with other project leads and refocused:
And moving through this project, especially as a project manager on the project of multiple groups, you can lose that focus and what we’ve had to do a couple of different times is just — I mean our teams are fairly self-running, fairly self-running, so what we would do is we’d pick times, advantageous times, where we would just bow out for two days, or a day or whatever, as a leadership team and we’d get together and do a lookout of, ‘OK, what do we have left on the project?’ – Agile Evangelist
The product owners were also challenged because they had to represent the project to stakeholders. It used to be that the customer turned over the project to IS, they disappeared, and then IS returned with the results. With agile, product owner representatives had a lot of stress not present before, because they had to continually bring their stakeholders into the loop. Customers also noted that user stories were a challenge, particularly because the level of granularity was not consistent. It took time for everyone to understand what a use case was and how to create one that was comparable across projects:
And for everybody to write [stories] at the same level and then, so then we can actually get a better sense from an estimating standpoint, everybody’s got them at the same level. Did not happen, right? Like, everybody wrote them at kind of different levels ….
[Now] I think they have a lot better understanding than they did, yes. I mean I don’t think that I would say that everybody would still write them at that same level, but I think everybody has a better idea […] they’re calibrated on to what it takes. – Project P Informant
For managers, a challenge with the agile approach was that they might be excluded because the developer and the project owner got together and redefined the project. Also, capacity constraints were a big problem – timelines were tight, and the staff was stretched thin. There were competing priorities across work streams, which challenged each project. Furthermore, there were a lot of people in distributed locations. Meeting coordination was challenging.
Future of agile at Company C.
Company C was increasing their use of agile. A manager reported that in the past 6-12 months, it had grown considerably. Agile best practices would be a focus on the internal website. Agile was definitely the direction they were going in.
In the last six months or so I’ve seen it, six to 12 months ago, it’s really grown a lot. And just the getting the things like this, right? And the PMO is really putting a focus team together, so they have put a focus team together, and agile is going to be – agile best practices is going to be one of the focuses on their website, internal internet site, so I know – that that’s the direction we’re going. – IT Manager
The senior manager noted that the company is neither 100 per cent agile nor is it true agile in their implementation. However, the long-term goal was to be 100 per cent agile. This was supported by the CIO, who sees the benefits of agile in terms of flexibility:
We do want to be there. Yeah, I think — what we have talked about as a management team is taking it more serious about investing in agile coaches and other pieces to make sure we have. What we’re doing is we’re leveraging it with vendors. We’re not really building that deep expertise internally, so— we’re struggling with that a bit. – Senior Manager
It was trying to build expertise through, among other means, using Centers of Excellence and project management offices (PMOs):
We have like a PMO group within IS and I know they’re trying to put together kind of a board or a work stream of some kind that kind of brings these people with that knowledge together to be a little mini-consult tool, so other projects can leverage them going forward but they’re in their very early stages of trying to identify who the right people are in getting that set up. – Agile Evangelist
Company C and agile principles.
Developers at Company C were faithful to only one of the four agile principles related to software delivery. While they used the agile approach to factor systems into tractable components, rather than focus on the continual development of a complete system, their focus was still on the continuous delivery of software. However, they did not welcome changing requirements – they found them to be frustrating. Due to the heavily regulated nature of their business, and the related need for documentation, they were unable to conduct two week sprints. Some sprints went for four or five weeks. Finally, they did not recognize working software as the primary measure of success. The key measures of success were customer ownership, fulfilled requirements or fewer defects. Developers were not faithful to two of the principles on people. While their customers were more involved under agile than waterfall, they were not involved on a daily basis. Second, the importance of documentation has not diminished at Company C, again due to the nature of their business. FtF communication was not the most important basis for communication. Video conferencing has become an important tool for communicating within groups and with customers.
For the agile principles that pertain to process, Company C was faithful to one and not the other three. They were faithful to a commitment to periodically reflect and alter their practices. They were working toward making their practices more agile, across the board, but entrenched work practices prevented them from being able to maintain a constant pace indefinitely. Company C was also unable to achieve continuous attention to technical and design excellence. The extent to which agile practices were used varied both within and across projects. As one informant said, Company C’s approach was not “completely pure agile” and still had “elements within the waterfall that kind of apply.” Finally, Company C was not able to develop a process based on simplicity, largely due to the regulated nature of their work.
Analysis and discussion
The preceding sections depict the history, current and future practices of agile at the three companies. Each company uniquely embraced agile, adhering to some of the principles and not others. Figure 1 provides a comparison of each company in terms of its adherence to the agile principles. Based on Cram and Newell’s (2016) categorization, Companies A and B would be considered Crusaders, entities that adopt agile in a more-or-less pure form; Company C would qualify as a Tailor, an entity that adapts agile to fit its specific circumstances.
The most striking finding, as revealed in the case descriptions and in Figure 1, is the lack of agreement within companies on the principles faithfully adhered to (or not). While Company B’s approach demonstrated faithfulness to seven out of eight principles (where there was enough information to evaluate), Company C’s approach was faithful to two out of ten. Company A was closer to the middle, with seven principles faithfully observed and five not. All three companies had support for using the agile approach from top management. In fact, in Companies A and C, agile was mandated. In all three companies, people were enthusiastic about agile, some were devoted to it, and some said they never want to go back to waterfall. Yet clearly there were differences in how agile had been implemented across companies. One factor that helps account for some of the differences is the need for documentation in Company C, due to its highly regulated environment. The other companies were not legally required to document the development of internal systems, so they were much freer to embrace such aspects of agile as short sprints and measuring success by the delivery of software. A second key difference was the unique situation the IA group at Company B found itself in, where their use of agile was among the first in the company. There were no corporate standards for agile use, and the developers in IA wholeheartedly embraced the Scrum standards they found on the Scrum website. A third key difference is illustrated by how Company A differed from the others. Of the three companies, they had the most experience with agile. By the time we visited, they had learned from their own experiences which principles worked and which did not. They had assembled an agile approach that was customized for their development work, with some principles seen as central and others seen as not necessarily relevant.
The second key finding from Figure 1 is that there was agreement across companies on only three principles. They were all faithful to the primary purpose of the agile approach, the focus on the continual delivery of quality software (Principle 1) and to the need to reflect and adjust behavior periodically (Principle 12). The agreement on continual delivery of quality software and the need to reflect and adjust behavior should be expected for any agile development group. All three companies chose agile to facilitate effective delivery of working software, so it would be counter intuitive if they did not value the end goal of the methodology. In the same way, reflecting on what is working and what is not and making the necessary changes to improve productivity and remove obstacles enhances the development teams’ ability to be truly agile. Williams (2012) surveyed developers about the relative importance of the principles, and she organized them into six tiers, based on the results. Principles 1 and 3 constituted the first tier, whereas the second tier consisted of Principles 5, 7 and 12. The universal adherence to Principles 1 and 12 in the companies we studied is congruent with these evaluations.
What is particularly interesting is that none of the companies are faithful to the adherence of FtF communication as the best way to convey information (Principle 6). All three companies are large scale and mature, and have, at least, a couple of factors that are in opposition to entirely FtF interactions. First, they have geographically dispersed development teams, and that makes regular FtF interactions challenging. Therefore, while it is ideal to be co-located, it is impractical. Second, many modern organizations allow their workforce to have some level of autonomy in whether they want to telecommute or not. So, the desirability of agile would be somewhat lessened if it was required for team members to give up the flexibility of work schedules and work environments. Again, this is a matter of evaluating which principles help increase effectiveness and choosing to be faithful or not. Williams (2012) found Principle 6 to be in the fifth of six tiers, illustrating its relatively low position in the hierarchy of principles, a placement also reflective of its lack of faithful adherence in the companies we studied. Although distributed agile teams may be necessary and may necessitate distributed communication, they are not without their problems. Alzoubi and colleagues (2016) determined through a literature review that the challenges of distributed agile development included time zone and geographical distances, coordination among members of distributed teams, the difficulties of involving customers in distributed agile teams, organizational culture and differences in language, national culture, trust and personal practices among members of distributed agile teams.
The third observation we can make from Figure 1 is taken from the perspective of the three larger categories into which we have grouped the agile principles: software delivery, people and process. The most faithful observation of agile principles is found in the area of the rapid delivery of quality software, with nearly complete adoption by Companies A and B and partial adoption by Company C. Principles related to people had the least adherence – Company B was faithful to two, whereas Company A was faithful to one. Principles related to process were in the middle, with equal numbers of faithful and not faithful observation of the agile principles. Similar to the first two observations, we believe the variation in faithfulness to the 12 principles is a function of the agile experience in the organizations we observed. The adoption of agile is young relative to the age of the organizations, and there already exists well-established pathways regarding people. So, it is of no surprise that applying agile to established organizations would be constrained by pre-existing traditions and behaviors. If an organization has established a policy of working from home or has multiple teams dispersed across the globe, it is very difficult to force FtF interactions. In addition, engaging the business units daily in the development projects may prove challenging because these business units also need to function in their respective expert domains, causing Principle 4 to be less faithfully adhered to.
We now return to our research questions. First, how is agile defined in practice? All three organizations believed themselves to be agile, yet each instantiation is distinct. At the core of each view of agile was a belief in the fundamental value of the continuous delivery of quality software. Second was the belief in regular adjustment based on reflection and self-examination. These two principles form the core of agile development. They both involve the attitude toward change that is at the heart of Conboy’s definition of agile (2009). Second, what environmental factors shape agile practices? We found at least three environmental factors that affected agile implementation. The first was governmental regulation, which resulted in the form of agile that emerged in Company C. The second was the extent of agile experience at each company. The firm with the more experience had adapted agile to their needs, whereas the other two firms were still working their way through the adaption process. The third factor was the extent to which these companies had dispersed customers and development teams, rendering the principle of FtF communication difficult to observe.
There are several implications managers can derive from this study. First, the definition of “agile” varies greatly across organizations. When the VersionOne.com (2017) survey reported that 94 per cent of responding organizations said they were agile, those organizations were not referring to a single unified approach. While 58 per cent reported they used Scrum, 10 per cent said they relied on a Scrum/eXtreme Programming hybrid, and 8 per cent said they used a custom hybrid. The remaining 24 per cent of respondents reported using one of 11 other approaches. In communications across industries, across organizations within an industry, and even across divisions and work groups within an organization, it is important to define what is meant by the term “agile.” Questions like “How can we improve the effectiveness of our agile approach?” can only be answered sensibly by first identifying the differences in how various units define and practice the agile approach.
The second implication is that you do not need to be totally agile to be agile. A systems development approach can fail to faithfully observe most of the 12 agile principles and still be considered agile. Organizations can adopt the agile approach whole cloth, as was the case for Company B. Or they can adjust their adherence to the principles over time, as was the case with Company A.
The third implication is that, to be agile, companies minimally need to adhere to the primacy of frequently delivered quality product and the periodic reflection and adjustment of team behaviors. This is not a distillation of the agile approach to simply two principles. Each company we interviewed followed at least these two in addition to other principles. From a practical perspective, these findings imply that the agile approach can succeed and even thrive without adherence to some of the most celebrated identifying principles of the agile approach, such as the necessity of FtF communication and of daily interaction with customers. In today’s global distributed economy with team members and customers remotely located for many organizations, this is welcome news.
The final implication is that organizations wishing to adopt agile must embrace cultural change to be successful. This is particularly important for companies that have a long history of development using traditional waterfall methodologies. Respondents in all three of the companies where we conducted interviews made multiple comments regarding the culture of agile and the change it brought in their organizations. Companies wanting to move toward agile must be willing to break away from the old ways of doing things, including redesigning office space. Cultural changes brought on by reconfiguring office space can positively influence perceptions and attitudes of employees (McElroy and Morrow, 2010).
How many of the 12 principles in the Agile Manifesto can a software development group not implement and still be considered agile? From the observations made in three organizations using agile to develop internal software systems, we see that it is possible to be faithful to just a few principles and still be agile. Effective delivery of software is key, as are periodic reflection and adjustments (retrospectives). The next set of principles that were somewhat faithfully adhered to were process related. The people-related principles were least important, but that is likely due to deeply ingrained organizational practices. The relative flexibility of agile allows organizations to pick and choose which principles are helpful and which are not. Future research investigating agile practices in non-IT environments may be promising.
Interviews held at each company site
|Company||Type of interview||Informants|
|A||Observation of backlog grooming meeting||All Scrum Masters, Product Owners, and a Program Manager|
|A||Observation of a team stand-up||All team members|
|A||Face-to-face and teleconference||Agile team consisting of two application developers, quality assurance engineer, application developer intern, Scrum master, and business analyst (on conference call)|
|A||Face-to-face||Associate Vice President|
|A||Face-to-face||Three product managers|
|B||Observation of a team stand-up||All team members|
|B||Face-to-face||Team members: Smoking Guns; Young Guns|
|B||Face-to-face||Two Scrum masters|
|B||Videoconference||Two customer representatives and Product owner|
|B||Face-to-face||Client liaison and project manager|
|C||Face-to-face||Two IT managers (Project S Informant)|
|C||Videoconference||Technical lead; team member|
|C||Face-to-face||Two customer representatives (Project P informant)|
|C||Face-to-face||Agile evangelist; project manager|
Ahimbisibwe, A., Cavana, R.Y. and Daellenbach, U. (2015), “A contingency fit model of critical success factors for software development projects: a comparison of agile and traditional plan-based methodologies”, Journal of Enterprise Information Management, Vol. 28 No. 1, pp. 7-33.
Alzoubi, Y.I., Gill, A.Q. and Ahmed, A.-A. (2016), “Empirical studies of geographically distributed agile development communication challenges: a systematic review”, Information & Management, Vol. 53 No. 1, pp. 22-37.
Beck, K. (1999), eXtreme Programming Explained: Embrace Change, Addison-Wesley Professional, Boston, MA.
Beck, K. Beedle, M. van Bennekum, A. Cockburn, A. Cunningham, W. Fowler, M. Grenning, J. Highsmith, J. Hunt, A. Jeffries, R. Kern, J. Marick, B. Martin, R.C. Mellor, S. Schwaber, K. Sutherland, J. and Thomas, D. (2001), “The agile manifesto”, available at: www.agilemanifesto.org (accessed 17 June 2016).
Boehm, B. (2002), “Get ready for agile methods, with care”, Computer, Vol. 35 No. 1, pp. 64-69.
Chesbrough, H. and Crowther, A.K. (2006), “Beyond high tech: early adopters of open innovation in other industries”, R&D Management, Vol. 36 No. 3, pp. 229-236.
Chow, T. and Cao, D.B. (2008), “A survey study of critical success factors in agile software projects”, Journal of Systems and Software, Vol. 81 No. 6, pp. 961-971.
Conboy, K. (2009), “Agility from first principles: reconstructing the concept of agility in information systems development”, Information Systems Research, Vol. 20 No. 3, pp. 329-354.
Conboy, K. and Morgan, L. (2011), “Beyond the customer: opening the agile systems development process”, Information and Software Technology, Vol. 53 No. 5, pp. 535-542.
Conboy, K., Coyle, S., Wang, X. and Pikkarainen, M. (2011), “People over process: key challenges in agile development”, IEEE Software, Vol. 28 No. 4, p. 48.
Cram, W.A. and Newell, S. (2016), “Mindful revolution or mindless trend? Examining agile development as a management fashion”, European Journal of Information Systems, Vol. 25 No. 2, pp. 154-169.
Dingsøyr, T., Nerur, S., Balijepally, V. and Moe, N.B. (2012), “A decade of agile methodologies: towards explaining agile software development”, Journal of Systems and Software, Vol. 85 No. 6, pp. 1213-1221.
Durrani, K.U., Pita, U. and Richardson, J. (2014), “Coexistence of agile and SCM practices: an exploratory study of Australian agile software development organizations”, Journal of Systems and Information Technology, Vol. 16 No. 1, pp. 20-39.
Eloranta, V.-P., Koskimies, K. and Mikkonen, T. (2016), “Exploring scrumbut – an empirical study of scrum anti-patterns”, Information and Software Technology, Vol. 74, pp. 194-203.
Fowler, M. and Highsmith, J. (2001), “The agile manifesto”, Software Development, Vol. 9 No. 8, pp. 28-35.
Kern, M. (2016), “Agile is dead”, available at: www.linkedin.com/pulse/agile-dead-matthew-kern (accessed 1 May 2016).
Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., May, J. and Kahkonen, T. (2004), “Agile software development in large organizations”, Computer, Vol. 37 No. 12, pp. 26-34.
McElroy, J.C. and Morrow, P.C. (2010), “Employee reactions to office redesign: a naturally occurring quasi-field experiment in a multi-generational setting”, Human Relations, Vol. 63 No. 5, pp. 609-636.
McHugh, O., Conboy, K. and Lang, M. (2012), “Agile practices: the impact on trust in software project teams”, IEEE Software, Vol. 29 No. 3, pp. 71-76.
Mishra, D. and Mishra, A. (2011), “Complex software project development: agile methods adoption”, Journal of Software Maintenance and Evolution: Research and Practice, Vol. 23 No. 8, pp. 549-564.
Nerur, S., Mahapatra, R. and Mangalaraj, G. (2005), “Challenges of migrating to agile methodologies”, Communications of the ACM, Vol. 48 No. 5, pp. 72-78.
Recker, J., Holten, R., Hummel, M. and Rosenbranz, C. (2017), “How agile practices impact customer responsiveness and development success: a field study”, Project Management Journal, Vol. 48 No. 2, pp. 99-121.
Schwaber, K. (1997), “Scrum development process”, Proceedings of Business Object Design and Implementation, OOPSLA ‘95 Workshop, Springer, pp. 117-134.
Scrum.org (2018), “What is scrumbut?”, available at: www.scrum.org/resources/what-scrumbut (accessed 9 March 2018).
Senapathi, M. and Srinivasan, A. (2012), “Understanding post-adoptive agile usage: an exploratory cross-case analysis”, Journal of Systems and Software, Vol. 85 No. 6, pp. 1255-1268.
Terje Karlsen, J., Hagman, L. and Pedersen, T. (2011), “Intra-project transfer of knowledge in information systems development firms”, Journal of Systems and Information Technology, Vol. 13 No. 1, pp. 66-80.
Tripp, J.F. and Armstrong, D.J. (2016), “Agile methodologies: organizational adoption motives, tailoring, and performance”, Journal of Computer Information Systems, Vol. 58 No. 2, pp. 170-179, doi: 10.1080/08874417.2016.1220240.
VersionOne.com (2017), “The 11th annual state of agile report”, available at: www.versionone.com (accessed 6 April 2017).
Wang, X., Conboy, K. and Cawley, O. (2012), “Leagile’ software development: an experience report analysis of the application of lean approaches in agile software development”, Journal of Systems and Software, Vol. 85 No. 6, pp. 1287-1299.
Williams, L. (2012), “What agile teams think of agile principles”, Communications of the ACM, Vol. 55 No. 4, pp. 71-76.
Wolpers, S. (2018), “Agile management ant-patterns – an introduction”, available at: https://age-of-product.com/agile-management-anti-patterns/ (accessed 9 March 2018).
Kahkonen, T. (2004), “Agile methods for large organizations-building communities of practice”, Agile Development Conference, IEEE, pp. 2-10.
Sutherland, J.V. and Schwaber, K. (1995), “Business object design and implementation”, Proceedings of OOPSLA ‘95 Workshop, The University of Michigan, p. 118.