Вы находитесь на странице: 1из 14

Chapter 25

Adaptive Life Cycle Models

25.1 Introduction
Project Management Institute (PMI) describes the project life cycle as “the series of phases that a
project passes through from its start to its completion. Within a project life cycle, there are gener-
ally one or more phases that are associated with the development of the product, service, or result.
ftese are called a development life cycle. Development life cycles can be predictive (plan-driven),
adaptive (agile), iterative, incremental, or a hybrid” (PMI, 2017, p. 665).
fte Project Management Body of Knowledge (PMBOK•) describes four types of life cycles,
which are and shown in Table 25.1 (PMI, 2017, p. 17):

1. Predictive life cycle. A more traditional approach, where the bulk of planning occurring
input upfront, then executing in a single pass; a sequential process.
2. Iterative life cycle. An approach that allows feedback for unfinished work to improve and
modify that work.
3. Incremental life cycle. An approach that provides finished deliverables that the customer
may be able to use immediately.
4. Agile life cycle. An approach that is both iterative and incremental to refine work items and
delivery frequently.

25.2 History
fte infrastructure for the early days of software development (the 1950s and 1960s) was primi-
tive in comparison to today’s environment. A programmer wrote logic using paper-based coding
sheets that were then given to a key-punch operator who would produce a deck of punch cards.
ften, based on a sign-up schedule, the punched card deck would be placed into a hopper of the
card reader. Finally, the program runs and the output, e.g., program error messages or test output,
was sent to the printer. On the user-side of production software, user involvement was similar, i.e.,
key-punching a data deck that would be the input for the program. Depending upon where these
users were located relative to the data center (e.g., in another city), it could take hours or days or

364 ◾ Project Management Theory and Practice

Table 25.1 Lifecycle Characteristics

Predictive Iterative Incremental Agile

Goal Manage cost Correctness of Speed Customer value

solution from frequent
deliveries and

Requirements Defined upfront Elaborated at Elaborated at Elaborated

periodic periodic frequently
intervals intervals during delivery

Product Deliver final Can be divided Can be divided Deliver

product at end into delivery into delivery frequently with
of project subsets subsets customer-
valued subsets

Change Constrained as Incorporated at Incorporated at Incorporated in

much as periodic periodic real-time
possible intervals intervals

Stakeholders Involved at Regularly Regularly Continuously

specific involved involved involved

Risk and cost Controlled by Controlled by Controlled by Controlled as

detailed progressive progressive requirements
planning elaboration elaboration and constraints

weeks before the user got his computer-generated output. Of the many adjectives that might be
used to describe this environment, agile isn’t one of them.
ftere are five major drivers that are the impetus for agile: technology platform, corporate cul-
ture, managements dissatisfaction with IT results, uncertainty work (versus definable work), and
the graphical user interface.

25.2.1 Technology Platform

Beginning in the 1970s with interactive, time-shared systems and especially with the commer-
cial success of the PC in the early 1980s, the user experience for both software developers and
users changed dramatically. fte programmer used an online editor to create files that would
contain the logic in place of the physical card deck. fte ability to view and alter the code
online versus a printout and card deck was tremendous. ftis change alone reduced cycle time

25.2.2 Corporate Culture

During the 1980s, companies began introducing total quality management (TQM) as part of a
corporate culture transformation to improve performance. TQM introduced team management
Adaptive Life Cycle Models ◾ 365

into organizations that were designed with hierarchical, command-and-control structures and
cultures. TQM has its starting point following World War II, when Toyota first implemented
quality circles in its production process (www.kanbanchi.com). fte concept was called Kaizen,
which is the philosophy of continually seeking ways to improve operations. An important belief
in Kaizen is that those closest to the operation are in the best position to identify changes that
should be made.

25.2.3 Management’s Dissatisfaction with IT Results

Beginning in the 1960s, companies were hiring programming staffs to automate business pro-
cesses, such as their general ledger, payroll, credit card, and so forth. ftese were very large,
complex undertakings for which there was no experience or previous history in doing so. fte pro-
grammers themselves didn’t have computer science educations as universities were just beginning
to formulate curricula. Companies gave tests to prospective programmers to assess their analytical
and logical abilities. ftose that they deemed ‘passed’ were given training in writing programs,
typically in COBOL. Developing these very large, complex programs would take multiple years
to deliver. It was not uncommon for these projects to run several years late and overrun millions
of dollars. Even worse, by the time they were delivered, they no longer met the need. fte bottom
line: management was not happy with IT.

25.2.4 High-Uncertainty Work (vs. Defined Work)

Aaron Shenhar and Max Wideman describe a method of classifying project types based upon
two attributes: product to be created (tangible, intangible), and type of work required to create
it (craft, intellect) (Shenhar and Wideman, 2002). Using their framework, a new plant, car, and
infrastructure are example project results that are tangible (craft). Characteristics of these types of
projects include:

◾ high-level of repetitive work

◾ learning curve effects
◾ resources predictable
◾ relatively high cost involved

Projects, however, that are high-uncertainty are intangible (intellect). ftey exhibit the following

◾ non-repetitive, first of its kind

◾ creative effort
◾ minimal repetition
◾ resources unpredictable; exploratory

ftese types of projects produce a new piece of intellectual property, such as, a new book,
poem, algorithm, theory, technology process, and software. Developing a new application, espe-
cially using the latest technology, is complex and risky. It is difficult, if not impossible, to deter-
mine the user requirements completely upfront largely because once users work with a new system
they invent new ways of working which cannot be anticipated at the beginning of a project.
366 ◾ Project Management Theory and Practice

25.2.5 Graphical User Interface

At the 1968 Fall Joint Computer Conference in San Francisco, Douglas Engelbart gave the
“Mother of all Demos.” He demoed NLS (oNLine System), which grew out of his 1962 paper,
Augmenting Human Intellect: A Conceptual Framework which he published for the U.S. Airforce
Office of Scientific Research (Engelbart 1997). fte technology used in NLS included a cathode
ray tube (CRT), a keyboard, and a mouse, which he invented. It also incorporated live audio,
video, windowed hypertext, and screen-sharing in real-time. ftese technology components are the
basis for today’s windowing systems.
With the pressure from management to improve IT performance and address the challenge
of high-uncertainty projects, software practitioners began experimenting with new approaches to
software development that would leverage these newer, graphical-oriented platforms and team-
based cultures.

25.3 Agile
In 2001, 17 software practitioners who had been working with new, yet different, approaches to
software development met at a ski lodge in Utah. fte outcome of that meeting was the Manifesto
for Agile Software Development shown in Figure 25.1 (Agile Manifesto Authors).
In addition, they defined 12 principles based on the manifesto: (Agile Manifesto Authors):

We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valu-
able software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.

We are uncovering better ways of developing software by doing it and

helping others do it. Through this work we have come to 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

That is, while there is value in the items on the right, we value the items
on the left more.

Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie Van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

Figure 25.1 Manifesto for Agile Software Development.

Adaptive Life Cycle Models ◾ 367

4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. fte most efficient and effective method of conveying information to and within a develop-
ment team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. fte sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. fte best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

Using an agile approach for a project requires that the project team adopt an agile mindset. PMI
suggests these questions to help in shaping how to implement agile (PMI, 2017, p. 843):

◾ How can the project team act in an agile manner?

◾ What can the team deliver quickly and obtain early feedback to benefit the next delivery
◾ How can the team act in a transparent manner?
◾ What work can be avoided in order to focus on high-priority items?
◾ How can a servant–leadership approach benefit the achievement of the team’s goals?

ftere are many approaches to agile. Some of the most popular ones are: Scrum, XP, and Kanban.

25.3.1 Agile Teams

A “team” in the agile sense is a small group of people, assigned to the same project or effort, nearly
all of them on a full-time basis. A small minority of team members may be part-time contributors,
or may have competing responsibilities. fte notion of team entails shared accountability: good or
bad, the outcomes should be attributed to the entire team rather than to any individual. fte team
is expected to possess all the necessary competencies, whether technical (programming, designing,
testing) or business (domain knowledge, decision-making ability).
Roles and responsibilities do not matter as much as results: a developer may test, perform
analysis, or think about requirements; an analyst or domain expert can suggest ideas about imple-
mentation, and so on. Team size is usually 3–10 people.
Hoegl and Gemuenden propose a Teamwork Quality framework for project outcomes that
consists of (Hoegl and Gemuenden, 2001, p. 437):

◾ Communication—frequent, informal, direct and open communication

◾ Coordination—individual efforts that are well structured and synchronized with the team
◾ Balance of member contribution—team members utilize their expertise to their full
◾ Mutual support—team members help and support each other in carrying out their tasks
◾ Effort—team members exert all effort to the team’s tasks
◾ Cohesion—team members are motivated to maintain the team
368 ◾ Project Management Theory and Practice

ftere are three primary agile roles: product owner; cross-functional team member; and team facil-
itator (PMI, 2017,p. 40). fte product owner is responsible for providing the direction of the prod-
uct. He creates and ranks the work in the backlog based upon business value. fte cross-functional
team comprises all the skills necessary to produce the working product. In software development,
for example, that typically include: designers, developers, and testers. fte team facilitator may go
by different names, such as scrum master, project team lead, or team leader. He is a servant leader
and serves as a combination of facilitator, coach, and impediment remover.
fte team develops and maintains a high-level summary of the project’s key success factors,
synthetic enough that it can be displayed on one wall of the team room as a flipchart-sized sheet
of paper. ftis description includes at least the major objectives of the project, scope boundaries,
and reciprocal agreements between the project’s implementation team and external stakeholders.

25.3.2 Common Agile Practices

fte following sections describe common agile practices: backlog preparation; backlog refine-
ment; iteration planning; daily standups; demonstrations/reviews; task boards; and retrospectives.
Figure 25.2 illustrates the flow in an agile cycle. Backlog Preparation

A backlog is an ordered list of all work that might be needed in the product as shown in Figure 25.3,
for example. It is also the single source of requirements for any changes to be made to the product.
fte product owner is responsible for the backlog, including its content, availability, and ordering
(Scrum Guides). fte work in the backlog is called a ‘user story’. Each user story is expected to
yield, once implemented, a contribution to the value of the overall product.

Product Sprint
backlog backlog


Iteration Iteration Iteration

Iteration Increment
planning review retrospective

What can be delivered in

Daily standups Demo Review team’s work on
the increment resulting
Product product and process to adapt
from the upcoming
owner and improve
How will the work needed declines
to deliver the increment be stories


Figure 25.2 Iterative framework.

Adaptive Life Cycle Models ◾ 369

Figure 25.3 Product backlog example.

fte product backlog lists all features, functions, requirements, enhancements, and fixes that
constitute the changes to be made to the product in future releases. Each item in the product
backlog has the attributes of description, order, estimate, and value. Backlog Refinement

Backlog refinement is when the product owner and some, or all, of the rest of the team review
items on the backlog to ensure the backlog contains the appropriate items, that they are priori-
tized, and that the items at the top of the backlog are ready for delivery. ftis activity occurs on
a regular basis and may be an officially scheduled meeting or an ongoing activity. Some of the
activities that occur during this refinement of the backlog include:

◾ removing user stories that no longer appear relevant

◾ creating new user stories in response to newly discovered needs
◾ re-assessing the relative priority of stories
◾ assigning estimates to stories which have yet to receive one
◾ correcting estimates considering newly discovered information
◾ splitting user stories which are high priority but too coarse grained to fit in an upcoming

It is an ongoing process involving the product owner and the development team. Higher-ordered
product backlog items usually are clearer than lower-ordered items. More precise estimates are
made based on the greater clarity and increased detail. Items for an upcoming iteration that are
refined such they can be “done” by the development team within one iteration are considered
“ready” for selection during iteration planning. Iteration Planning

Each team’s capacity is different. Each product owner’s typical story size is different. Teams con-
sider their story size, so they do not try to commit to more stories than there is a team capacity to
complete within one iteration. Team capacity may change from one iteration to the next depend-
ing upon the availability to the developers (e.g., holiday, vacation, training). When teams have a
370 ◾ Project Management Theory and Practice

reduced capacity, they will only plan for work that meets the capacity. Teams estimate what they
can complete, which is a measure of capacity. Agile teams do not plan just once in a single chunk.
Instead, they plan a little, deliver, learn, and then re-plan a little more in an ongoing cycle. An
iteration, in the context of an agile project, is a timebox, typically one to four weeks. Figure 25.4,
shows the relationship between the product roadmap, release plan and iteration plan.
fte product roadmap is derived from the product vision. fte product roadmap drives the
release plan, which in turn drives the iteration plan. fte following describes an approach to itera-
tion planning used in Scrum called sprint planning (Scrum Guides). ftis is created by the col-
laborative work of the entire team. It answers the following:

◾ What can be delivered in the increment resulting from the upcoming sprint?
◾ How will the work needed to deliver the increment be achieved?

fte team works to forecast the functionality that will be developed during the sprint. fte product
owner discusses the objective that the sprint should achieve and the product backlog items that, if
completed in the sprint, would achieve the goal. fte input to this meeting is the product backlog,
the latest product increment, projected capacity of the developers during the iteration, and past
performance. fte number of items selected from the product backlog for the sprint is solely up to
the developers. Only they can assess what it can accomplish over the upcoming sprints.

Release 1 Release 2 Release 3

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration n

Feature 1 Feature 2 Feature 3 Feature 4 Feature 5

Task 1

Task 2

Task 3

Task 4

Figure 25.4 Relationship between product roadmap, release plan, and iteration plan.
Adaptive Life Cycle Models ◾ 371

After the developers forecast the product backlog items it will deliver in the sprint, the team
crafts a sprint goal. fte goal is an objective that will be met within the sprint through the imple-
mentation of the product backlog, and it provides guidance to the developers on why it is building
the increment.
Having set the sprint goal and selected the product backlog items for the iteration, the
developers decide how it will build this functionality into a “Done” product increment during
the sprint. fte product backlog items selected for this sprint plus the plan for delivering them
is called the sprint backlog. fte development team usually starts by designing the system and
the work needed to convert the product backlog into a working product increment. Work may
be of varying size, or estimated effort. However, enough work is planned during sprint planning
for the development team to forecast what it believes it can do in the upcoming sprint. Work
planned for the first days of the sprint by the development team is decomposed by the end of
this meeting, often to units of one day or less. fte development team self-organizes to under-
take the work in the sprint backlog, both during sprint planning and as needed throughout the
fte product owner can help to clarify the selected product backlog items and make trade-
offs. If the development team determines it has too much or too little work, it may renegotiate
the selected product backlog items with the product owner. fte developers may also invite other
people to attend to provide technical or domain advice.
By the end of the sprint planning, the development team should be able to explain to the prod-
uct owner how they intend to work as a self-organizing team to accomplish the sprint goal and
create the anticipated increment. Iteration/Daily Standups

Each day at the same time, the team meets to bring everyone up to date on the information that
is vital for coordination: each team members briefly describes any “completed” contributions and
any obstacles that stand in their way. ftis meeting is normally no longer than 15 minutes, and it
is recommended that participants stand to encourage keeping the meeting short. Any topic that
starts a discussion is cut short, added to a “parking lot” list, and discussed in greater depth after
the meeting, between the people affected by the issue.
ftese meetings typically take the form of three questions for each member in round-robin

1. What did I complete since the last standup?

2. What am I planning to complete between now and the next standup?
3. What are my impediments (or risks or problems)?

Although seldom highlighted as a full-fledged agile practice, the allocation of tasks based on self-
selection rather than assignment by a third-party (whether a project manager, lead developer, or
other role) appears to be an important, possibly an essential, feature of agile work. Iteration Review/Demonstrations

As the team completes features (user stories), the team periodically demonstrates the working
product. In Scrum teams, it is done at the end of a sprint, which is typically two or four weeks.
fte product owner sees the demonstration and accepts or declines the stories.
372 ◾ Project Management Theory and Practice

ftis review is a four-hour time-boxed meeting for one-month iterations, or less for shorter
iterations. fte team facilitator ensures that the event takes place and that attendants understand
its purpose. fte Iteration Review includes the following elements (Scrum Guides):

◾ Attendees include the team members and key stakeholders invited by the Product Owner;
◾ fte Product Owner explains what Product Backlog items have been “Done” and what has
not been “Done”;
◾ fte Development Team discusses what went well during the Sprint, what problems it ran
into, and how those problems were solved;
◾ fte Development Team demonstrates the work that it has “Done” and answers questions
about the increment;
◾ fte Product Owner discusses the Product Backlog as it stands. He or she projects likely
completion dates based on progress to date (if needed);
◾ fte entire group collaborates on what to do next, so that the Sprint Review provides valu-
able input to subsequent Sprint Planning;
◾ Review of how the marketplace or potential use of the product might have changed what is
the most valuable thing to do next; and,
◾ Review of the timeline, budget, potential capabilities, and marketplace for the next antici-
pated release of the product.

fte result of the Iteration Review is a revised Product Backlog that defines the probable Product
Backlog items for the next Sprint. fte Product Backlog may also be adjusted overall to meet new
opportunities. Task Boards

In its most basic form, a task board can be drawn on a whiteboard or even a section of wall. Using
electrical tape or a dry erase pen, the board is divided into three columns labeled “To Do,” “In
Progress,” and “Done.” Sticky notes or index cards, one for each task the team is working on, are
placed in the columns reflecting the status of the tasks.
fte task board is updated frequently, most commonly during the daily standup meeting based
on the team’s progress since the last update. fte board is commonly “reset” at the beginning of
each iteration to reflect the iteration plan. fte purpose of the task board is to ensure that everyone
has a visual picture of the plan. Retrospectives
A primary practice in agile is the retrospective. It is a look back that can occur at any time though
often it follows a sprint. fte format is a meeting where all team members, including the team
facilitator, participate to review the team’s work on both the product and process to adapt and
improve. During the meeting, team members identify, and rank improvement needs. fte team
then selects a few to implement for the next sprint.

25.3.3 Testing
fte team must test at all levels: system for end-to-end information; and unit for the building
blocks. It is also important to understand when integration and integration testing is needed. fte
following are practices commonly deployed in agile teams.
Adaptive Life Cycle Models ◾ 373

Acceptance Test-driven Development (ATDD) involves a cross-functional team with members

representing customers, development, and testing. ftis team works together to develop accep-
tance tests in advance of implementing the corresponding functionality. ftese acceptance tests
are designed from the user’s point of view and act as a form of requirements to describe how the
system will function. ftey serve as a way of verifying that the system functions as intended. In
some cases, the team automates the acceptance tests.
Test-driven development (TDD) refers to a style of programming that integrates coding, testing,
and design. fte Agile Alliance describes it in the following set of rules:

◾ write a “single” unit test describing an aspect of the program

◾ run the test, which should fail because the program lacks that feature
◾ write “just enough” code, the simplest possible, to make the test pass
◾ “refactor” the code until it conforms to the simplicity criteria
◾ repeat, “accumulating” unit tests over time

Behavior-driven development (or BDD) is an agile software development technique that encour-
ages collaboration between developers, quality assurance (QA) and non-technical or business par-
ticipants in a software project. It focuses on obtaining a clear understanding of desired software
behavior through discussion with stakeholders. It extends TDD by writing test cases in a natural
language that non-programmers can read. Behavior-driven developers use their native language in
combination with the ubiquitous language of domain-driven design to describe the purpose and
benefit of their code. ftis allows the developers to focus on why the code should be created, rather
than the technical details, and minimizes translation between the technical language in which
the code is written and the domain language spoken by the business, users, stakeholders, project
management, and so forth (North, 2018).

25.3.4 Measurements
Agile utilizes empirical and value-based measurements instead of predictive measurements.
Agile measures what the team delivers, not what the team predicts it will deliver. Agile is based
on working products of demonstrable value to customers. Baselines are often an artifact of
attempted prediction. In agile, the team limits its estimation to the next few weeks at most. In
agile, if there is low variability in the team’s work and if the team members are not multitask-
ing, the team’s capacity can become stable. ftis allows better prediction for the next couple
of weeks.
After the team completes work in iteration or flow, they can re-plan. Agile does not create the
ability to do more work. However, there is evidence that the smaller the chunk of work, the more
likely people are to deliver it. Software product development, like other knowledge work, is about
learning—learning while delivering value. Hardware development and mechanical development
are similar in the design parts of the project. Learning takes place by experimenting, delivering
small increments of value, and getting feedback on what has been accomplishes thus far. Many
other product development projects incorporate learning also.
Some iteration-based projects use burndown charts to see where the project is going over time.
Story Points rate the relative work, risk and complexity of a requirement or story. “Velocity,” in
the sense agile teams use the term, has no preferred unit of measurement, it is a dimensionless
quantity. Velocity allows teams to compute the expected remaining duration of the project, as a
number of iterations, each iteration delivering some number of features.
374 ◾ Project Management Theory and Practice

Another important reason has to do with the social and psychological aspects of estimation:
using units such as story points, emphasizing relative difficulty over absolute duration, relieves
some of the tensions that often arise between developers and managers around estimation: for
instance, asking developers for an estimate then holding them accountable as if it had been a firm
Burndown charts show where the project is going over time. fte Burndown chart in Figure 25.5
shows that the team is planning to deliver 28 story points. In reviewing it, the team is behind on
Day 3.
To see work completed, teams use the Burnup chart as depicted in Figure 25.6. It uses the same
data as shown in Figure 25.5, which also shows the team getting behind on Day 3.
ftese charts are typically displayed in the team room. ftey constitute an “information radia-
tor,” provided it is updated regularly. ftis practice results in up-to-date project status being visible
to everyone involved, which encourages the team to confront any difficulties sooner and more
fte Features Burnup/Burndown chart, shown in Figure 25.7 may indicate that requirements
grew during the release. fte total features line shows how the features changed over time. fte
remaining features line shows how the rate of completion changes over time. As features are
added, the features remaining line changes. fte features completed line shows the accumulated
number of features completed over time.

Storypoints remaining
1 2 3 4 5 6 7 8 9 10
Plan Actual

Figure 25.5 Burndown chart.

Storypoints completed
1 2 3 4 5 6 7 8 9 10
Plan Actual

Figure 25.6 Burnup chart.

Adaptive Life Cycle Models ◾ 375

Feature burnup burndown

1 2 3 4 5 6 7 8 9 10
Number of features remaining Number of features completed
Total number of features

Figure 25.7 Features burnup/burndown chart.

Neither the burndown or burnup chart provides any indication of which product backlog
items have been completed. ftis means that a team can have a burndown chart that shows contin-
ued progress, but it does not indicate whether the team is working on the correct things. For this
reason, burndown and burnup charts can only provide an indication of trends rather than giving
explicit indication of whether a team is delivering the right product backlog items.
Velocity, the sum of the story point sizes for the features completed in this iteration, allows the
team to plan its next capacity more accurately by looking at its historical performance.

25.4 Further Reading

For the reader interested for additional materials on agile the following are useful resources:

◾ Agile Alliance (www.agilealliance.org)

◾ Scrum Guides: (www.scrumguides.org)

Agile Manifesto Authors, 2001. www.agilemanifesto.org. (Accessed on May 4, 2018).
Engelbart, D.C., Workstation history and the augmented knowledge workshop, Proceedings of the ACM
Conference on the Mitchell, R.K., B.R. Agle and D.J. Wood, 1997. Toward a theory of stake-
holder identification and salience: defining the principle of who and what really counts. Academy of
Management Review, 22, 4, 853–888.
Hoegl, M. and H.G. Gemuenden, 2001. Teamwork quality and the success of innovative projects: a theo-
retical concept and empirical evidence. Organization Science, 12, 4, 435–449.
North, D., January 2018. www.dannorth.net (Accessed May 4, 2018).
PMI, 2017. A Guide to the Project Management Body of Knowledge (PMBOK • Guide), 6th ed. Newtown
Square, PA: Project Management Institute.
Scrum Guide. www.scrumguides.org (Accessed May 4, 2018).
Shenhar, A.J. and R.M. Wideman, April 2002. Optimizing Success by Matching Management Style to
Project Type. www.maxwideman.com (Accessed May 4, 2018).