review paper about future direction of requirement analysis and enterprise architecture management.

profileMike9295
HybridProjectManagementAgilewithDiscipline.pdf

Association for Information Systems AIS Electronic Library (AISeL)

CONF-IRM 2017 Proceedings International Conference on Information Resources

Management (CONF-IRM)

5-1-2017

Hybrid Project Management: Agile with Discipline Olayele Adelakun DePaul University, [email protected]

Robert Garcia DePaul University, [email protected]

Ted Tabaka DePaul University, [email protected]

Redar Ismail DePaul University, [email protected]

Follow this and additional works at: http://aisel.aisnet.org/confirm2017

This material is brought to you by the International Conference on Information Resources Management (CONF-IRM) at AIS Electronic Library (AISeL). It has been accepted for inclusion in CONF-IRM 2017 Proceedings by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contact [email protected].

Recommended Citation Adelakun, Olayele; Garcia, Robert; Tabaka, Ted; and Ismail, Redar, "Hybrid Project Management: Agile with Discipline" (2017). CONF-IRM 2017 Proceedings. 14. http://aisel.aisnet.org/confirm2017/14

1

HYBRID PROJECT MANAGEMENT: AGILE WITH DISCIPLINE

Olayele Adelakun

DePaul University [email protected]

Robert Garcia

DePaul University [email protected]

Ted Tabaka DePaul University

[email protected]

Redar Ismail DePaul University

[email protected]

Abstract Effective management of software projects will always be important regardless of the software development method (agile, iterative or waterfall) used. A recent movement in the

software development industry towards adopting Agile practices have left many questioning the role of traditional project management. However, in practice companies often struggle with changing established practices. Many companies have adopted hybrid methods to adjust

to changing requirements. For many of these companies these hybrid approaches are seen as the best of both worlds as they can leverage the advantages of Agile with the strengths of

traditional practices. While researchers have begun proposing ways that these approaches can integrate there remains limited actual academic evidence that describes how these models are being integrated in practice. This research contributes to the knowledge by discussing

findings based on a unique approach adopted by the IBM Center of Excellence called Agile with Discipline.

Keywords:

Project Management, Agile, Waterfall, Hybrid

1. Introduction Over the past several years there has been a growing interest in technology development that

steers away from traditional practices towards methods that embrace Agile princ iples. Many adopters believe that Agile practices p rovide advantages over traditional methods. Some of

these advantages include adaptability, increased product quality, developer happiness, and earlier defect detection (Laanti, Salo, & Abrahamsson, 2011). These changes have followed what some view as a growth in the importance of knowledge based work and changes in

management from hierarchical approaches towards more collaborative efforts with frequently changing requirements (Fernandez & Fernandez, 2008).

These practices are both changing and challenging the traditional approaches used in project management (B. Boehm & Turner, 2005). Studies show that management may view the benefits of Agile efforts as aiding in changing requirements, accelerating time to market and

contributing to software (Papatheocharous & Andreou, 2013). Despite the perceived advantages of Agile there are a number of challenges facing management in its adoption (B. Boehm & Turner, 2005; Nerur, Mahapatra, & Mangalaraj, 2005). Further, Agile practices

may not always be viewed as suitable for adoption in different environments, particularly those with more stringent requirements (McHugh, McCaffery, & Casey, 2012).

To manage many of the challenges with modern development in businesses many have resorted to developing hybrid project management practices that integrate Agile with traditional approaches (Binder, Aillaud, & Schilli, 2014; Rahmanian, 2014). However,

because of the divergence between Agile and traditional practices, some have stressed the

2

importance in further examining these approaches, the decision making behind them and the characteristics adopted (Špundak, 2014).

This paper seeks to add to the knowledge on hyb rid Agile approaches by discussing a hybrid management style observed during a case study at the IBM Center of Excellence in Chicago,

Illinois, USA. O ver the years companies have increased their adoption of Agile practices (Diebold & Dahlem, 2014). However, many of the Agile practices and methodologies used by companies in rapidly changing information technology environments continue to evolve.

In order to understand the best approaches towards developing and improving the current state of Agile development it is important to examine this evolution and the contextual factors

that influence them.

The approach observed at IBM, which we are calling Agile with discipline, is unique in that it integrates elements of the waterfall model used within an Agile framework. First a discussion

will be presented comparing traditional project management (TPM) versus Agile project management (APM) to help discuss the different elements of these approaches. Next a

discussion of the IBM environment will be presented. Following a discussion on the Agile with discipline approach will be discussed based on a case study and interviews with managers at IBM. Based on the discussions in the paper a proposed model based on Agile

with discipline will then be presented.

2. Traditional and Agile Project Management Project management has been defined as the planning, organizing, directing and controlling of resources for short term objectives that aid companies in meeting specific goals (Kerzner,

2013). Project management has traditionally been a very linear process that has relied on hierarchical methods. These methods rely heavily on planning, documentation and

requirements analysis in the early stages of a project (Sixsmith, Freeburn, & Mooney, 2014). This is demonstrated in the views of process groupings in TPM.

Figure 1. Traditional Project Management (TPM) Process Groups according to (Rose, 2013)

In TPM many processes are viewed as linear and sequentially based on the products of

previous phases (Fernandez & Fernandez, 2008). For example, through visioning in the imitation phase teams are able to move on towards planning the entire product based on the vision. Once the plan is created it can then be moved to execution and eventually to closure.

The control phase is used to handle the real world aspects of execution, not always following plans and processes in this phase are used to monitor and redirect efforts as needed (Rose,

2013). In this approach changes to the project are carefully controlled with proper documentation until the final item on the work breakdown structure is delivered.

3

Software development practices have typically followed TPM approaches. These practices are generally plan-driven and rely on command and control approaches (Rehman, Rauf, &

Shahid, 2010). For example, the most widely used model for software development that follows this framework is the waterfall model.

Figure 2: Waterfall development model (Royce, 1970)

Royce (1970) first discussed the waterfall model as the approach many or ganizations took

towards software development. The waterfall model follows a sequential approach that separates development into unique phases. Each phase is performed sequentially and a new

phase does not start until the previous one ends. During the end of a phase documentation is also developed (Balaji & Murugaiyan, 2012). In this manner the flow of development has a defined beginning and end. The project begins with the initial planning and flows through the

cycle until the project is complete and implementation begins. However, this also becomes one of its main weaknesses. The waterfall method does not adequately address unexpected

issues, that are common in software development occurring during any of its phases (Ken Schwaber, 1997). Issues such as this have led to a variety of other software development models such as the spiral model, v- model, iteration model, and extreme model (Munassar &

Govardhan, 2010). These have resulted in new practices.

The development of new software development practices has also led to a need for new

management approaches. While TPM approaches and practices have been suitable in previous decades, some have challenged the theory behind tho se approaches as obsolete (Koskela & Howell, 2002). These critiques are based on views of a changing business environment that

requires increasingly complex development in uncertain project e nvironments. The rapidly changing environments in which modern projects exist can create situations in which TPM

can not only fail to address issues but can increase the problems (Williams, 2005). O ne of the main arguments against the traditional approach is its inability to adjust to the dynamic and volatile nature of business organizations, technology, market place, customer and socio -

technological environments (Baskerville, Ramesh, Levine, Pries-Heje, & Slaughter, 2003). Among the alternatives towards project management in these environments are Agile

approaches.

Agile is a term used to describe an approach towards software development that integrates a set of principles that encourage iterative and incremental development through the

collaborative efforts of self-organizing and cross- functional teams. Agile is iterative, incremental, self-organizing, and emergent (Lindvall et al., 2002). Agile is iterative in the

respect that development is completed over several cycles. It is iterative in that the product is not delivered at once, but in small completed parts. Teams in Agile are self-organizing and

4

determine on their own the best way to handle work. Agile is considered emergent as processes, principles and work structures are not pre-determined but rather determined during

the project development. Agility in Agile development is about embracing change throughout the development process as opposed to traditional methods that lock requirements. Agile

methods are willing to capture last minute changes as they believe such changes could produce unanticipated benefits to all stakeholders especially the end customers. Table 1 outlines some of the key components of Agile as described in the Agile manifesto (Beck et

al., 2001).

Agile

Over

Traditional

Individuals and Interactions Processes and Tools

Working Software Comprehensive Documentation

Customer Collaboration Contract Negotiation

Responding to Change Following a Plan

Table 1: Agile manifesto summarized by (Moniruzzaman & Hossain, 2013)

In Agile the traditional project manager (PM) is replaced with that of a team lead or scrum

master. The PM is not required to do heavy documentation and the end user is much more involved in the process (Uikey & Suman, 2012). There are various agile methods (eXtreme

Programming, Scrum, Dynamic Systems Development Method, Adaptive Software Development, and Crystal), Scrum is the most adopted agile method (Moniruzzaman & Hossain, 2013; K Schwaber & Beedle, 2002). Agile works well where the requirements are

more uncertain and subject to change, that is, where components are more interdependent and subject to frequent changes (Augustine, Payne, Sencindiver, & Woodcock, 2005).

Agile Project Management (APM) implies that agile managers will lead small teams, clarifying roles and responsibilities; communicate a vision to the team; follow simple rules that allow for quick and flexible team work; allow for free and open access to information for

the team to accomplish tasks and goals; lead with a light touch management style; a nd employ adaptive leadership (Augustine et al., 2005). This framework differs from the traditional PM

(TPM) which is document, process, and plan heavy.

Software development practices in Agile are typically more dynamic. Among the most popular Agile framework used in software development is Scrum. Scrum is an iterative and

incremental framework (Ken Schwaber, 1997). Scrum begins with an overall visioning session. In practice the product visioning moves towards product backlog creation and then

the planning for sprint cycles. Sprint backlogs are then created. This then moves to an iterative sprint cycle in which planning, development and releases of small product deliverables. This cycle is completed until the final product deliverable is completed. In

Scrum the project flow differs from traditional approaches such as waterfall.

5

Figure 3: Modern Scrum Approach

While waterfall defines the entire life-cycle at the beginning of the project with known

deliverables, Scrum is more of an evolving process. The incremental deliverables in Scrum allows a project to change midstream without reducing the ability to complete the end project.

With traditional approaches, changing a project midstream requires a revision of the entire planning process and a return to earlier project stages. Further Agile approaches such as Scrum change the role of traditional PMs. In Scrum, traditional PMs are replaced by Scrum

masters who move from playing the role of team leaders to coaches that motivate team members to complete project goals (Cervone, 2011). Included in Scrum teams are clients that

take the role of product owners.

In some businesses Agile approaches are seen as an alternative that can rapidly be used to replace traditional practices (Laanti et al., 2011). Others caution that a slow and deterministic

change is necessary (Nerur et al., 2005). Although in theory, there are wide differences between the two approaches, researchers have described how the reality of approaches in

practice differ (Sixsmith et al., 2014). Researchers have described approaches towards project management that mix both TPM and APM (Binder et al., 2014; Hass, 2007). However, many of these have been experimental or theoretical frameworks. In the following sections a

hybrid model that has been observed in practice at a corporation in the United States will be discussed.

3. Research Method In order to examine Agile development further in 2014 a team of researchers from DePaul

University began exp loring the use of Agile in practice. The team was interested in exploring the research question of how Agile was being used by companies in practice and how this

differed from theoretical approaches. During visits to IBM, one of the major software development companies being investigated, the team identified a unique hybrid management approach. The team explored the method further by conducting interviews with project

development leaders at the organization The goal of this research is to understand they hybrid TPM-APM practices at IBM.

In order to examine these practices further direct observations and Semi-structured interviews were conducted at IBM Center of Excellence, Chicago, USA in the winter 2014. The empirical data was collected using a semi-structured interview data collection technique. All

the data were collected from employees at the IBM Center of Excellence in Chicago. All interviews were recorded with permission, except for one interviewee who preferred not to be

recorded. In total four hours of interview data was collected. All of the interviewees are either PMs, project leads; Architects or Senior PMs. Five people were interviewed in total. Although, the sample size may be considered relatively small for quantitative research for

qualitative studies samples are generally collected until saturation occurs (Guest, Bunce, & Johnson, 2006). This can generally occur within the first 12 interviews. After about the third

6

interview we noticed that we began getting similar responses from other interviewees. Further the interview data collected from high level practitioners at IBM supported what researches

observed in practice and therefore the number of interviews collected is considered sufficient for describing the practices.

The structured interviews covered questions such as what PM methods are used in the center and what methods within IBM? Do all PMs use the same methods across the enterprise? What influences the decision of which software development method is used and thereby the PM

approaches? Do PMs develop same type or same quantity of documentation regardless to the development method? These questions were based on descriptions

All interviewees noted that both the traditional and agile software development methods are used within IBM. The project development method, tools, that project team members use different approach depending on a number of factors. None of our interviewees gave us one

method that supersedes all other methods. Instead all of them discuss a hybrid-agile approach often referred to as “Agile-with-Discipline.”

Our research findings are discussed in the next sections.

4. Selecting a Software Development Method The software development method applied to a project in IBM depends on a number of factors, and our data shows that no one method is always used. Table 3 summarizes some of

the factors that our interviewees identified as determinant of the project development method.

1. The nature of the project (size, complexity, number, global site, customer preference, etc. 2. Project complexity: simple development or integrating many applications

3. Modification of an existing system or brand new development. 4. What type of technology will be used: a tool that will be customized or build from ground

zero 5. The environment of the development project 6. Based on previous work, best methods in previous situations.

7. What is defined in the project contract/scope of work. 8. Has the project been determined in the contract as time and material (T&M) or fixed

price? This can leverage the project methodology. If it is a fixed price, requirements will be locked down and the project will follow a waterfall methodology. T&M provides opportunities for the customer to make changes to the requirements and provide input,

which is the purpose of agile development. 9. Does the customer prefer a particular method?

To summarize, many of our interviewees state that projects that require more customer/client collaboration, such as web-based projects are more conducive to agile development methods.

All of the PMs noted the limitation with the traditional method, but none of them follows the agile method as discussed in the literature. Instead they have adopted a hybrid-agile method.

This is partly because IBM has its own set of custom methodologies that it has developed through years of experience in working with clients, managing successful projects, and providing IT/Business solutions to its clients.

Our interviewees often refer to their hybrid-agile method at IBM as “Agile-with-Discipline.” The Agile-with-Discipline is IBM’s methodology that incorporates components of agile

development into a more structured approach to project management.

“In this approach [hybrid-agile] sufficient documentation and timelines with flexibility can accommodate requirement changes, development sprints, and continuous

customer/client feedback .” – A senior PM

7

5. The Role of the Project Manager with Agile Software Development While current literature on the topic down plays the role of project managers within the agile methodology we found that project managers in our research are just as involved irrespective of the development method. PMs still play an integral part in managing people, leveraging

resources, and overseeing the project’s success. As one PM explains:

“The PM’s role does not change with managing an agile project in a delivery

organization. How the PM delivers his/her solution and involves customers is what changes. The PM still owns the project, still drives the project through the completion of sprints, still goes through all of the checks and balances needed, and still gets all of the

required sign-offs. The things that change are that the PM has a lot more interaction with the customers, leads daily sprint calls with the team, and scopes the projects a bit

differently (i.e. delivery in smaller chunks and frequent reviews with the customer.”

– A Senior PM

Sometimes other people like architects, senior developers or other project stakeholders may

play the role of the PM/ scrum master but only temporarily. It appears that every project ha s a project manager, especially client projects.

“I am an architect but sometimes I take the role of the scrum master on an agile project when needed.” – An Architect

6. Project Planning Within the Agile Method All PM interviewees note that they are responsible for creating a project plan in the Agile-

With-Discipline method. While time, scope and budget are loose, project success ultimately still depends on good project organization. The PMs are also responsible for providing tools to team members needed to accomplish project tasks. Some spoke of using internal company

collaboration tools or software such as SharePoint. The selection of the collaboration tool that works best often depends on the client’s preferences and the type of project., The PM is always responsible for maintaining the tool and ensuring team collaboration regardless of the

tool used.

“The plans developed for agile-w ith-discipline projects may not be as detailed and as far

thought out as a traditional project plan may be.” – A PM

Part of the project plan can also include setting project milestones and implementing a loose project timeline. Often, a payment schedule or some type of success-measurement marker is

attached to project milestones. Scheduling team meetings/scrum meetings and communicating key project information to the team is also an important part of the PM’s

overall project plan.

“We have noticed that the Traditional approach to project planning doesn’t work very well. You can’t plan everything before you execute. It is impractical... So we do the best

to plan some [hybrid-agile] but be ready to adapt as needed.” – Senior PM

7. Project Constraints In traditional project management, the project manager scopes out a project within the very tight constrains of scope, time, and budget. In the agile development process, these

constraints are defined as the project progresses. What we find in the case of hybrid - processes is that these constraints are loosely defined at the start of the project for the PM.

The PM is to monitor these constraints, mitigate the expansion of any one area to the point that it would lead to customer dissatisfaction or violate a contract. Also the PM

8

communicates the effect that changes in one area can have on other areas to the customer and the team.

8. Project Reports and Documentation To control project constraints and to ensure the customer is getting a valuable and useful product, documentation becomes an integral part of hybrid-agile/Agile-with-Discipline approach. PMs need to keep documentation on project requirements, changes, resources

used, and the project timeline. While requirements can evolve over the project lifecycle, documentation is important in holding project stakeholders accountable for the project’s

success, keeping track of the project’s requirement changes and iterations, and establishing an overall project plan.

“When we start any project we at least try to get a blueprint or an initial set of

requirements and what we do is internally manage a change request process…if there are changes to the original requirement, we go through the change request process to

make sure the customer is aware of this particular change before we make it happen so, it’s more documented; any changes to the timeline or the budget is reflected based on the new change request.” – Senior PM

Documentation is also important for project communication. IBM rarely has teams that are co-located. A team usually consists of members across the globe. In these instances,

documentation and the use of project collaboration tools are integral for project hand-offs and keeping the project moving forward.

Document version control, reporting to the team, the client, and to other project stakeholders,

and creation/collection of test scripts and design decision documents are all part of the PM’s documentation management role. The formality and frequency of documentation again

depends on the context of the project, including the client being served, the nature of the project and the business culture.

9. Project Team The literature emphasizes that one of the distinguishing characteristics of the agile

development process is its allowance for self-organizing teams with decision making power. In theory, this may be true. In reality, a team is often part of a larger company organization and ecosystem where organizational impediments can obstruct team success. In this case, a

PM can serve as a liaison for the team to the larger organization to gather resources and remove obstacles. O ne PM gave the example of when he needed to procure an additional

team member for the team that suddenly lost one of its members. In such a case, it is rarely appropriate for any team member to select a new person, and no one on the team has access to that type of resource. Depending on the organizational culture and the larger context within

which the team is working, it is easy to imagine situations and scenarios where a PM has access to more resources and support that he/she can funnel into the team, as opposed to the

team itself.

The tasks outlined above illustrate some of the larger roles and responsibilities the PM interviewees mentioned in the conversation. They are not inclusive of all responsibilities a

PM might undertake in managing an agile or agile- like development project. These roles and responsibilities can vary by project, team, and company.

10. Industry Opinion – Agile vs. Traditional As the agile development method becomes more popular, more companies are requesting it

and expecting it to be a part of the development processes. Companies want to be shown progress and be involved in the development of their products.

9

“More PMs are managing agile or agile-like projects. Interest in Agile Project Management seems to be increasing in the project management field.” – Team Lead

Our interviewee noted that to meet customer demands for hybrid-agile, IBM has been providing resources, tools, and processes (such as agile development education) to its PMs

internally. This support has often come through its project management office, which serves more as a professional development and resources office for its project managers than as a center for managing the company’s portfolio of projects.

11. Insights into Agile with Discipline Based on our findings we performed a comparative analysis between elements described as Agile and Traditional in the literature versus the hybrid Agile with Discipline approach identified at IBM. Table 2 below outlines some of the differences between approaches.

Elements TPM APM Agile w/ Discipline

Applicable Development

Life Cycle

Favors Linear (waterfall) and Iterative

(spiral) - (B. W. Boehm, 1988; Fernandez & Fernandez, 2008;

Royce, 1970)

Iterative, Evolutionary (scrum

or XP) (Augustine et al., 2005; Victor, 2003)

Varies based on project context

Style of

Development process

Predictive (Ken

Schwaber, 2004)

Adaptive (Paetsch,

Eberlein, & Maurer, 2003)

Limited adaptiveness

based on project context

PM

(Requirement and scope

management)

Clearly defined scope,

knowable early, largely stable, well documents,

WBS, scope creep - (Rehman et al., 2010)

Scope emerges, rapid

change, unknown requirement

discovered during the project development, no WBS and no

scope creep - (Cockburn &

Highsmith, 2001; Rehman et al., 2010)

Loosely defined

constraints at project beginnings,

constraints are monitored throughout process, constraints

are modified when leading to customer

dissatisfaction or contract violation

Project

Management Approach

Plan and process

centric, monitoring and control - (Cockburn &

Highsmith, 2001; Hoda, Noble, & Marshall, 2008)

People centric,

collaborative, adaptive - (Hoda et

al., 2008; Paetsch et al., 2003)

Loose planning but

extensive organization with PM

serving as gatekeeper

Project Goal Clear and Predictable (Ken Schwaber, 2004)

Exploration or Adaptation - (Paetsch

et al., 2003)

Project Context dependent

1 0

Project Documentation

Heavy Documentation in General - (Sixsmith et

al., 2014)

Generally Light or Insignificant

Documentation - (Beck et al., 2001;

Lindvall et al., 2002)

Documentation is integral but formality

and frequency is project dependent

Requirement Changes

Controlled, Changed Averse - (Fernandez &

Fernandez, 2008)

Embrace Change - (Beck et al., 2001;

Cockburn & Highsmith, 2001;

Fernandez & Fernandez, 2008)

Based on product owner satisfaction

and contract limitations

Team Members Dispersed Team,

Specialists, Task-Skill Alignment (Cockburn &

Highsmith, 2001)-

Agile,

Knowledgeable, Favors Collocated

and Collaborative - (Beck et al., 2001; Cockburn &

Highsmith, 2001)

Dispersed or

collocated teams, multiple roles,

collaborative

Team

Orientation

Structured, headed by

PM - (Nerur et al., 2005)

Self-organizing

teams, decision making empowered - (Beck et al., 2001;

Cockburn & Highsmith, 2001)

Teams exist as part of

larger corporate ecosystem with PM serving as liaison and

roles can vary based on context

Client and Stakeholder Involvement

Low involvement mostly requirement and validation - (Hoda et al.,

2008; Thompson, 1991)

Actively Involved, Client is part of the team - (Beck et al.,

2001; Racheva, Daneva, Herrmann,

& Wieringa, 2010)

Continuous client feedback non-direct involvement

Organization Culture

Hierarchical, command and control culture -

(Nerur et al., 2005; Rehman et al., 2010)

Collaborative, flat organizational

culture, team empowerment and

decision making leadership - (Beck et al., 2001; Rehman et

al., 2010)

Hierarchical outside of project team,

internal team empowerment

Table 3: Comparison between TPM, APM and Agile with Discipline

Overall the practices at IBM seem to be structured as a means of addressing a transition from traditional practices towards Agile. In order, to obtain some of the benefits of Agile while retaining some of the structure of traditional approaches, the IBM team has managed to merge

approaches to fit their development needs.

1 1

12. Conclusion Based on our research we conclude that one development method does not fit all software development projects in the case of IBM center in C hicago. Both agile and traditional (modified waterfall) are in use. We also conclude that agile methods have not replaced

traditional methods. One important deciding factor is the customers’ preference. Our data shows that more and more project managers in IBM are equipped to manage agile projects.

Project managers in IBM do not follow any agile method as described in literature. T hey follow a hybrid model that they call Agile-with-Discipline. This hybrid-agile allows flexibility to have continuous changes to requirements throughout the project development

process but at the same time ensures that proper tools, techniques and suppor ting documentation are done. While the literature downplays the need for documentation in agile

projects our data shows that proper documentation is still needed especially on external / customer projects. Lastly, our data does not support the opinion that agile teams are completely self-organized and self-managed.

REFERENCES Augustine, S., Payne, B., Sencindiver, F., & Woodcock, S. (2005). Agile project

management: steering from the edges. Communications of the ACM, 48(12), 85-89. Balaji, S., & Murugaiyan, M. S. (2012). Waterfall vs. V-Model vs. Agile: A comparative

study on SDLC. International Journal of Information Technology and Business Management, 2(1), 26-30.

Baskerville, R., Ramesh, B., Levine, L., Pries-Heje, J., & Slaughter, S. (2003). Is internet- speed software development different? IEEE software, 20(6), 70.

Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., C unningham, W., Fowler, M., . . .

Jeffries, R. (2001). Manifesto for agile software development. Binder, J., Aillaud, L. I., & Schilli, L. (2014). The project management cocktail model: An

approach for balancing agile and ISO 21500. Procedia-Social and Behavioral

Sciences, 119, 182-191. Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in

traditional development organizations. IEEE software, 22(5), 30-39. Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer,

21(5), 61-72.

Cervone, H. F. (2011). Understanding agile project management methods using Scrum. OCLC Systems & Services: International digital library perspectives, 27(1), 18-22.

Cockburn, A., & Highsmith, J. (2001). Agile software development, the people factor. Computer, 34(11), 131-133.

Diebold, P., & Dahlem, M. (2014). Agile practices in practice: a mapping study. Paper

presented at the Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering.

Fernandez, D. J., & Fernandez, J. D. (2008). Agile project management—agilism versus traditional approaches. Journal of Computer Information Systems, 49(2), 10-17.

Guest, G., Bunce, A., & Johnson, L. (2006). How many interviews are enough? An

experiment with data saturation and variability. Field methods, 18(1), 59-82. Hass, K. B. (2007). The blending of traditional and agile project management. PM world

today, 9(5), 1-8. Hoda, R., Noble, J., & Marshall, S. (2008). Agile project management. Paper presented at the

New Zealand Computer Science Research Student Conference.

Kerzner, H. R. (2013). Project management: a systems approach to planning, scheduling, and controlling: John Wiley & Sons.

1 2

Koskela, L., & Howell, G. (2002). The underlying theory of project management is obsolete. Paper presented at the Proceedings of the PMI Research Conference.

Laanti, M., Salo, O., & Abrahamsson, P. (2011). Agile methods rapidly replacing traditional methods at Nokia: A survey of opinions on agile transformation. Information and

Software Technology, 53(3), 276-290. Lindvall, M., Basili, V., Boehm, B., Costa, P., Dangle, K., Shull, F., . . . Zelkowitz, M.

(2002). Empirical findings in agile methods. Paper presented at the Conference on

Extreme Programming and Agile Methods. McHugh, M., McCaffery, F., & Casey, V. (2012). Barriers to adopting agile practices when

developing medical device software. Paper presented at the International Conference on Software Process Improvement and Capability Determination.

Moniruzzaman, A., & Hossain, D. S. A. (2013). Comparative Study on Agile software

development methodologies. arXiv preprint arXiv:1307.3356. Munassar, N. M. A., & Govardhan, A. (2010). A comparison between five models of software

engineering. IJCSI, 5, 95-101. Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to agile

methodologies. Communications of the ACM, 48(5), 72-78.

Paetsch, F., Eberlein, A., & Maurer, F. (2003). Requirements Engineering and Agile Software Development. Paper presented at the WETICE.

Papatheocharous, E., & Andreou, A. S. (2013). Evidence of agile adoption in software organizations: An empirical survey. Paper presented at the European Conference on Software Process Improvement.

Racheva, Z., Daneva, M., Herrmann, A., & Wieringa, R. J. (2010). A conceptual model and process for client-driven agile requirements prioritization.

Rahmanian, M. (2014). A Comparative Study on Hybrid IT Project Managment. International Journal of Computer and Information Technology, 3(05).

Rehman, I. U., Rauf, A., & Shahid, A. A. (2010). Scope management in agile versus

traditional software development methods. Paper presented at the Proceedings of the 2010 National Software Engineering Conference.

Rose, K. H. (2013). A Guide to the Project Management Body of K nowledge (PMBOK® Guide)—Fifth Edition. Project Management Journal, 44(3), e1-e1.

Royce, W. W. (1970). Managing the development of large software systems. Paper presented

at the proceedings of IEEE WESCON. Schwaber, K. (1997). Scrum development process Business Object Design and

Implementation (pp. 117-134): Springer. Schwaber, K. (2004). Agile project management with Scrum: Microsoft press. Schwaber, K., & Beedle, M. (2002). Agile Software Development with Scrum.

Sixsmith, A., Freeburn, C., & Mooney, G. (2014). Project Management in Practice: Views from the Trenches. Paper presented at the The 24 th International Business Information

Management Association Conference. Špundak, M. (2014). Mixed agile/traditional project management methodology–reality or

illusion? Procedia-Social and Behavioral Sciences, 119, 939-948.

Thompson, P. (1991). The client role in project management. International Journal of Project Management, 9(2), 90-92.

Uikey, N., & Suman, U. (2012). An empirical study to design an effective agile project management framework. Paper presented at the Proceedings of the CUBE International Information Technology Conference.

Victor, R. (2003). Iterative and incremental development: A brief history. IEEE Computer Society, 47-56.

1 3

Williams, T. (2005). Assessing and moving on from the dominant project management discourse in the light of project overruns. IEEE Transactions on engineering

management, 52(4), 497-508.

  • Association for Information Systems
  • AIS Electronic Library (AISeL)
    • 5-1-2017
  • Hybrid Project Management: Agile with Discipline
    • Olayele Adelakun
    • Robert Garcia
    • Ted Tabaka
    • Redar Ismail
      • Recommended Citation
  • tmp.1498120007.pdf.vSvR7