Chapter 10

Advances in Agile software development

Diane Strode

In the early 2000s, the information technology community of New Zealand greeted Agile software development with both wild enthusiasm and deep scepticism. The ideas of Agile software development overturned many of the best practices of software development that IT professionals learned during the 1980s and ’90s. The ideas seemed extreme. Extreme programming, the Agile method that made the biggest splash in the early 2000s, was named to fit in with a fashion for things extreme: extreme sports, extreme dating, extreme makeovers, and more. The enthusiasts were excited, they hoped that Agile methods would make development better for developers and customers, and they would shuck off the burden of managerial oversight and bureaucracy. People with traditional development roles like manager, project manager, analyst, software designer, programmer and tester were horrified because, if the agilists were to be believed, this new paradigm would change everything, eliminating these familiar development roles. These were the roles that people had been trained for; roles that fitted within a particular organisational and work structure for software and system development projects. In the early days, Agile was viewed as a fad and, like all fads, it would pass.

There are a lot of Agile things happening in New Zealand now. This short article is an overview of past and current events. I first explain what Agile software development is and describe Agile variants that have emerged. Next, I describe how Agile software development has been adopted and adapted in New Zealand. Then I cover what has happened in the New Zealand government sector to accommodate this new Agile way of working, and show how some large organisations in New Zealand have made headlines by restructuring based on Agile ideas. I discuss the new job roles that are now common as organisations adapt to Agile. I finish with three foundations for the Agile movement in New Zealand: research, communities of practice, and the education sector.

What is Agile software development?

Agile software development emerged when 17 experienced practitioners and method experts met in 2001 in the USA. They met to discuss persistent problems in software development not adequately addressed by traditional systems development methodologies, by best practice software engineering, or by IT project management practice. This group developed a manifesto for Agile software development and posted it online in 2001. The manifesto remains there to this day. Figure 1 shows the key principles of the manifesto and Figure 2 shows the people who wrote the key books that explained Agile software development.

Initially, Agile methods were called ‘lightweight’ to distinguish them from the traditional ‘heavyweight’ methods. Heavyweight methods produce many non-software artefacts during development such as documented plans, models and specifications. In this camp, are methods like SSADM (Eva 1994), Information Engineering (Martin & Finkelstein 1981), and the Unified Software Development Process (Jacobson et al 1999).

During their meeting, the manifesto contributors decided to rename the lightweight methods ‘Agile methods’. Each Agile method, more or less, follows the philosophy written in the Agile Manifesto’s four values and twelve guiding principles. ‘Agile software development’ became a catch-all term used when a project is organised using any one of the Agile methods.* There are about twelve Agile methods, although there is no definitive list because there is no agreed definition on what constitutes an Agile method. Table 1 shows the twelve.

When they were first published, Agile methods imposed specific requirements on project teams (e.g. Beck 2000). Teams should be co-located with up to ten developers, projects should be creating small interface-intensive, internet-based applications in greenfield environments,* and development would be most effective where requirements were uncertain and changing and getting the software product to market quickly was overwhelmingly important (Baskerville et al 2010). Agile methods were considered unsuitable for large projects, legacy redevelopment projects, distributed projects, or mission-critical projects (Lindvall et al 2004). An early definition stated:

An agile method is a software development methodology designed for the management and support of iterative and incremental development of business systems in environments where change is constant. Agile methods use software development techniques that enhance teamwork in small, empowered teams and support active customer involvement. An agile method is designed to produce working software early, using communication, feedback, learning, and frequent meetings in preference to modelling and documentation. Agile methods adapt existing software development techniques to achieve these goals. (Strode 2006, p. 262)

Although Agile methods share the common features written in the definition above, each method has a different purpose. For example, XP was designed for software development in high change environments, for satisfying customer needs, and for maintaining effective teams (Beck 2000). Scrum focuses on project management of iterative development (Schwaber & Beedle 2002). DSDM (Dynamic Systems Development Method) is a framework for Rapid Application Development (RAD) (Stapleton 1997), and Crystal methods provide techniques for designing a methodology to suit a specific project (Cockburn 2002).

Agile software development is now an accepted approach in New Zealand and worldwide, and has been adopted and adapted in a multitude of different project contexts. In the last two decades, Agile methods have been adapted for globally distributed projects, very large-scale projects, and for the development of mission-critical, high security, and embedded software (Bartsch 2011; Conboy & Carroll 2019; Dingsøyr et al 2014; Edison et al 2021; Jalali & Wohlin 2012; Messina et al 2016; Shen et al 2012). New Agile methods have emerged, usually variations of a core Agile method. These variants are described in the next section.

As some groups have found, focusing on Agile practices (pair programming, refactoring, wallboards, demos, retrospectives, etc.) can be confusing when you learn about Agile software development. Different Agile methods (Scrum, XP) assemble different Agile practices differently. As I found in about 2003, after researching software development teams using Agile methods in Wellington …

Without a definition of agility, any author can state that their method is an agile method. The agile manifesto (Beck et al 2001) is not a suitable set of criteria for defining agility. To be useful as an accurate indicator of agility all of the manifesto principles would need to be met by any method that called itself agile. However, each of the commonly acknowledged agile methods fulfils some subset, but not all of the 12 principles of the manifesto (Visconti & Cook 2004), making it…a poor tool with which to (measure agility) (Strode (2005) cited in Baham and Hirschheim (2021, p. 4)).

Because of this problem with defining what constitutes an Agile method and deciding which practices to focus on, trainers, coaches and scrum masters often begin Agile training by conveying the ideas of an Agile mindset, empowered teams and servant leadership or shared leadership, rather than focusing on religiously following specific practices. Another fundamental idea that fits with this set of principles is that teams can continuously reflect and then adapt their Agile method to suit their project, team, product, or organisation.

Due to this complexity, I use the term ‘Agile approach’ in this paper because it encompasses the use of an Agile philosophy, Agile principles, an Agile method, a hybrid of Agile methods, or groups of Agile practices used by teams, projects and organisations.

Agile variants

To adjust the basic Agile approach for different environments, variants of the Agile methods are now available. Scrum has been the most commonly adopted method and well-defined variants have been published. Variants of other Agile methods are less common, and many provide minimal guidance on how to tailor or scale up a method. One exception is the Crystal family of Agile methods (Cockburn 2005), which was originally published with explicit advice on scaling up by adopting one of Crystal Clear, Crystal Yellow, Crystal Orange and Crystal Red, depending on the project environment and team size.

The Agile variants were created to handle large projects, large teams, and distributed teams, with some more suitable for organisation-wide Agile adoption.

• LeSS (Large Scale Scrum) is for very large-scale scrum product teams (Paasivaara & Lassenius 2016).
• SAFe (Scaled Agile Framework) is for enterprise-level agility (Paasivaara & Lassenius 2016).
• DAD (Disciplined Agile Delivery) a hybrid method that combines Scrum framework practices with Extreme Programming, Unified Process, Lean and other Agile practices (Paasivaara & Lassenius 2016).
• Scrum of Scrums (SoS) is a Scrum variant to coordinate a large project across multiple Scrum teams (Khmelevsky, Li & Madnick 2017).
• Scrum@scale has practices for coordinating multiple Scrum teams working on a single product.
• The Spotify Model (Salameh & Bass 2019) organises work into groups called squads, chapters, tribes and guilds. Referred to as squadification, this model has been adopted at Trademe and other software development organisations in New Zealand.
• DevOps is a set of Agile practices that enables software development units and other IT units to work together seamlessly to continuously deliver software (Leite et al 2019).

An Agile practice guide was published by the PMI (Project Management Institute) in 2017 (Griffiths et al 2017) further influencing Agile adopters beyond the software development world. Agile has also morphed to adapt to non-project based software development such as product-centric development and service-centric development (Niederman et al 2018).

History of adoption and adaptation

New Zealanders began using Agile methods not long after Agile hit the headlines in the early 2000s with the publication of two books, Extreme Programming Explained: Embrace Change (Beck 2000) and Agile Software Development with Scrum (Schwaber & Beedle 2002), and the Agile Manifesto (Hayes & Andrews 2003; Strode 2005). In the early days, XP was the preferred Agile method but eventually, the Scrum method became more popular, probably due to its simpler set of practices and less prescriptive guidelines. Adopters learned to tailor the Agile methods to suit their context and often combined XP with Scrum since the technical practices described in XP could be used within the simpler Scrum framework.

Since 2010, the Agile approach has become strongly embedded as the way to do the work of software development in New Zealand. Organisations have observed the benefits of Agile software development for software teams and observed improvements in product quality, customer satisfaction, and time to market (VersionOne 2020). This has influenced them to adopt Agile approaches to try and generate these benefits company-wide and increase their organisational agility (see the Agile making headlines section).

Anywhere software is designed, developed and tested, Agile approaches are in use. Small software development companies, large consultancies, most banks, and many insurance companies in New Zealand have adopted Agile approaches in their software development centres. Companies such as Snapper Ltd, Trade Me, Xero and Vodafone, NZME (New Zealand Media and Entertainment), and retailers such as The Warehouse are using Agile approaches. The New Zealand Defence Force, hospitals and city councils are using Agile approaches. The most commonly adopted Agile method in New Zealand is Scrum. This was reported in an Australasian study (Licorish et al 2021), once again reflecting the international trend (VersionOne 2020).

Agile adoption in New Zealand, consistent with international trends, has extended to large-scale development and globally distributed development. Agile adoption has influenced the DevOps movement. Table 2 shows the popularity of DevOps experience in job roles.

Recently, due to the global COVID-19 pandemic, Agile software development has morphed again to adapt to virtual teamwork. At the time I write, this pandemic has not affected New Zealand workplaces to the extent it has elsewhere around the world, where very long and restrictive lockdowns have forced virtual teamwork to become the norm. In New Zealand, remote working has always been possible but after the peak of the pandemic lockdown in New Zealand in early 2020, virtual working became more popular as people working in software development became familiar with this way of working.

Agile in the government sector

Agile is now considered a legitimate, although still ‘new’ way of working in 2019, by the New Zealand government. The guidelines set out risk-based assurance principles that should be applied by government organisations when they use Agile delivery in IT and non-IT contexts (NZ Government 2019). The reason for developing this set of guidelines was because the people working in government departments wanted to work in an Agile way. One show-stopper issue with working in an Agile way, both within government departments and for software development companies contracting services to the government, was the government’s contracts and procurement process, which was heavily traditional. In traditional contract negotiation, requirements, timelines and costs must be documented to win a government contract for software development. This issue perfectly illustrated the Agile principle, ‘customer collaboration over contract negotiation’. The recently published guidelines should assist in reducing this barrier so that software developers working in an Agile way can bid for and win government contracts more easily.

Agile making headlines

The relationship between organisational agility and Agile software development has proved problematic for some sectors. Headlines focus on the bad news or potential problems when New Zealand companies have adopted agility and certain Agile practices have been imposed throughout their organisations. A few examples show how organisations often forget to listen to their local experts.

Spark, in 2018, made the headlines with a radical organisational transformation where new contracts were signed if staff agreed to work in an Agile way. ‘Staff were given five weeks to decide whether they wanted to get on the Agile bus. Old roles were effectively gone — everyone in an Agile workplace works in multi-disciplined work groups, or ‘squads’.’

The New Zealand Herald, in March 2020, stated, ‘… more and more organisations are now aligning to Agile ways of working, where you may need to “hot desk”, work in “squads” and “tribes” instead of departments (or the dreaded silo), and work for “coaches”, not managers.’ But, an experienced Agile consultant was at pains to explain: ‘Hot desking doesn’t make an organisation Agile.’

In 2020, another headline: ‘Restructures giving Agile a bad name’. A local consultancy firm specialising in Agile methods condemned the ‘movement to agility’ by some organisations (The Warehouse Group, in this case), saying, ‘We’ve seen it time and time again. Organisations that dress up their episodic restructures and routine layoffs as a move towards Agile or new ways of working. They’ll implement a few Agile or Scrum practices, reduce costs here and there and check some boxes just to become a bit more efficient. These organisations give Agile a bad name.’

As most of these organisational transformations to agility have yet to be tested over time, the outcomes are not yet known. A recent article in the project management field noted, ‘it is an open question as to whether Agile project practices, inside and beyond SWD [software development], result in more Agile organizations and/or whether they result in more profitable or strategically well-positioned firms whether or not they are more Agile.’ (Niederman et al 2018, p. 13).

The lack of top management support, well-recognised internationally as a problem in any organisational change, is a problem also reported for these whole-organisation Agile transformations. But, the news is not uniformly bad. One newspaper, reporting a thought piece from the large consultancy Assurity, stated that Agile, alongside other new ideas in the technology industry such as data analytics, AI and machine learning, and implementing end-to-end processes, are predicted to help companies become ‘future ready’ to survive.

Old petunias in new vases*

The widespread adoption of Agile soft­ware development has created new job roles. For those who thought that the traditional roles of project manager, business analyst and tester would vanish, they have remained but now have an ‘Agile’ flavour. Whether these roles have truly changed is an open question.

In 2021, Agile-related roles are in demand in the New Zealand workforce. AbsoluteIT, an IT recruitment firm that reports on annual demand for IT skills in New Zealand,13 reported that in 2020 ‘Agile’ was the eighth most in-demand skill country-wide, and the fourth most in-demand skill in Auckland. A simple search of the popular New Zealand job seeker site, Seek, has many calls to fill job roles for ‘Agile X’, where X is a tester, team lead, business analyst, developer, or project manager. Calls for new Agile roles include Scrum master, Scrum coach, Agile coach, Agile consultant, and for people who want to work in Agile teams or the new group arrangements of tribes and squads. Table 2 indicates this trend. Less common, are unique new roles such as ‘Agile delivery lead’, ‘Agile capability lead’, and requests for ‘SAFe Agile experience’, and for ‘Agile culture and Lean change management experience’.

Agile research in New Zealand

New Zealand is at the forefront of research into Agile approaches. New Zealand software development teams are particularly welcoming to researchers, which is not always the case in other countries. This has allowed significant studies of Agile software development based on empirical investigations of the work of software development to be carried out within New Zealand.

New Zealand based research draws on the knowledge and experiences of organisations, teams, projects and individuals and is published internationally. This research contributes to the international knowledge base on Agile software development and has influenced research overseas and practitioners in other countries. Most of the research is based on case studies, surveys and grounded-theory studies (working directly from data). For example, early research investigated customer involvement in XP teams in New Zealand and the USA and identified the complexities and high workload experienced by people in this role (Martin et al 2004). Based on a study of developers in New Zealand and India, Hoda et al (2013) highlighted the roles that emerge in self-organising Agile software development teams: mentor, coordinator, translator, Agile champion, promoter and terminator. Strode et al (2012) investigated how Agile practices contribute to project coordination in a study of New Zealand organisations and found that Agile practices support synchronisation, structure and boundary spanning in software projects. Senapathi and Srinivasan (2012) compared New Zealand and UK-based organisations in a study of post-adoptive Agile usage. They found that the factors affecting post-adoption usage were the relative advantage of adoption, top management support, compatibility, attitude, technical competence, a methodology champion, understanding Agile practices and tools that support Agile practices. A New Zealand perspective on DevOps was provided by Hussain et al (2017) who identified key knowledge areas, skills and capabilities for the DevOps role, and how DevOps for globally distributed development is desirable in the New Zealand job market. Very recently, Edmondson and Chiu (2020) generated new ideas on mental models within Scrum teams based on a study of teams in the New Zealand government. They found that the mental model of the product owner and the development team appears to affect client and team satisfaction.

This small summary of the New Zealand based research shows that local knowledge is valuable, has an international audience, and can help us to better understand Agile practice.

Agile communities of practice in New Zealand

Agile communities of practice and support groups flourish in New Zealand. Online organisation is easy with tools such as Meetup (I found thirteen groups in a search on 20 April 2021). Agile and Scrum Meetup groups exist in all of the larger cities and many of the smaller ones. The government has internal groups to provide support for Agile initiatives. New Zealand chapters of organisations such as IIBA (International Institute of Business Analysts) and PMI (Project Management Institute) regularly have talks devoted to Agile discussions. A small group of experienced practitioners also contribute internationally by designing certification content (e.g. ICAgile), by hosting international chapters (e.g. Agile Alliance New Zealand) and by writing for international audiences (e.g. InfoQ articles).

Agile education, training and certification

In New Zealand, consultancies such as Assurity, ThreePoints, SoftEd, Boost, Radically, Nomad8, Catalyst, Equinox and many others, offer Scrum training and training in some of the variants to both large and small organisations. Certifications are available, although the idea of certification, especially if there is no practical experience component, is anathema to some Agile traditionalists. Common certifications are all international and include PMI (with its ‘Agile Practice Guide’, which had New Zealand contributors), ICAgile (which had New Zealand contributors), PSM (Professional Scrum Master training), CSM (Certified Scrum Master), PMI Agile Certification and SAFe Scrum Master training. Many large organisations hire consultants and coaches when adopting Agile approaches. These coaches work on-site with a team or teams for days, weeks, or months to embed the Agile philosophy, principles and practices.

Agile methods are now standard knowledge in the curricula of all universities and polytechnics in New Zealand that teach software engineering, IT project management and information systems. Sometimes these courses are shy about their ‘Agile’ content, embedding Agile philosophy, principles and practices without naming their courses Agile software development.

‘Teaching Agile practices has found its place in software engineering curricula in many universities across the globe … educators and students have embraced different ways to apply Agile practices during their courses through lectures, games, projects, workshops and more for effective theoretical and practical learning. Practicing Agile in university contexts comes with challenges for students … This study describes the constraints the students faced while applying Agile practices in a university course taught at the University of Auckland’ (Masood et al 2018, p. 501).

Conclusion

I conclude that Agile software development is no fad. The Agile philosophy, methods and practices are adopted widely in New Zealand. Agile is used in all types of organisations where it has had a significant impact on individuals, teams, projects and management. This is because Agile adoption changes organisation structure, culture, roles, contract negotiation, human resourcing, teams and teamwork, leadership and project management practices, the way customers are involved in projects, how system quality is negotiated, and the way that software is delivered.

The success of small-scale Agile has spawned a new wave of Agile in the non-IT field and influenced whole organisations to adopt Agile mindsets and practices. Agile has now moved into marketing teams, sales teams, construction teams, strategic management, and has evolved to encompass Agile organisational transformations. The next decade will show us if this simple set of ideas will continue to influence teams, software products and service provision, and change whole organisations for the better.

Dr Diane Strode’s research concerns Agile software development and its effect on projects, teams and organisations. Her interest in this topic began in 2002 and since then she has carried out many case studies of active software development projects. She has published research on coordination and dependencies in Agile projects, Agile teamwork, organisational agility and Agile leadership, onboarding to Agile teams, and the business value of Agile projects.

Diane collaborates on research projects with groups in New Zealand, Germany, Malaysia, Norway and the United Kingdom (Agile Research Network) and is a research fellow at the Open University in the UK. Her research appears in the Journal of Systems and Software, Information Systems Frontiers, and international and New Zealand conferences. Her experience includes chairing the long-running Agile and project management track for the Australasian Conference on Information Systems (ACIS), Associate Editor roles in information systems conferences (ICIS, ECIS), and the XP conference series, and reviewing for leading journals in information systems and software engineering.

Diane is a Senior Lecturer in the School of Information Technology at Whitireia Polytechnic New Zealand where she teaches on the Master of Information Technology (MIT), the Bachelor of Information Technology, and supervises MIT theses. She has also lectured at OTH Regensburg (Technical University of Applied Sciences) in Germany and Victoria University of Wellington in NZ. Diane has experience as a software developer in Melbourne Australia and her qualifications include a BSc (Computer Science) from the University of Melbourne, a Master of Information Sciences (Information Systems) from Massey University and a PhD (Information Systems) from Victoria University of Wellington in New Zealand.

References

Abrahamsson, P, Warsta, J, Siponen, MK & Ronkainen, J (2003). New directions on Agile methods: A comparative analysis. In Proceedings of the 25th International Conference on Software Engineering, ICSE’03 (pp. 244–254). IEEE Computer Society.

Agerfalk, PJ & Fitzgerald, B (2006). Flexible and distributed software processes: Old petunias in new bowls? Communications of the ACM, 49(10), 27–34.

Ambler, SW (2002). Agile modeling: Effective practices for Extreme Programming and the Unified Process. John Wiley & Sons, Inc.

Baham, C & Hirschheim, R (2021). Issues, challenges, and a proposed theoretical core of Agile software development research. Information Systems Journal, 1–27. doi.org/10.1111/isj.12336

Bartsch, S (2011). Practitioners’ perspectives on security in Agile development. 2011 Sixth International Conference on Availability, Reliability and Security,

Baskerville, R & Pries-Heje, J (2001). Racing the E-bomb: How the Internet is redefining information systems development methodology. In B Fitzgerald, N Russo & J DeGross (Eds.), Realigning research and practice in IS development (pp. 49–68). Kluwer.

Baskerville, R, Pries-Heje, J & Madsen, S (2010). Post-agility: What follows a decade of agility? Information and Software Technology, 53(5), 543–555.

Beck, K (1999). Embracing change with Extreme Programming. Computer, 32(10), 70–77.

Beck, K (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley.

Beedle, M, Devos, M, Sharon, Y, Schwaber, K & Sutherland, J (1999). Scrum: A pattern language for hyperproductive software development. In N Harrison, B Foote & H Rohnert (Eds.), Pattern Languages of Program Design (pp. 637–651). Addison-Wesley.

Charette, R (2002). Foundations of Lean Development: The Lean Development manager’s guide (Vol. 2). ITABHI Corporation.

Cockburn, A (1998). Surviving Object-oriented Projects: A Manager’s Guide. Addison Wesley Longman.

—— (2002). Agile Software Development. Addison-Wesley.

—— (2005). Crystal Clear: A Human-Powered Methodology for Small Teams. Pearson Education.

Conboy, K & Carroll, N (2019). Implementing large-scale Agile frameworks: challenges and recommendations. IEEE Software, 36(2), 44–50.

Cusumano, M & Yoffie, DB (1999). Software development on Internet time. IEEE Computer, 32(10), 60–69.

Dingsøyr, T, Fægri, TE & Itkonen, J (2014). What is large in large-scale? A taxonomy of scale for Agile software development. In International Conference on Product-Focused Software Process Improvement (pp. 273–276). Springer.

Dynamic Systems Development Method (1995) (2 ed.). Tesseract Publishing.

Edison, H, Wang, X & Conboy, K (2021). Comparing Methods for Large-Scale Agile Software Development: A Systematic Literature.

Edmondson, S & Chiu, Y-T (2020). Exploring the Impact of Mental Models on Scrum Outcomes: Insights from Scrum Teams in New Zealand Government. In Proceedings of the Australasian Conference on Information Systems, ACIS 2020 (pp. 1–12). AIS. aisel.aisnet.org/acis2020/2

Eva, M (1994). SSADM Version 4: A User’s Guide (2 ed.). McGraw-Hill Book Company.

Griffiths, M, Fewell, M, Slusanschi, H, Matola, S, Rothman, J, Hartman, B & Kauffman, B (2017). Agile practice guide. Project Management Institute.

Hayes, S & Andrews, M (2003). An introduction to Agile methods. Steve Hayes (Khatovar Technology) khatovartech.com

Highsmith, J (2000). Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House Publishing.

Hoda, R, Noble, J & Marshall, S (2013). Self-organizing roles on Agile software development teams. IEEE Transactions on Software Engineering, 39(3), 422–444. doi.org/10.1109/TSE.2012.30

Hunt, A & Thomas, D (2000). The Pragmatic Programmer. Addison Wesley.

Hussain, W, Clear, T & MacDonell, S (2017). Emerging trends for global DevOps: a New Zealand perspective. 2017 IEEE 12th International Conference on Global Software Engineering (ICGSE),

Jacobson, I, Booch, G & Rumbaugh, J (1999). The Unified Software Development Process. Addison-Wesley.

Jalali, S & Wohlin, C (2012). Global software engineering and Agile practices: A systematic review. Journal of Software: Evolution and Process, 24, 643–659. doi.org/10.1002/smr.561

Leite, L, Rocha, C, Kon, F, Milojicic, D & Meirelles, P (2019). A survey of DevOps concepts and challenges. ACM Computing Surveys (CSUR), 52(6), 1–35.

Licorish, SA, Treude, C, Grundy, J, Blincoe, K, MacDonell, S, Tantithamthavorn, C, Li, L & Schneider, J-G (2021). Software Engineering in Australasia. ACM SIGSOFT Software Engineering Notes, 46(2), 16–17.

Lindvall, M, Muthig, D, Dagnino, A, Wallin, C, Stupperich, M, Kiefer, D, May, J & Kahkonen, T (2004). Agile software development in large organizations. Computer, 37(12), 26–33.

Martin, A, Biddle, R & Noble, J (2004). The XP customer role in practice: Three studies. Agile development conference,

Martin, J & Finkelstein, C (1981). Information Engineering. Vol 1 and 2. Prentice Hall.

Martin, R (1998). The process: Object oriented analysis and design with applications. Addison-Wesley.

Masood, Z, Hoda, R & Blincoe, K (2018). Adapting Agile practices in university contexts. Journal of Systems and Software, 144, 501–510.

Messina, A, Fiore, F, Ruggiero, M, Ciancarini, P & Russo, D (2016). A new Agile paradigm for mission-critical software development. CrossTalk, 29(6), 25–30.

Niederman, F, Lechler, T & Petit, Y (2018). A research agenda for extending Agile practices in software development and additional task domains. Project Management Journal, 49(6), 3–17.

NZ Government (2019). Assuring Digital Government Outcomes: Assurance Guidance for Agile Delivery, Version 1.1 October. Retrieved from www.digital.govt.nz/dmsdocument/115-assurance-guidance-for-agile-delivery-full/html

Paasivaara, M & Lassenius, C (2016). Scaling scrum in a large globally distributed organization: A case study. 2016 IEEE 11th International Conference on Global Software Engineering (ICGSE),

Palmer, SR & Felsing, JM (2002). A Practical Guide to Feature-Driven Development. Prentice Hall.

Poppendiek, M & Poppendiek, T (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley.

Salameh, A & Bass, JM (2019). Spotify tailoring for promoting effectiveness in cross-functional autonomous squads. In International Conference on Agile Software Development (pp. 20–28). Springer.

Schwaber, K & Beedle, M (2002). Agile software development with Scrum. Prentice Hall.

Senapathi, M & Srinivasan, A (2012). Understanding post-adoptive Agile usage: An exploratory cross-case analysis. Journal of Systems and Software, 85(6), 1255–1268.

Sharma, R, Sugumaran, V & Rajagopalan, B (2002). A framework for creating hybrid-open source software communities. Information Systems Journal, 12(1), 7–25.

Shen, M, Yang, W, Rong, G & Shao, D (2012). Applying Agile methods to embedded software development: A systematic review. In 2012 Second International Workshop on Software Engineering for Embedded Systems (SEES) (pp. 30–36). IEEE.

Stapleton, J (1997). DSDM Dynamic Systems Development Method. Addison-Wesley.

Strode, DE (2005). The Agile methods: An analytical comparison of five Agile methods and an investigation of their target environment. [Master’s Thesis, Massey University]. Palmerston North, New Zealand. hdl.handle.net/10179/515

—— (2006). Agile methods: a comparative analysis. In S Mann & N Bridgeman (Eds.), Proceedings of the 19th Annual Conference of the National Advisory Committee on Computing Qualifications, NACCQ 2006 (pp. 257–264). NACCQ.

—— (2007). Characterising the Agile methods. New Zealand Journal of Applied Computing and Information Technology, 11(1), 65–79.

Strode, DE, Huff, SL, Hope, B & Link, S (2012). Coordination in co-located Agile software development projects. Journal of Systems and Software, 85(6), 1222–1238.

VersionOne (2020). The 14th state of Agile report. stateofagile.com/

Visconti, M & Cook, CR (2004). An ideal process model for Agile methods 5th International Conference on Product Focused Software Process Improvement, PROFES 2004, Berlin