Adoption of Agile Methodology

in Software Development
D. Duka
Ericsson Nikola Tesla, Split, Croatia
e-mail: denis.duka@ericsson.com

Abstract - As adopting Agile software development becomes a Only recently the Lean principles and the Agile
trend, there is a need for a more structured definition of what development philosophy has been recognized as the source
is Agile and what is a high-level of Agile maturity. Traditional for solutions to these challenges.
development methodologies rely on documents to record and
pass on knowledge from one specialist to the next. Feedback Paper starts with describing Lean, Agile and Scrum
cycles are, in many cases, too long or even nonexistent. Agile methodology highlighting the difference between traditional
principles emphasize building working software that people waterfall and new approach in software development. The
can get hands on quickly, versus spending a lot of time writing third chapter describes some main Agile characteristics.
specifications up front. Agile development focuses on cross- Scaling the Agile architecture and four proposed approaches
functional teams empowered to make decisions, versus big are also presented here. The final chapter deals with real
hierarchies and splitting by function. It also focuses on rapid experiences following the Agile implementation in Ericsson
iteration, with continuous customer input along the way. This underlining some observed changes and used practices
paper deals with Agile methodology and scaling. The special while applying this new way of working. Some concrete
highlight is put on people investigating their contribution in measurements following the new concept are also presented.
Agile approach success. Some reflections after using Agile in
our own organization are also presented.
II. ABOUT LEAN, AGILE AND SCRUM
The classical way to organize software development of
I. INTRODUCTION large systems is the waterfall model, where the development
Traditionally the Telecom business has been starts from defining and analyzing the requirements and
standardization-driven and regulated on a national level. The ends to operating (or maintaining) the software. Actual
development lead times have been long. Consequently the coding is only a minor part of the entire process, whereas
Telecom vendors have developed capabilities to influence there is much emphasis on defining, designing,
standards, develop products and interact with the Telecom documentation, testing and operating (maintaining) the
operators in a slow-moving industry. The business software system [3].
landscape has changed leaving the major slow-moving
vendors to struggle with the pace of the newcomers [1]. Figure 1 [4] illustrates the waterfall software
development model.
The slow-moving market forces us to develop our ability
to run major multi-year projects. We became predictable
development machinery with extensive mechanisms to
ensure predictability and control on the expense of
flexibility and customer closeness.
This, in turn, led to organizational setups focusing on the
alignment with the project structures and deepening the
competencies in narrow areas both in the product and the
functional dimensions. The result was organizational silos
with multiple related hand-over challenges.
This gradually led to possessing less and less people
with a broad systems understanding, which in turn slowed
down both the organizational capability to handle broad
technical challenges and the individual opportunities to
learn and broaden the contribution. The feedback loops
within the product development became longer and longer Figure 1. Waterfall Software Development Model
[2].
 Agile software development model based on short
iterations and quick releases challenges the waterfall models
having emphasis on design and documentation.
The Agile manifest [5] recaps the ideology:
• Individuals and interactions over processes and
tools,
• Working software over comprehensive
documentation,
• Customer collaboration over contract negotiation,
• Responding to change over following a plan.
Lean manufacturing, initially called Just-In-Time
production (JIT) was originally developed by Toyota in the
latter part of the 20th century. Lean manufacturing system is
built on several principles and philosophies. These include
minimization of waste (through pull-production), Kaizen
Figure 2. Scrum overview
(continuous improvement), getting quality right from the
beginning (stop production for fixing), among others. The
Lean principles have been applied to Agile software
development, and quite often are referred as Agile/Lean. III. AN AGILE APPROACH
Poppendieck Mary and Tom have published several books The Agile approach aims to nurture organization assets
on the principles [6]. and to support other groups, such as development teams,
within organization. These groups should act in an Agile
Agile and Lean are relatively broad concepts. There are manner that reflects the expectations of their customers and
several more detailed software development models, the the ways in which their customers work [8].
developers of which call them as Agile methods. Some can
also be considered Lean. These models include Scrum, First and foremost, the Agile values, principles and
Extreme Programming (XP) and Agile Unified Process practices should help to guide organization architecture
(AUP), among others. modeling and documentation efforts. This is just a good start
though. In order to be successful at organization architecture
Stober [7] describes Scrum as a drastic simplification of you need to rethink your overall approach and address some
project management containing three roles, three documents fundamental issues. These issues are connected in a
and three meetings. As can be seen from Figure 2, in a synergistic manner; you must address all of them otherwise
Scrum software development project, Product Owner (PO) you will put your effort at risk. Some of these issues are:
decides the product backlog, i.e. the features expected from
the software (for the next release), signs off all deliverables • Focus on people, not technology or techniques:
and represents budget and interests of the stakeholders. At All of the arguments over “which model is right”,
the start of each sprint, the project team decides in a sprint “which notation is right”, and “which paradigm is
planning meeting, which items from the product backlog are right” are meaningless if you don’t have a viable
taken to the sprint backlog as use cases for the software. strategy for working together effectively. You could
This is based on the prioritization by the Product Owner and create a perfect organization architecture model but
teams work estimates and commitments. During each sprint, it doesn’t matter if project teams can’t or won’t take
which duration is typically two weeks, the team completes advantage of it.
the sprint backlog. A daily short Scrum meeting is held to
follow-up the ongoing work and solve rising issues. Scrum • Keep it simple:
Master (ScM) facilitates issue solving outside the meetings. A critical concept is that organization architecture
At the end of each sprint a sprint review meeting is held to models and documents just need to be good enough,
review the sprint results. Each sprint results in a working they don’t need to be perfect. By keeping
increment of the software product. Sprints are repeated until organization architecture artifacts simple you
the product backlog is depleted and the software release is increase the chances that your audience will
ready. Releases again are repeated for major software understand them, that project teams will actually
updates. read them, and that you will be able to keep them up
to date over time. Overly detailed documents might
In this paper I refer principally to Scrum model, when look impressive sitting on a shelf, but a simple
discussing Agile, as it constitutes a clear and tangible model that project teams actually use is what your
reference model. true goal should be.
• Work iteratively and incrementally:
 Agile organization architects work in an iterative • Open source approach:
and incremental manner. They don’t try to create With this strategy one or more
complete models. Instead they create models that subsystems/components are developed in an open
are just good enough. When they find that their source manner, even if it is for a single
models are not sufficient they work on them some organization. This strategy is typically used for
more. The advantage of this approach is that they subsystems/components which are extensively
evolve their models incrementally over time, reused by many teams, for example a security
effectively taking a just-in-time (JIT) model framework, and which must evolve quickly to meet
storming approach that enables them to get the the changing needs of the other systems
models in the hands of their customers as quickly as accessing/using them. This strategy requires you to
possible. adopt tools and processes which support open
source approaches.
On large Agile teams, geographically distributed Agile
teams, or for organization-wide architectural efforts, an • Combinations thereof:
architecture owner team will be required. Agile teams at Most Agile teams at scale will combine the previous
scale are organized into smaller sub-teams. The architecture three strategies as appropriate.
owner on each sub-team is a member of architecture owner
team, which helps to increase the chance that each sub-team IV. IMPLEMENTING AGILE
understands and follows the overall architecture as well as
increases the chance that the overall architecture strategy Recently, our R&D management team started discussing
will address the full needs of the overall solution. There will how to adapt the way-of-working in our Unit to the
be an overall architecture owner, this could be a rotating increasingly turbulent business environment. Prediction of
role, who is responsible for facilitating the group [9]. long-term market development, which had been the basis of
our operations and requirement setting, was getting more
There are four basic strategies for organizing Agile and more difficult. Looking into the future, it became clear
teams at scale: that we needed to do a proactive change in order to more
• Architecture-driven approach: flexibly react to customer wishes. After months of
With this strategy you organize your sub-teams discussions, Agile and Lean principles were chosen as the
around the subsystems/components called out in guiding principles of our way forward.
your architecture. This strategy works well when In the beginning, we became aware of the concept of
your architecture is of high quality and the Agile in large scale telecom industry. It was challenging to
interfaces to the subsystems have been identified realize in advance how we could change ourselves from a
before the sub-teams really get going. Although the component-based technically-thinking organization into a
interfaces will evolve over time, they are needed to customer-focused cross-functional and value-thinking
get a good start at them initially. The challenge with organization [10].
this strategy is that it requires your requirements to
be captured in a way which reflects the architecture. Even before the beginning of the change journey we
For example, if your architecture is based on large- could identify multiple obstacles in front of us. However,
scale business domain components then a the expected advantages were greater. Soon we realized that
requirement should strive to focus on a single if we want to stay as a serious player in the fierce telecom
business domain if possible. If your architecture is industry, we need to start the journey towards becoming an
based on technical tiers then requirements should Agile software company.
focus on a single tier if possible.
A. Less detailed level planning
• Feature-driven approach:
With this strategy each sub-team implements a We used approximately half a year to internally spread
feature at a time, a feature being a meaningful the knowledge of Agile software development methods. The
chunk of functionality to your stakeholders. This change was complex and thus we were not able to justify the
strategy should be applied in situation where the change by utilizing the normal business case study
architecture exhibits a lot of coupling and where procedure.
you have sophisticated development practices in We wanted to have a detailed plan of the one year
place. The challenge with this approach is that the change project. We wanted to understand and solve all the
sub-teams often need to access a wide range of the major potential problems beforehand. We wanted to mold
source code to implement the feature and thereby this plan into our yearly strategic planning process and have
run the risk of collisions with other sub-teams. As a each organizational silo responsible for part of the change.
result, these teams require sophisticated change The coaches changed our approach more to “start
management, continuous integration, and implementing with a small scale and tackle the problems as
potentially even parallel independent testing they occur”.
strategies in place.
 We started with one cross-functional development team • More personal growth and less comfort zone.
and one Product Owner that had a task to implement a real
customer feature into our product. In the beginning, it was a The teams are expected to learn in two dimensions. One
constant struggle to grant room for the experiment and, at is the functional dimension, i.e. system-design-testing. The
the same time, keep the customer promises for the ongoing other is the product dimension, i.e. different components in
project. It was clearly two extremely different worlds that the system. They need to learn the tiny end-to-end
met. One world that we knew how it worked, that was functionality that goes through multiple components. This
predictable and going on with a slow but steady tempo. new dimension of learning needs different attitude than
Then the new world with a greater tempo in which all before.
current weekly and monthly meeting routines felt as road Combining system, design and test competences into
blockers on the way. The previous organization was not one team gave the possibility to share knowledge between
ready to react fast enough with the new requirements that the team members. Visualizing the task both in the Kanban
two-week Scrum sprints brought to surface. Early on the board and the sprint planning board was found to be a
team realized that our development environment was valuable tool for the team coach to help the team members
outdated and not built for making fast and small end-to-end to broaden their competences.
deliveries. The team was encouraged to experiment with
new tools and find better means that would support the C. Innovation
faster feedback in our R&D organization.
Change from the silo-based R&D center towards the
Here are the steps that we have taken during the journey: Agile development R&D center included intensive learning,
facing new challenges and risk taking which are also typical
• One team, one Product Owner and one Scrum parameters of innovations. The elements in Lean & Agile
Master, and our innovation environment are complementing each
• Three teams (one off-site), one Product Owner and others.
three Scrum Masters, We have seen that by bringing people around the same
• Customer Support Request (CSR) and Fault table from the different backgrounds, it generates a spin of
Handling (FH) Kanban teams with Product Owners positive, innovative energy. Focal point of the current Agile
and Team Coaches, software development is efficient software development in
Agile teams. Hence, the majority of the creativity is
• Building the continuous integration machinery, naturally directed towards the improvements around the
ongoing work in the sprints.
• More new teams with a Scrum Master and a Product
Owner,
D. Involving the whole organization
• Feature and System integration in close co- From the beginning, we chose to be as open as possible
operation, during the planning and transformation. We realized that if
• All development teams are cross-functional, self- we want value workers to actively contribute we need to
organized and stable, involve them in the decision making and show all
information openly. We had all meeting notes and workshop
• Feature feasibility study done in co-operation with material visible in the intranet.
the lead feature team,
We introduced the “current best thinking“ to emphasize
• The Release verification is in close co-operation that we plan only short period ahead and want everybody to
with the feature development. participate and look for alternatives.
Once a week we had an open question session called
B. Intense learning & competence build up Fast Forward Friday. The sessions were found extremely
Changing people mindset starts from small and visible valuable. Everybody had a chance to ask questions and
actions that are repeated everyday. Management created a grow their understanding of what is expected in the future.
guideline to make clear what we want more in our everyday The level of questions told to the management team what
working environment. We believe that fundamental changes the maturity of the rest of the organization was.
that are needed in our minds to succeed with this journey are
as follows: We utilized also anonymous web polls to gather
individuals’ opinions. The free text answers also gave
• More people initiative and less top-down control, valuable information regarding where to put effort while
driving the change into the proper direction.
• More team players and less individual heroes,
• More courage and less risk avoidance, E. Making the change visible
• More conversations and less one-way Already some years back we had the understanding that
communication, working according the strict organizational silo-
responsibility and budget-areas will limit the whole V. CONCLUSION
organization to improve. Therefore, we intended to Successfully implementing organizational wide change
introduce a new organizational setup. First, we started to requires extra time and high energy level from the whole
break down the organizational silos by introducing flow organization.
based pipes that consist of several organizational resource
pools. For instance, the execution pipe had resources from By using this approach in software design we are able to
system, development and verification department. first recognize and then eliminate activities which don’t add
value e.g. partially done work without any guarantee if
The other issue was seating arrangement. We had a long customer will take it in use, unnecessary task swapping,
history of everybody having their own 8 m2 offices where waiting, handoffs, faults, etc.
one could close the door while wanting to concentrate in
privacy. Therefore, it was understandable that the resistance This way of working also implies improved
for the new seating arrangement was substantial. Our responsiveness through rapid deliveries allowing customers
management and also the project management team had to delay decisions. This is especially enabled by short
shared an open space area for a year. Their positive feedback loops and continuous integration.
experiences of how much easier it is to communicate in an
Our motivation behind the change was not only the
open space area was supporting the move.
current product under development but also to increase the
level of our R&D center ability. First-hand experience of
F. Agile practices used Scrum framework is the real source of learning. Only
While introducing Agile we have followed the basic through experiencing it is possible to express real meaning
Scrum and tried out how it fits into our environment without of how well the new way of working fits into our situation.
judging something that we have not tried.
Preliminary evidence we’ve collected from an
In product maintenance, where the nature of work is a assessment, but also from other sources all tell us that Agile
constant flow of customer service requests, we have utilized software development is making a positive difference in our
Kanban combined with practices from the Scrum organization. In addition, interest and respect for Agile
framework. For instance, since the retrospectives are seen practices is constantly growing. Other parts of the company
essential while experimenting the new way of working, we are interested in what we’re doing and how we’re making it
added that into the Kanban method. work. Consequently, our future work will target other
software teams who are adopting Agile practices and who
Behind the decision of using Scrum there was a
need our guidance and support. Following such approach
profound discussion and consideration. As a large R&D
we'll be able to improve our pratices used and also to spread
center developing a complex product, we needed to have
Agile culture within and outside our organization.
one common approach for the teams. At Ericsson we have a
history of tailor-making own tools and methods. This time
the fact was that we did not have enough experience or REFERENCES
competence to tailor a suitable process. It would have [1] J. Astemark, “ Agile@ITTE“, Internal Ericsson Documentation,
required too much time to develop an Ericsson-specific Sweden 2011
Agile process. [2] D. Duka, “Agile approach in Software Development“, Proceedings
of the 35th Mipro CTI conference, 2012
G. Agile experiences [3] J. Sääskilahti, J. Röning “Challenges with Software Security on
Agile Software development, Internal Ericsson Documentation,
Following the new methodology an assessment was Sweden 2011
performed in our organization. Overall 8% improvement is [4] R. Winston, “Managing The Development of Large Software
seen across all nodes put together. Results are presented Systems“, Proceedings, IEEE WESCON, August 1970, pages 1-9.
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfal
through the following graph: l.pdf
[5] K. Beck, “Manifesto for Agile Software Development”, 2001 http://
Agilemanifesto.org
[6] M. and T. Poppendieck, “Lean Software Development Principles”,
http://www.poppendieck.com/
[7] T. Stober, U. Hansmann. "Overview of Agile Software
Development", Agile Software Development: Best Practices for
Large Software Development Projects, Springer. 2010.
[8] S. W. Ambler, “Agile Enterprise Architecture”, http://www.
Agiledata.org
[9] S. W. Ambler, “Agile Architecture: Strategies for Scaling Agile
development”, http://www. Agilemodeling.com.org
[10] K. Mikkonen, “How We Learned to Stop Worrying and Live with
Figure 3. Agile Q1 & Q2 Assessment Scores Trend the Uncertainties“, Internal Ericsson Documentation, Sweden 2011