Investigating the Gap between Scrum Theory and Practice in

Pakistan

Muneeba Jilani

and Naveed Ikram

Department of Computer Science and Software Engineering, International Islamic University, Islamabad, Pakistan

Riphah International University, Islamabad, Pakistan

Keywords: Scrum, Agile Software Development, Theory Practice Gap, Software.

Abstract: Theory and practice gap highlights deviations thus projecting any changes that hindered theory less beneficial.

Among the companies that practice agile, the most common methodology is Scrum. Scrum advocates strict

adherence to the original theory until it's successful prevalence in the organization. Industrial investigation is

conducted in this research to reveal practice theory gap in case of Scrum thus providing detailed insight into

the matter. It concludes with a set of guidelines for optimal Scrum implementation by addressing the gap in

depth.

1 INTRODUCTION

Scrum (Schwaber, 2011) is an agile framework in

which a software is developed incrementally via short

iterations lasting from one to four weeks. Introduced

by Jeff Sutherland and Ken Schwaber, the

framework’s main emphasis is on changing the work

environment and mind set of teams, making them

cross-functional and self-organizing.

Theory of Scrum provided in a standard Scrum

Guide, is simple and concise and adherence is advised

to reap full benefits of the method. However, Scrum

is hardly ever used in accordance with the theory

giving rise to the theory-practice gap. The adaptation

in Scrum practices should be based on past

experiences and not one’s own interpretation.

Section 2 comprises existing work, section 3

provides details of how interviews were conducted and

analyzed. Section 4 gives insight into the proposed

solution. Section 5 comprises concluding thoughts.

2 BACKGROUND

Sverrisdottir et al. (Sverrisdottir, 2014) have

compared the perception of product owners (PO) of

their roles with the role of product owner according

to Scrum theory. PO role is hardly ever in

conformance with Scrum recommendations. Also the

study reveals that Scrum is hardly ever used

exclusively rather a combination with other practices/

methods is favoured. A survey was conducted by

Salo et al. (Salo, 2008) in order to show the extent of

adoption of XP and Scrum in European embedded

software industry. It indicates expected usefulness of

these methods when there is no background

experience as well as actual level of use of practices

where agile methods are systematically used. The

study reveals that the usage of Scrum practices is

more method specific as compared to XP, still major

deviation exists as some practices such as Sprint

planning are not necessarily popular. Kurapati et al.

(Kurapati, 2012) conducted an online survey that

shows compliance of industry with XP and Scrum

practices. Survey results show that a combination of

methodologies is favoured as compared to using one

methodology with all its practices. Zieris et al. (Zieris,

2013) compared intended way of proceeding with

actual process and practices of two Polish Scrum

teams. Using Scrum Guide as standard, they closely

observed practices of both the teams. Their

observation revealed that additional practices were

introduced into the method and also some XP

practices were also added. M. Bass (Bass, 2012) have

conducted a case study involving 19 practitioners

from seven international distributed organizations.

The main purpose of this case study was to find out

trends in agile process tailoring. Not many changes

are made to Scrum process i.e. most of the practices

are performed in most of the organizations whereas

only selected practices of XP are followed. Eloranta

180

Jilani, M. and Ikram, N.

Investigating the Gap between Scrum Theory and Practice in Pakistan.

DOI: 10.5220/0009855201800186

In Proceedings of the 15th International Conference on Software Technologies (ICSOFT 2020), pages 180-186

ISBN: 978-989-758-443-5

et al. (Eloranta, 2010) have classified deviations from

Scrum into two categories namely ScrumBut and

ScrumAnd. They refer incomplete adoption of Scrum

as one of reasons for low success rate of Scrum

projects. Overhage et al. (Overhage, 2012) have

investigated developer’s acceptance or reluctance

towards Scrum in real scenarios in depth. They

presenteda model that can be used to developer

acceptance of Scrum as well as validation of

developer acceptance level afterwards. Ovesen et al.

(Ovesen, 2015) conducted a case study of seven

integrated systems development companies and used

semi-structured interviews to find out team

composition challenges faced by these companies

when they implemented Scrum. The paper shows that

companies deviate from Scrum based on their own

interpretation and suitability.

From the analysis of literature, we see that there

exist many articles that compare core

principles/practices of Scrum with how the method is

actually applied in the industry. However there are

limitations. According to our knowledge, none of the

currently conducted studies covers all the practices

from Scrum theory and none of these studies goes into

the depth of Scrum theory i.e. into the details of

Scrum practices provided in the Scrum Guide. Also,

post deviation identification none of the related

articles propose any solution for the problem even

though deviation is deemed harmful (Kurapati, 2012).

Another gap observed is that despite being the

most common agile method used, we rarely see any

studies on Scrum beyond the adoption stage.

Especially in the context of Pakistani software

industry we hardly see studies that explore Scrum

process implementation at all.

Hence through this study, we tried to analyze and

present a solution to the gap between Scrum theory

and practice in Pakistan.

3 RESEARCH METHOD

Multiple research techniques were combined and

used while conducting different phases of research.

Semi-structured interviews were conducted to gather

data from Scrum practitioners from organizations of

varying sizes. Data was analyzed via thematic

network analysis. Focus group was used as means to

validate the findings.

3.1 Interviews

Semi-structured interview (Jacob, 2012) technique

was chosen as a data collection method since it

provide in-depth understanding of the context which

was mandatory in our case. Also an interview guide

ensures common structure thus making results

comparable. After reading the background material

on Scrum, initially an interview protocol was

prepared in which questions were included related to

all Scrum practices (roles, events, artifacts) as

described in the Scrum guide (Schwaber, 2011).

Questions from Nokia Test (Eloranta, 2010) were

also included. A good interview protocol is

constructed in a way that the questions asked connect

with the informants (Jacob, 2012). Following

Spikard’s (Jacob, 2012) guidelines and keeping the

flow of Scrum activities in mind, interview protocol

was revised again and questions were re-assembled.

The final interview questionnaire consisted of three

parts.

Part A constituted of questions related to

 The background of the interviewees

 The organization

Part B had questions related to inception and

background of Scrum within the organization

Part C consisted of questions related to core

Scrum practices as enlisted in the Scrum guide.

Except for the closed ended questions related to

presence of core practices, most of the questions were

mainly open-ended. After forming an interview

protocol, a pilot test was conducted which revealed a

few flaws in interview design. This test was

conducted with a Scrum practitioner with educational

and research background in agile and Scrum. The

interview lasted 45 minutes. After the pilot test,

interview protocol was revised and finalized.

In the third step the interviews were conducted

among various role titles (Table 1). Size of the

organizations ranged from Medium (<250

employees) to Large (>250 employees). Out of seven

contacted organizations known to use agile, five

claimed of using Scrum. Response rate was high. Five

out of five contacted organizations agreed on letting

us study the methodology of their organization.

Table 1: Distribution of roles.

Role title Interviews

Scrum Master 8

Developer 11

Manager 1

Project Manager 2

The interviews that were conducted over a span of 6

months, generated very useful data related to Scrum

Investigating the Gap between Scrum Theory and Practice in Pakistan

181

practice. A number of deviations were revealed which

were categorized into different standard Scrum

practices in the Scrum guides. Cross-questioning was

done to reveal causes of deviation. The interview data

was analyzed again to find out the causes of identified

deviations. Root cause analysis (Williams, 2001) was

performed to dig deeper into deviation reasoning so

that guidelines could be formulated. Once the

guidelines were established, they were validated by a

Focus group (Krueger, 2014) of experts. Bulletin

board format of online focus group was chosen. Focus

group revealed a few changes in the proposed

solution hence the proposed solution was revised in

the light of expert guidance

4 ANALYSIS AND RESULTS

4.1 Deviation from Scrum Theory

The deviations were revealed via Thematic Network

Analysis (Gill, 2015). Data from primary studies such

as interviews consists of numerous concepts that need

some refinement and restructuring to answer the

research question. Thematic network analysis serves

this purpose. It is a detailed step-by-step process: The

first step of thematic network analysis consists of

identifying category codes. A category code is a

suitable name that represents a set of related concepts

in interview text. The purpose of this step is group

concepts into manageable chunks on basis of which a

thematic network can be established. Then we look

for basic, organizing and global themes in the

underlying knowledge.

Second step is development of thematic network

based on concepts in each category. Thematic

network consists of themes at three levels. Lowest

level theme is basic theme that groups concepts under

a concept category at lowest level. A set of basic

themes is further grouped into an organizing theme

and finally a set of organizing themes are grouped

into a global theme which is the highest-level theme.

This way a network of themes is developed by

analysis concepts repeatedly (Figure 1).

Since interview protocol was designed using

Scrum guide, it rendered the first step very easy as 11

category codes were recognized right away consisting

of main Scrum practices. Three of these category

codes representing deviation from Scrum roles of

Scrum Master, Product Owner and development

team, three representing deviations from Scrum

artifacts of Product Backlog, Sprint backlog and

Increment, one representing deviation from the Sprint

Figure 1: Thematic network analysis.

Table 2: Deviation from Scrum theory.

Deviation Frequency Percentage

Role specific titles for

Development team members

18 73%

Development Team is not

self-organizing

15 68%

Progress not monitored 13 59%

Definition of Done not used 13 59%

Development Team is not

cross-functional

13 59%

Sprint retrospective not held 11 50%

Product Owner does not exist 10 45%

Scrum Master is partial

Product Owner

10 45%

Estimation is not performed

by the Development Team

8 36%

Sprint Review not held 8 36%

Product Backlog not used 7 32%

Sprint Backlog not used 7 32%

Requirements are signed off 7 32%

Daily Scrum not held 6 27%

Scrum Master is not called

Scrum Master

6 27%

Scrum Master does not exist 2 9%

Product not developed in

Sprints

2 9%

ICSOFT 2020 - 15th International Conference on Software Technologies

182

and three representing deviations from Scrum events

of Sprint Planning, Sprint Review and Daily Scrum.

One category of additional practices was identified

from interview data. 35 concepts were then found

related to the identified category codes. Then these 35

concepts were reduced to 17 basic themes i.e. the

deviations practiced. The thematic network analysis

was only used till this step as it served its purpose.

The most common deviation found was the use of

“Role specific titles for Development Team

members”, This deviation is practiced by 18 out of 22

teams interviewed. This practice is closely followed

by “Team is not self-organizing” deviation occurring

in 15 out of 22 cases. Other notable deviations

observed include “Product Owner does not exist”,

“Definition of Done not used”, “Development Team

is not cross-functional” (Table 2).

4.2 Causes of Deviation

Once deviation was identified in Scrum theory, the

interview data was reanalyzed to identify causes of

those deviation. Follow-up questions were asked

from interviewees via email when needed. Once the

causes of each deviation were identified Root Cause

Analysis (RCA) (Williams, 2001) was performed.

RCA is used to get deeper insight into the problem at

hand so that solution can be identified. More

specifically 5-Why Analysis (Williams, 2001)

technique of RCA was used as causes were identifies

via interviews. 5-Why Analysis is a Six Sigma

technique in which why to a cause is recurrently

asked until the root cause is reached. An Excel tool

perform 5 why analysis (Figure 2).

Figure 2: 5-Why analysis.

To have a clearer picture of root cause analysis

RAWGraphs tool was used (Figure 3). Thickness of

the lines represent how frequently certain root cause

occurs for a deviation.

Figure 3: RCA Visual.

4.3 Proposed Guidelines

A set of guidelines was devised to lessen the noted

gap. The source of guidelines included literary best

practices, interviewed teams that complied with

Scrum and literary articles. The guidelines consisted

of three phases namely, process preparation, process

commencement and process propagation (Figure 4).

Figure 4: Solution Phases.

4.3.1 Investing in the Process

Only 32% of the Scrum masters among the

interviewed teams actually claimed to receive formal

Scrum training thus indicating reluctance from the

management end to invest in the process.

Management Persuasion

Approval by upper management is critical to fund any

trainings. Convincing them by highlighting benefits

of process investment (Hajjdiab, 2011) along with a

thorough introduction to methodology could be

promising.

Process

Preparation

Process

Commencement

Process

Propagation

Investigating the Gap between Scrum Theory and Practice in Pakistan

183

Reducing Work Pressure for Dedicated Scrum

Implementation

Resources are so dedicated to the operational work

and fire fighting that they cannot be trained on the

process. Investment of more time in agile adoption by

reducing the workload for a bit as Scrum

implementation cannot be rushed and it must be

precewded by an organizational change.

Strategic Planning

The main root cause of deviation being the lack of

strategic planning prior to the adoption of the method.

Choosing work best for them is up to the

organization. Haque et al. (Haque, 2008) chose to

introduce Scrum incrementally. Play Zero

(Leffingwell, 2005) is a series of steps recommended

by Ken Schwaber that are to be undertaken before

method commencement. It has two stages. First one

being overview and assessment (Figure 5) and second

being pilot preparation.

Figure 5: Play Zero - Stage 1.

Figure 6: Play Zero – Stage 2.

Customer Involvement

The core of agile is customer involvement. 50% of the

customer to get hand on with the project. Ambiguous

requirements lead to rework and other issues.

“When these people [customers] are not there,

actually see the product after a few sprints, cause

problems as they don’t have the complete

picture.”

Mainly, the customers merely don’t see the point

of being involved with the development out-and-out.

Agile teams (Hoda, 2011) deal with these issues with

the following contingencies

a. Selling Advantages

Holding sessions with customers who are

unwilling to collaborate to begin with might persuade

them to change their minds. Once idea of agile clicks,

they might be willing to get a little more involved.

b. Changing Requirement Priority

Due to the lack of customer involvement,

sometimes the team makes assumptions about

requirements thus creating features that the customer

did not want. A counteractive strategy is to change the

priority of ambiguous features awaiting clarification

and build features that have more distinct

specification.

c. Customer Proxy

When the customer is collaborating but is

reluctant to wear the hat of PO, a customer proxy can

be appointed. Duties include requirement

clarification and eliciting feedback.

d. Frequent Demonstration

One way to ensure involvement of a disinclined

customer is to create more frequent demos thus

achieving customer collaboration to some extent.

4.3.2 Process Commencement

Conducting Pilot(s)

Conducting a pilot before organization-wide

expansion should be mandated to test the waters

(Hajjdiab, 2011). Pilot should be chosen keeping

these things in mind:

a. The pilot should span around the middle of

average length of projects conducted

b. It should be small enough to be doable by

one team

c. It should not be a critical project

Once conducted, pilot should be assessed and

adjusted. Retrospect to assess impediments,

improvements and ROI.

Organizational Expansion

At this stage, the outcome of the pilot(s) should be

made available to everyone in the organization.

Initiation of many development projects is started

based on the outcome. There are values that need to

• ScrumMasterare

trainedforgettingthe

pilotscarriedout

Trainingofthe

ScrumMasters

• ProductOwnersare

trainedformaximizing

ReturnonInvestment

Trainingofthe

ProductOwners

• EstablishProduct

Backlogfortracingand

evaluating

organizational

impedimentstopilots

ChangePB

Establishment

• Informmanagementof

changepreceeding

Scrumandassesstheir

willingnesstoproceed

Aptitude

Assessment

• Evaluatethereadiness

oftheorganizationand

decidenextsteps

Readiness

Assessment

• Identifyandresource

thepilotsandSchedule

trainings

Further

Planning

ICSOFT 2020 - 15th International Conference on Software Technologies

184

be established for Scrum to flourish, which like all

good things takes time and effort.

From Bureaucracy to Autonomy

Expecting organizational culture to change overnight

from current ‘command and control’ to the flat

management is not the solution. The remedy to this

problem (Moe, 2009) is team autonomy. Chung et. al

(Chung, 2009) have presented a scenario in which a

Scrum team at Yahoo managed to thrive in

predominantly command and control culture. With

the right guidance, this can be achieved over time.

Handling Distribution

Scrum in distributed environments needs proper

collaboration tool. Currently 75% of the distributed

teams use emails for collaboration. There is no central

repository of data for transparency to prevail.

Distributed environment is not ideal but is still doable

as demonstrated by Rayhan et al. (Rayhan, 2008)

where Basecamp is used to handle distribution. Team

J and K who have PO residing abroad are using TFS.

85% of the teams have issues due to time zone

differences. Team J and K have resolved this by

changing their work hours to the team that resides at

another continent thus resolving this time zone issue

created by distribution.

4.3.3 Process Propagation

Method Assessment and Retrospective

Measuring progress with Scrum vs other projects

might help organizations realize what suits them best

(Rayhan, 2008). Scrum enables self-improvement to

the method in itself by highlighting what needs to be

changed for Scrum to flourish. The key is to use

Scrum as a process for implementation and scaling of

Scrum in the organization. Method retrospective by a

highly trained and skilled Scrum Master is the key to

this all.

Handling Smells over Time

A Smell is an issue that arises as an indicator of not

following the method correctly. A skilled Scrum

Master promptly addresses the issue by investigating

what’s the real cause. Interviewed teams

predominantly feel overwhelmed by using the

method as mostly Scrum is pushed upon them and the

teams are not internally motivated causing smells.

One suggestion would be the use of continuous

learning tools such as Agile Meeting Cube which

provide teams with why of each practice in depth.

Another suggestion would be to have more studies

like this in the future and make the deviation

drawbacks as known to the organizations that are

practicing or rather mal-practicing the method.

4.3.4 Guideline-Root Cause Relationship

Although guidelines were designed to be systematic,

certain clauses specifically target particular root

causes (Table 3).

Table 3: Guidelines and targeted root causes.

Guideline Clause Targeted Root Cause

Management persuasion

Unsupportive

Management

Reducing work pressure for

dedicated Scrum adoption

Operational workload

Introducing the Play Zero

Insufficient strategic

planning

Removal of stringency in roles Specialist culture

From bureaucracy to

autonomy

Bureaucratic

management system

 Selling Advantages

 Customer proxy

Frequent

demonstration

 Pay for collaboration

 Change requirement

riority

Unmotivated customer

Making continuous learning

tools available

Scrum involves

overhead

 Tool support

 Synchronizing work

hours

Distributed

environment

5 CONCLUSION

Significant deviation exits between theory and

practice of Scrum. The revealed gap highlights that

there is need for educating people on Scrum. Also

there is a need for a cultural shift that promotes flat

management over a hierarchy.

The study helps fill the gap to some extent as

illustrated by guideline-root cause relationship.

Availability of tools that facilitate employee learning

on the method within the practicing organizations will

help the matter significantly. Shift in management

mindset is crucial which will facilitate removal of

stringency in roles and bureaucratic management

Investigating the Gap between Scrum Theory and Practice in Pakistan

185

system which are seemingly the biggest barriers to

implementation accuracy. The next part of the

research constitutes implementation of the guidelines

in SEMAT as means of standardization. The research

continues further and validates the solution by field

experts by means of a Focus Group discussion.

ACKNOWLEDGEMENTS

We would like to express gratitude to all the people

involved in the interview process via personal

connections and LinkedIn.

REFERENCES

Schwaber, Ken, & Jeff Sutherland (2011) “The Scrum

Guide – The Definitive Guide to Scrum: The Rules of

the Game,” http://www.scrum.org/Scrum- Guides, last

access: 2014-06-14.

Version One, (2009) “Fourth Annual Survey on The State

of Agile Development”,

Gill, Asif, Deborah Bunker, & Philip Seltsikas. (2015)

"Moving Forward: Emerging Themes in Financial

Services Technologies’ Adoption." Communications of

the Association for Information Systems, vol. 36, No. 1

Sverrisdottir, H. S., Ingason, H. T., & Jonasson, H. I. (2014)

"The role of the product owner in Scrum-comparison

between theory and practices." 27th IPMA World

Congress, Dubrovnik, Croatia.

Salo, O., & Abrahamsson, P. (2008). "Agile methods in

European embedded software development

organisations: a survey on the actual use and usefulness

of Extreme Programming and Scrum." Software, IET

software 2, No. 1, pp 58-64.

Kurapati, N., Manyam, V. S. C., & Petersen, K. (2012)

"Agile software development practice adoption

survey." Agile Processes in Software Engineering and

Extreme Programming, Springer, Berlin Heidelberg, pp

16-30.

Zieris, F. and Salinger, S., (2013) "Doing Scrum Rather

Than Being Agile: A Case Study on Actual

Nearshoring Practices." 8th International Conference

on Global Software Engineering (ICGSE), IEEE. pp.

144-153.

Bass, Julian M. (2012) "Influences on agile practice

tailoring in enterprise software development." 2012

Agile India. IEEE. pp. 1-9.

Eloranta, Veli-Pekka, (2013). "Scrum Anti-Patterns--An

Empirical Study." Software Engineering Conference

(APSEC), 20th Asia-Pacific, Vol. 1, IEEE.

Fernandes, J.M. & Almeida, M. (2010) “Classification and

comparison of agile methods” In Seventh International

Conference on the Quality of Information and

Communications Technology (QUATIC), IEEE. pp.

391-396.

Overhage, S. & Schlauderer, S., (2012) “Investigating the

long-term acceptance of agile methodologies: An

empirical study of developer perceptions in scrum

projects.” In 45th hawaii international conference on

System science (hicss), IEEE, pp. 5452-5461.

Ovesen, Nis. (2015) "Pragmatic Team Compositions in

Scrum-Based Development Projects." The 20th

International Conference on Engineering Design.

Williams, P.M., (2001). “Techniques for root cause

analysis”. Baylor University Medical Center

proceedings, Vol. 14, No. 2, pp.154-157.

http://rawgraphs.io/

Krueger, R.A. & Casey, M.A. (2014) “Focus groups: A

practical guide for applied research” Sage publications.

Jacob, Stacy A., & S. Paige Furgerson. (2012) "Writing

interview protocols and conducting interviews: Tips for

students new to the field of qualitative research." The

Qualitative Report 17, No. 42, pp. 1-10.

http://www.bulsuk.com/2009/07/5-why-analysis-using-

table.html

Hoda, Rashina, James Noble, & Stuart Marshall. (2011)

"The impact of inadequate customer collaboration on

self-organizing Agile teams." Information and Software

Technology 53.5, pp 521-534.

Hajjdiab H & Taleb AS (2011) “Agile adoption experience:

A case study in the UAE” In 2nd International

Conference on Software Engineering and Service

Science (ICSESS), 2011 IEEE, pp. 31-34.

Rayhan SH & Haque N., (2008) “Incremental adoption of

Scrum for successful delivery of an IT project in a

remote setup.” In Agile Conference 2008l AGILE'08,

IEEE, pp. 351-355.

Leffingwell D & Smits H., (2005) “A CIO’s playbook for

adopting the scrum method of achieving software

agility.” Technical report, Rally Software Development

Corporation and Ken Schwaber-Scrum Alliance.

Chung MW & Drummond B., (2009) “Agile at yahoo! from

the trenches.” In Agile Conference, 2009, AGILE'09,

IEEE, pp.113-118

Moe, N. B., Dingsøyr, T., & Dybå, T., (2009) “Overcoming

barriers to self-management in software teams.” IEEE

software 26.6, pp.20-26.

ICSOFT 2020 - 15th International Conference on Software Technologies

186