See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/358199804

A Systematic Literature Review on LSD

Article · January 2022

CITATIONS READS

0 48

1 author:

Amreen Ayesha
Presidency University, Bangalore
7 PUBLICATIONS   0 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Amreen Ayesha on 29 January 2022.

The user has requested enhancement of the downloaded file.

 Journal of Advance Research in Mobile Computing
Volume 1 Issue 1

A Systematic Literature Review on LSD

Amreen Ayesha
Assistant Professor, Presidency University, Bengaluru
*Corresponding Author
Email ID:-ayesha1.success@gmail.com

ABSTRACT
Lean development has been frequently proposed as an adjustment to agile for
scaling-up to bigger settings. Objectives: we needed to all the more likely
comprehend the "agile-to-lean" transformation, as far as: I) detailed advantages,
ii) challenges confronted, iii) metrics utilized. Technique: we played out a
Systematic Literature Review (SLR) about "agile-to-lean" changes. Results:
decreased lead time, improved stream, nonstop improvement, and improved
imperfection fix rate were the fundamental announced advantages. Adjustment to
lean reasoning, showing the lean outlook, ID of the idea of waste, and scaling
adaptability were the principle challenges. Lead time was the most revealed
measurement.
Keywords:-Software, Mobile, Techniques, SLR

INTRODUCTION actualize and receive agile development

Now a days, numerous software associations
utilize agile systems for their software
development forms, discovering benefits for
procedure improvement [1-3]. Lean delicate
product development [4] has been utilized to
streamline development forms, for the most
part because of the idea of waste decrease
involved in the improvement of all exercises
creating inefficiencies [4]. This view is
corresponding to agile standards, more
concentrated on all exercises that make an
incentive for the client.
The term lean software development began
from crafted by Mary and Tom
Poppendieck [4]. Lean software
development can be portrayed as a blend of
lean assembling with the lean IT standards
and their application into software
development [5]. This methodology is
driven by a progression of seven standards:
dispose of waste, choose as late as would be
prudent, intensify learning, convey as quick
as could be expected under the
circumstances, engage the group, fabricate
respectability in, and see the entire [4,5].
Numerous creators recommend that lean
reasoning can be utilized as core values to
rehearses [4]. Wang [1] has distinguished
and investigated different mixes of lean and
agile as revealed by past re-look: lean
standards can either be utilized to adjust
existing agile practices or to scale-up the
agile software development rehearses [1].
Notwithstanding, there is no widespread
sort of "agile-lean" mix that can be utilized
for each circumstance [1].
The objective of this paper is to recognize
advantages, difficulties, and measurements
utilized in "agile-to-lean" changes.
Recognizable proof of such factors can
permit to more readily comprehend "agile-
to-lean" changes, giving more proof about
how such change is occurring.
SLR
A Systematic Literature Review (SLR) is a
procedure which condenses, sorts out, and
archives past research of a field in a
methodical manner [6]. To lead the audit on
"agile-to-lean" changes, we pursued the
SLR rules by Kitchenham and Charters [6].
A.Needs for a SLR
"Agile-to-lean" is a less investigated
research zone contrasted with "cascade to-

HBRP Publication Page 1-10 2019. All Rights Reserved Page 1

 Journal of Advance Research in Mobile Computing
agile" (e.g., Middleton [7]). There are
different SLRs performed on lean
approachs yet they are centered either at the
business level [8], or at the dimension of
measurements utilized in lean/agile
software extends inside industry [9]. One
writing audit on the "agile-to-lean" change
[10], concentrated on ordering and looking
at the changes including 30 experience
reports. Contrasted with the examination by
Wang et al. [10], our examination is
increasingly centered around advantages,
difficulties and measurements.
B.Research questions
RQ1. What are the advantages that have
been accounted for after the selection of
lean standards with regards to a progressing
agile development process?
RQ2. What are the difficulties that have
been accounted for after the reception of
lean standards with regards to a progressing
agile development process?
RQ3. Which measurements have been
utilized to quantify the "agile-to-lean"
change?
C.Search system and study determination
We have gathered research papers
accessible online in three computerized
stores: Web of Science (WoS), IEEExplore,
ACM Digital Library (DL) (on 2017-06-10,
Figure 1). We utilized "lean software
development OR agile change OR lean
Fig.1:-SLR papers selection process.
Study quality assessment criteria
After 18 papers were selected (Table I), we
have conducted a quality assessment
process to select the papers fitting the
exact purpose of this research:
HBRP Publication Page 1-10 2019. All Rights Reserved
Volume 1 Issue 1
trans-arrangement" as inquiry string, as we
wanted to begin with a progressively broad
question and channel out outcomes later.
The primary phase of hunt procedure
(robotized look in online databases)
included just examinations written in
English. The EndNote reference
administrator software was utilized for
barring copies and narrowing down the
underlying list items from 1,787 to 856
research papers (Figure 1). We have
included diaries and meeting papers
distributed since 2003, after crafted by
Mary and Tom Poppendieck [4].
In the second stage (separating dependent
on title and unique), various inquiry criteria
have been connected, for example, the
rejection of papers that included lean
assembling or some other branches of
knowledge outside software building. An
aggregate of 131 papers have passed the
second phase of the inquiry technique
(Figure 1).
Stage three (full-content separating) was
performed physically experiencing the rest
of the sections. 18 papers were incorporated
dependent on full content perusing. Quality
criteria (area II-D) were connected to
discover papers including hierarchical
change from agile to lean. After quality
evaluation, a sum of 8 papers were
incorporated into the last SLR list (Figure
1).
C1. Is the agile methodology at the initial
state of the transformation?
C2. Is the reported company making a
transformation towards lean software
development practices?
Page 2
 Journal of Advance Research in Mobile Computing
Volume 1 Issue 1

C3. Does the paper provide metrics used
for the transformation and states clear
outcomes?
Papers were given points from 0 (meaning
”no”), 0.5 (”partly”) to 1 (”yes”). All
papers reaching the score marked as ≥ 2.5
for sum(C1, C2, C3) (Table I) were
included for conducting the literature
review (Table II).

Table.1:-Quality assessment of the selected papers.

SLR Article C1 C2 C3 Score
S1 Hayata et al. [11] yes no no 1.0
S2 Jakobsen and Poppendieck [12] yes yes yes 3.0
S3 Kuusela and Koivuluoma [13] yes partly no 1.5
S4 Middleton and Joyce [2] yes yes yes 3.0
S5 Misaghi and Bosnic [14] yes yes yes 3.0
S6 Paasivaara et al. [15] no yes yes 2.0
S7 Perera and Fernando [16] yes yes yes 3.0
S8 Petersen and Wohlin [17] yes yes yes 3.0
S9 Rodr´ıguez et al. [18] no yes yes 2.0
S10 Rodr´ıguez et al.[19] yes yes yes 3.0
S11 Samanta et al. [20] - yes yes 2.0
S12 Schnitter and Mackert [21] yes partly partly 2.0
S13 Sjøberg et al. [22] yes no partly 1.5
S14 Swaminathan and Jain [23] yes yes yes 3.0
S15 Trimble and Webster [24] no yes no 1.0
S16 Vilkki [25] no yes no 1.0
S17 Viswanath [26] no yes yes 2.0
S18 Walter et al. [27] yes yes partly2.5

SLR RESULTS was accounted for in four cases [12,19,23,27].

A. Benefits (RQ1)
To respond to our first research question we
have checked on and classified the revealed
advantages.
1) Reduced lead time: The most well-
known advantage that has been accounted for is
diminished lead time as it was found in six
examinations [2,16-19,23,27]. Middleton and
Joyce [2] depict lead time as the all out time
recorded from a client solicitation to the
finished work conveyance. Decreasing lead
times adds to stream improvement with the
goal that exercises are sorted out persistently,
empowering smooth conveyances to the client.
Middleton and Joyce [2] additionally express
that they have encountered 47% less change
and by and large 37% shorter lead time to
convey software, which is a critical
improvement. Also, Walter et al. [27] have
recorded an upgrade of roughly 70% which can
significantly expand an opportunity to-
showcase responsiveness. Early input from the
client infers visit combination, a critical factor
to improve the software item quality.
2) Improved stream: Improved stream
Walter et al. [27] have found that the key to
improve the stream is to control Work-in-
Progress (WiP) things. By diminishing the
quantity of synchronous errands they have
achieved lean stream state with steady
throughput. Stream can be viewed as the
quantity of WiP things, with the goal that
bringing down the quantity of such things can
accelerate the entire procedure and more
highlights can be actualized and in the long run
conveyed. Along these lines, to accelerate the
stream, it is basic to evacuate squander in the
stock to abstain from heaping up client stories.
Rodr'ıguez et al. [19], Middleton and Joyce [2]
express that constraining WiP is an imperative
component for accomplishing stream.
Constrained WiP prompts progressively
composed exercises with the goal that the
improved stream can prompt smooth
conveyances [19]. Moreover, persistent mix
and test robotization essentially sup-ported the
stream by successive and littler forms [19]. As
per Swaminathan and Jain [23], following and
following up on the visual markers given by the
aggregate stream outline kept up a uniform

HBRP Publication Page 1-10 2019. All Rights Reserved Page 3

 Journal of Advance Research in Mobile Computing
Volume 1 Issue 1

stream. Additionally, it likewise recognized and
evacuate bottlenecks and improve the
productivity of the procedure. This expansion
in effectiveness likewise upheld quick
development and constant improvement to
software conveyance [23]. Jakobsen and
Poppendieck [12] have improved the
progression of story usage from 30% to 60%.
The stream was improved in different regions,
for example, test, development, venture start-up
and client exercises identified with contracting
and continuous elucidations, significant
advantages for the organization.
3) Continuous improvement: Four
investigations [2], [12], [23], [27] experienced
constant improvement as an advantage of their
change. In Swaminathan and Jain [23], the
story rate per emphasis was utilized as a
measurement to quantify constant im-
provement, which was demonstrated by the
proof of cumulating story focuses. Then again,
the reason for the consistent improvement in
Walter et al. [27] was set up by giving each
group self-a chance to sort out and set their own
WiP measure. Ceaseless improvement
completed consistently demonstrated a huge
increment in the software conveyance pre-

Table.2:-Primary studies linked to the references with country and domain of the case
study/experiment.
Paper Reference Domain Type Year Country
ID
S2 Jakobsen andSoftware company: complex and critical IT solutions case study 2005 Denmark
Poppendieck [12]
S4 Middleton and JoyceWebmedia department software processes case study 2009 UK
[2]
S5 Misaghi and BosnicSoftware company: leading supplier of systems for thecase study 2011 Brazil
[14] supply chain
S7 Perera and FernandoStudents groups during len-to-agile transformation experiment 2007 Sri
[16] Lanka
S8 Petersen and WohlinLarge provider of ICT to service providers case study 2009 Sweden
[17]
S10 Rodr´ıguez et al. [19] Wireless Embedded Systems case study 2010 Finland
S14 Swaminathan and JainMultinational IT consulting organization case study 2012 India
[23]
S18 Walter et al. [27] Software development for big telecommunication case study 2015 Brazil
companies

B. Dictability [2]. In addition, information encountered a lower measure of bugs. As

gathered over an a year duration
demonstrated huge improvement as the
time taken to determine issues was
diminished by 81%.
C. 1) Improved deformity fix rate:
Adopting lean standards to a progressing
agile procedure has reflected in improved
imperfection fix rate in five papers
[2,12,14,16,27]. Lean advances finding and
fixing abandons early, so there is a superior
and command over quality from the earliest
starting point. In this manner, constant
reconciliation apparatuses are frequently
generally utilized in lean software
development worldview. Middleton and
Joyce [2] not just figured out how to fix
issues in a shorter period, yet additionally
the bug rate diminished, the group
possessed apparently more energy for
finishing client stories. Better item quality
was accounted for by Misaghi and Bosnic
[14] with the decrease of time spent on bug
fixing. Like the examination by Middleton
and Joyce [2], less blunders were
discharged as a result of the higher measure
of time for new highlights and upgrades
[14]. Another example of overcoming
adversity of upgraded software quality has
been accomplished with half bug decrease
as announced by Walter et al. [27]. Two test
bunches for estimating imperfection rate
had been seen amid the analysis by Perera
and Fernando [16]. One gathering
embraced the mix of lean and agile, the

HBRP Publication Page 1-10 2019. All Rights Reserved Page 4

 Journal of Advance Research in Mobile Computing
other one simply unadulterated agile
strategy. The unadulterated agile gathering
encountered a lower measure of deformities
toward the start. In any case, this
circumstance swapped at later stages and
the lean-agile example had a negligible
deformities rate [16]. A higher number of
imperfections for the agile gathering was
Fig.3:-Challenges mapped to papers. O = metric reported in the paper
An "agile-to-lean" change brings a
progression of challenges. Keeping up
procedure perceivability, overseeing
sustainability, and correspondence among
groups are seen regularly as key challenges
[5]. The improvement of the testing
procedure is additionally announced as a
key test, as the driving standard is
perfectionism and recognizable proof of
main drivers for software absconds [5]. All
things considered, putting lean over agile
conveys much more significance to the
testing procedure. Gaining the best possible
outlook can be viewed as a test in lean
appropriation [14], [20], as lean requires an
alternate mentality contrasted with the
utilization of unadulterated agile practices.
Another test of "agile-to-lean" is to
incorporate the ideas of waste minimization
and quality enhancements that are a piece
of the lean rationality, conveying to a
progressively total development and the
board procedure [16]. Lean over agile
brings more the attention on the start to
finish esteem stream of the entire
development process, hence putting loads
of accentuation on various apparatuses and
their help, similar to esteem stream
HBRP Publication Page 1-10 2019. All Rights Reserved
Volume 1 Issue 1
likely because of unfixed shrouded
absconds at the beginning times.
D. Challenges (RQ2)
In general, it was difficult to extract
information about the challenges from the
papers (RQ2, Figure 3), as
controversial/negative aspects might be
omitted from papers.
mapping or Kanban [17]. Consistent
administration of stream is likewise an
applicable issue [27], together with
structure a lean outlook towards
imperfections decrease [23]. Scaling
adaptability, business the executives
inclusion and waste decrease were found as
difficulties, with scaling adaptability risky
because of the administration of the entire
esteem spilling, making adaptability
progressively hard to reach [19].
1) Adapting to the Lean Mindset: all
in all, protection from change is a typical
issue when attempting to embrace better
approaches for working. This was the
situation in the audited contemplates [14],
[17], [19], [23], [27]. Consequently, getting
the promise to this new worldview is
required from the long-term viewpoint as it
is a nonstop procedure that should be
upheld. Misaghi and Bosnic [14] express
that characterizing the criteria to execute
the "lean mentality" into the association is a
primary test. Then again, despite the fact
that there are some intense difficulties
toward the start to get the group to think
start to finish and work in another manner,
Page 5

when the group begins to see the additional
esteem, such way turns out to be normally
acknowledged inside the group [23].
2) Identification of "genuine waste":
Waste decrease is the key rule to keep up
when working with a lean attitude.
Rodr'ıguez et al. [19], Walter et al. [27]
found that it very well may be difficult to
distinguish "what a genuine waste is" inside
the association and it might be much all the
more testing to wipe out such waste.
Despite the fact that setting-up groups and
building up self-association inside groups
have not been difficult to accomplish,
scaling adaptability and contribution of
business the executives undertakings were
considerably more testing in the lean
method for working [14]. Viewpoints like
individuals performing various tasks, which
may appear at first suitable to be
increasingly effective, can likewise be
viewed as a loss as they may be the
significant reason hindering profitability
[14].
3) Iteration-related difficulties:
Studies have confronted challenges
additionally with training, gauges, pair
programming, all amid the keep running of
development cycles [27]. In Walter et al.
Fig.4:-Metrics mapped to papers. O = metric reported in the paper
Five examinations [2,12,14,17,19] have
utilized lead time as one of the
measurements to gauge the advancement of
HBRP Publication Page 1-10 2019. All Rights Reserved
Journal of Advance Research in Mobile Computing
Volume 1 Issue 1
[27], group mentors experienced issues to
guarantee that assignments were conveyed
on schedule and with quality. Thus, the
instructing procedure received some
progressively noticeable markers (physical
banners). Development of pair
programming couples and cycle
estimations were adjusted to the
requirements of the genius cess [27]. In
Rodr'ıguez et al. [19], groups grumbled
about too long input circles, brought about
by the contribution of business the board in
the entire esteem stream mapping process.
4) Scaling Flexibility: Scaling
adaptability was characterized as the
effectiveness of performing changes amid
the software create ment process and was
found as one of the key difficulties in
Rodr'ıguez et al. [19]. The issue in "agile-
to-lean" is that flex-ibility needs to go
through the entire esteem stream, making
the procedure more mind boggling than in
unadulterated agile settings [19].
E. Metrics (RQ3)
To answer our third research question
(RQ3, Figure 4), we have reviewed and
categorized findings of metrics that have
been used to measure the lean
transformation.
their hierarchical change. As we have
depicted ear-lier (Section III-An about the
advantages), lead time speaks to the length
Page 6
 Journal of Advance Research in Mobile Computing
from the client demand until the time the
item is transported to the client. Lead time
is typically estimated in working days and
it is halted when client acknowledgment
testing is finished and the item is prepared
for discharge [2]. Petersen and Wohlin [17]
accomplished higher responsiveness to
client needs by methods for diminished lead
time, figuring out how to diminish time for
conveyance. Petersen and Wohlin [17]
guarantee that this measurement is
profoundly imperative as the client
regularly needs visit changes. The capacity
to react to these progressions rapidly is an
incredible upper hand. Alongside this
measurement, Middleton and Joyce [2]
revealed utilizing likewise process
duration, that can be considered as a sub-
estimation of lead time. Process duration is
the time from genuine inception of the
element development (beginning of the
taking a shot at the thing) until the work on
the component is finished.
2) Number of imperfections: The
quantity of deformities per given timeframe
was utilized as a measurement in two
investigations [2], [16]. The principle focal
point of Perera and Fernando [16] was on
limiting the quantity of deformities. In any
case, this investigation calls attention to that
higher number of deformities at the
beginning periods is normal, as portrayed in
area III-A4. Thusly, number of deformities
should be estimated in view of quite a while
viewpoint. Middleton and Joyce [2] were
estimating the quantity of deformities every
week for a year timespan. The mean
quantities of bugs open every seven day
stretch of their issue following framework
declined [2].
3) Fix time for deformity: Similarly to
the past measurement, two different
examinations [12], [14] inspected deserts
from the fixing time point of view. Misaghi
and Bosnic [14] have seen that, as the time
spent on growing new highlights expanded,
the time spent on bug fixing diminished.
HBRP Publication Page 1-10 2019. All Rights Reserved
Volume 1 Issue 1
The general nature of the item improved as
the discharges contained less imperfections
[14]. Estimations have been watched for the
time of one year, that demonstrates the
positive long haul impact of lean.
4) Velocity: We have discovered this
measurement in four examinations [12],
[16], [19], [27]. Speed can be estimated by
separating the normal time of errand
fulfillment by the genuine time the
undertaking has been shut. Walter et al. [27]
have improved their speed by classifying
the time gauges utilizing diverse sizes
(additional little, little, medium, enormous,
additional huge). The quantity of hours was
assessed dependent on their verifiable
qualities and added to every classification
[27]. In Jakobsen and Poppendieck [12],
speed was estimated as a sub-stream for
story usage, guaranteeing that the accounts
were created in a smooth stream, killing the
waste related with setting movements and
hand-overs. To confirm whether the
venture is accomplishing the objectives
identified with its timetable, expected work
and genuine work lev-els were additionally
utilized by Perera and Fernando [16]. Be
that as it may, this time the measurement
was marginally adjusted by separating the
difference among real and expected work
level with the normal work level [16].
5) Lines of code: Two examinations
[16], [17] have been measuring lean
execution by assessing the quantity of Lines
of Code (LoC) created. The result of the
investigation by Perera and Fernando [16]
was that the half breed lean-agile
methodology delivered more LoCs. Perera
and Fernando [16] assessed this
measurement from different points of view,
for example, new LoCs, expelled LoCs and
changed LoCs. Then again, Petersen and
Wohlin [17] utilized this measurement in a
marginally extraordinary manner, by
estimating esteem proficiency: the contrast
between the estimation of yield and
estimation of contribution inside a given
Page 7
 Journal of Advance Research in Mobile Computing
time span [17].
6) Story rate per cycle: Customer
necessities are caught as client stories,
which are a short time later evaluated and
organized [28]. For imagining the long haul
impact with this measurement, information
have been shown for the most part in story
stream outlines and aggregate story stream
graphs to gauge consistent improvement
from the long-term perspective, which
additionally distinguished the heaping up of
stock [23]. Contingent upon the time
committed to development, every story was
given a story point esteem talked about and
dealt with by the designers of the group.
More often than not, designers were
evaluating the story estimate as little and
even, to all the more likely structure their
work. Swaminathan and Jain [23] estimated
story rate per emphasis as the absolute
number of story focuses affirmed and shut
by the client in the given cycle. The
progression of necessities through the
software development life-cycles was the
key point additionally in Petersen and
Wohlin [17]. In any case, this investigation
was estimating hand-overs inside the
accounts just as the difference, to more
readily foresee the development cycle [17].
7) Release recurrence: The main
investigation which utilized the quantity of
discharges was Middleton and Joyce [2],
characterizing it as the quantity of things
discharged to clients. Time span for
estimating the recurrence of discharges was
set to one month. Despite the fact that this
measurement does not uncover how much
esteem is being conveyed to the clients, it
demonstrated an eight-overlap increment in
discharges for a two years time frame [2].
This is demonstrating an improvement in
setup the executives order and ability [2], as
the more incessant discharges are lessening
specialized and showcase dangers, as the
client can assess a genuine item in littler
augmentations as opposed to simply seeing
impermanent outcomes from improvement
HBRP Publication Page 1-10 2019. All Rights Reserved
Volume 1 Issue 1
reports.
CONCLUSION
The objective of this paper was to all the
more likely comprehend the "agile-to-lean"
change process in regards to advantages,
difficulties, and measurements that
essential examinations detailed in changes
inside organizations. To achieve the
objective, we led a Sys-tematic Literature
Review (SLR) [6]. The most spoken to
benefits were diminished lead time,
improved stream, consistent improvement
and improved imperfection fix rate.
Looking for the chal-lenges confronted, the
regular issues were the adjustment to the
lean attitude, instructing and keeping up the
"lean outlook", keeping up development
adaptability, and the distinguishing proof of
the idea of waste. The most utilized
measurement to gauge a lean change was
lead time.
REFERENCES
1. X. Wang, “The combination of agile
and lean in software development:
An experience report analysis,” in
2011 Agile Conference, Conference
Proceedings. doi:
10.1109/AGILE.2011.36 pp. 1–9.
2. P. Middleton and D. Joyce, “Lean
software management: Bbc
worldwide case study,” IEEE
Transactions on Engineering
Management, vol. 59, no. 1, pp. 20–
32, 2012. doi:
10.1109/TEM.2010.2081675
3. M. Kalenda, P. Hyna, and B. Rossi,
“Scaling agile in large organiza
tions: Practices, challenges, and
success factors,” Journal of
Software:Evolution and Process, p.
e1954. doi: 10.1002/smr.1954
4. M. Poppendieck, T. Poppendieck,
and T. Poppendieck, Lean Software
Development: An Agile Toolkit, ser.
The agile software development
series. Addison-Wesley, 2003. ISBN
9780321150783
Page 8
 Journal of Advance Research in Mobile Computing
5. A. Shalloway, G. Beaver, and J. R.
Trott, Lean-agile software develop-
ment: achieving enterprise agility.
Pearson Education, 2009.
6. B. Kitchenham and S. Charters,
“Guidelines for performing
systematic literature reviews in
software engineering,” 2007.
7. P. Middleton, “Lean software
development: two case studies,”
Software Quality Journal, vol. 9, no.
4, pp. 241–252, 2001. doi:
https://doi.org/
10.1023/A:1013754402981
8. K. B. Stone, “Four decades of lean:
a systematic literature review,”
International Journal of Lean Six
Sigma, vol. 3, no. 2, pp. 112–132,
2012. doi:
https://doi.org/10.1108/20401461211
243702
9. E. Kupiainen, M. V. Ma¨ntyla¨, and J.
Itkonen, “Using metrics in agile and
lean software development–a
systematic literature review of
industrial studies,” Information and
Software Technology, vol. 62, pp.
143–163, 2015. doi:
https://doi.org/10.1016/j.infsof.2015.
02.005
10. X. F. Wang, K. Conboy, and O.
Cawley, “leagil software de-
velopment: An experience report
analysis of the application of lean
approaches in agile software
development,” Journal of Systems and
Soft- ware, vol. 85, no. 6, pp. 1287–
1299, 2012. doi:
10.1016/j.jss.2012.01.061
11. T. Hayata, J. Han, and M. Beheshti,
“Facilitating agile software de-
velopment with lean architecture in
the dci paradigm,” in 2012 Ninth
International Conference on
Information Technology - New
Generations. doi:
10.1109/ITNG.2012.157 pp. 343–
348.
12. C. R. Jakobsen and T. Poppendieck,
“Lean as a scrum troubleshooter,” in
HBRP Publication Page 1-10 2019. All Rights Reserved
Volume 1 Issue 1
2011 Agile Conference, Conference
Proceedings. doi: 10.1109/AG-
ILE.2011.11 pp. 168–174.
13. R. Kuusela and M. Koivuluoma,
“Lean transformation framework for
software intensive companies:
Responding to challenges created
by the cloud,” in 2011 37th
EUROMICRO Conference on
Software En- gineering and
Advanced Applications, Conference
Proceedings. doi:
10.1109/SEAA.2011.74. ISBN
1089-6503 pp. 378–382.
14. M. Misaghi and I. Bosnic, “Lean
mindset in software engineer- ing: A
case study in a software house in
brazilian state of santa catarina,”
vol. 466, pp. 697–707, 2014. doi:
https://doi.org/10.1007/
978-3-319-11854-3 60
15. M. Paasivaara, C. Lassenius, V. T.
Heikkila, K. Dikert, and C. Engblom,
“Integrating global sites into the
lean and agile transformation at
ericsson,” 2013 Ieee 8th Int.
Conference on Global Software
Engineering (Icgse 2013), pp. 134–
143, 2013. doi:
10.1109/icgse.2013.25
16. G. I. U. S. Perera and M. S. D.
Fernando, “Enhanced agile software
development - hybrid paradigm with
lean practice,” in 2007 Int. Confer-
ence on Industrial and Information
Systems, Conference Proceedings.
doi:
10.1109/ICIINFS.2007.4579181.
ISBN 2164-7011 pp. 239–244.
17. K. Petersen and C. Wohlin,
“Measuring the flow in lean software
development,” Software-Practice
and Experience, vol. 41, no. 9, pp.
975–996, 2011. doi: 10.1002/spe.975
18. P. Rodr´ıguez, J. Markkula, M. Oivo,
and K. Turula, “Survey on agile and
lean usage in finnish software
industry,” in Proceedings of the ACM-
IEEE International Symposium on
Empirical Software Engineering and
Page 9
 Journal of Advance Research in Mobile Computing
Measurement, ser. ESEM ’12. New
York, NY, USA: ACM, 2012. doi:
10.1145/2372251.2372275. ISBN
978-1-4503-1056-7 pp. 139–148.
19. P. Rodr´ıguez, J. Partanen, P. Kuvaja,
and M. Oivo, “Combining lean
thinking and agile methods for
software development: A case study
of a finnish provider of wireless
embedded systems detailed,” in 2014
47th Hawaii International
Conference on System Sciences,
Conference Proceedings. doi:
10.1109/HICSS.2014.586. ISBN
1530-1605 pp. 4770– 4779.
20. U. Samanta, V. S. Mani, and Ieee,
“Successfully transforming to lean
by changing the mindset in a global
product development team,” pp.
135–139, 2015. doi:
10.1109/icgse.2015.17
21. J. Schnitter and O. Mackert, “Large-
scale agile software development at
sap ag,” vol. 230, pp. 209–220,
2011. doi: https://doi.org/10.1007/
978-3-642-23391-3 15
22. D. I. K. Sjøberg, A. Johnsen, and J.
Solberg, “Quantifying the effect of
using kanban versus scrum: A case
study,” IEEE Software, vol. 29, no.
5, pp. 47–53, 2012. doi:
10.1109/MS.2012.110
23. B. Swaminathan and K. Jain,
“Implementing the lean concepts of
con- tinuous improvement and flow
on an agile software development
project: An industrial case study,” in
2012 Agile India, Conf. Proceedings.
doi: 10.1109/AgileIndia.2012.12.
ISBN 2326-6007 pp. 10–19.
24. J. Trimble and C. Webster, “From
HBRP Publication Page 1-10 2019. All Rights Reserved
View publication stats
Volume 1 Issue 1
traditional, to lean, to agile devel-
opment: Finding the optimal
software engineering cycle,” in 2013
46th Hawaii Int. Conference on
System Sciences, Conference
Proceedings. doi:
10.1109/HICSS.2013.237. ISBN
1530-1605 pp. 4826–4833.
25. K. Vilkki, When Agile Is Not
Enough, ser. Lecture Notes in
Business Information Processing,
2010, vol. 65, pp. 44–47. ISBN 978-
3-642-
16415-6
26. U. Viswanath, “Lean transformation:
How lean helped to achieve quality,
cost and schedule: Case study in a
multi location product development
team,” in 2014 IEEE 9th Int.
Conference on Global Software
Engineer- ing, Conf. Proceedings.
doi: 10.1109/ICGSE.2014.13 pp. 95–
99.
27. M. Walter, R. Tramontini, R. M.
Fontana, S. Reinehr, and A.
Malucelli, From Sprints to Lean
Flow: Management Strategies for
Agile Improve- ment, ser. Lecture
Notes in Business Information
Processing, 2015, vol. 212, pp. 310–
318.
28. M. Pergher and B. Rossi,
“Requirements prioritization in
software engineering: a systematic
mapping study,” in Empirical
Requirements Engineering
(EmpiRE), 2013 IEEE Third
International Workshop on. IEEE,
2013. doi:
10.1109/EmpiRE.2013.6615215 pp.
40–44.
Page 10