Chapter 1. Introduction
1.1 – Overview and scope
Baker (2017) determines that agility – more than ever – is the driver of organizational experience. Throughout the 21st century, technology has become a fundamental success factor for organisations who can implement and exploit its capabilities. More specifically, the use of up-to-date, game-changing software is a key contributor to competitive advantage. Organisations who can release software that their customers need before their competition will understand that this process is constantly required in order to be successful. As organisations seek for the creation of innovative products through software delivery, they must be aware of development methodologies and when the best time to utilise them is.
The agile methodology has become a market leader through its practises being widely adopted by the most successful technology firms in the world. The success of agile is attributed with its flexibility to adapt to technological change over time. It continuously evaluates the mistakes of traditional project management methodologies and has transformed software delivery in the past two decades. However, traditional methods including Waterfall and Prince2 still exist in current business practises today and have their continued successes.
The evaluation of the competition between agile and traditional methods is an interesting concept when assessing their importance. Agile encourages a flexible, team working environment who constantly deliver working software to their customers with clear communication. Agile is open to unpredictability and welcomes change late on in the development process which has made this methodology so unique. However, is this practise sustainable as technologies such as the Internet of Things (IoT) and big data become crucial in the near future? This dissertation will look into whether this methodology is a sustainable source of organisational performance or firms need to continually reassess their software delivery strategies.
1.2 – Aims and objectives
The aim of this dissertation is to advise organisations who haven’t thus far to consider adopting a working agile methodology in their respected practice. This suggestion will be supported through examples of agile successes and its sustainability in the future. It will also advise these companies and current organisations who practise agile to have knowledge of emerging methodologies in order to stay ahead of the market.
In order to adhere to the aims of this dissertation, the following objectives will be met:
- Defining traditional project management methodologies within software delivery to understand the emergence of agile and its uniqueness.
- Understanding agile’s key focuses on scope and user experience compared to traditional methodologies and how vital this is to the organisation.
- Knowing how the implementation of agile between small, medium and large organisations can vary and what the best approach for this is.
- Using case studies, explore how organisations have implemented agile and evaluate their outcomes.
- Understanding where and how the agile methodology impacts organisations end-users directly and revealing this relationship.
- Exploring the future of agile and its advantages and challenges going forward.
1.3 – Chapter structure
Following chapters are planned for this dissertation as follows.
Chapter 2 – In order to receive an understanding of the importance of the agile methodology, a review of project management literature is necessary. This has been conducted through the use of secondary research of academic resources and website articles. This chapter begins with a synopsis of traditional project management methodologies, giving a timeline of how they have been adopted. It concludes with the formation of the agile methodology, its success, its failures and how it’s been implemented across organisations.
Chapter 3 – After evaluating the significance of the agile methodology within software delivery, the agile user experience chapter will discuss where its implementation has been a success. This chapter will show a variety of examples in a case study format to explain the why organisations more commonly turn to agile and how it has benefitted their products. From these case studies, analytic tools will be used to evaluate whether the adoption of agile has been a success or a failure under many different factors.
Chapter 4 – A vital area of understanding is required in this chapter when concerning a recommendation. Agile’s sustainability for the foresee-able future will conclude whether organisations should adopt this methodology as part of a long-term development structure. This chapter will also allude to where agile may not be best suited to in certain organisations. In particular, where the use of different and even emerging methodologies is vitally important to software delivery successes.
Chapter 5 – To conclude, this chapter will summarise the arguments and information discussed in this dissertation. This chapter will also relate directly to the aims and objectives detailed in the introduction of this dissertation. Using a strong understanding of the literature in chapter 2 combined with use case examples and analysis in chapter 3, the author will provide a strong argument for the adoption of the agile methodology. This recommendation will aim to target a variety of organisations not dependant on size.
Chapter 2. Literature Review
2.1 – Overview of project management methodologies
The Cambridge Dictionary (2018) defines a ‘project’ as a piece of planned work or an activity that is finished over a period of time and intended to achieve a particular purpose. In addition to this understanding, the Project Management Institute (2018) would refine this term by signifying that a project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. In order to appreciate current practises used by project managers today, a brief but important history of their origins is required.
2.1.1 – Traditional, sequential methodologies
Gantt chart
The birth of modern project management was pioneered by Henry Gantt through his creation of the Gantt chart in the early 20th century. The Gantt chart is a bar chart illustrating a project schedule from start to finish, with a work breakdown of the various stages and processes of the project (Mcray, 2015). The International Association of Project Managers (2017) would agree with this explanation adding that the Gantt chart is a powerful graphic tool for visualising all the tasks and activities in a classic project. It has been in use for decades, and it played a key role in the famous Hoover Dam construction project. Mcray (2015) also confirms that Gantt charts were adopted by the American military beginning with World War I, and today are commonly used in Web-based collaborative groupware. An example of a Gantt chart (6.7 – Gantt Chart) has been used to foresee the completion of this dissertation.
Critical Path Method
In 1957, a new managerial planning and control technique was developed, Program Evaluation and Review Technique (PERT) by the U.S Navy Special Projects Office on the Polaris missile system to support the nuclear submarine project. It is a technique for estimating and planning a large project (Aziz, 2013). Through the use of this research, the next major advancement in project management methodologies was the introduction of the Critical Path Method (CPM). Kelly and Walker (1959) developed the CPM as a project modelling technique within their 1959 paper. They determine that within a project, individual activities have a duration through start and end times and thus can be projected through a diagram. Once this has been completed, this tool will allow the project manager to plot the projects critical path through activities which take the shortest time to complete incurring the lowest cost. One of CPM’s prime success stories is its use in the Apollo 11 Project, which landed two men on the moon on July 20, 1969. NASA used the CPM to help determine an efficient schedule for 2 million tasks that led to the moon landing (Daneshmand, 2011).
Waterfall
Among the traditional development approaches, the waterfall model is the oldest software development process model (Huo et al, 2004). Davis and Radford (2014) describe the waterfall method simply as a model to deliver change. They proceed further by stating that waterfall is predicated on a sequential approach to change whereby development is linear, with outputs of each phase of an analysis (requirements), the design, build, and test and deploy development process cascading like a waterfall into the next phase upon completion (Figure 1.1). The waterfall development model provides us with a high-level framework and within this framework, are five distinct stages: 1) requirements analysis and definition 2) system and software design 3) implementation and unit testing 4) integration and system testing 5) operation and maintenance (Sommerville, 2016). The waterfall model is typically associated with the development of software (Davis and Radford, 2014). In 1985, the United States Department of Defense used the ‘waterfall’ approach in their defense system software development which included the following six stages; Software Requirements Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Computer Software Component (CSC) Integration and Testing, CSCI Testing (‘Department of Defense’, 1985).
Howcroft and Carrol (2000) propose that the major problem with using the waterfall methodology for the development of websites (and also Information Systems) is the rigidity of its structure and the lack of iteration between any stage other than adjacent stages. The web is a fast-moving environment and new technologies are becoming available almost daily. They suggest that any methodology used for the development of websites must be flexible enough to cope with change. Dhandapandi (2016) takes this concern further proposing one of the drawbacks of the waterfall model is that – the requirement gathering sets fixed goals, which by end of the project cycle can become outdated – given the multiple stages in between. The model also does not provide much room for the feedback or iteration to change the UI (User Interface) or design once the development starts. At the end of the phase, the requirements are generally frozen and goals are set.
Figure 1.1 – The waterfall model (Sommerville, 2016).
2.1.2 – Process-based methodologies
PRINCE2
During the 1970’s, the increase in the number of computer software projects and their failures led to the demand of desirable methodologies to suit this new environment. In the UK, a series of system development methodologies were promoted in the early 1980’s (IPSE, PROMPT, SSADM) from which was to come PRINCE – Projects in a Controlled Environment – as a project management methodology in 1990 and PRINCE2 in 1998 (Morris, 2013). Bentley (2009) defines PRINCE2 as a scalable, flexible project management method, suitable for use on any type of project. The implementation of PRINCE 2 produces the following business outputs:
1. Controlled management of change by the business in terms of its investment and return on investment;
2. Active involvement of the users of the final product throughout its development to ensure the business product will meet the functional, environmental, service and management requirements of the users;
3. More efficient control of development resources (Bentley, 2009)
The work of Barker (2013) states PRINCE2’s advice on how a project should be managed is built around three fundamental building blocks: Principles, Themes, and Processes (Figure 1.2). He reveals that the guiding principles drive the design of processes and the theme’s techniques. The latter are also tailored for a snug fit with the way in which projects are organised and run. Lastly, processes make extensive use of PRINCE2’s toolkit as a venture is guided from its early preparation, through initiation and delivery, and on to closure.
Figure 1.2 – The relationship between PRINCE2’s fundamental blocks. (Barker, 2013)
Ahimbisibwe et al. (2015) argues that software development projects continue to fail even with the existence of communities of methodology practise such as PRINCE2. They offer that PRINCE2 is a traditional plan-based approach that seeks to adhere to a pre-established plan, as well as presumed certainty, stability, and ease of targeting/controlling existing processes. Howell et al (2010) would agree with this statement, concluding that the plan-driven process model is inevitably based upon assumptions about the goal, methods, required effort and resource constraints amongst under things. As uncertainty increases, the assumptions will be less valid. Lowe (2000) adds that PRINCE2 doesn’t address all aspects of project management including; leadership and management skills, conflict and stakeholder management and an explanation of tools and techniques.
Lean
Lean was born as part of the industrial renaissance in Japanese manufacturing after the Second World War in the 1940s but the term “Lean” was first applied publically to a product management process and then to product development at MIT during the mid-1980s (Razzak, 2016). Poppendieck and Poppendieck (2003) state that there are seven key principles to lean software development which are fundamental to project management success. The principles and their brief explanations are as follows:
1. Eliminate waste – Waste is anything that does not add value to a product, values as perceived by the customer. If developers code more features than are immediately needed, that is waste.
2. Amplify learning – The best approach to improving a software development environment is to amplify learning.
3. Decide as late as possible – Delaying decisions is valuable because better decisions can be made when they are based on fact, not speculation.
4. Deliver as fast as possible – Without speed, you cannot delay decisions. Without speed, you do not have reliable feedback. Speed assures that customers get what they need now, not what they needed yesterday.
5. Empower the team – Local signalling occurs through visible charts, daily meetings, frequent integration, and comprehensive testing.
6. Build integrity in – Software needs an additional level of integrity – it must maintain its usefulness over time. Software is usually expected to evolve gracefully as it adapts into the future.
7. See the whole – When individuals or organizations are measures on their specialized contribution rather than overall performance, suboptimization is likely to result.
Nataraja and Ramesh (2016) indicate that although lean is a widely accepted and effective methodology it does come with its own set of challenges and complications. They state that companies find it difficult to imbibe and transform with lean because of the following reasons:
1. The main problem of all lean projects is their high dependence on the qualification and discipline of team members.
2. Lean isn’t just a set of tools or a change program that can run its course over a short period; it takes considerable time for organizations to change and evolve.
3. Lean is a change in thinking which doesn’t apply only to specific departments of functions, but even the upper levels of management and the organization as a whole.
Six Sigma
During a period of over ten years from the mid-1980s, a consortium including Motorola developed its own quality approach, based on elements taken from existing quality ideas dating back to the 1950’s and from current Japanese practises. Ultimately, called six sigma, this concept of a quality metric was peculiar to Motorola for many years (Tennant, 2001). The six sigma method is a project-driven management approach to improve the organization’s products, services, and processes by continually reducing defects in the organization. It is a business strategy that focuses on improving customer requirements understanding, business systems, productivity and financial performance (Kwak and Anbari, 2006). Possibly the biggest revelation of six sigma’s achievement was through General Electric’s adoption in 1995 by CEO Jack Welch. Working with engineers and consultants, Welch detected a great deal of defect that had previously gone unnoticed. This build-up of waste was holding the company back, losing them money, and slowing down their production. General Electric’s implantation of six sigma took five years, and the end-result was reported twelve billion dollars in savings (Six Sigma, 2017).
Although Kwak and Anbari (2006) promote the perceived benefits of six sigma in their paper, they also offer obstacles and challenges in its method. They have identified three areas where an organisation may face issues through their strategy, culture and training. Within strategy, organizations must realize that six sigma is not the universal answer to all business issues, and it may not be the most important management strategy than an organization feels a sense of urgency to understand and implement six sigma. They recommend for culture that organizations without a complete understanding of real obstacles of six sigma projects or a comprehensive change management plan are likely to fail. Finally, these authors urge that training is a key success factor in implementing six sigma projects successfully and should be a part of an integrated approach. The belt program should start from the top and be applied to the entire organization.
2.1.3 – Common occurring issues with these methods
Hibbs et al. (2009) draws on the work of the 1994 CHAOS report from the Standish group which is the landmark study of IT project failure. By 1994, the Standish Group had studied over 8,000 software development projects and found that only 16% were successful. This means that 84% of the projects either failed outright or had serious problems. Therefore, the main issues relating to the adoption of traditional and process-based methodologies need to be made explicit.
The following are a summary of the key issues raised thus far:
– Methodologies can’t be static when applying them to software development. Software is constantly and quickly being changed and required by end users. A model that replicates this autonomy is essential.
– A project should not comprise of fixed end results. Fixed end results mean that no changes can be made once development work starts. End users may no longer require this updated once the software is released.
– Plan-driven models are based strongly on assumptions. This results in estimations potentially failing the project significantly.
– These methods don’t solve every business requirement possible. They are very specific to certain types of software development tasks.
– Projects require highly qualified members to introduce and manage the methodology from start to finish. Not every organisation has these resources.
– Introducing a method applies to the whole organisation and make take time to implement. Organisations are too eager to administer change without the appropriate awareness.
Therefore, a prevalent methodology is required in order to combat these key issues and produce consistent project success.
2.2 – The introduction of agile practices and its importance
On February 11-13th, 2001, in the mountains of Utah, seventeen people met to talk and try to find common ground. What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and other sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened (Agile Manifesto, 2001). The founders of this manifesto understood that methodologies that came before agile were not directly benefitting end users due to the fast-paced and unique nature of software development. Therefore, this resulted in the creation of twelve principles (Figure 1.3) that an agile adopted project could follow to ensure successful software delivery resulting in end user benefits.
The traditional and process-based methodologies that have been argued and criticised allow for the conception of methodologies that would proceed to fall under the agile umbrella. This reconfirms the agile methodology’s intent to succeed under past failings.
Figure 1.3 – The twelve principles behind the agile manifesto (Agile Manifesto, 2001).
Throughout the 1990’s, the methods that were formed included: Rapid Application Development (RAD), Dynamic Systems Development Method (DSDM), Scrum, Extreme Programming (XP) and Feature-Driven Development (FDD). The work of Canty (2015) enforces the idea of agile choosing to trade off values with traditional methods (Table 1.1) in order for it to be unique and resulting in its effectiveness. One of the agile manifesto authors Alistair Cockburn proposes an agile process is both light and sufficient. The lightness is a means of staying maneuverable. The sufficiency is a matter of staying in the game (Cockburn, 2002). Greer and Hamon (2011) wouldn’t necessarily agree with any definition for agile software development because they advocate that there is still no complete agreement on what it is. However, they do convey the opinion that agile methods aim to answer a need to develop software quickly, in an environment of rapidly changing requirements.
Table 1.1 – Agile and traditional project management value statements (Canty, 2015).
Agile value Rather Than Traditional Value
Individuals and interactions Over Processes and tools
Working software Over Comprehensive documentation
Customer collaboration Over Contract negotiation
Responding to change Over Following a plan
Agile in the 21st century has advanced in terms of quantities of available practices but also in refinement of the quality of methodologies. Canty (2015) offers additional agile methodologies to those previously mentioned comprising of: Agile Modelling (AM), Lean Development and Kanban. Canty advocates that the most two popular uses of the agile concept are through Scrum and XP.
2.2.1 – Scrum
Hossain et al (2009) effectively summarises Scrum’s working methodology in order to understand its accomplishments. They evaluate that Scrum is an iterative and incremental project management approach that provides a simple “inspect and adapt” framework. In Scrum, software is delivered in increments called “Sprints” (usually 2-4 weeks iterations). The stakeholders of a project attend sprint review meetings to review the state of the business, the market and the technology. Scrum produces three artefacts, namely: product backlogs, sprint backlogs and burn-down charts. Backlogs contain customer requirements and daily burn down charts show the cumulative work remaining.
The Scrum framework (Figure 1.4) is a simple yet highly effective cycle in which teams work within sprints towards a common goal of a working end product. Firstly, a list of ideas for a specific product is created by the product owner and labelled the product backlog. The sprint team will choose collective tasks from the top of the product backlog and then plan how to achieve these tasks in the upcoming sprint. This results in the sprint backlog which allows the team to become aware of upcoming sprints. Sprint periods can last between one to four weeks, during these sprints the team meets every day in a ‘Daily Scrum’ to gage progress and make required amendments. During a sprint, the Scrum Master removes barriers for success so that each team member is focused on the end goal. Once the sprint has been completed, the end product should be ready to deliver to the customer or involve a key stakeholder. Every sprint that has been conducted closes with an evaluation of what has been delivered but also how the team functioned including interactions and tools.
Figure 1.4 – The Scrum software delivery cycle (Scrum Alliance, 2016)
Co-developer of the Scrum methodology, Ken Schwaber (1997), draws upon the faults of traditional development methodologies before proceeding to show why the Scrum methodology is advantageous in this respect. Schwaber suggests that these methodologies are designed only to respond to the unpredictability of the external and development environments at the start of an enhancement cycle.
He takes this further by signifying that these models are limited in their ability to respond to changing requirements once the project has started. The Scrum Methodology, on the other hand, is designed to be quite flexible throughout. It provides control mechanisms for planning a product release and then managing variables as the project progresses as we have found in Figure 1.4. Schwaber (1997) includes three main advantages for the adoption of a Scrum methodology compared to the traditional predecessors and when the best application of the model is.
Figure 1.5 – The advantages of the Scrum Methodology (Schwaber, 1997)
1. The Scrum methodology is designed to be quite flexible throughout. It provides control mechanisms for planning a product release and then managing variables as the project progresses. This enables organizations to change the project and deliverables at any point in time, delivering the most appropriate release
2. The Scrum methodology frees developers to devise the most ingenious solutions throughout the project, as learning occurs and the environment changes. Small collaborative teams of developers are able to share tacit knowledge about development processes. An excellent training environment for all parties is provided.
3. Object oriented technology provides the basis for the Scrum methodology. Objects, or product features, offer a discrete and manageable environment. Procedural code, with its many and intertwined interfaces, is inappropriate for the Scrum methodology. Scrum may be selectively applied to the procedural systems with clean interfaces and strong data.
2.2.2 – Extreme Programming
Qureshi and Ikram (2015) agree with Canty (2015) suggesting that one of the broadly used agile methods is extreme programming (XP). They proceed in defining XP, commenting that it inherits all of the previously mentioned features of agile. In XP, programmers develop the system in pairs. Code is extensively tested and reviewed. Only the functional requirements are focused on without any additional features that are not yet needed. XP focuses on collaboration between all team members including managers, customers and developers. XP consists of 4 main phases: plan, design, code and test (Quershi and Ikram, 2015).
Kent Beck, the creator of XP, detailed his methodology within his 1999 book. This book reveals Beck’s understanding of how XP can be used to create successful software delivery. Beck proposes that XP is a lightweight methodology, in that you only do what you need to do to create value for the customer. This value creation stems from the flexibility of XP to work with teams of any size through its values and principles. One of the key values that Beck advocates is that XP holds an ability to adapt to vague or rapidly changing requirements. This is essential as with all agile methods because requirements need to change to adapt to rapid shifts in the modern business world (Beck and Andres, 2004).
Even though XP and Scrum originate from similar founding ideals, they individually offer different perceived benefits. Firstly, XP is far more open to customer requirement changes than Scrum because in this practise, once a sprint has been planned and started it must be finished before any changes can be made. Another key difference lies within the power of the customer to manager relationship. XP work to a strict order of features detailed directly by the customer and their requirements, whereas the Scrum Master will prioritise product delivery within their sprint backlog. However, the main key feature that sets these two successful practises apart is through their founder’s backgrounds. Beck and XP adopted engineering procedures that focuses on speed of release and quality of the software. On the contrary, Schwaber (1997) and Scrum focuses on the productivity of software delivery and how the team can work effectively to achieve these goals.
2.3 – The implementation of agile
Exercising the agile methodology through a fast paced and flexible team working environment appears to be critical in order to produce continuous software of value. Yet, this transition from traditional approaches to an agile focus may not seem as seamless as organisations believe. Distinguished professor of software engineering, Barry Boehm (2005), poses a significant enquiry into the implementation of agile within traditional organisations. The question we will be looking to answer is ‘How do you merge agile, lightweight processes with standard industrial processes without either killing agility or undermining the years you’ve spent defining and refining your systems and software engineering process assets?’ (Boehm and Turner, 2005).
2.3.1 – Opportunities
Waldron (2017) demonstrates that a business must have a top down approach at a very high level, with major investment required from significant time and commitment changes to the whole organisation. Work environments have to be entirely transformed to best seek rewards, an all or nothing approach. Boehm and Turner (2005) agree that if agile and traditional teams work together on the same product they can develop radically different artefacts that might not integrate easily which in turn impacts onto the customer needs. Waldron continues to recommend that instead of individual departments focusing on their expertise, project managers, technical development, user experience, content and product teams must work collectively in order to be cohesive. If this is achieved, a more agile approach enables us to build better services that ultimately better serve our customers’ needs. In order for a smooth transition to agile, certain fundamental steps (Figure 1.6) can be taken.
Figure 1.6 – Approaches to help organisations integrate agile practises into their traditional processes (adapted from Boehm and Turner, 2005).
Do some serious preparation: Conduct significant analysis of existing processes to identify mismatches in requirements and expectations.
Build up processes: Look at the project needs and select only those process assets that seem indispensable.
Define specific functionality or responsibilities: with agile approaches.
Develop architectures: Look for areas where requirements will likely change rapidly or where the design is unclear and designate these as agile opportunities.
Realign or redefine traditional milestone reviews: to better fit an iterative approach.
Implement agile practises: that support existing processes or new organizational priorities.
Evaluating risks: is the best overall approach to determining how much agility is enough.
2.3.2 – Challenges
Even though Waldron (2017) advocates vast advantages for an agile adoption, it doesn’t come without its initials problems. As we already know, agile environments are more collaborative with physical and visual interactions which may come as a shock to certain individuals. Waldron believes within firms; a great challenge is balancing the creation of high performing cross functioning project teams whilst remaining a functional unit.
Holbeche (2015) labels this challenge as ‘Agility at the expense of resilience’ due to organisations who practise agile are required to employ resilient, flexible and competent staff. Resilience is severely put to the test in today’s work-intensive and insecure workplaces that tend to be dehumanizing and routinely destroy meaning for people (Holbeche, 2015). Gregory et al (2016) actually conclude that there are a wider range of concerns regarding the adoption of an agile methodology within their findings (Table 1.2). Although these barriers seem in abundance, organisations must take the necessary precautions if they want to improve their software development process.
To put these challenges into a real-world scenario, we need to take lessons from an example. Meingast (2013) reveals that the Dell Corporation faced its fair share of setbacks during agile implementation. Dell moved to an agile methodology for the reason that it wanted to release a new product to market with the speed of delivery that agile possess. To begin with, Dell found that lack of development perspective within sprint reviews meant that extra time needed to be taken to re-understand requirements and re-work wireframes. This resulted in the development team and the design team becoming constantly behind planning. Dell found this particularly different once the development team had quadrupled in size and had to add resources to counter this problem. Furthermore, the design team at Dell found a significant problem in the amount of time allowed for user testing. The faster pace of agile meant that time was scarce for important activities such as testing, which ultimately will impact on your users. Finally, working to a sprint by sprint basis meant that the team lost sight of the overall product flow. Teams were working on the same product months apart resulting in requirements rendered useless after this time.
2.3.3 – Lessons learned
We now know that although the agile methodology seems easy to comprehend in concept, implementing its practises may become problematic to an organisation. To remove any potential barriers, organisations should:
1. Introduce agile’s concepts through all levels of management and teams using training techniques and if possible, hire out agile professionals from outside of the organisation.
2. Be prepared to break the norm and form cross-functional teams to share expertise.
3. Transform the work environment to incorporate agile techniques for team working but also ‘agile free’ spaces where members can step out of this setting.
4. Employ individuals who are open to risk and are resilient to agile working practises.
5. Understand that there are many different methods within the agile methodology and project managers should be equipped enough to make this choice based on the project outcomes.
6. Involve your customers in as much as you can when applying agile to their products. The more they are aware of what they want and what you can provide, the better.
7. Finally, be patient with implementation. An agile working environment may not reap rewards immediately. It’s all about understanding how agile can work with your products and customers and evolving from this.
Table 1.2 – Challenges identified in the context of ‘agile in a non-agile environment’ (Gregory et al, 2016).
Main theme Subthemes Example challenge
Claims and limitations Misconceptions
Organisation Business and IT transformation
Management buy in & understanding
Agile in a non-agile environment
Commitment/Engagement
Adoption
Culture Organisational culture
Changing mindsets
Sustainability Process improvement
Contract
2.4 – Evaluation of literature
The literature discovered in this section is absolutely imperative when concerning the relevance of argument. We have covered a vast range of ground-breaking concepts through the work of Cockburn (2002), Schwaber (1997) and Beck (1999) who truly pioneered software development as we know it today. In addition to this, we have received academic understanding from some of the leading researchers in the software industry including; Poppendieck and Poppendieck (2003), Hibbs et al. (2009), Boehm and Turner (2005). As the amount of research conducted on project management methodologies increases, it is essential to acknowledge these prominent scholars of the software industry before proposing new notions.
Regarding the use of modern literature, vast examples have been introduced where academics have advanced these founding theories. As agile has developed over time with technology, innovative research followed meticulously. The efforts of Gregory et al (2016), Waldron (2017) and Canty (2015) increasingly cement agile’s successes and failings whilst creating new perceptions. These ideas are reinforced through central bodies such as the International Association of Project Managers (2017) and the Project Management Institute (2018).
2018-4-5-1522931206