Conference PaperPDF Available

Characteristics and Principles of Scaled Agile

Authors:

Abstract and Figures

The Agile Manifesto and Agile Principles are typically referred to as the definitions of "agile" and "agility". There is research on agile values and agile practises, but how should " Scaled Agility " be defined, and what might be the characteristics and principles of Scaled Agile? This paper examines the characteristics of scaled agile, and the principles that are used to build up such agility. It also gives suggestions as principles upon which Scaled Agility can be built.
Content may be subject to copyright.
T. Dingsøyr et al. (Eds.): XP 2014 Workshops, LNBIP 199, pp. 9–20, 2014.
© Springer International Publishing Switzerland 2014
Characteristics and Principles of Scaled Agile
Maarit Laanti
Nitor Delta, Finland
Maarit.Laanti@nitor.fi
Abstract. The Agile Manifesto and Agile Principles are typically referred to as the
definitions of "agile" and "agility". There is research on agile values and agile practises,
but how should “Scaled Agility” be defined, and what might be the characteristics and
principles of Scaled Agile? This paper examines the characteristics of scaled agile, and
the principles that are used to build up such agility. It also gives suggestions as principles
upon which Scaled Agility can be built.
Keywords: large-scale agile software development, agile methods, software
engineering, project management, portfolio management, Scaled Agile.
1 Background and Models for Scaled Agile
Scaled agile has been an interest of the agile community for some years now [1]. Although
there exists already research on agile values [2] and practices [3], the agile community is
wondering if the principles listed in the agile manifesto scale as such or if something else is
needed [1].
The first models for scaling agility to the whole organization already exist. Scaled Agile
Framework [4, 5] was introduced to a wide audience in the Agile 2013 conference in August
2013 [6] and Disciplined Agile Delivery (DAD) [7] by Ambler in the International Conference
of Software Engineering in May 2013 [8]. Also other frames for scaling agile are emerging,
such as the Agility Path by Schwaber [9]. All the above-mentioned models have been created
by practitioners.
Scaled Agile and Agile Organizations have become hot topics since the launch of the Scaled
Agility Big Picture that describes an operational model for an Agile Organization, and the
Scaled Agile Academy that delivers certified training courses for Scaled Agility. The Scaled
Agile Framework (SAFe) is in use in multiple companies, including BMC Software, Mitchell
International, Trade Station Technologies, Discount Tire, John Deere, Valpak, Infogain and
SEI [10], and has become very popular. Scaled Agile Academy won the North American Red
Herring 100 competition that ranks new start-ups based on their success [11].
Early adopters of Scaled Agile Framework have reported significant improvement in terms
of productivity and quality. Improving productivity and quality is a key concern of any
organization, but there are also some global trends that amplify the reasons why organizations
are looking into ways to boost their performance.
1. Change or die. New innovations and new technologies come to markets with increased
speed. [12, 13]
10 M. Laanti
2. Constant need for further innovations. What is there is quickly copied – a need for constant
innovation to enable competitiveness. [14, 15]
3. Transaction cost is small or almost missing compared to traditional settings. Publishing new
(software) versions in the cloud is “free” once the cloud and the continuous deployment
infrastructure is there. This leads to a faster ROI circulation. [16, 17]
4. Markets are more unpredictable than before. There is a need to be flexible with investments
and capacity. [18, 19]
2 Principles Behind Scaled Agile Framework
Agile Software Development is most typically defined via the “Manifesto for Agile Software
Development” [20, 21]. When agile methods are taken into use in other organizational
disciplines (other than software development) it is typical to rely on other principles that are
compatible with Agile Principles. SAFe e.g. has practices that cover the Portfolio level
responsible for investments, Program level responsible for the execution of the planned
initiatives and Team level.
The Team level can work using Scrum method, Kanban method or their combination that
means that the SAFe Team level practices are compliant with Agile Principles like Scrum and
Kanban are. But the Agile Principles are not enough to tell how to most efficiently organize
Portfolio and Program levels. Thus SAFe builds on 2nd generation of Lean: Principles of the
Product Development Flow as defined by Reinertsen [16] to define new way of working
practices that are compliant with agile Team level practices for Program and Portfolio levels.
Agile changes when it scales, and lean principles provide a good source for this. For example, a
single agile team typically needs to worry only about one value chain, but lean principles
advice how to manage multiple value chains, which is an organizational level problem. On
Portfolio level the question is whether the organization has the right number of projects that
represent the best mix of opportunities [22].
2.1 Aspects of Scaled Agile
However, Scaled Agile means more than adding Adaptivity to Program and Portfolio level.
From various other sources we can find also other Aspects of Organizational-level agility, see
Table 1.
One could argue that in Table 1 the first three aspects (Strategic Agility, Business Agility,
and Agile Organization) are actually the same, only observed from different angles or
viewpoints. The list could also contain Agile Innovation [30] as one agile aspect. Oza and
Abrahamsson [30] define Agile Innovation as an aspect that combines innovation processes
with agile processes. Here it is omitted because creativity and innovation are seen as an
outcome of a Complex System tolerating internal conflicts [31]. Creativity and innovation can
thus be understood as intrinsic qualities of such an Agile Organization, and they could thus be
derived from other Agile Aspects as a result.
Characteristics and Principles of Scaled Agile 11
Table 1. Different Aspects of Agility, detected in large organizations
Agile Aspect Definitions
1 Strategic Agility The ability to continuously redirect and reinvent the core businesses
without losing momentum (in contrast to traditional portfolio
restructuring) by maintaining balance with strategic sensitivity (awareness
and attention), leadership unity (collective commitment), and resource
fluidity (people rotation and organizational structures), working as an
integrated real-time system [23].
2 Business Agility The marriage of strategy (awareness) and agility (tactics) in order to
create a responsive organization for business benefit [24] or a sum of
process agility and technical agility or a sum of speed and flexibility that
we can then, e.g., use to enable mobile business solutions [25]. Hugos
[24] states that all products have two components: the actual product and
an information component that adds value to a customer. The information
component can be understood as covering all the immaterial benefits that
the user gets when purchasing the specific product in question. A product
ecosystem provides similar (immaterial) added value to the customer;
thus here the additional value provided by a product ecosystem is
included in the Business Agility aspect.
3 Agile Organization The well-working combination of Informal Networks and the Formal
Organizational structure, for which agility is key and pervading, trust a
necessity [26].
4 People Agility The ability to shuffle work around the organization when the priorities or
focuses change — this is roughly similar to the “Resource Fluidity” [23].
5 Tools Agility The ability to have tools that support the agile way of working and can
easily be modified for a new purpose as the process changes [27].
6 Organizational
Culture
The competing different organizational values and cultures related to
agile values and agile culture [28].
7 Agility of the Product
that is Built
The ability to modify, version, personalize, configure, or refresh the
product to reach new customer groups or please the existing user [29].
8 Agility of payoff
functions
Options thinking in regarding new investments. Balancing capacity into
most profitable work, instead of having people to work on designated
areas only. Prioritizing work based on future value [5].
12 M. Laanti
3 Definition for S
c
When studying the different
people have used agile thinki
n
Design, Marketing, Portfolio
M
Fig.
Fig. 2. Left. Negative feedbac
k
system behaviour in electrical
How different disciplines
w
what Scaled Agile is, i.e. we
w
That would mean we set goal
s
between various initiatives.
W
based, cumulative metrics. Te
a
in-progress, and follow-up wi
t
c
aled Agile
Aspects of Large-Scale Agile the common nominator is
n
g to solve problems in different disciplines, such as Architec
t
anagement or Program Management.
1. Model for an Adaptive Organisation
k
system behaviour in electrical circuits. Right. Positive feed
b
circuits.
w
ould be enhanced by agile thinking could be a way to d
e
w
ould be adaptive on all levels of the organization, see Figu
r
s
to an organization that are relative, and balance the investm
e
W
e would use rolling forecasting and adaptive planning and f
l
a
ms would plan their work using increments or limiting the w
o
t
h relative metrics.
that
t
ing,
b
ack
e
fine
r
e 1.
ents
l
ow-
o
r
k
-
Fig. 3. Left. Negative feedb
systems measure progress and
Traditionally, we have ste
e
and then measuring the gap b
e
known as a negative feedbac
k
system operating under confo
r
adaptive system on the contra
r
direction. These kinds of syst
e
suitable for volatile markets.
S
An agile organization ma
y
view with Goldman’s [63] de
fi
“a comprehensive respons
continually fragmenting, gl
o
configured goods and service
s
and growth-oriented. It is not
business hatches to ride out
fe
winning: about succeeding in
share, and customers in the ve
4 Principles for S
c
The Scaled Agile Framework
b
of the mentioned Aspects of
A
of Principles could be a sourc
e
of Scaled Agile are e.g. To
Principles [35] that cover bot
h
principles such as Blue Ocean
But what principles should
for Scaled Agile by studying t
h
as agile-minded. An alternat
i
some experience in Scaled Ag
i
present the list of principles
w
been peer-reviewed and sug
g
each principle, the origins of t
h
Characteristics and Principles of Scaled Agile
ack systems look for conformance. Right. Positive feed
b
direction.
e
red companies and projects by setting a target, creating a
p
e
tween the progress and the plan. In electrical circuit design th
k
loop, looking for a conformance and stability, see figure
2
r
mance can never produce more than was originally planned.
r
y is a positive feedback system that measures the output an
d
e
ms tend to either grow or shrink exponentially, being thus
m
S
ee Figure 3.
y
be better at adapting to its surroundings. This is a compa
t
fi
nition of agility:
e to the business challenges of profiting from rapidly chan
g
o
bal markets for high-quality, high-performance, custo
m
s
. It is dynamic, contex
t
-specific, aggressively change-embra
c
about improving efficiency, cutting costs, or battening dow
n
fe
arsome competitive “storms”, it is about succeeding and a
b
emerging competitive arenas, and about winning profits, m
a
ry center of the competitive storms many companies now fear
.
c
aled Agile
b
uilds on Principles of Lean Flow thinking, but does not cove
A
gility. The Agile Aspects and various other compatible sou
r
e
for new process innovations. The possible sources for Princi
p
yota Principles [32, 33], or Lean [34] or Beyond Budg
e
h
leadership principles and process principles, or various strat
e
[36]. See Appendix A for list of these related principles.
we choose? One could also find a number of potential princi
p
h
e values (if not the principles) of companies that people ide
n
i
ve way is to discuss with the people in organizations who
h
i
lity and derive the principles from this experience. In Table
2
w
e believe could form the principles for Scaled Agile. This list
g
estions incorporated from some experienced practitioners.
h
ought are also presented.
13
b
ack
p
lan
h
is is
2
. A
.
An
d
the
m
ore
t
ible
g
ing,
m
e
r
-
c
ing,
n
the
b
out
a
rket
.
r all
rces
p
les
e
ting
e
gic
ples
n
tify
h
ave
2
we
has
For
14 M. Laanti
Table 2. Principles of Scaled Agile
Principle Explanation Origins
1 The content
is the key
Use the feedback from user and the
intrinsic knowledge based on expertise
and experience to create the best you can
dream of. Delighting the user is key to
success.
This principle combines Agile Principle
of Working software is the primary
measure of progress [20] with the first
values (Focus on the user and all else
will follow) of Google [37] and the first
value (Empathy for Customers/Users) of
Apple [38]. Great design as well as great
user experience can only be created
iteratively. Denning [39] emphasizes
NPS as primary metrics that correlate
with business success.
2 Co-creation Groups are faster solving problems than
individuals. Let the software evolve
together, as the sum of the whole is more
than its parts. Software Development is a
Co-operative Game.
This principle combines the idea that
groups are faster solving problems than
individuals [40, 41] with Cockburn’s
research [42] that Software
Development is a co-operative game.
The co-creation is a synergistic, rather
than a reductionistic view.
3 Feedback is
the
fuel to
learning
Use rapid and concrete feedback on all
work done. Study what creates success
and do more of that.
Reinertsen [16] emphasises fast
feedback . The plan-do-check-act is the
essence of all lean improvement actions.
4 Business
Agility
Releases generate revenue. The business
model must dictate the release rate and
user interest defines the business model.
A pay per month basis business can only
be based on continuous releasing.
Release less often when the transaction
cost is high.
See Reinertsen [16] on transaction and
holding costs. Business model
refactoring [43] discusses different ways
of generating money in software
business.
5 Use of
Automation
as Leverage
Use automation to leverage the manual
effort needed. Develop the system, so
that it gives a better leverage for the
work unit done.
Use of autonomination is one key idea of
Taiichi Ohno from Toyota [44]. The idea
of depeloping a system, rather than
people, comes from Deming [45].
6 Scale Using
Fractals
Fractals are nature’s way to scale, and
fairly permanent structures. Use higher
abstraction levels and nested systems,
such as nested control loops.
Refer to ideas of Panarchic systems [46].
7 Avoid
Combina-
torial
Explosions
Complexity is best tamed by splitting it
to smaller pieces. Internal releases must
be as small as possible.
Adding more people to project slows
down the progress, as need for
communication grows almost
exponentially when the number of
interfaces increases [47]. Combinatorial
explosions come from mathematics [48,
49].
8 Sequence for
maximal
throughput
Modular architecture increases speed.
Find the maximum throughput for your
portfolio by balancing what can be done
in parallel, and what must be done in
sequence.
Refer to theories of value chain, and
value chain analysis [40]. Per
researcher’s experiences [5].
9 Appreciate
deep
knowledge
Only more than five years experience
creates deep knowledge. Use the best
experts to tackle the most important and
wicked problems. Check what new is
learned and that your knowledge is still
deep. Give creativity room.
Per researcher’s experiences. Also Apple
[38], Facebook [50] and Netflix [51] are
known to value experience.
Characteristics and Principles of Scaled Agile 15
Table 2. (Continued)
10 Work
Leveling
Even distribution of work and
elimination of unnecessary work and
waiting time based on measured
performance. Work prioritization and
Kanban are the tools here.
According to lean thinking, muri
(uneven distribution of work) creates
mura (overburden) that creates muda
(waste). According to researcher’s
experience, the concepts are applicable
to both humans and machinery [52].
11 Simplicity Seek simplicity in solutions.
Simplicity is one of the Agile Principles
[20].
12 Situationality Use Pareto principle to avoid making
processes overly complex. Not all cases
need to be treated equally.
Refer to Beyond Budgeting Principles
[35].
13 Control
process,
not items
Create simple rules for decision-making,
instead of controlling each decision
individually. Make clear game rules.
Refer to Reinertsen [16] and Beyond
Budgeting [53] for distributed decision-
making.
14 Growth
mindset
Do more of what created success. Best
leaders do not reject faulty attempts, but
instead twist them to create more
success. Have a growth mindset and
improve what originally created success.
Failures are the secret source of success.
Systematic on actions. Refer how Pixar
works [54].
Refer to Mindset [55].
15 Listen to
employees,
they know
all the
problems
Value is created in the front-line. The
rate at which you are able to remove
impediments of progress or service
correlates with the improvement done
for business. Understand the problem
you are solving.
Unused employee creativity is one form
of waste [56]. Your people create the
service, the rest of the organization is
there to help them [57].
16 Detect and
use patterns
Use and apply patterns. Your problems
have already been solved by someone
and somewhere.
Refer to TRIZ for patterns to solve
product engineering problems [58].
17 Cost
innovation
Ease the user’s burden with a solution
that costs less. Provide better service or
fill the gaps between value chains. Do
not tie capital, allow flexibility in
investments and option thinking in
portfolio level. Optimize cost of
portfolio.
For cost innovation, refer to [14]. For
value chains refer to [40]. For agile
portfolio and cost thinking, refer to [59].
18 Utilize tacit
knowledge.
Crowdsource the strategy. Use tacit
knowledge of people to tell if you are
heading in the right direction or not.
When people feel proud of the outcome,
you are heading in the right direction.
According to researcher’s experience.
The idea is similar to lean Niko-niko
tables [60]
19 Learning
happens
between
teams
Create collective knowledge that share
the same vision and ambition. Collective
must have multitalented semi-permanent
teams combined with deep individual
knowledge.
See organizational learning theories
[61].
20 Fast is better
than
perfection.
Maximize the work undone. If it is not
broken, do not fix it. Tolerate small
imperfections. Fast is better than
perfection. The best is the enemy of the
good.
Lean startups are good when quickly
trying new ideas [62].
21 Prevent
problems
when small.
Success hides small problems. In order
to stay successful do not become
ignorant for small problems.
See Creativity, Inc. [54]
16 M. Laanti
5 Conclusions
This paper has examined Scaled Agile from Agile Aspects point of view, and presented a set of
Principles for Scaled Agile. Simply put, Scaled Agility can be understood as an attempt to
solve process problems other than software development on team level using agile mind-set
and tools (adaptivity).
The new kind of emerging and disappearing opportunities, shortening cycles times, constant
need for further innovations and disappearing transaction costs combined with cloud
technologies may make future organizations as growing and shrinking adaptive fractals. This
metaphor of an adaptive fractal may replace the old metaphor of an organization as a hierarchy
over time.
References
1. Dingsøyr, T., Moe, N.: Reserach Challenges in Agile Software Development. In: ACM
SIGSOFT Software Engineering Notes, vol. 38(5) (September 2013)
2. Fagerholm, F., Pagels, M.: Examining the Structure of Lean and Agile Values among
Software Developers. In: Cantone, G., Marchesi, M. (eds.) XP 2014. LBIP, vol. 179, pp.
218–233. Springer, Heidelberg (2014)
3. Doyle, M., Williams, L., Cohn, M., Rubin, K.S.: Agile software development in practice.
In: Cantone, G., Marchesi, M. (eds.) XP 2014. LNBIP, vol. 179, pp. 32–45. Springer,
Heidelberg (2014)
4. Leffingwell, D.: Agile Software Requirements: Lean Requirements Practices for Teams,
Programs, and the Enterprise. Addison-Wesley (2011) ISBN-10: 0-321-63584-1, ISBN-
13: 978-0-321-63584-6
5. Laanti, M.: Agile Methods in Large-Scale Software Development Organizations.
Applicability and model for adoption. Dissertation. University of Oulu (2013) ISBN 978-
952-62-0033-0
6. Blog post by Dean Leffingwell, Agile 2013 conference schedule (2013),
http://scaledagileframework.com/safe-at-agile-2013/,
http://agile2013.agilealliance.org/program/sessionschedule/
(accessed on July 1, 2014)
7. Ambler, S.: Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery
in the Enterprise. IBM Press (2012) ISBN-13: 978-0132810135
8. Brown, A.W., Ambler, S., Royce, W.: Agility at scale: Economic governance, measured
improvement, and disciplined delivery. In: Proceedings of the 2013 International
Conference on Software Engineering, pp. 873–881 (2013)
9. https://www.scrum.org/About/All-
Articles/articleType/ArticleView/articleId/691/The-Path-to-
Agility (accessed on July 01, 2014)
10. http://scaledagileframework.com/case-studies/ (accessed July 01, 2014)
11. http://www.prweb.com/releases/2014/05/prweb11892399.htm
12. Moore, G.: Escape Velocity: Free Your Company’s Future from the Pull of the Past.
Harper Business (2011) ISBN-13: 978-0062040893
13. Hitt, M.A., Keats, B.W., Demarie, S.M.: Navigating the new competitive landscape:
Building strategic flexibility and competitive advantage in the 21st century. The Academy
of Management Executive 12(4), 22–42 (1998)
14. Zeng, M.: Dragons at your door: How Chinese Cost Innovation Is Disrupting Global
Competition. Harvard Business Review Press (2007) ISBN-13: 978-1422102084
Characteristics and Principles of Scaled Agile 17
15. Zhou, K.Z.: Innovation, imitation, and new product performance: The case of China.
Industrial Marketing Management 35(3), 394–402 (2006)
16. Reinertsen, D.: The Principles of Product Development Flow. Second Generation Lean
Product Development. Celeritas Publishing (2009) ISBN-10: 1935401009
17. Abrahamsson, P.: Speeding up embedded software development. ITEA Innovation report
(2007)
18. Christopher, M.: The Agile Supply Chain. Industrial Marketing Management 29, 37–44
(2000)
19. Stalk, G.: Time – the next source of competitive advantage. Harward Business Review
(July/August 1988)
20. Agile Manifesto (2001), http://www.agilemanifesto.org (accessed on July
2011 and May 2012)
21. Fowler, M., Highsmith, J.: The Agile Manifesto. Software Development (August 2001)
22. Stettina, C.J., Hörz, J.: Agile Portfolio Management: An empirical perspective of practice
in use. International Journal of Project Management (April 2014)
23. Doz, Y., Kosonen, M.: Fast Strategy. How Strategic Agility will help You Stay ahead of
the Game. Wharton School Publishing (2008) ISBN: 978-0-273-71244-2
24. Hugos, M.H.: Business Agility. Sustainable Prosperity in a Relentlessly Competitive
World. Microsoft Executive Leadership Series. John Wiley & Sons, Inc. (2009) ISBN 978-
0-470-41345-6
25. Evans, N.D.: Business Agility. Strategies for Gaining Competitive Advantage through
Mobile Business Solutions. Prentise Hall (2002) ISBN-0-13-066837-0
26. Atkinson, S.R., Moffat, J.: The Agile Organization: From Informal Networks to Complex
Effects and Agility. Information Age Transformation Series. Library of Congress
Cataloging-in-Publication Data (2005) ISBN 1-893723-16-X
27. West, D., Hammond, J.: The Forrester Wave: Agile Development Management Tools, Q2
2010. Forrester Research (2010)
28. Iivari, J., Iivari, N.: Organizational Culture and the Deployment of Agile Methods: The
Competing Values Model View. In: Agile Software Development, Current Research and
Future Directions. Springer (2010) ISBN 978-3-642-12574-4
29. Grant, T.: Tech Vendors Supporting Agile Must Be Adaptive. For Technology Product
Management & Marketing Professionals. Forrester Research (2010)
30. Oza, N., Abrahamsson, P.: Building Blocks of Agile Innovation. Booksurge Llc. (2009)
ISBN-10: 1439260982, ISBN-13: 978-1439260982
31. Appelo, J.: Management 3.0. Leading Agile Developers, Developing Agile Leaders.
Addison-Wesley (2011) ISBN-10: 0-321-71247-1, ISBN-13: 978-0-321-71247-9
32. http://www.toyota-
global.com/company/vision_philosophy/guiding_principles.html
/ (accessed September 08, 2014)
33. Spear, S.J.: Learning to Lead at Toyota. Harvard Business Review 82(5), 78–91 (2004)
34. Poppendieck, M.: Principles of Lean thinking. IT Management Select 18 (2011)
35. Beyond Budgeting Principles, http://www.bbrt.org/beyond-budgeting/bb-
principles.html (accessed July 22, 2014)
36. Kim, W.C.: Blue Ocean Strategy: How to Create Uncontested Market Space and Make
Competition Irrelevant. Harvard Business Review Press (2005) ISBN-13: 978-
1591396192
37. Google values, http://www.google.com/about/company/philosophy/
(accessed July 05, 2014)
38. Apple values, http://www.seanet.com/~jonpugh/applevalues.html
(accessed July 05, 2014)
39. Denning, S.: Leader’s Guide to Radical Management Reinventing the Workplace for the
21st Century. JosseyBass (2010) ASIN: B00CNWRJS4
18 M. Laanti
40. Poppendieck, M., Poppendieck, T.: Lean Software Development: An Agile Toolkit.
Addison Wesley (2003) ISBN-0-321-15078-3
41. Surowiecki, J.: The Wisdom of Crowds. Anchor (2005) ISBN-13: 978-038572707
42. Cockburn, A.: Agile Software Development: The Cooperative Game, 2nd edn. Addison-
Wesley (2006) ISBN-10: 0321482751
43. Osterwalder, A.: Business Model Generation: A Handbook for Visionaries, Game
Changers, and Challengers. John Wiley and Sons (2010) ISBN-13: 978-0470876411
44. Ohno, T., Miller, J.: Taiichi Ohno’s Workplace Management. Gemba Press (2007) ISBN-
13: 978-0978638757
45. Lazko, W.J., Saunders, D.: Four Days with Dr. Deming: A Strategy for Modern Methods
of Management. Prentice Hall (1995) ISBN-13: 978-0201633665
46. Holling, C.S.: Understanding the complexity of Economic, Ecological, and Social Systems
47. Brooks, F.: The Mythical Man-Month: Essays on Software Engineering. Addison Wesley
(1995) ISBN-13: 978-0201835953
48. Krippendorff, K.: Combinatorial Explosion. Web Dictionary of Cybernetics and Systems.
Principia Cybernetica Web (accessed on July 03, 2014)
49. Grindal, M.: Handling Combinatorial Explosion in Software Testing. Linköping Studies in
Science and Technology. Dissertation, 1073 (2007)
50. Facebook values, https://www.facebook.com/careers/ (accessed on May 25,
2014)
51. Netflix values http://jobs.netflix.com/ (accessed on May 25, 2014)
52. Smits, H.: The impact of scaling on planning activities in an agile software development
center. In: 40th Annual Hawaii International Conference on System Sciences, HICSS
2007, pp. 274c–274c. IEEE (2007)
53. Bogsnes, B.: Implementing Beyond Budgeting: Unlocking the Performance Potential
(2008) ISBN-13: 978-0470405161
54. Catmull, E., Wallace, A.: Creativity, Inc.: Overcoming the Unseen Forces That Stand in
the Way of True Inspiration (2014) ISBN-13: 78-0812993011
55. Dweck, C.: Mindset: How you can fulfill your potential. Amazon Digital Services, Inc.
ASIN: B005RZB65Q
56. Cawley, O., Wang, X., Richardson, I.: Lean Software Development–What Exactly Are We
Talking About? In: Fitzgerald, B., Conboy, K., Power, K., Valerdi, R., Morgan, L., Stol,
K.-J. (eds.) LESS 2013. LNBIP, vol. 167, pp. 16–31. Springer, Heidelberg (2013)
57. Vineet, N.: Employees First, Customers Second: Turning Conventional Management
Upside Down. Harvard Business Review Press (2010) ISBN-13: 978-1422139066
58. Gadd, K.: TRIZ for Engineers: Enabling Inventive Problem Solving. Wiley (1887) ISBN-
13: 978-0470741887
59. Laanti, M., Sirkiä, R.: Lean and agile financial planning, BBRT research paper, work in
progress
60. Medinilla, Á.: Self-Organization. In: Agile Management, pp. 99–117. Springer, Heidelberg
(2012)
61. Argyris, C.: On Organizational learning. Wiley-Blackwell (1999) ISBN-13: 978-
0631213093
62. Ries, E.: The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to
Create Radically Successful Businesses. Crown Business (2011) ISBN-13: 978-
0307887894
63. Goldman, S., Naegel, R., Preiss, K.: Agile Competitors and Virtual Organizations:
Strategies for Enriching the Customer. Wiley (1994) ISBN 0471286508
Characteristics and Principles of Scaled Agile 19
Appendix A. List of Related Principles
Source Principles
1 Toyota [32] 1.
Honor the language and spirit of the law of every nation and
undertake open and fair business activities to be a good corporate
citizen of the world.
2.
Respect the culture and customs of every nation and contribute to
economic and social development through corporate activities in
their respective communities.
3.
Dedicate our business to providing clean and safe products and
to enhancing the quality of life everywhere through all of our
activities.
4.
Create and develop advanced technologies and provide
outstanding products and services that fulfill the needs of
customers worldwide.
5.
Foster a corporate culture that enhances both individual
creativity and the value of teamwork, while honoring mutual
trust and respect between labor and management.
6.
Pursue growth through harmony with the global community via
innovative management.
7.
Work with business partners in research and manufacture to
achieve stable, long-term growth and mutual benefits, while
keeping ourselves open to new partnerships.
2 Lean Thinking [34]
1. Specify value from the standpoint of the end customer by product
family.
2. Identify all the steps in the value stream for each product family,
eliminating whenever possible those steps that do not create value.
3. Make the value-creating steps occur in tight sequence so the product
will flow smoothly toward the customer.
4. As flow is introduced, let customers pull value from the next
upstream activity.
5.
As value is specified, value streams are identified, wasted steps
are removed, and flow and pull are introduced, begin the process
again and continue it until a state of perfection is reached in
which perfect value is created with no waste.
3 Beyond Budgeting
[35]
Governance and transparency
1. Values Bind people to a common cause; not a central
plan
2. Governance Govern through shared values and sound
judgement; not detailed rules and regulations
3.
Transparency
Make information open and transparent; don't
restrict and control it
Accountable teams
4. Teams Organize around a seamless network of
accountable teams; not centralized functions
5. Trust Trust teams to regulate their performance; don't
micro-manage them
6.
Accountability
Base accountability on holistic criteria and peer
reviews; not on hierarchical relationships
20 M. Laanti
Goals and rewards
7. Goals Set ambitious medium-term goals, not short-term
fixed targets
8. Rewards Base rewards on relative performance; not on
meeting fixed targets
Planning and controls
9. Planning Make planning a continuous and inclusive
process; not a top-down annual event
10.
Coordination
Coordinate interactions dynamically; not through
annual budgets
11. Resources Make resources available just-in-time; not just-in-
case
12. Controls Base controls on fast, frequent feedback; not
budget variances
4 Blue Ocean [36]
1. Reconstruct market boundaries. This principle identifies the paths by
which managers can systematically create uncontested market space
across diverse industry domains, hence attenuating search risk. Using a
Six Paths framework, it teaches companies how to make the competition
irrelevant by looking across the six conventional boundaries of
competition to open up commercially important blue oceans.
2. Focus on the big picture, not the numbers. This principle, which
addresses planning risk, presents an alternative to the existing strategic
planning process, which is often criticized as a number-crunching
exercise that keeps companies locked into making incremental
improvements. Using a visualizing approach that drives managers to
focus on the big picture, this principle proposes a four-step planning
process for strategies that create and capture blue ocean opportunities.
3. Reach beyond existing demand. To create the greatest market of new
demand, managers must challenge the conventional practice of aiming for
finer segmentation to better meet existing customer preferences, which
often results increasingly small target markets. Instead, this principle,
which addresses scale risk, states the importance of aggregating demand,
not by focusing on the differences that separate customers but rather by
building on the powerful commonalities across noncustomers.
4. Get the strategic sequence right. The fourth principle describes a
sequence that companies should follow to ensure that the business model
they build will be able to produce and maintain profitable growth. When
companies follow the sequence of (1) utility, (2) price, (3) cost, and (4)
adoption requirements, they address the business model risk.
The remaining two principles address the execution risks of blue ocean
strategy.
5. Overcome key organizational hurdles. Tipping point leadership shows
managers how to mobilize an organization to overcome the key
organizational hurdles that block the implementation of a blue ocean
strategy. This principle mitigates organizational risk, outlining how
leaders and managers can surmount the cognitive, resource, motivational,
and political hurdles in spite of limited time and resources.
6. Build execution into strategy. This principle introduces fair process to
address the management risk associated with people’s attitudes and
behaviors. Because a blue ocean strategy represents a departure from the
status quo, fair process is required to facilitate both strategy making and
execution by mobilizing people for the voluntary cooperation needed for
execution. By integrating execution into strategy formulation, people are
motivated to act.
... These qualities allow an organization to apply SAFe R in a way that suits their needs. Early adopters of SAFe R report that the application of the practices contained in this framework led to significant productivity and quality improvements [9]. The literature also claims that SAFe R adoption is widespread including sectors such as manufacturing, software, and financial services [9,5,10,11]. ...
... Early adopters of SAFe R report that the application of the practices contained in this framework led to significant productivity and quality improvements [9]. The literature also claims that SAFe R adoption is widespread including sectors such as manufacturing, software, and financial services [9,5,10,11]. SAFe R 4.0 is organized into four layers: 1) Portfolio -Funding and coordinating programs, 2) Value Stream -Used when a single Agile Release Train (ART) cannot deliver the full solution, 3) Program -Contains 5-12 teams working towards a common goal, and 4) Team -Teams, which practice Scrum and/or eXtreme Programming and/or Kanban. ...
Preprint
Context: How to adopt, scale and tailor agile methods depends on several factors such as the size of the organization, business goals, operative model, and needs. The Scaled Agile Framework (SAFe) was developed to support organizations to scale agile practices across the enterprise. Problem: Early adopters of SAFe tend to be large multi-national enterprises who report that the adoption of SAFe has led to significant productivity and quality gains. However, little is known about whether these benefits translate to small to medium sized enterprises (SMEs). Method: As part of a longitudinal study of an SME transitioning to SAFe we ask, to what extent are SAFe practices adopted at the team level? We targeted all team members and administrated a mixed method survey in February, 2017 and in July, 2017 to identify and evaluate the adoption rate of SAFe practices. Results: Initially in Quarter 1, teams were struggling with PI/Release health and Technical health throughout the organization as most of the teams were transitioning from plan-driven to SAFe . But, during the transition period in Quarter 3, we observed discernible improvements in different areas of SAFe practice adoption. Conclusion: The observed improvement might be due to teams merely becoming more familiar with the practices over-time. However, management had also made some structural changes to the teams that may account for the change.
... Most agile software development organisations are based on self-managed teams responsible for developing a subset of features [Camara et al. 2020, Marinho et al. 2019]. Agile at scale is a way to manage processes beyond teamlevel software development using specific agile tools [Laanti 2014], also encompassing the implementation of agile methods and principles throughout the organisation [Dingsøyr and Moe 2014]. ...
... Regarding the variety of research types, experience reports predominate [Brown 2011, Greening 2010, Greening 2015, Razzak et al. 2017, Stettina and Schoemaker 2018, Tabib 2013, Tripathi et al. 2015, followed by solution proposals [Heidenberg et al. 2013, Staron et al. 2012, Staron et al. 2013, Thawaba et al. 2020, with 7 and 4 occurrences, respectively. Only 2 validation studies [Grimaldi et al. 2016, Tessarolo et al. 2022] and 1 philosophical study [Laanti 2014] were recorded. This reinforces the need for more relevant research addressing new metric proposals not yet implemented in practice and extensive evaluations of metric usage in daily operations using large-scale agility. ...
Conference Paper
Software development is widespread across various sectors. As large-scale projects increasingly adopt agile development practices, there arises a need for metrics to enhance team coordination, promote continuous improvement and monitor progress. This discussion focuses on the current state of metrics for large-scale agile software development, outlining the reasons for their adoption and showcasing the achieved results. The analysis involves a comprehensive literature review, exploring grey literature. A catalog of metrics applicable to scalable agile projects is presented, featuring examples such as ‘Velocity’, ‘Business value per effort’, and ‘Defect rate’.
... Atualmente, grande atenção está sendo dada ao desenvolvimento ágil de software em larga escala (Grimaldi et al., 2016). Embora existam muitas pesquisas sobre valores e práticas ágeis nesse campo, a comunidade está perguntando se algo mais é necessário (Dingsøyr e Brede, 2014;Laanti, 2014). Dingsøy e Brede (2014) estabelecem como alta a prioridade de identificar métricas apropriadas para que as partes interessadas monitorem o progresso promovendo a transparência no desenvolvimento ágil em larga escala. ...
... A maioria das organizações de desenvolvimento ágil de software são baseadas em equipes auto gerenciadas responsáveis pelo desenvolvimento de um subconjunto de recursos (Grimaldi et al., 2016;Vieira et al., 2020;Camara et al., 2020). Agilidade em escala pode ser considerada como uma forma de resolver problemas de processo além do desenvolvimento de software a nível de equipe utilizando determinadas ferramentas ágeis (Laanti, 2014). ...
... Nord et al. (2014) concentrated upon the architecture of a system development and defined what large scale means in terms of scope, team size, and project duration. Laanti (2014) focused on scaled agile term and explained its characteristics. In addition, the suggestions upon how to build scaled agility are listed. ...
Conference Paper
Full-text available
Digitalization is a trendy issue in the business development world. It has experienced how vital the need for digitalization is during the Covid-19 pandemic process. Today's world needs digital transformation both to create a systematic data flow and to compete with competitors. Although the main reason behind digital transformation is to be able to compete because it helps businesses respond more effectively to the customer needs. Software product development differs from the conventional product development, so does the management of the project. In the last century, software development became a complex problem due to the change in customer needs. Thus, it requires different project management approach than traditional project management. This paper seeks to understand large-scale software development issue in terms of project management manners by reviewing literature. The paper will highlight the studies performed starting from 1992 until 2022. In doing so, the reader will observe the change in this issue over time. The papers are categorized into 5 groups according to their research questions. These groups are (1) project management and monitoring papers that focused on the governance of a project, (2) case study papers that they do not provide universal solutions but assess a specific case, (3) problem solving papers as they try to develop an algorithm to solve a problem during management processes, (4) explanatory/taxonomy papers which explains the terms and conditions of project management concept, and finally (5) literature review papers. To the best of authors’ knowledge, the literature lacks a review study which provides an overview of project management of software product development concept that contains all project management frameworks in the literature.
... Tomando como referencia el mapeo sistemático de la literatura presentado por Cañizares, Gómez y Pardo (2020), ha sido posible observar que algunos autores proponen soluciones como: (i) una taxonomía que clasifica y define los niveles de escala , (ii) principios ágiles para proyectos a gran escala (Dingsøyr y Moe, 2014;Laanti, 2014), (iii) modelos para el soporte de la arquitectura emergente en grandes entornos (Eckstein, 2014), (iv) artefactos que facilitan el desarrollo offshore a gran escala (Bass, 2016), y (v) factores de éxito y desafíos identificados en 42 casos industriales (Dikert et al., 2016). Sin embargo, hasta el momento ninguno de los estudios encontrados realiza la integración de las experiencias reportadas en los trabajos relacionados, o que integren los atributos comunes entre los marcos escalados más usados en la industria. ...
Article
Full-text available
The benefits of agile frameworks applied to small projects have aroused interest in the large-scale software industry. However, applying them in scaled environments has meant facing multiple challenges, including communication, coordination, and cooperation. Scaled frameworks emerge in response to these challenges, describing the implementation guides to achieve the agile large-scale transformation. However, a lack of conceptual clarity regarding the elements prescribed by these frameworks was identified in the literature. This article introduces the Scaled Agile Model reference model, which integrates the experience reported in the literature and the fundamental attributes of scaled agile frameworks: SAFe, LeSS, Nexus, and DAD. A protocol was followed for the harmonization of multiple models, which allowed integrating and obtaining a reference model from the results of the harmonization of frameworks and the literature found. Additionally, SAM was evaluated for clarity, suitably, and completeness through a focus group. Thus, the proposed reference model defines sixteen roles, three levels of scale, and 34 practices grouped into 8 categories. The results suggest a good acceptance by the experts who evaluated the proposal. Likewise, the proposed model aims to be of great practical benefit for companies that want to scale, companies that are scaling, or companies that have already scaled and want to evaluate their implementation.
... In total, 16 studies (13%) in this focus area contribute theoretical concepts such as success factors for agile transformations [48], integrations of the Scaled Agile framework (SAFe) for software development [49,50] or differences between quality management strategies [51] on organizational level. Concrete guidance for implementing NFRs in DevOps that address organization-wide themes is contributed by 22 studies (49%, comprised of 5 guidelines, 12 studies elaborating on lessons learned, and 5 giving advices). ...
Technical Report
Full-text available
Context: Software non-functional requirements address a multitude of objectives, expectations, and even liabilities that must be considered during development and operation. Typically, these non-functional requirements originate from different domains and their concrete scope, notion, and demarcation to functional requirements is often ambiguous. Objective: In this study we seek to categorize and analyze relevant work related to software engineering in a DevOps context in order to clarify the different focus areas, themes, and objectives underlying non-functional requirements and also to identify future research directions in this field. Method: We conducted a systematic mapping study, including 142 selected primary studies, extracted the focus areas, and synthesized the themes and objectives of the described NFRs. In order to examine non-engineering-focused studies related to non-functional requirements in DevOps, we conducted a backward snowballing step and additionally included 17 primary studies. Results: Our analysis revealed 7 recurrent focus areas and 41 themes that characterize NFRs in DevOps, along with typical objectives for these themes. Overall, the focus areas and themes of NFRs in DevOps are very diverse and reflect the different perspectives required to align software engineering with technical quality, business, compliance, and organizational considerations. Conclusion: The lack of methodological support for specifying, measuring, and evaluating fulfillment of these NFRs in DevOps-driven projects offers ample opportunities for future research in this field. Particularly, there is a need for empirically validated approaches for operationalizing non-engineering-focused objectives of software. Remark This paper is an addition to our peer-reviewed publication in [1] and contains a more elaborate presentation of our findings. When citing our work, please always cite the peer-reviewed publication; citing this technical report should always be optional for cases where you explicitly reference aspects that were not published in the peer-reviewed publication.
... In total, 16 studies (13%) in this focus area contribute theoretical concepts such as success factors for agile transformations [48], integrations of the Scaled Agile framework (SAFe) for software development [49,50] or differences between quality management strategies [51] on organizational level. Concrete guidance for implementing NFRs in DevOps that address organization-wide themes is contributed by 22 studies (49%, comprised of 5 guidelines, 12 studies elaborating on lessons learned, and 5 giving advices). ...
Preprint
Full-text available
Software non-functional requirements address a multitude of objectives, expectations, and even liabilities that must be considered during development and operation. Typically, these non-functional requirements originate from different domains and their concrete scope, notion, and demarcation to functional requirements is often ambiguous. In this study we seek to categorize and analyze relevant work related to software engineering in a DevOps context in order to clarify the different focus areas, themes, and objectives underlying non-functional requirements and also to identify future research directions in this field. We conducted a systematic mapping study, including 142 selected primary studies, extracted the focus areas, and synthesized the themes and objectives of the described NFRs. In order to examine non-engineering-focused studies related to non-functional requirements in DevOps, we conducted a backward snowballing step and additionally included 17 primary studies. Our analysis revealed 7 recurrent focus areas and 41 themes that characterize NFRs in DevOps, along with typical objectives for these themes. Overall, the focus areas and themes of NFRs in DevOps are very diverse and reflect the different perspectives required to align software engineering with technical quality, business, compliance, and organizational considerations. The lack of methodological support for specifying, measuring, and evaluating fulfillment of these NFRs in DevOps-driven projects offers ample opportunities for future research in this field. Particularly, there is a need for empirically validated approaches for operationalizing non-engineering-focused objectives of software.
Article
L’adaptabilité des entreprises via l’agilité est largement prise en compte dans la transformation numérique qui est au cœur de l’agenda de la recherche en management des systèmes d’information (MSI). Puisant ses origines dans le développement logiciel et la fabrication, l’agilité est fortement liée au MSI, en particulier à la conception et à l’évaluation. De nombreuses études se sont penchées sur les apports de l’agilité, mais ne l’ont pas clairement considérée comme une orientation organisationnelle. Développer une telle compréhension conduit à la question de recherche suivante : quelles sont les dimensions liées à l’orientation agile (OA) et comment peuvent-elles être mesurées ? Pour répondre, cette recherche propose d’utiliser la théorie des capacités dynamiques qui vise à détecter le changement, réaligner et reconfigurer l’organisation ce qui est caractéristique des méthodes agiles. Cette recherche est basée sur une approche de développement d’échelle. Les résultats de cette recherche présentent des apports théoriques : concevoir l’OA à travers les capacités dynamiques, caractériser les dimensions de l’OA et contribuer à la littérature sur l’évaluation des SI en introduisant l’OA comme un déterminant pour expliquer certains phénomènes. Cette notion offre des perspectives pour revisiter des modèles en particulier centrés sur la post adoption. Cette recherche représente également une contribution managériale par la construction d’un indice d’évaluation de l’OA.
Conference Paper
Gaining maximum benefit of Lean and Agile methods requires a thorough understanding of their assumptions regarding culture, mindset, and values. This paper examines the value system structure of experienced developers working with Lean and Agile methods, and compares it to universal human values and individual personality. We developed and deployed an online survey on Lean and Agile values, with embedded measures for universal values and personality. The resulting data set, with 61 respondents, was analysed using agglomerative hierarchical clustering and multidimensional scaling. A value structure containing 11 Lean and Agile values was uncovered, yielding insight into how Lean and Agile developers experience values in their work. The analysis shows that Lean and Agile values are connected, but not equal, to universal values and personality. The proposed model can help practitioners understand the ethos of Lean and Agile methodologies and to assess their organisational culture. It may also help researchers to study models of software developer experience and value systems.
Chapter
As we’ve already seen, command-and-control and hierarchical military-style management has been the prevalent paradigm for centuries. It survived during the industrial revolution, but as it happened with classical military operations that evolved from the brutal clash of well-formed battalions to guerrilla-style warfare, command-and-control management started to tumble down when the information society was born and the rise of knowledge workers changed the world’s economy.
Conference Paper
Agile software development methods have been around since the mid 1990s. Over these years, teams have evolved the specific software development practices used. Aims: The goal of this paper is to provide a view of the agile practices used by new teams, and the relationship between the practices used, project outcomes, and the agile principles. Method: This paper provides a summary and analysis of 2,229 Comparative AgilityTM (CA) assessment surveys completed between March 2011 and October 2012 by agile developers who knew about the survey. The CA tool assesses a team’s agility and project outcomes using a 65-statement Likert survey. Results: The agile principle of respect for individuals occurs the most frequently, while simplicity occurs least. Progress/Planning is correlated strongly to nine principles. Conclusion: Subject to sampling issues, successful teams report more positive results for agile practices with the most important practice being teams knowing their velocity.
Chapter
As the Software Engineering landscape continues to evolve and new paradigms are introduced, there can be a tendency for both industry and academia to enthusiastically embrace new approaches and march forward under whatever banner conventional wisdom has decided to adopt. One such banner is Lean Software Development, a paradigm that continues to see a growth in interest driven by the need for cost reductions within industry. The term lean attracts the attention of business, but precisely how it applies within software development is still being debated. In addition, its relationship to the better understood agile methodologies is also a topic for debate. Having been drawn into this research area ourselves, we present here a review of Lean Software Development and try to distil out for the reader some understanding of this somewhat undefined topic. We conclude with some thoughts on where this subject might go to from here.
Chapter
Function Analysis and Maps for Problem UnderstandingWhy Use TRIZ Function Analysis?What Can TRIZ Function Analysis Reveal at a Glance?Basic Building Blocks for Problem Solving – Defining IdealityFor Problem Solving We Need Both the Ideality Audit and the Function AnalysisFunction Analysis of the Current System (System We've Got)Function Analysis for Understanding and Solving Simple ProblemsSystems Develop to Deliver Benefits Better – Perfecting Functions to DeliverThose BenefitsSystems Develop in Response to Changing NeedsSimple Rules of Function AnalysisFunction Maps Contain All the System and Relevant Environmental ElementsProblem Solving from the Function Analysis Problem ListOxford Standard Solutions for Solving Problems Mapped in Function AnalysisFunction Analysis at Every Stage and for Every Kind of Difficult ProblemFunction Analysis Identifies All Significant ProblemsExample of Function Analysis of a Single Item – a Coffee CupFunction Analysis For Locating and Dealing with the Causes of Problems – Roadside BombsConclusionCase study: Improving the Opening of the Bitesize Pouch at MarsMars Enjoys Immediate Success of New Pouch Packaging ConceptThe Pouch ProblemSolving the Pouch Problem with TRIZThe Winning Idea and the ValidationPatenting the IdeaThe FutureConclusion Appendix 11.1 – Oxford Standard Solutions These are the Traditional TRIZ 76 StandardSolutions Re-Arranged into Three Categories
Article
A new competitive landscape is developing largely based on the technological revolution and increasing globalization. The strategic discontinuities encountered by firms are transforming the nature of competition. To navigate effectively in this new competitive landscape, to build and maintain competitive advantage, requires a new type of organization. Success in the 21st century organization will depend first on building strategic flexibility. To develop strategic flexibility and competitive advantage, requires exercising strategic leadership, building dynamic core competences, focusing and developing human capital, effectively using new manufacturing and information technologies, employing valuable strategies (exploiting global markets and cooperative strategies) and implementing new organization structures and culture (horizontal organization, learning and innovative culture, managing firm as bundles of assets). Thus, the new competitive landscape will require new types of organization and leaders for survival and global market leadership.
Article
In the 1980's, a massive paradigm shift hit factories throughout the US and Europe. Mass production and scientific management techniques from the early 1900's were questioned as Japanese manufacturing companies demonstrated that 'Just-in-Time' was a better paradigm. The widely adopted Japanese manufacturing concepts came to be known as 'lean production'. In time, the abstractions behind lean production spread to logistics, and from there to the military, to construction, and to the service industry. As it turns out, principles of lean thinking are universal and have been applied successfully across many disciplines. Lean principles have proven not only to be universal, but to be universally successful at improving results. When appropriately applied, lean thinking is a well-understood and well-tested platform upon which to build agile software development practices.