See

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

Agile adoption at Ericsson hardware product

development

Conference Paper · August 2013

DOI: 10.13140/2.1.3781.3447

CITATIONS READS

0 913

2 authors, including:

Tomas Gustavsson
Karlstads Universitet
8 PUBLICATIONS 8 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Inter-team coordination in large-scale agile development settings View project

All content following this page was uploaded by Tomas Gustavsson on 07 November 2014.

The user has requested enhancement of the downloaded file.

 Agile adoption at Ericsson hardware product development

Tomas Gustavssona, Peter Rönnlundb

a
M.Sc, Karlstad University, Project Management Dept, SE-65188 Karlstad, Sweden
b
Ph.D, Karlstad University, Project Management Dept, SE-65188 Karlstad, Sweden.
Tomas.Gustavsson@kau.se

Abstract

This case study report experiences from a unit at the Swedish telecommunications company Ericsson
AB using for the first time agile project management methods in hardware development. A pilot
project organized with agile principles and processes was initiated in January 2012. This was the first
attempt to adopt agile methods for pure hardware development projects. Extending the use of agile
methods in hardware projects is not obvious. The main argument being that agile is solely designed
for software projects with the possibility to make changes, even late in the process. Since hardware
products cannot easily be changed once the circuit board has been put in production, the benefit of
the agile flexibility could be limited.

This case study is based on surveys and interviews at the hardware development unit six months into
the project. In all, 30 people were working in the pilot project. The timing was chosen since at this
point, the first progress evaluation was available.

The result at this early stage indicates that the pilot project delivered results in a higher pace than in
earlier hardware projects. It also shows that benefits of flexibility still can be obtained in various
parts of the working process with the use of simulating environments and advanced testing
possibilities. According to statements from interviews, the ability to cope with changes has increased
allowing the team members to put more time focusing on what is most important. This report
indicates that it may be possible to get benefits of agile methods even in other areas far from
traditional software development.

Keywords

agile methods, agile adoption, agile project management, product development, scrum, hardware.

Introduction

The popularity of agile methods within software developing compaines are steadily growing and
research clearly shows an increasing amount of successful projects due to this transition (Schatz and
Abdelschafi, 2005). In agile projects, plans are made to be flexible and allow changes to the product
even late in the process. Reccuring demonstrations of the product, follow up and retrospectives allow
the project to repeatedly decide on changes to the product (Schwaber, 2004). Agile methods are
characterized by short iterative cycles with actual delivery of the software product at the end of every
cycle.

The agile methods, originating from software development environments are now being used in
various other fields and industries. E. g. in such diverse areas as event projects (Gustavsson &
Rönnlund, 2010) and marketing (Poolton, Hossam, Reid, Arokiam, 2006). The common ground for
adopting agile methods in these areas has been the possibility to change the project result iteratively,
even late in the process. Thompsson (2011) states that: “historically, the view was, ‘Let’s make the
hardware first, then develop the software, and get it to work well”. Sceptics in the industry have not
seen the benefits for agile methods within hardware product development since circuit boards and
chips are expensive and hard to change late in the product development cycle. Nerur et al. (2005)
also points out that organizations must carefully assess their readiness before treading the path of
agility and that the adoption of agile practices in traditional organizations pose several challenges.

Agile methods: There are several characteristics in ways of working when a company says that they
are “going agile”. The first is ‘the people factor’ (Cockburn and Highsmith, 2001). Instead of trying
to control thousands of people in large projects, agile methods focus on how to achieve efficiency in
small teams, no matter the size of the actual project itself. Small teams means, in agile terms, less
than ten people. To achieve this, team members need flexibility in their team roles and use a “high
bandwidth”, informal communication. The formal communication is usually carried out in a daily
gathering for a fifteen minute, time-boxed, meeting to sort out problems. (Cockburn and Highsmith,
2001)

To get high efficiency in small teams, the agile framework Scrum defines two new roles: the Scrum
master and the Product owner (Schwaber, 2004). These two roles, although the names of them may
differ, is common in agile environments (Larman, 2003). A Scrum master has the responsibility to
coach and assist the team. An important task for the Scrum Master is to remove obstacles, both
practical issues as well as lack of training for new team members. The Product owner has the
responsibility of being a proxy for a sponsor or a customer. The most important tasks are to prioritize
and clarify requirements to help the team in delivering the most important parts of the project result
first. (Schwaber, 2004)

Another importat characteristic is that agile methods emphasize the use of the time-box concept. This
means that the time and date (the deadline) supersedes the activities meaning that regardless of how
many activities have been completed, the short project phase ends on a specific date. On this specific
date a demo of the project result is shown (for getting feedback) and a retrospective of the way of
working during this time-boxed period is carried out. In management and control terms that mean
that the product owner must, together with the team, constantly prioritize and reprioritize what
should be done before the accepted deadline. The time-boxed iteration cycles are often called
“sprints”. (Schwaber, 2004)

Definition of done, DoD, is an important concept of the agile way of working (Cohn, 2006). It means
that the team members agree on what need to be fulfilled in order to call a part of the functionality
finished and ready for use. Example: “to be able to call this software function ‘done’, the
functionality needs to be tested, documented and accepted by the customer”. An agile process aims
at delivering usable functionality at the end of every time-boxed iteration. An explicit and concrete
definition of done therefore means higher velocity and better estimations (Cohn, 2006).

The case study environment: In 2010, the Swedish telecommunications company Ericsson AB stated
that they wanted to become a lean and agile organization. In many of the software development
departments, called PDU:s (Product Development Unit), this work has been a success with faster
product development cycles with fewer errors in their released software products (according to
internal Ericsson documents from the SGSN department in Shanghai 2011). Now, the Agile and
Lean ways of working are spreading across the organization. In January 2012, a hardware
development unit at Ericsson decided to start a pilot project organized and run with agile principles
and values.

Several companies have embraced the Lean philosophies (Hou, 1995) in their work with hardware
production, since Lean originates from car production, but so far, few reports have shown the use of
agile methods for hardware product development. Many sceptics within the Ericsson organization
tried to convince the hardware development unit to give up their efforts, stating that the agile
movement is something solely for software development where you easily can make changes, even
late in the process.

The people at the hardware development unit didn’t agree. Sure, once the circuit board is put in
production, it’s hard to make changes but there is a lot of work before that happens. (And even
circuit boards needs updating once in a while.) The actual work normally means a lot of iterative
work and testing in simulated environments to realize how the hardware actually behaves. In that
sense, hardware product development isn’t that much different from software development. The
hardware unit therefore started their pilot project and this survey occurred six months into the
project.

The pilot project was started up with 30 participants with the goal of developing an upgraded circuit
board with an estimated duration of two years. This is considered as a small sized project with a
“normal” duration for projects within the department. It was also a stand-alone project, not a part of a
larger program. There was no external customer to the project, the product development management
acted as sponsors. Although several projects were run simultaneously within the department, the
participants were only part of the pilot project, no other projects. The participants, averageing an age
of 40, were mainly experienced employees.

Research questions: This survey was based on the following research question: What are the
perceived effects among project participants from using agile methods in hardware development
projects? One part of the survey was designed to compare perceived effects with claimed advantages
in software development projects (Cho & Cao, 2008) and these survey questions are focused on
efficiency for the way of working in an agile context. Sometimes higher efficiency sounds like more
work and more stress. In order to find out if the employees perceive other effects besides efficiency
related issues in their new way of working, the other part of the survey was designed with questions
regarding the psychosocial work environment.

Method

The study employed a questionnaire survey method to gather data complemented with semi-
structured interviews. The target population was the thirty members of the pilot project within a
department of two hundred employees. A survey with Likert scale questionnaires was distributed to
the target population. The survey was divided in three sections:
1. Psycho-social work environment
2. Agile success factors
3. Thoughts on success or problems

The first section contained questions regarding the psycho-social work environment, 1-5 in Table 1.
The five questions used for this survey is a subset from the survey by Hackman & Oldhams, Job
diagnostic survey (1976). The instrument is based on how job design affects our work motivation
and the authors claimed that high levels of satisfaction at work is reached when the following three
psychological states are reached: 1. Experienced meaningfulness of the work. 2. Experienced
responsibility for outcomes of the work. 3. Knowledge of the actual results of the work activities.
This study does not look at all three levels of work satisfaction. The chosen questions are a very
small subset of the original questionnaire aimed mainly at questions regarding stress in the work
environment.

The second section was on a number of agile success factors based on Chow & Cao (2008). Chow &
Cao (2008) made an explorative study to identify factors that positively influences the success of
agile system development projects. Members of 109 agile system development projects from 25
countries responded to their survey, which was based on success factors reported in agile literature.
Chow & Cao boiled down what was pointed out in agile literature into 12 success factors, which
were classified into the five dimensions: Organizational, People, Process, Technical and Project.

The five most important success factors out of the 12 factors (based on the the empirical survey of
Chow and Cao (2008)) were the following (in descending ranking order of importance): delivery
strategy and agile software engineering techniques (the technical dimension), team capability (the
people dimension), project management process (the process dimension), team environment (the
organizational dimension) and customer involvement (the people dimension).

The Organizational dimension is formed by conditions regarding management commitment,

cooperative organizational culture and team environment. The survey questions for this dimension
are questions number 6-11 in Table 1.
The People dimension is formed by conditions regarding competence with team members and strong
customer involvement. The survey questions for this dimension are questions number 12-13 and 19-
20 in Table 1.
The Process dimension is formed by conditions regarding following the agile-oriented process and
strong communication focus with daily face-to-face meetings. The survey questions for this
dimension are questions number 14-18 in Table 1.
The Technical dimension is formed by conditions such as working towards a simple design approach,
delivering most important features first and constant delivery of software. No questions in the survey
survey were included for this area.
The Project dimension is formed by conditions such as project type being of variable scope with
emergent requirement and projects with small teams. No questions in the survey survey were
included for this area.

This survey focused on percieved benefits in the following areas: Organizational, People and Process
and the questions used for the second section of the survey were from these three areas. The last two
dimensions (Technical and Project) were excluded. The main reason for excluding these two areas
were:
- the Technical dimension mostly concerns specific software development details (most questions not
applicable to hardware development)
- the Project dimension mostly concerns questions regarding overall project issues (most questions
not applicable to project members, only project sponsors and managers). Excluding these areas was
not difficult since they fell out of scope for this survey. A second possible benefit would be a higher
response rate with a less time-consuming survey for the project members. To measure the level of
achieved success for these factors, a 5-point Likert scale was used.

The third section was for additional comments, where respondents could enter any thoughts on
success or problems within a free-form text area, which was later used for follow-up for clarification.
Results from the survey: 22 out of 30 people responded to the survey which gives a 73 percent
responce rate. To further increase validity and reliability, follow-up personal semi-structured
interviews were conducted with five project members and two managers. They were based on an
interview guide developed on basis of the questions from the survey together with answers from the
survey in the free-form text area.

Stated below in table 1 and picture 1 are the questions and their average results in a 5-graded scale
where 1 equals the answer “No”, 3 equals the answer “Somewhat” and 5 equals the answer “Yes”.
Answers were converted to values (“No” equals 1 and “Yes” equals 5 except for question number 4
where “Yes” equals 1 and “No” equals 5).

Table 1: Survey questions and results

The first section. Questions regarding the psycho-social work Mean value Standard
environment: deviation
In your current situation, compared to before you started your
agile transition, do you feel that…
1. You have a reasonable workload? *PS 3,7 1,03
2. You can usually determine the pace of your work? *PS 3,3 1,25
3. The demands on you in your work are reasonable? *PS 3,8 1,19
4. You often feel stress that affects you negatively? (In this 3,3 1,20
question, “No” equals five and “Yes” equals “one”) *PS

5. There is a positive feeling about your work? *PS 4,0 0,84

The second section Questions regarding agile success factors: Mean value Standard
Right now, do you feel that you have… deviation
6. Strong executive support? *OR 4,1 0,92
7. Committed sponsor or manager? *OR 4,2 0,91
8. Cooperative organizational culture? *OR 4,1 0,83
9. An Organization where agile methodology is universally 4,1 0,77
accepted? *OR
10.Facility with proper agile-style work environment? *OR 3,4 1,24
11. Reward system appropriate for agile values? *OR 2,0 1,06
12. Team members with high competence and expertise? *PE 4,1 0,99
13. Team members with great motivation? *PE 4,3 0,83
14. Managers knowledgeable in agile process? *PR 4,2 0,81
15. Managers who have an adaptive management style? *PR 4,2 0,93
16. Self-organizing teamwork? *PR 4,4 0,65
17. Strong communication focus with daily face-to-face meetings? 4,6 0,73
*PR
18. Honoring regular working schedule (no overtime)? *PR 3,5 1,4
19. Well working process with your Scrum Master? *PE 4,7 0,57
20. Well working process with your Product Owner? *PE 4,2 0,9

*PS: questions regarding the psycho-social work environment

*OR: questions regarding the the Organizational dimension
*PE: questions regarding the the People dimension
*PR: questions regarding the the Process dimenstion
Picture 1: Graphical presentation of the survey results (mean values).

The highest variation in the survey answers were in questions number 18, 2 and 10. The lowest
variation were in questions number 19, 16 and 9.

The third section was the free-form text area where thoughts on success or problems could be
entered. 14 respondents gave comments and below you find a summary of the answers divided into
perceived benefits and problems. Most comments were only written in one sentence describing a
benefit or a problem and the longest answer contained three benefits and two problems. The list
below is summarized based on number of respondents describing every aspect with the highest
number of answers at the top of the list, the lowest at the end. Examples of answers are quoted.

Table 2. Perceived benefits of using agile methods

# Percieved benefit Number of comments
1 Teams are delivering results in a much higher pace with higher 3
quality
2 Better ability to cope with changes due to planning in shorter 2
time-spans. (“This saved time for Product Owners and Scrum
Masters. Instead of long hours of planning, they put more time
and effort into looking at actual results which helped them in
replanning”. “This helps killing darlings since actual results of
old ways of working gets visible”.)
3 Early warning (seeing what isn’t working according to plan 2
early) helps understanding what needs to be done and in what
order.
4 Better focus and less risk for duplication of work – everyone 2
knows what they should focus on on a daily basis due to the
morning stand-up-meetings.
5 Employees experience less conflicts than earlier. Since they are 1
“forced” into actual team work problems get raised, discussed
and sorted out before they grow into conflicts
6 Realizing that everything doesn’t have to work at the end of 1
every sprint, only the committed work for the specific sprint,
gives employees more courage. It’s OK to try other solutions
 and try better ways of solving problems

Table 3. Percieved problems of using agile methods

# Percieved problem Number of comments
1 Since a lot of hardware product development has to do with 2
simulating results, definition-of-done criteria are hard to define
and get useful for the view of actual progress.
2 The demo’s has so far been hard to get actual value out of. 1
3 Some very specialized competencies were hard to organize in 1
efficient teams. Still a culture where people are not very sharing
of their knowledge. Probably a problem that will be able to
solve over time through competence sharing.
4 Product owners experience that it’s hard to get close to the team 1
members, both in terms of if information has been understood
as well as to really understand difficulties among team
members
5 The first months there were problems about dependencies. A lot 1
of frustration emerged as people still laid plans for too far
ahead.

Results from the interviews: During the interviews some of the answers were discussed in detail and
the respondents were given opportunity to give overall comments to the current situation and reflect
on the work ahead for the pilot project. These were their conclusions:
- The Scrum Masters realized that they have to put more effort in actual team work issues rather than
technical issues.
- Since this has been an environment of very specialized experts, the transformation into a team
oriented way of working takes a lot of effort and time. Cultural changes aren’t done easily.

Discussion and Conclusion

The results from questions regarding the psycho-social work environment (questions 1 to 5 in table
1) shows an average of 3,62 with a mean standard deviation of 1,102. On this 5-numbered scale, with
3 as an average, this shows a positive perceived experience of the psychosocial work environment. In
other words: the people of the pilot project did not perceive problems with stress, changed
responsibility or other work-related negative effects.

The Organizational dimension, a comparison between benefits in agile software development and
hardware development, responds to questions 6 to 11 (see table 1) in the survey.
Apart from question number eleven, the response to all of these questions has been positive (a higher
mean value than 3,0). The mean value for the survey questions within this dimension was 3.65 with a
mean standard deviation of 0,955.

Free-text comments regarding the Organizational dimension were

- Perceived benefits: # 4 (see table 2)
- Perceived problems: #3, #4 (see table 3)

The People dimension responds to questions 12 to 13, 19 to 20 (see table 1) in the survey. The
response to all of these questions has been positive (a higher mean value than 3,0). The mean value
for the survey questions within this dimension was 4,24 with a mean standard deviation of 0,842.
The Process dimension dimension responds to questions 14 to 18 (see table 1) in the survey. The
response to all of these questions has been positive (a higher mean value than 3,0). The mean value
for the survey questions within this dimension is the highest of all studied dimensions with 4,25 with
a mean standard deviation of 0,9.

Looking at all three dimensions the total mean value is 4 with a standard deviation of 0,9 which
shows that the overall perceived view of the new way of working with agile methods is positive.

Comments from management also indicates that the pilot project so far has delivered results in a
higher pace than in earlier hardware projects. The result of the survey also shows that benefits of
flexibility still can be obtained in various parts of the working process with the use of simulating
environments and advanced testing possibilities. Statements from interviews indicate the ability to
cope with changes has increased allowing the team members to put more time focusing on what is
most important.

The difference between hardware and software product development lies in possibilities for upgrades
once the product is launched. A software product can easily be patched but a hardware circuit board
must be changed in order for a hardware product upgrade to take place. The hardware unit has
decided to set this as a boundary for their agile possibilities. That means that their project ends once
the product is handed over to production and any need for changes means that a new project needs to
be set up for a new product (i. e. a new circuit board). This decision helps the teams in that they don’t
have any problems with legacy issues (maintenance of older design) for their product development.

These findings at this early stage of the project indicate that agile methods can work well for
hardware product development. The adoption has so far, six months into the process, not
encountered any serious problems and early benefits are already experienced in the organization. We
cannot prove that the agile methods have been the definitive reason for successful findings of this
pilot project. Other factors, such as “the Hawthorne effect” (a possible explanation for positive
results in intervention studies), could have been reasons for the perceived benefits this early on in the
project. Therefore, this particular study will as a first step be repeated in this hardware project using
the same questionnaire at the end of the project to see if the perceived benefits remain.

This report indicates that it may be possible to get benefits of agile methods even in other areas than
in software product development.

References

Cho T. & Cao D.-B. (2008). A survey study of critical success factors in agile software projects. The
Journal of Systems and Software 81, 961–971
Cohn M. (2006). Agile estimating and planning. Pearson Education, Massachusetts.
Cockburn, A. & Highsmith, J. (2001), Agile Software Development: The People Factor, IEEE
Computer, 34(11): 131-133, Los Alamitos
Gustavsson T. & Rönnlund P. (2010). Agile Project Management in Public Events.
Hackman R. & Oldham G. (1976). Motivation through the design of work: test of a theory.
Organizational Behavior and Human Performance. Volume 16, Issue 2, August 1976, Pages 250–
 279
Hou A. (1995). Toward Lean Hardware/Software System Development: An Evaluation of Selected
Complex Electronic System Development Methodologies, Lean Advancement Initiative. MIT
Larman, C. (2003). Agile and Iterative Development: A Manager's Guide, Addison-Wesley, Boston.
Nerur, S., Mahapatra, R. & Mangalaraj, G. (2005). Challenges of migrating to agile methodologies.
Communications of the ACM, 48 (5), 73-78.
Poolton J, Hossam S. I., Reid I. R., Arokiam I.C., (2006). Agile marketing for the manufacturing-
based SME, Marketing Intelligence & Planning, Vol. 24 Iss: 7, pp.681 - 693
Schatz, B. & Abdelschafi, I. (2005) Primavera Gets Agile: A successful transition to Agile
Development, (IEEE Software, Volume 22, Issue 3), IEEE Computer Society Press, Los
Alamitos.
Schwaber, K. (2004) Agile project management with Scrum, Microsoft Press, Redmond
Thompson, K. (2011) Scrum in the Enterprise: How to Manage the Common Issues of Scrum
Projects, cPrime, Foster City

View publication stats