Agile project management on digital transformation : a reference meta-framework for the assessment of compatibility on existing organizations

(1)

POLITECNICO DI MILANO

SCHOOL OF INDUSTRIAL AND INFORMATION ENGINEERING

Master of Science in Management Engineering

Agile Project Management on Digital Transformation:

a reference meta-framework for the assessment of compatibility on

existing organizations

Supervisor: Prof. Barbara PERNICI Co-supervisor: Ing. Giulio NICELLI

M.Sc. Thesis Giulio MAUGERI 883824

(2)

(3)

Table of Figures

Figure 1: The classic project triangle... 8

Figure 2: Environment complexity ... 10

Figure 3: The Waterfall approach ... 12

Figure 4: The development of Projects with Traditional and Agile approaches ... 13

Figure 5: The Product Owner ... 21

Figure 6: The Development Team ... 22

Figure 7: Sprint sequence ... 24

Figure 8: The Sprint cycle ... 25

Figure 9: Sprint Review ... 26

Figure 10: Sprint Retrospective ... 27

Figure 11: The iceberg metaphor ... 43

Figure 12: Extract of the product backlog... 76

Table of Charts

Chart 1: Size of Organization ... 29

Chart 2: Years of Agile development methods adoption ... 31

Chart 3: Reasons for Adopting Agile ... 32

Chart 4: Benefits of Adopting Agile ... 33

Chart 5: Agile methodologies used in 2018 ... 34

Chart 6: Agile Techniques Employed ... 34

Chart 7: Measurement of success with Agile Initiatives ... 35

Chart 8: Measurement of success with individual Agile projects ... 37

Chart 9: Scaling Methods and Approaches ... 38

Chart 10: Challenges experienced adopting and scaling Agile ... 39

Chart 11: Time lost due to context-switching ... 57

Table of Tables

Table 1: Main typologies of project management ... 9

Table 2: Key elements of organizational structure (Robbins, 1998) ... 45

Table 3: Favorable and unfavorable aspects for Work Specialization dimension ... 46

Table 4: Favorable and unfavorable aspects for Departmentalization dimension ... 47

Table 5: Favorable and unfavorable aspects for Chain of Command dimension ... 47

Table 6: Favorable and unfavorable aspects for Span of Control dimension ... 48

Table 7: Favorable and unfavorable aspects for Centralization and Decentralization dimension .... 50

Table 8: Favorable and unfavorable aspects for Formalization dimension ... 51

Table 9: Evaluation module ... 66

Table 10: Evaluation of the shared module by question ... 81

(5)

Abstract

The aim of this research is to give a comprehensive overview of Agile Project Management and the deep impacts of its adoption into human relationships, processes and corporate culture.

Throughout the analysis, a meta-framework has been developed to understand, at first, whether the environment and the structure of the project are compatible with a potential successful integration in the company.

Once identified the dimensions of analysis, these have been translated into an evaluation module which has then been applied to the empirical experience. The final aim of the work is then to understand whether APM can be applied on an Organization by applying the model.

This thesis is structured in three main sections:

 The first pillar is an introduction to the basis of Agile Project Management and its key components, under the form of a Literature Review. This section features an extract of the latest State of Agile reports, a yearly document giving an overview on the involvement of APM in a sample of industries worldwide with detailed statistics on the features considered fundamental and their impact on the result

 The second pillar of the research features the development of the meta-framework, with the analysis of the parameters that constitute the three dimensions of an organization: its organizational culture, organizational structure and strategic setting. These dimensions have been explored according to their compatibility with Agile practices

 The third section of the thesis illustrates the company experience according to the factors introduced throughout the development of the thesis. The meta-framework is then used to assess the compatibility of the corporate culture, the features of the project, its width and impact with those ideal for a frictionless Agile development

The research stemmed from the desire to deepen the knowledge of company dynamics which are internal, after a year-long traineeship experience as a business analyst in a consulting firm. Having personally faced the issues that have been presented in this document, the thesis has been developed to be as complete and extensive as possible.

The intent of the research was to evaluate, at first, the situation of a company to understand whether a transformation towards the adoption of Agile practices was suggested or even discouraged if the structure of the organization was found to be incompatible with a minimum set of key features that would otherwise be detrimental to the change of project management method. The change in style, moving from a traditional approach to an Agile one, being a radical change to

(6)

the philosophy that guides a company itself, has deep impacts in terms of economic evaluations. Furthermore, the description of the different practices that are involved in this transformation with their possible downsides contributes in stimulating the organization to evolve towards a higher maturity level describing step by step what is needed to optimize the processes. Among these, a “fil rouge” in the analysis of Agile practices is dedicated to deepening the knowledge on the added value given by the contribution of employees which are actively involved in the dynamics of the company. The project on which we were enrolled was meant to lead an Italian first tier insurance company into a digital transformation process through which they would have brought together several legacy systems into a mobile app. Simultaneously, the organization would pursue a digital transformation strategy.

The project was first introduced in early 2018 in the company by following a traditional waterfall stage-gate methodology; in November 2019 the company switched to Agile, under the form of Scrum framework. The evolution has been documented in the dedicated chapter.

(7)

Research Methodology

The original documents and papers reviewed in the following chapters have been found through the use of Google, the platform Google Scholar, the academic database of Politecnico di Milano (www.biblio.polimi.it).

Care has been given to the analysis of the bibliography and references of the works found. Each paper presents several references to corroborate its thesis, which reference several papers more themselves. In the deepening of the different chapters, the different streams have been followed to provide relevant information with a strong background.

The analyzed papers followed a qualitative approach, providing a description of the phenomena they were dealing with, whether was it a case study, a framework or an interview.

The quantitative documents hereby presented have been extracted from State of Agile reports, which feature numerical indexes to measure the level of Adoption for Agile practices in different industries and the main KPIs taken into consideration for the analysis. For this purpose, the last 5 editions of the report have been collected

(8)

An introduction to Project Management

In this chapter a preliminary overview on the traditional project management concept is presented, thus highlighting the elements that brought to the arise of Agile Project Management.

A project can be traditionally defined as:

 A unique, transient endeavor, undertaken to achieve planned objectives, which could be defined in terms of outputs, outcomes or benefits. […] Time, cost and quality are the building blocks of every project. (Association for Project Management 2012)

 A set of people and other resources temporarily assembled to reach a specific objective, normally with a fixed time period (Graham 1989)

 A temporary endeavor undertaken to create a unique product or service (Project Management Institute 2013)

Uniqueness, time and resources limitation can be picked as key words in the definitions. The building blocks of a project are the unique scope (the objective to be reached), the time (or duration) and the cost (usually defined as the available budget).

Project success has been traditionally measured with these three simple categories. The three dimensions are the classic sizes of a project. Each decision on the management of a project can act on a precise one of them, but they cannot be managed as independent as they are intertwined in their definition. The trade-off among the dimensions has to be considered as the time needed to get to the market, the unit-cost sustained and the scope (and therefore quality), intended as product performance (Tatikonda 2008),reached are in relation with each other and this reflects on the overall quality of the outcome.

This concept has been simplified under the definition of quality, cost and timing and finds a clear representation under the form of the classic, golden (Drury-Grogan 2014), project triangle:

(9)

The scope of a project is rarely clear in mind. In a traditional, consolidated process this is known to the members of a group, so each of them knows what are the issues they may face, the budget allowed, the time usually needed to perform the activities.

What if, instead, the project must take place in a startup or in a large and well-settled organization that needs to change years and years of legacy traditions for a digital transformation project? The initial steps may be known, but then over time, by small steps, the requests may differ from what was needed at first and with the use of small resources and an even smaller scope, the aim can grow and adapt time by time.

According to the typology of environment in which the project is being deployed (figure 2) and the elements of the project triangle that need to be followed there can be distinguished three main project management methodologies, as illustrated in table 1. A Project management methodology is defined as the set of methods, techniques, procedures, rules, templates, and best practices used on a project (Project Management Institute 2013):

 Traditional Project Management  Agile Project Management  Extreme Project Management

Scope Time Costs

TPM Fixed Fixed Fixed

APM Variable Possibly fixed Possibly fixed XPM Not well defined Re-Plannable Re-Financeable

Table 1: Main typologies of project management

For what concerns the environment we can consider two dimensions for the analysis: stability of requirements, e.g. how subject they are to change, and the maturity of technology, whereas this represents how likely it is to face obsolescence and important changes in the methods of adoption.

(10)

Figure 2: Environment complexity

In simple and complicated projects, the requirements are static, clear and technology is well known to the team: the risk of unexpected changes is low, so a traditional project management approach can be adopted. Once requirements become fluid and subject to changes, the project shifts towards the complex area: technologies can be either new or change throughout the development phases, so a need for flexibility arises, calling for an agile approach. In case technologies become unstable, with a very high risk of obsolescence before the delivery, business requirements are likely to follow with reworks: chaotic projects are dealt with using an extreme project management approach. The development of this research has set the focus on Agile Project Management techniques and methods, using TPM as a benchmark to assess differences and similarities.

Traditional project management methods often encompass the movement of a project through a structured series of stages, followed by a gate where a decision is made to stop or continue to the next stage (Totten 2017). This process, called stage-gate, maps out in detail what needs to be completed and how. (Cooper 2008)

Typical phases in Cooper’s model include the defining of the project scope, a solution development, test and launch. There is no phase 2 if phase 1 has not been checked out on all its sides. This model can be successful with “seasoned” projects for which the outcomes are known, and the development pathway is well planned and structured. With traditional methods the thorough planning of activities is encouraged as low variability is encountered through time.

In a chaotic space, which can be intended as a lack of flexibility, project reworks, continuous change in customers’ requirements it is hard to set up a predefined set of actions needed to pursue the initial objective, and this could bring to project failure.

Furthermore, it is to be noted that an excessive setup time concerning the initial requirements project requirements can be so time consuming that an important part of the resources can be

(11)

spent just in the planning phase, sometimes even going to waste because of technological changes in the meanwhile.

One of the main dimensions in the selection of the project management style is the uncertainty. Uncertainty decreases as time passes and the project is developed: at the very beginning, the level is high because of the lack of information on the outcomes. At an initial stage it can be dealt with a relatively low cost, as there have been no developments yet and there’s plenty of room to “steer”. Moving on, choices are made and turning back becomes pricier and pricier according to different elements. A corrective action could impact on goals, time needed, and constraints applied. There arises the need to reduce uncertainty as fast as possible, throughout the support of stakeholders’ requirements, team knowledge and flexibility.

It is clear to see how the undergoing of a project without a predetermined groove requires the ability, for those involved, to be able to dance in the rain, whereas for this it is intended the reaction to unexpected changes and evolutions in the development of the activities.

According to (Dyba and Dingsoyr 2008) the overall process could be made more efficient by reducing the initial planning and allowing the project development to become more evolutionary. The next paragraphs are meant to describe the main types of project management, highlighting their key features and thus how they can be suitable for a certain type of project.

Traditional Project Management

In a traditional project management setting, the idea is that of methods that can be applied to different projects in a uniform way. By using the same procedures in different settings, the standardization should contribute to robustness and flexibility for a wide range of projects. This traditional, rational and normative approach considers projects to be relatively simple, predictable and linear with clearly defined boundaries: since they have a similar structure, it is easy to outline in detail the plan to be followed without much changes (Špundak 2014). The goal of this type of approach is the optimization and efficiency in the following of the initial predetermined project plan. However, as robustness is often emphasized as one of the main advantages in this traditional approach, stressing how the same methods and techniques can be applied to different projects in a uniform way, this is increasingly mentioned as one of the main disadvantages of the approach as well (Špundak 2014). The progressive evolution of business environments and therefore projects, with their higher and higher number of tasks, complex relations and uncertainties reflects on the

(12)

stillness of traditional project management, which heavily relies on structured hierarchies of linear tasks.

The second major flaw in dealing with TPM is the assumption that a project can be structured only based on its expected outcomes and not with its surrounding environment. It is not expected to face changes in any of its parameters, for its 3 key components (time, scope and cost) have been defined in the project outline and none of them has an aura of uncertainty around it: it is actually unlikely to have a project flow unchanged, for these can happen in the external conditions in which the project is nurtured or in the parameters of the project itself.

The key factors for which a TPM approach is nowadays unsuggested for a wide range of projects have been collected (Williams 2005) under:

 Structural complexity

 Uncertainty in goal definition  Project time constraints

This kind of approach is defined Waterfall or Stage Gate because in order to pass to the next phase of the project there is the need to have completed all the steps in the current phase. As in a natural waterfall the flow is from top to bottom without any state skipped, there is no way the product can be designed if the analysis is not completed, it can’t be tested if the implementation is not complete, and so on as illustrated in figure 3.

Figure 3: The Waterfall approach

Agile management

The evolution in the approach stems from the need to adapt to changes, whether these are in the elements of the golden triangle or in the environment. These impacts have affected all industries, with a special mention for the software development. In this sector the need for new functions, continuous bug fixing release after release and cyclical improvement has stressed the need for a system able to absorb fluctuations and uncertainties.

(13)

In this kind of approaches the common trait of project management, under the name of Agile, lean, extreme, etc., is the higher focus on the adaptability of the process to the needs rather than predictability and strict following of what was initially planned as it happens for TPM. Furthermore, in a traditional method the product passes through different stages of design, requirements, building and as last stage it gets to the market. The time elapsed between the definition of business requirements and the value delivery to the final customer under the form of sales/revenues and value-in-use has often been way too extended to be sustainable (figure 4). Businesses, requirements and needs change fast and it is unaffordable to have something in the works for so long without even the guarantee that the efforts will bring value in the end, not meeting current needs or having become obsolete.

Figure 4: The development of Projects with Traditional and Agile approaches

Since changes are inevitable during the lifecycle of projects, new approaches have learnt to embrace rather than avoiding them, acknowledging that it is impossible to create a complete complex project plan at the beginning of a project (Špundak 2014). The emphasis therefore turns on the project execution, not on thorough planning. This mindset requires important levels of communication and collaboration among team members, so that everyone is aligned and able to keep the development on lane. These factors require more involvement in the company, starting from top managers, if compared to a standard project to be followed, where tasks and responsibilities are defined in advance and are not likely to change throughout the phases of the development. The key characteristics of Agile development are presented in the following chapter.

(14)

Throughout the research, the focus has been set on Information Technology projects as their structure better fits the ideas and methodologies at the basis of Agile Management, such as the ability to formally release end products in increments.

It is to be noted that this is not the only setting on which Agile can be applied, as explained in the dedicated section, since different projects can benefit from a shift in mindset towards a more collaborative, iterative and customer centric experience.

(15)

Agile management

Introduced in the previous paragraph, Agile is not only a project management approach, nor just a methodology for development. It is indeed a set of values and principles that set the foundation for how a team operates and makes decisions.

It has been first introduced in 2001, with the Agile manifesto, and was initially designed for software development. On its front page it reports:

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.

THE AGILE MANIFESTO,2001

Agile boils down to delivering value to the customer early and often. As the working team for a software project is made of programmers and developers, the team is often referred to as dev team/developers even though this can refer to designers, analysts, manufacturers, etc. This means getting comfortable with iterative progress over big-bang perfection and finding ways to allow dev team and customers to ideate, co-create and test & learn together.

Individuals and interactions over processes and tools

The first value in the Manifesto highlights the importance, for Agile practitioners, of people and relationships compared to objective processes. Since people oversee the management of the process and its outcomes they need to be valued more. The importance given to team members and the communications among them is even clearer when analyzing Scrum ceremonies (Scrum is one of the most diffused Agile methodologies), where different scheduled meetings are held every day. This helps making the communication fluid and facilitates the emerging of needs at a team level as soon as they arise.

Working software over comprehensive documentation

As Agile was born for software development reasons, the need to prioritize the efforts for developers arose. Documents needed included: technical requirements, interface designs, specifications, documentation plans, approvals for each product. The focus with Agile moves on

(16)

putting the actual development with priority with proper documentation in the form of what is strictly needed for the activity. Only after that the remaining documentation can be produced. This switch helps the dev team produce and create without being held away with paperwork. In Scrum the starting point is a User story, with the dimension of a single card, to begin a new task.

Customer collaboration over contract negotiation

In a traditional setting the customer interacts with the development team in two phases: the outlining of business requirements for a new product, with lots of details over the different areas of the deliverable, and during the delivery phase, as the final product is ready to be shipped. Under Agile the customer is invited to participate during the development process, not only for what concerns the requirements. This helps the development team meet the needs of the customer that may arise throughout scheduled meetings, during design and production phases or even through the attendance of meetings under the form of a Product Owner (for Scrum).

Responding to change over following a plan

Under a super-detailed contract for every aspect of the project, each change request is an expense as it requires the rework of features that have already been developed. With Agile approaches instead the check phases with the customer are much more frequent and this allows for an early change in direction where this is needed. Short iterations allow re-prioritization of features from release to release with reduced dependencies. Furthermore, here change is welcomed as it allows to better suit the interests of the customer, which is kept up-to-date and doesn’t risk receiving a product which is already obsolete even before coming out of the developers’ hands. Any change with the Agile mindset provides additional value, improving the project.

The Manifesto illustrates the 4 values which create the basis for Agile management and are supported by 12 further principles. These illustrate the culture that is meant to infuse the mindset of team members and the philosophy of the whole project as this is brought forward. The 12 principles are listed below, each with a brief description.

1. Customer satisfaction through early and continuous software delivery: a periodic update on the status of the project helps keeping the customer up to date, rather than having to wait for extended periods of time between subsequent releases

2. Accommodate changing requirements throughout the development process: the ability of the team to re-prioritize business requirements without excessive reworks in a short time window

(17)

3. Frequent delivery of working software: The iterations help ensuring the delivery of PSPs – Potentially Shippable Products at the end of each Sprint (Scrum)

4. Collaboration between the business stakeholders and developers throughout the project: The alignment helps developing a product which is in line with the expectations

5. Support, trust, and motivate the people involved: As team members are accountable for their work, they can produce at their best with tangible results

6. Enable face-to-face interactions: communication is encouraged, and teams work better when they share the same location

7. Working software is the primary measure of progress: the delivery of software to the customer is the actual measure of work done

8. Agile processes to support a consistent development: teams are free to define their own routines, to be repeated from iteration to iteration. After a while their speed of software delivery can be computed, making it easier to evaluate the capacity for further releases 9. Attention to technical detail and design enhances: a constant speed guarantees the team

can work out the details of the features they release with constant improvements

10. Simplicity: in line with Lean management theories, just what is requested is what is going to be developed

11. Self-organizing teams encourage great architectures, requirements, and designs: having skilled team members ensures a high-quality outcome, where everyone is accountable for their slice of deliverable and can act at his best on it

12. Regular reflections on how to become more effective: teams set up periodic meetings in which they exchange best practices, techniques and process improvements ideas especially for what concerns team dynamics

It is to be noted how the principles present a recurring theme of the centrality of the customer, with his guidance and participation, and the mutual support among the participants in the project. The sense of trust and transparency that arises from these lines is fundamental to understand the philosophy of agile. The core values can be applied to Agile project management as a whole, not just for what concerns software development. (Aguanno 2004).

The word picked to differentiate this new approach from the traditional one was agility: it is defined as the ability to create and to respond to change in order to create value in turbulent business environment. Agility, as almost every research endeavor, is based on several business principles like

(18)

continuous innovation, product adaptation, shortening delivery times, adjustment of people and processes, and reliable results. (Highsmith 2004).

Scrum

Scrum is a goal-oriented methodology which focuses on processes and best practices as tools to provide functioning software. The focus of the methodology is on the outcomes: each iteration is focused on the result.

It is defined by its creators as “a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value” (Schwaber and Sutherland 2017).

In 1986 Takeuchi and Nonaka introduced the term “Scrum”, originally used in rugby, to define a situation where a team moves from a sequential (waterfall) approach to a more holistic one. An actual scrum in a game lets the players move up the field by continuously passing the ball among the team members. Scrum teams can rearrange their priorities and assignments among different work-shifts, defined as sprints.

Scrum is a process framework based on teams and it is structured with rules concerning people roles, events and artifacts. It has been first used in the early 1990s and it can employ various processes and techniques along its guidelines. The core of scrum is the team, made of up to 8 people. As a small team it is highly flexible, reactive and adaptive to external demands. Several teams can cooperate in networks, if needed, and interact by means of sophisticated development architectures that allow them to maintain their identity and high-traction capabilities, given the size. This chapter has been developed on the guidelines provided by The Scrum Guide by Ken Schwaber and Jeff Sutherland. This book, whose first edition came out in 2010 and is now at its 7th_revision,

illustrates in detail what the framework is made of and how it can contribute to the successful development of a project in its details.

Scrum pillars

The framework is founded on empiricism, which asserts that “knowledge comes from experience and making decisions based on what is known”. Several practices in the description of Scrum are based on this assumption: as an iterative and incremental process for development, next actions are based on what has been previously done. Scrum is defined iterative as its main structure of sprints is composed of repeating cycles and incremental as at the end of every sprint there is the

(19)

 Transparency  Inspection  Adaptation

Transparency states that every aspect of the overall process must be visible to the other members of the team and the stakeholders. Since team members are accountable for their actions and contributions, there arises the need for a clear common standard in the definition of what is ongoing and what can be marked as “Done”.

Inspection requires that every participant in the process takes charge in inspecting and analyzing the artifacts produced throughout the development phases, so that a constant alignment towards the Goal is granted without undesirable variances.

Adaptation translates in the need to be able to realign the aims and efforts in case a requirement changes or evolves. Without flexibility, one of Agile pillars, the whole framework would lose its fundamental ability to react in complex environments. Scrum teams can take advantage of 4 different recurring events to check the current state of development:

 Sprint planning  Daily scrum  Sprint review  Sprint retrospective

Scrum values

The three pillars are supported throughout the daily application of Scrum activities by 5 values, which allow teams being Agile each in its own way. These values are meant to guide the team and their application is aimed towards the achievement of the Goal in the most efficient way, whereas with efficiency it is meant not only the economic side but the well-being of team dynamics.

 Commitment  Courage  Focus  Openness  Respect

Each member of the team is simultaneously in charge of providing a pleasant and productive work environment for others, and as a facilitator the Scrum Master can support and enforce the compliance.

(20)

Commitment is a fundamental value in driving the dynamics of Scrum teams. Each team member commits himself in front of the others in developing a precise section of the software, for which he is fully responsible. Commitment can be supported by the SM through appropriate sprint plannings and by means of suitable workloads definition.

Courage is one of the values that most helps Scrum teams. Standing up and raising concerns, asking for help, deciding to try new ways of working. Each sprint is short and with a clear goal in mind. Speaking up helps team members make this happen. The SM should be the first one to take care of impediments that may slow down the team, even if this means standing up to the product owner in order to protect the work done by the team.

The value of Focus makes team members to only select precise issues to be brought to the next sprint. The work to be done is known and resources are limited, so there is no scattering of concentration or time on activities with low to no-value added. Focus can be encouraged by the SM through sprint plannings and daily scrums, where each collaborator is exhorted to deep dive into what he oversees. As different people deal with different issues simultaneously, each of them can work with acute focus on a single matter. The role of the SM is to ease this transition, helping team members concentrate.

Openness helps the team in the pursuit of their objectives in a scrum environment. Each morning during daily scrums team members have the chance to make others aware of any impediments they are facing, making everyone aware of the status of the sprint. There is no shame in honesty, as issues brought up can be discussed by different point of views and therefore resolved with ease. During meetings and reviews the SM lets others speak up, aligning on the status of ongoing works. He can act as a meeting point among stakeholders and product owner’s requests and the team capability. The key to the growth and self-development from sprint to sprint is in the Retrospective, a meeting held at the end of the sprint where the team reflects on how to improve their relationships and processes.

Respect is the last of the 5 values that drive and inspire team members in their pursuit of the goal. The strength of the team resides in the relationships they can maintain among them, where communication plays an important role. Each one has its own ideas and conflicts are likely to arise but only through respect towards others the team can reach the predetermined goal.

(21)

The process

Scrum organizes the development of a project through sprints, timeframes in which the teams can work on features picked from an omni comprehensive list, the backlog, which contains all the prioritized business requisites. Every feature is written in the form of a user story that narrates the desired behavior of the item to be developed, whether it is software or product manufacturing. People roles

In a Scrum Team there can be highlighted three main figures which are accountable for the correct execution of the sprints. Each of them deals with different responsibilities and tasks, detailed below. Product Owner: this figure is responsible for the definition of the features to be introduced in the development phases. It is a representation of all the stakeholders’ interests and feedbacks for a product that reflects the desires of upper levels and it is responsible for the constant alignment with the rest of the team. He is in charge for the management of the product backlog and for its proper prioritization throughout the different sprints. Acting as a bridge between the team and the customer, he curates the overall vision of the product. The product owner needs to be a subject matter expert on the project domain, on the market for the project and in the end users. Furthermore, he needs to be empowered since he is charged with making executive decisions. Figure 5 represents the activities of the Product Owner inside the Scrum framework (courtesy of Innolution.com).

Figure 5: The Product Owner

Scrum Master: this figure acts as a coach and a facilitator for the team during sprint activities. He simultaneously serves different stakeholders in dedicated ways:

 Product Owner, by coaching and educating on Scrum practices and supporting him in the management of the product backlog

(22)

 Development team, by stimulating productivity through precise estimation of their capacity, removing impediments that may arise, facilitating and organizing sprint activities and ceremonies

 Organization, by helping employees understand the meaning behind Scrum activities and working with Scrum Masters responsible for other teams to increase the level of coordination for cross-functional activities that involve different teams

Development team: a cross-functional and self-organizing unit. They are empowered to define the translation of the product backlog into actual increments of functionalities to be developed. Inside the group there are no hierarchies, each member may be specialized with a precise skill set on which he focuses but accountability as a group belongs to the team as a whole. The number of members is set halfway between two needs: remaining nimble and being able to complete significant work within each sprint, reasons why the members are usually 3 to 9. The dev team does not only include actual software developers, as UX/UI designers and analysts can be included in this category. They are in charge of the technical definition and implementation of the solution to be adopted since only they can detect dependencies and impediments bound to the procedures. Figure 6 represents the activities of the Development Team inside the Scrum framework (courtesy of Innolution.com).

Figure 6: The Development Team Artifacts

Scrum artifacts represent work or value needed to provide transparency and occasions to proceed with inspection and adaptation phases. They are designed to maximize transparency of key information so that each member of the Scrum team, whether he is the Product Owner, Scrum Master or Dev team, has the same level of comprehension of the activity.

(23)

Product backlog: an ordinated list of everything that may be useful to the product, it represents the only source of requisites to perform changes and evolutions to the product. The Product Owner is responsible for its management, including its content, availability and prioritization. A PB is never complete and definitive, as the first drafts only include what is initially requested or known. It evolves with the product and the architecture on which it is developed throughout its lifespan. The product backlog is dynamic, as it constantly changes to identify what the product needs to be appropriate, competitive and useful, and exists as long as the product exists. Inside the backlog all the features, requisites, corrections, are listed. These elements constitute the improvements and changes to be applied on the product for next releases. Changes in business requirements, market or technology can cause changes in the product backlog. Good product backlogs share similar characteristics, defined by the acronym DEEP by Mike Cohn and Roman Pichler (Rubin 2012): Detailed appropriately, Emergent, Estimated, Prioritized.

 Detailed appropriately: the product backlog contains different items, each with a different level of detailed according to its prioritization. High priority items need to be more detailed as the team will start working on it soon, and details are going to be added to backlog items through a refinement process

 Emergent: the PB is not created entirely at the beginning of the process, but it gets constantly updated in an iterative fashion to reflect requirements that have emerged throughout the development phases and as the users learn more about the product and the marketplace. A dynamic emergent backlog is a sign of a healthy development and planning  Estimated: each item of the PB is assigned a size estimate that corresponds to the effort

required by the dev team to produce it. Its value helps the dev team plan in detail the number of features that can be implemented in the next sprint without exceeding their capacity and the Product Owner properly prioritize items. Items which are considered too large can be sub-divided in smaller tasks which fit well in a sprint

 Prioritized: a product backlog needs to be prioritized, which means that items are planned to be developed according to the value the business unit (typically the PO) assigns them. Sprint backlog: it is constituted by the product backlog items picked for the sprint, plus a plan for the development of the product increment to the realization of the Sprint goal. The SB is a forecast of the dev team on what is going to be implemented through the next iteration and what is needed so that a functional increment can be developed and recognized as “done”. It explicates the work the dev team considers as necessary to reach the sprint goal and has a level of detail which lets the

(24)

team adapt it according to what is shared during the daily scrum. The DT edits the sprint backlog during the sprint if needed and as they learn what is needed to reach the goal: as new tasks emerge from user stories these are added to the sprint backlog; as tasks are no longer useful, they are removed from the backlog. It is important to notice that only the Development team is in charge to edit the sprint backlog once the sprint has started, as a slight change in business requirements can have a wide impact on the development efforts.

Potentially shippable product increment: it is made of the sum of all the items of the Product Backlog that have been marked as completed during the sprint and the value of the increments from antecedent Sprints. At the end of the Sprint it must be “done”, it needs to satisfy the definition of “Done” set up by the whole Scrum Team. It should be usable regardless the PO decision of actually releasing it, hence why “potentially releasable”.

Events and Ceremonies

A Sprint is a timeframe with specific start and end dates of usually 2 to 4 weeks during which the Scrum team works to complete a chosen set of work, aligned with a larger goal, bringing to the status of “Done” the part of the backlog they committed to. Each sprint begins with a planning of the work, continues with daily updates on the status of the team and ends with a double review, one for the work completed and a retrospective on the way the team worked together. These events are defined:

 Sprint Planning  Daily Scrum  Sprint Review

 Sprint Retrospective

Each sprint happens right after the other, without breaks of any kind in their succession as represented in figure 7 (courtesy of Innolution.com).

(25)

By maintaining a steady cadence, the team is able to maintain a consistent workload thus becoming comfortable with the amount of work that it can accomplish in a typical sprint, which helps them become more predictable (Rubin 2012). Since each sprint is dedicated to a specific goal, it describes the commitment made by the team and the product owner for its delivery. The PO is not allowed to make changes to the sprint backlog if this may modify the goal, so that the team can work focused on an objective that is not likely to be altered. Figure 8 represents the structure of a Sprint (courtesy of Innolution.com).

Figure 8: The Sprint cycle

Sprint Planning: During the SP the Scrum Team discusses the items put at the top of the Product Backlog which are desiderata for the next iteration. This meeting aims at defining the Sprint Goal and each member of the team has its role here: the Product Owner defines the priorities and the objective of the Sprint, the Dev team expresses how much outcome it can accomplish with possible impediments that may arise and the Scrum Master has to facilitate the meeting. The planning may last as long as 2 hours for every week of sprint as a rule of thumb, which means that the planning for a 4-weeks sprint can be time-boxed for a maximum of 8 hours. This meeting answers the following questions and each component of the team has it say:

 What can be done during this sprint?  How will the chosen work get done?

Daily Scrum: Each morning the Development team meets for 15 minutes to inform the others how their work is going and whether they still think the Goal is reachable, as well as of impediments that have arisen and that are likely to compromise the reach of the goal. The scrum Master attends each of these meetings, so that he can facilitate the solving of issues. The meeting is orchestrated by the dev team and can be both question-based or discussion-based:

(26)

 What did I do yesterday?  What will I do today?

 Did I face any impediment that is likely to alter the Sprint Goal?

Sprint Review: The SR is an occasion for the Scrum Team to invite any involved stakeholder in discussing what has been completed during the sprint. Its main objective is “to inspect the Increment and adapt the Product Backlog if needed” (Schwaber and Sutherland 2017). The participants to the meeting collaborate and discuss on what has been done and the next things that could be done in order to optimize value, which is any stakeholder’s main interest. There is no limit to how many people can join the review, as the more and diverse the feedbacks the better for the development of the product. Figure 9 represents the activities held inside the Sprint Review by the Scrum Team (courtesy of Innolution.com).

Figure 9: Sprint Review

Sprint Retrospective: these events set focus on the review of the overall development process by the whole team and what constitutes it. The SR is an opportunity for the team to inspect itself and create a plan for improvements to be enacted during the next sprint. (Schwaber and Sutherland 2017) The goal here is to improve the process, the tools and the relationships hence why the whole team must attend. The iterative and incremental approach in Scrum reflects here: after each sprint the Retrospective acts as an improvement step so that:

 the following sprint can recover from mistakes that may have arisen and therefore be avoided in the following iteration,

 the team can implement new best practices that are being acquired  the definition of Done can be adapted to new evidences

(27)

Figure 10 represents the activities performed during a Sprint Retrospective (courtesy of Innolution.com).

(28)

State of Agile

The State of Agile is a report issued yearly by CollabNet, a software company whose main product VersionOne is an Agile Management platform. (CollabNet VersionOne 2019)

The report gives software professionals insights into recent trends for Agile applications, best practices to be adopted and key takeaways from other industries to help succeed with digital transformations.

It is currently the largest and widely cited agile survey in the world, counting on 1.319 full responses from across the globe and 13 editions at the time of writing.

This chapter is dedicated to analyzing what the main trends and critical success factors are in adopting an Agile framework for operating a long-term successful strategy according to respondents from across the world and different industries so that the best mindset and tools can be adopted. The report is based on the following categories, for which data is presented from the latest issues to gather trends and insights.

1. Respondent Demographics

2. Company Experience and adoption 3. Benefits of Agile

4. Agile Methods and practices 5. Agile success and metrics 6. Scaling Agile

7. Agile Project management tools

8. Agile + DevOps & Value Stream Management

Note: Data reported refers to years where respondents may have changed and therefore subsequent years do not represent actual evolutions of preferences and behaviors in the same audience but rather must be considered as a general evolution in the global audience of respondents. Sections 7 and 8 have not been explored in this analysis as they are unfit for the objective of the thesis.

1 - Respondent Demographics

The survey collected responses from practitioners coming from different sets of organization sizes, roles, geographic locations, industries.

(29)

Compared to 2017 the overall number of participants reduced 11%, from 1.492 to 1.319, while the highest number of participants has been reached in 2015 with 3.880 answers.

Recent years have seen a shift in the dimensions of organizations whose members filled the survey, portraying the higher and higher adoption by larger entities by means of different scaling frameworks such as SAFe and Scrum of Scrums (SoS), reaching a total of 46% answers from organizations with more than 5.000 members compared to 39% in 2015.

Chart 1: Size of Organization

The respondents to the survey perform duties as different roles inside organizations and are able to show the different levels of involvement across the organization chart.

Most of the responses have been submitted by those who are responsible for the formation and guidance of teams: Scrum Masters and Agile Coaches represent the 34% of the total; they are followed by figures in charge of developing the level of adoption of Agile practices inside companies: Development Leadership VPs, Directors and Managers represent the 15% of the audience.

The breakdown of the audience is reported below:  ScrumMaster / Internal Coach: 34%

 Development Leadership: VP/Director/Manager: 15%  Project / program Manager: 11%

 Development Team Member: 11%  External Consultant / Trainer: 10%  Product Manager / Product Owner: 6%  Business Analyst: 5%  C-Level Executive: 3%  DevOps: 2% 36% 39% 39% 44% 18% 21% 18% 17% 18% 16% 17% 15% 28% 28% 26% 24% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 2018 2017 2016 2015

Size of Organization

< 1.000 1.001 - 5.000 5.001 - 20.000 20.001+

(30)

It is not surprising to see how the majority of respondents represents the guiding people for the correct application of Agile practices but it’s important to notice the relatively high presence of C-Level Executives in the audience, indicating how important Agile is considered important inside organizations and therefore worthy of taking time from such a high level manager. As analyzed in the dedicated chapter, Agile practices are most effective when the values are implemented not only bottom-up but top-down, involving all the managers and directors.

The Industries tab gives a representation of the areas where Agile practices are most implemented. Technology sectors account for only 25% of the total, representing how versatile the practices are and the different industries in which they can be employed under different forms.

 Technology: 25%  Financial Services: 19%  Professional Services: 10%  Insurance: 8%

 Government: 6%

 Healthcare and Pharmaceuticals: 6%  Industrial and Manufacturing: 4%  TLC: 4%

 Energy: 4%  Education: 3%  Retail: 3%

 Transportation: 3%

 Media and Entertainment: 1%  Non-profit: 1%

 Other: 3%

The report highlights how organizations support distributed teams and team members across boundaries and time zones as well. There is no evidence of relevant trends toward an increased co-location, even while working face-to-face can be highly desirable for business related practices as further described in the chapter dedicated to Organizational Structure.

78% of the respondents work in organizations with distributed team members and 68% take part in organizations whose teams are multiple and co-located while collaborating across geographic boundaries.

(31)

2 - Company Experience and adoption

This section of the report aims at portraying the level of adoption of Agile practices inside respondents’ organizations and the maturity of the teams in the implementation of aforementioned practices and values.

According to the level of maturity of a company, the reasons and the benefits pursued for this adoption can widely differ as a younger company can aim at optimizing its processes for gaining efficiency while a more established one can pursue strategic alignments across its 3 main hierarchical levels (IT, Business and Leadership) since with consolidated processes the refinements are less likely to take place.

Chart 2: Years of Agile development methods adoption

The report then states which are the reasons stated for adopting Agile across organizations and an evolution of the data. For a comparison of the data, the last 3 reports from 2018, 2017 and 2016 have been listed below.

27% 34% 23% 10% 29% 34% 26% 9% 28% 32% 25% 15% 5+ years 3-5 years 1-2 years < 1 year

Years of Agile development methods adoption

(32)

Chart 3: Reasons for Adopting Agile

Throughout last year the reasons stated have been less about increasing productivity (51% compared to 55% in 2017), reducing project risk (28% compared to 37% in 2017) with an important bump in reduction of project cost (41% compared to 24% in 2017) and improvement of team morale (34% compared to 28% in 2017).

The list of reasons can be considered as an ex-ante reading of what the company was aiming at before actually adopting this methodology.

3 - Benefits of Agile

Companies who adopt Agile report different actual benefits from the implementation of practices and in recent years it is worth noting the increase in improvement of team morale (64% compared to 61% in 2017) and higher levels of project predictability with an increase of 3% (52% compared to 49% in 2017) and a similar level of reduction in project risk (50% compared to 47% in 2017). The flexible nature of Agile practices reflects in the first position of the chart, where the ability to manage changing priorities has been noted as a positive outcome by most respondents. The higher visibility of project features to team components is a direct result of the methodologies involved with Agile frameworks such as Scrum, where the detailed product backlog gives a complete overview of the issues that the Dev Team is going to develop over time.

0% 10% 20% 30% 40% 50% 60% 70% 80% Accelerate software delivery

Enhance ability to manage changing priorities Increase productivity Improve business/IT alignment Enhance software quality Enhance delivery predictability Improve project visibility Reduce project risk Improve team morale Improve engineering discipline Reduce project cost Increase software maintainability Better manage distributed teams

Reasons for Adopting Agile

(33)

Chart 4: Benefits of Adopting Agile

The list of benefits can be considered as an ex-post reading of what the company actually achieved after actually adopting Agile methodologies. It can be seen how the percentages for the different responses are actually higher than those given for the reasons of adopting, signaling how companies in average found 14% more in Agile than they were expecting before changing their paradigm.

4 - Agile Methods and practices

Among the different Agile frameworks and methodologies adopted by organizations, the most used according to the survey is Scrum (54%) followed by the Scrum/XP Hybrid (10%).

0% 10% 20% 30% 40% 50% 60% 70% 80% Ability to manage changing priorities

Project visibility Business/IT alignment Delivery speed/time to market Increased team productivity Team morale Project predictability Software quality Project risk reduction Engineering discipline Managing distributed teams Software maintainability Project cost reduction

Benefits of Adopting Agile

(34)

Chart 5: Agile methodologies used in 2018

Analyzing data from the report it is possible to see how Scrum and Scrum-based hybrids are the most diffused frameworks for practicing Agile. Many of the techniques employed, as represented in the chart below, constitute the basis of Scrum: this shows how other methodologies that drift from the idea of Scrum actually involve its practices, even if incapsulated in different forms.

Chart 6: Agile Techniques Employed Scrum 54% Hybrid/Multiple 14% Scrum/XP 10% Scrumban 8% Kanban 5% Iterative development 3% Don't know 3% Lean Startup 2% _1%XP

Agile Methodologies Used

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Daily Standup Sprint/iteration planning Retrospectives Sprint/iteration review Short iterations Release planning Planning poker/team estimation Kanban Dedicated customer/Product owner Single team (integrated dev and test) Frequent releases Common work area Product roadmapping Story mapping Agile portfolio planning Agile/Lean UX

Agile Techniques Employed

(35)

These Agile practices constitute, each in a different way, the values promoted by the Agile manifesto as they support continuous interactions among team members and transparency across the organization. The teams that adopt practices such as retrospectives and reviews aim at continuously improving their level of work, therefore creating virtuous circles for productivity matters and project quality.

5 - Agile success and metrics

The positive impact of Agile practices can be measured over Agile initiatives and Agile projects. In the report 95% of the respondents report at least a successful Agile project while 48% report that most of their agile projects have been successful.

The concept of success, for each of these two cases, can be represented by means of different metrics.

Chart 7: Measurement of success with Agile Initiatives

For what concerns the success of agile transformations, the three main measures of success have been stable throughout the last reports and are represented by:

 Customer/user satisfaction: since Agile practices are built on the specific demands of the client, products and software comply with the latest requests from customers and are then able to satisfy expectations, as they are co-created (e.g. the figure of the Product Owner in Scrum acts as a representative of the customer).

 Business value: its concept can usually be expressed by means of financial metrics according to the department of the organization it refers to. It represents all the forms of value that are able to sustain a company, which can take the form of (Verwijs 2014):

0% 10% 20% 30% 40% 50% 60% Customer/user satisfaction Business value On-time delivery Quality Productivity Predictability Project visibility Process improvement Product scope

Success measurement with Agile Initiatives

(36)

o Commercial Value, which translates directly into profit

o Market Value, which increases the potential number of customers

o Efficiency Value, which increases the efficiency of the organization and reduces costs o Customer Value, which increases the retention rate of customers

o Future Value, which increases the chances of achieving any of the other kind of values in the future by translating in innovation and investments

 On-time delivery: the flexibility of Agile practices allows for the delivery of features, from iteration to iteration, that are always up to date with the latest requirements from the customer. The time-boxed iterations then allow for planning the implementation of these updates

Analyzing individual projects, the measurement of perceived success doesn’t differ much as the three most cited metrics match the ones for Agile initiatives.

It is interesting to see how the definition of success has dramatically changed in the last three years, moving Velocity from a value of 67% of the respondents in 2016 to just 38%, as well as Iteration burndown which moves from 51% in 2016 to 24% in 2018 (as a note, Iteration burndown represents the amount of work left to do versus time, useful for predicting when the work left in the sprint is likely to be completed based on historic data). The shift towards the re-evaluation of customer satisfaction and business value can be linked to the necessity and importance of delivering actual value to the customer as the main benchmark compared to internal team dynamics, to which metrics bound to development can be linked.

(37)

Chart 8: Measurement of success with individual Agile projects 6 - Scaling Agile

The Agile frameworks presented, such as Scrum, are designed for small individual development teams. Managing two or more teams requires logics that differ from those of a small group and there arises the need of a strategy able to align every team’s work.

The most popular scaling method cited in the survey is SAFe, the Scaled Agile Framework, which consists of a set of organization and workflow patterns aimed at guiding enterprises in scaling lean and Agile practices by promoting alignment, collaboration and delivery across large numbers of agile teams. It is actually recognized as the most common approach to scaling.

0% 10% 20% 30% 40% 50% 60% 70% Customer/user satisfaction

Business value delivered Velocity Budget vs. actual cost Planned vs. actual stories per iteration Planned vs. actual release dates Defects in to production Iteration burndown Burn-up chart Defects over time Cycle time Release burndown WIP (work in process) Defect resolution Customer retention Estimation accuracy Earned value Revenue/sales impact Product utilization Scope change in a release

Measurement of success with individual Agile projects

(38)

Chart 9: Scaling Methods and Approaches

Throughout the survey, respondents reported the tips that have helped in adopting and then scaling agile practices in the organization.

1. Internal Agile coaches 2. Executive Sponsorship

3. Company-provided training programs

4. Consistent practices and processes across teams 5. Implementation of a common tool across teams

These practices have all in common the fact that they constitute a basis, for the benefit of members of the organization, of trust and guidance. The presence of internal coaches and company-provided training programs guides people into the certainty that the transition into a different way of developing work is possible and that they are supported in doing this. The sponsoring of these new approaches by company executives endorses the belief that they are encouraged into this new mindset with a top-down approach which is ready to meet the needs rising from the bottom of the pyramid. There is a shift of focus from the mechanistic view of the bare process to a broader view which takes care of individuals and the interactions that regulate team dynamics. The concept of endorsement by top-level executives and managers will be explored in the chapter dedicated to organizational culture and structure and the effect these have on Agile practices adoption.

At a company level the presence of homogeneous tools and practices helps to streamline the processes for which workers may have to move from a project to another, either for just a sprint

(2-SAFe 30%

Hybrid 19%

Scrum of Scrums 16% Internally created methods 8%

Disciplined Agile Delivery 7% Spotify Model 5% Large Scale Scrum 3% Enterprise Scrum 3% Lean Management 3%

APM 3% Nexus 2%

RAGE 1%

(39)

4 weeks) or for much longer. It provides a common ground for the exchange of practices and expressions, for which the company can gain efficiency value and save from avoiding several activities that require synchronization and adaptation one to another (e.g. syncing teams that work in Scrum with those that develop under Six Sigma).

Adopting and scaling Agile is not always easy, as there are different barriers and challenges that may arise during the process. They can be related to the culture of the organization, its structure or the traditions from which the current experience of the company has stemmed. Below the most common responses from the last reports have been detailed.

Chart 10: Challenges experienced adopting and scaling Agile

For the objective of this thesis, these issues have been analyzed and a strong correlation between the categories of organizational culture/structure and the likelihood of a project success has been found. This link has been explored in the dedicated chapter and the development of the analysis has brought to an actual list of critical success factors that are able to determine the compatibility of a company with an Agile approach for a certain project.

0% 10% 20% 30% 40% 50% 60% Organizational culture at odds with agile values

General organization resistance to change Inadequate management support and sponsorship Lack of skills/experience with agile methods Inconsistent processes and practices across teams Insufficient training and education Lack of business/customer/product owner availability Pervasiveness of traditional development methods Fragmented tooling and related data Minimal collaboration and knowledge sharing Regulatory compliance or government issue

Challenges experienced adopting and scaling Agile

(40)

Definition of the meta-Framework

In order to define how fit agile practices can be for a certain type of project and organization it is necessary to define the features of the environment under analysis.

As these Agile methods and frameworks are meant to improve quality and performances of the software development processes, they are mainly focused on human aspects: “Individuals and interactions over processes and tools” (Agile Manifesto).

However, the successfulness of their application in companies depends on the adequacy of the organization and how accommodating this is to change. In order to do so, the parameters that define these levels of acceptance must be identified and then explored.

The purpose of this chapter is to analyze the relationships between the organization environment and the adoption of agile practices under several dimensions such as organizational culture, organizational structure and the strategic setting.

Organizational culture

In the adoption of Agile methods some specific precautions should be taken into consideration as they are highly dependent from human relations: the effectiveness of the outcome depends on how people involved in the project interact among themselves. This can represent an obstacle in the adoption as it requires a working environment where developers, managers and stakeholders have principles and values that are aligned with those of Agile.

Organizational culture can influence the implementation of Agile practices in both a positive and efficient or negative and flawed way.

According to Chiavenato, “Organizational culture represents the perception of managers and workers and reflects the predominant mentality at the organization.” (Tolfo, Wazlawick e Forcellini, et al. 2011) It corresponds to the values, principles and beliefs that guide the behavior of the company staff. Since each organization behaves differently the implementation of practices must be contextualized in order to evaluate the feasibility of the process and its likelihood of success. A successful method can be considered as such, according to Shore and Warden, if it satisfies the balance among the needs of each stakeholder involved in the project. (Shore e Warden 2007) Agile development focuses on the achievement of success under three different spotlights:

 Personal success: proudness, motivation, pleasantness of a collaborating team  Technical success: high quality code, low-effort maintenance

(41)

 Organizational success: delivery of value and decrease of costs by focusing on the most valuable features first and frequent releases

These 3 levels can be linked with each other, as a high-quality software (technical) leads to satisfaction for the developer (personal). However, organizational success may be misaligned as a motivated team does not necessarily imply profits or higher value for the customer.

Software teams tend to favor technical and personal success as they’re easier to accomplish and therefore neglect the interests of stakeholders such as managers and investors which tend to take care of the return on the investment made by the project, independently by its technical features. For the company to reach any kind of organizational success, its actions and moves must be directed and guided by common guidelines and principles that permeate all its levels: organizational culture. Agile values sustain this view by means of collaborating practices at different levels of the organization such as the presence of the Product Owner during Sprint Plannings or frequent early deliveries of working software for the customer as this is most valuable.

It is therefore necessary to deepen the concept of organizational culture and its implications at a company level. The analysis has been performed by means of Schein’s framework, which considers organizational culture as made of 3 different interconnected levels.

There exist several definitions and interpretations of organizational culture:  “The way we do things around here” (Johnson 1999)

 “The institutionalized way to think and act, and its essence is expressed by the way the company does business, the way it deals with customers and employees, and the autonomy given to its members” (Tolfo, Wazlawick e Forcellini, et al. 2011) (Chiavenato 1999)

 “A pattern of shared basic assumptions that a group learned in solving its problems of external adaptation and internal integration, and which has worked well enough to be considered valid and, therefore, worth of being taught to new members as the correct way to perceive, think, and feel about those problems”. (Schein 2009)

According to Schein, organizational culture is manifested in 3 levels: 1. Artifacts: visible organizational structures and processes 2. Espoused Values: Strategies, goals, philosophies

3. Shared tacit assumptions: unconscious, taken for granted beliefs, perceptions, thoughts and feelings