Agile projects

Currently, even bigger interest towards lighter and delivery focused project and process management methodologies has been aroused outside traditional IT-industry. Classic waterfall-approach to project management is not responding anymore enough to rapidly changing delivery requirements in even more turbulent market environments where agil-ity, capability to adopt changes, has become more crucial (Rigby et al. 2016; Grant et al.

2010; Paquette 2015, pp.24-29). Even though agile development is originally designed, or at least reinvented, for software development there are useful principles and tools that are adoptable in other kind of development environments as well. The core principle in agile adoption is that each organization must itself decide which agile methods are ap-plicable in its development procedures as was stated in the prior change management chapter. If industry is not even delivering software, it should not full agile

ing all similar ways of working than true software development team. It should get knowledge what agile development is essentially about and sort out from which its prin-ciples it could start implementing agile in order to get maximum benefits out of it. (Grant et al. 2010)

Agile projects in this study refers to projects that are utilizing agile project management methodology in their management. Agile methodology is usually compared to traditional

project m waterfall plan-driven ) where scope is

fixed in the beginning and delivery concentrates on the final release. Following table 7 presented by Conboy & Coyle (2011), consolidates main differences between traditional and agile project management methodologies:

Differences between traditional and agile methods (adopted from Conboy

& Coyle 2011)

Project component Traditional Agile

Control Process centric People centric

Management style Command and control Leadership and collaboration Knowledge

Communication Formal and only when nec-essary

Informal and continuous Customer involvement Important usually only

dur-ing project analysis

Critical and continuous Project cycle Guided by tasks or

activi-ties Technology No restriction Favors object-oriented technology Team location Predominantly distributed Predominantly collocated

Team size Often greater than 10 Usually fewer than 10 Continuous learning Not frequently encouraged Embraced

Management culture Command and control Responsive Team participation Not compulsory Necessary

Project planning Up front Continuous

Feedback mechanisms Not easily obtainable Usually numerous mechanisms available

Documentation Substantial Minimal

Following illustration (figure 18) is commonly used in comparing traditional and agile work: agile is typically applied when outcome cannot be defined in advance, but costs and schedule at least for short-term are better known. Traditional approach relies on fixed scope but might allow costs and schedule adjustments during the project. This should be taken into account in project planning phase which has appeared to be a chal-lenge for traditional enterprises (Waardenburg et al. 2013).

Agile vs. Traditional approach in terms of scope, cost and time

Most essential difference is the scope: if uncertainty is high and there is strong likelihood or need to invent new things and change directions during the progress, agile methodol-ogy supports the work better. Hybrid model combining elements from both approaches is discussed, but not systematically studied (Conforto et al. 2014; Fernandez et al. 2009;

Serrador & Pinto 2015). Organizations adopting agile methodology need to consider in which ratios agile and traditional project management methodologies should be utilized (Dikert et al. 2016). Paquette 2015 summarizes advantages and disadvantages of tradi-tional project delivery methodology in following way (table 8):

Summary of usage of traditional vs agile model (adopted from Paquette 2015, p.29)

Advantages of traditional approach Disadvantages of traditional approach Defined scope easier for writing Business must understand all requirements at

beginning Clearly defined costs limit business exposure

especially in a fixed price contract

Reduced flexibility to changing circumstance Well understood delivery metrics Increased documentation is low value-added

proposition Better suited for vendor and outsourcing to

lower cost specialized resources

Reduced opportunity for innovation Simplified delivery (reduced communication

between resources)

He also proposes following list of most important elements in successful technology pro-ject delivery (Paquette 2015, pp.17-18):

1. Active senior management and stakeholder involvement

2. The effective identification, measurement and communication of the intended benefits of the change

3. Promotion of a change culture is addressed through mutual collaboration 4. Effective management of people through the change

Krucht level factors as requirements for

agile projects to succeed. He divides factors effecting on agile project outcome to two sub groups: organizational level and project level factors (figure 19). Organization-level factors do influence heavily the project-level factors, which in turn should enable utilizing agile practices in develop Sweet spot

level factor:

Two levels of factors enabling agile adoption and success (adopted from Kruchten 2011)

agility should not be defined in terms of practices, but as the ability of an organization to react to changes in its environment faster than the rate of these changes. In addition to high emphasis on organizational level enablers he sweet spot hould note which factors are not ideal for agile practices and pay attention in finding customized solutions to them.

Highest interest in this thesis lies on enablers, barriers, and success criteria of projects that have used agile methodology instead of traditional project management models.

Research related to the comparison between agile project management and traditional project management usually attempt to explain how agile approach leads to better out-comes than traditional approaches (Rigby 2016). Serrador & Pinto (2015) conducted a quantitative study of over 1002 agile projects across different industries and nations in

Does Agile work? A quantitative analys . Their

results stated that the greater the agile approach was reported, the higher was the re-ported project success. Hypothesis of their study was based on following model where moderators and outcomes were gathered and consolidated from prior literature:

Hypothesis model in analysing correlation between agile adoption and project success (adopted from Serrador & Pinto 2015)

From moderators, quality of the vision or goals appeared to have the most significant effect on project success leaving two others with less relevance.

Waardenburg et al. (2013) studied the relationship between organization and agile

pro-jects When agile meets the enterprise . They found

out a few critical impediments that cause agile projects to fail in traditional organizations from which the most crucial were increased IT landscape complexity and lack of business involvement. Corporate culture was found to slow down agile adoption and shift was seen happening mainly bottom-up direction. According to them, shift from-plan driven to agile ways of working requires fundamental changes in project management roles and re-established practices in collaboration with IT and business organizations. Study pro-posed following ways to increase collaboration between project and organization: chang-ing the mindset of business stakeholders, directchang-ing business knowledge through the product owner, and aligning knowledge and requirements at the business level.