NEWSLETTER 1/2009 • Contents: Inside View: Testing Agile • An Agile – Innovation Alignment Method • Impacts Of Agile Transformation •FLEXI PMS Helps to Define Agile Position • People over Process: Key People Challenges in Agile Development • Improving Software De-velopment Using CMMI Goals and Agile Practices • Going Agile? Beware of Architecture-related Changes and Challeng-es!• Agile Principles and Software Product Line Engineering – How Could These Approaches Cooperate With Each Oth-er? • User Stories for Agile Product Line Engineering Tooling • System Operation Model to Drive Software-intensive System Development in Agile • Industrial Agile Workshop in Västerås • A Research Agenda for Agile Software Development • Flexi Publications • Upcoming Events

agile in the large and very large

GIVING

CLOSER LOOK AT

AGILE-INNOVATION

In Flexi, we are closely examining the blend of agile practices and innovation issues. Our consortium effort is transforming into one of the first books on ‘Building blocks of Agile Innovation’ and methods for fostering better align-ment between innovation enablers, agile practices and stakeholder values.

Nilay Oza, VTT

This is the fourth issue of Flexi newsletter, con-tinuing to dissemi-nate research-led and industry rel-evant knowledge in agile software development. This time, Newsletter topics are mainly focused on the following: a view on innovation and agile addressing alignment issue, several industrial surveys highlight-ing feedback from industry, discus-sions on how to improve agile processes, and analysis on how to accomodate software architec-ture and agile. The reader will have the chance to enjoy different perspec-tives for a number of subjects.

Juan Garbajosa, Editor-in-chief,

Flexi Newsletter

The Agile product development newsletter Flexi is a free newsletter offering summaries of the latest developments on key methods and techniques. Flexi is published by the Flexi (Flexible Integration in Global Product Development) research project. Flexi focuses on: market shaping innovation, release defi-nition, agile product development and integration. The target audience for Flexi is small and medium-sized software intensive companies, research and development departments in large companies, universities and colleges and consulting companies that develop and offer SPI services. If you would like to receive a free subscription to the newsletter, register at: http://www.flexi-itea2.org/newsletter.php.

2 �

ISBN 978-951-42-8586-8 / Publisher: Flexi research project / Design: www.pakkahuone.com / Print: Kalevaprint / 2009

ITEA 2, the follow-up to the

successful ITEA programme,

is a strategic pan-European

programme for advanced pre-

competitive R&D in software

for Software-intensive Sys-

tems and Services (SiS).

ITEA 2 stimulates and supports

projects that will give Europe-

an industry a leading edge in

the area of SiS (in which soft-

ware represents a significant

segment in terms of system

functionality, system develop-

ment cost & risk and system

development time).

Our ambition is to mobilise a

total of 20,000 person-years

over the full eight-year period

of the programme, requiring a

significant increase in invest-

ment . This ambition is based

on experience in ITEA, the

need to further close the gap

in R&D investment (�% of GDP,

Lisbon objective) and the ever

growing importance of SiS.

As one of the main EUREKA

cluster programmes ITEA 2

has close links with other EU-

REKA projects and the Frame-

work Programmes of the

European Commission. Our

projects are supported finan-

cially by all �7 members of the

EUREKA framework.

This is the fourth issue of Flexi Newsletter. Two years of work stay behind the Flexi Consor-tium, and this is noticed in ana-

lyzing some of the project results, already mature enough and available to be shared with the community. However, too much satisfaction may be contradictory with the agile principles of improving and being more efficient. This is how the consortium feels. Those goals achieved help us iden-tify new obstacles, and new milestones are accordingly defined. This is the spirit that underlies the current issue, in which achievements presented in some arti-cles become balanced with new research questions presented in some of the other contributions. In any case, most difficult challenges require broader thinking as well as result oriented approaches. This is the case that the cover page reflects: blending innovation and agile.

Inside View columnist, Michael Bolton, analyzes what he calls Agile testing; it will be difficult not to keep thinking for a while before starting the next article. Nilay Oza and Brian Donnellan assert, as a continu-ation of the message sent off in the cover page, that to answer some of the strategic alignment challenges may be unavoidable in merging of innovation and agility; they guide us across this topic in aligning in-

novation enablers and agile practices. Kati Vilkki focuses on different ways en-gineers perceive agile. She analyzes im-pacts of Agile Transformation based on an organization-wide web-survey in Nokia Siemens Networks. The results uncover novel insights in agile transformation. Complementary to this survey, Anna Ro-hunen, Pilar Rodríguez, Tommi Linna, Pasi Kuvaja, Lech Krzanik, Jouni Similä, and Markku Oivo present an on-going sur-vey, the FLEXI Project Management Sur-vey, started to gain detailed understand-

ing on how software companies manage their agile software developments. Then, we have two contributions analyzing agile processes from different perspectives: Ki-eran Conboy, Sharon Coyle, Minna Pikka-rainen, and Xiaofeng Wang present a set of required skills in People over Process: Key People Challenges in Agile Develop-ment, and Minna Pikkarainen discusses CMMI and Agile in Improving Software Development Using CMMI Goals and Agile Practices, based on her PhD dissertation.

After diving into the process, it is now the turn of architecture. M. Ali Babar presents

an overview of problems related to prod-uct architecture in Agile software devel-opment - Beware of Architecture-related Changes and Challenges! Furthermore, Jessica Diaz and Jennifer Perez elaborate on Agile Principles and Software Product Line Engineering, focusing on How Could These Approaches Cooperate With Each Other? Somehow related, but in the do-main of tools, Jabier Martinez suggests us some User Stories for Agile Product Line Engineering Tooling. Finally, equidis-tant between processes, architecture and tools, Pedro P. Alarcón, Pilar Rodríguez, Agustín Yagüe go into detail and explain how user stories, in so called operations models, and a number of tools can help us develop with the required agility for software intensive systems, with the help of Scrum.

From a different perspective, Geir K. Hanssen presents A Research Agenda for Agile Software Development, and, Stig Larsson, and Daniel Sundmark sum-marize an Industrial Agile Workshop held recently in Västerås. It will be difficult not to check one against the other and draw some conclusions, left to the reader.

Juan Garbajosa,

Editor-in-chief, Flexi Newsletter

EDITORIAL

2 �

Testing Agile INSIDE VIEW

Michael Bolton

I’m a tester. I question things, especially soft-ware, and I teach other people to do that too. I’ve been successful at teach-

ing them to question software, and I’m hoping to teach them to question other things, like Agile practices.

The Agile Manifesto says “We are uncovering better ways of developing software by do-ing it and helping others do it. Through this work we have come to value: individuals and interactions over processes and tools; working software over comprehensive documen-tation; customer collaboration over contract negotiation; re-sponding to change over fol-lowing a plan. That is, while there is value in the items on the right, we value the items on the left more.”

Why would I want to question that? I don’t think the Agile Manifesto itself is bad. On the contrary, as my colleague Cem Kaner once remarked to me, the Agile Manifesto represents the most humanist set of prin-ciples to come along in the last �0 years. What I want to ques-tion is the way in which some members of the community have interpreted those princi-ples, especially in my domain, testing.

The Agile community started with programmers who were focused on optimizing the quality of their work. They observed that communication between programmers and customers was mediated by contracts, requirements docu-ments, and project manage-ment tools, leaving out con-versation, concrete examples, negotiation and collaboration. They noticed that software development was slowed down by heavyweight process models, long feedback loops

between programmers, test-ers, and customers, and code that the programmers them-selves admitted to be overly buggy. So they decided to take responsibility for com-munication the quality of their work, and targeted delivering customer value quickly and consistently. Some proposed efficient morning meetings, inviting the customers, remov-ing the chairs, and focusing on three simple questions: “What did you do yesterday? What will you do today? What’s blocking progress?” Others incorporated ideas from eX-treme Programming: small teams, pairing, and frequent builds and releases. Agilistas promoted test-driven develop-ment, in which programmers write a test (that fails, since the code to pass it hasn’t been written yet), write code to make the test pass, and then run the test. When the test passes (sometimes that requires some fixing first), the programmer it-erates, making sure that each new piece of code is driven by a test, and that all preceding tests still pass.

This is a good and wonderful thing. It encourages program-mers to build more robust pro-grams, dramatically reducing the number of trivial bugs that cause much bigger problems when they hide in the code. Those tests form a regression testing suite, too. Code can be changed with confidence at maximum speed, which al-lows the programmers to re-spond rapidly to customer requirements, which reason-ably change due to immediate needs and market conditions.

Yet there was a catch: talk about testing took on a dra-matically programmer-centric turn. One early book on testing in XP suggested that that test-ing work should be focused on

creating a suite of automated acceptance tests, prescribed at the beginning of a one- to four-week iteration, and then verifying that the product passes them. The authors of that work now advocate a more expansive approach, but the original idea got stuck; there is still an overwhelming focus on scripted approaches and tools in the Agile commu-nity’s discussion of testing. A scripted high-level test can be executed much more quickly by machines than by humans, but it’s still very expensive to develop and to maintain com-pared to low-level tests. So let’s test: what do scripted ap-proaches remind you of more? Individuals and interactions, customer collaboration, and responding to change? Or processes and tools, negoti-ated contracts, and following a plan? With their focus on confirmation and repetition, do scripted tests represent much advance over traditional ap-proaches to testing?

Excellent testing isn’t just a question of making sure that the product passes tests; it’s not just confirmation, verifica-tion, and validation. Heavily scripted testing, whether au-tomated or performed by hu-mans, focuses the tester on the question “pass or fail?” rather than a question targeted directly at customer and user value: “Is there a problem here?” Excellent testing is fo-cused on exploration, discov-ery, investigation, and learn-ing, seeking information about a product that we’re building for other people to use. So use it like a person; change your mind, backtrack, make “mistakes”, ask “what if?”, and develop new questions inspired by what you see. Use automation to help explore those questions, not to dis-

place them. Good tests may confirm known information; great tests reveal new informa-tion. We need both kinds.

There’s plenty more to agile development than testing, of course. Whatever your role, look at what you do and compare it to the principles expressed in the Agile Mani-festo. Question whether your practices and your principles look more like the values on the left or the right. Treat your practices as you would your products: if you’re not get-ting value out of them, why not try changing something about them?

About the author:Michael Bolton has been teaching software test-ing on five continents for eight years. He is the co-author (with senior author James Bach) of Rapid Soft-ware Testing, a course that presents a methodology and mindset for excellent software testing that’s fast-er, less expensive, highly informative, and explaina-ble. He is also the Program Chair for TASSQ, the Toron-to Association of System and Software Quality, and a co-founder of the Toronto Workshops on Software Testing. He has a regular column in Better Software Magazine, writes for Qual-ity Software (the magazine published by TASSQ), and produces his own testing newsletter.

Michael lives in Toronto, Canada, with his wife and two children. He can be reached at mb@devel-opsense.com, or through his Web site, http://www.de-velopsense.com

4 5

Agile – Innovation ScenarioUnder the monikers of ‘to be agile’ and ‘to be innovative’, the investment in enabling and merging agile and innovation is grow-ing more than ever in high-tech companies. Often, such programs and subsequent projects lack the strategic alignment. They end up investing time, money and effort in ‘non-value’ adding activities. As a result, over the time, senior management loose interest in financing such programs and acting managers fail to provide traceabil-ity into impact of investment in agile and innovation, as it is difficult to track how and what innovation happened; how they impacted agile practices and how specific stakeholder values were addressed. This, in practical terms, calls for a system-atic method of understanding what may enable innovation that is aligned with agile practices and stakeholder values. In this paper, we provide one of the answers to this call. We propose a four-phase method on how a software company can identify and align key enablers of innovation with the company specific agile practices and corresponding stakeholder values. Such alignment then may become the founda-tion for strategizing an agile innovation program. We have already implemented two phases of our proposed method and results have clearly suggested that sys-tematic effort of identifying key innova-tion enablers is important before jumping into the bandwagon of ‘Agile Innovation’. In the next section, we propose short de-scription of the proposed method.

Agile and InnovationWe propose a four-phase method (shown in Table 1). We recommend a grounded ap-proach to investigation and therefore the proposed method may be experimented in a relevant company based on evolution in each phase mentioned. At broader level, we have established four phases for im-plementing agile innovation in an organi-zation. Each phase is summarized here.

Phase 1: AlignIn this phase, we propose to use matrix based, Quality Function Deployment ap-proach to align three key variables - agile practices, innovation enablers and stake-holder values. As a result, an alignment process gives two matrices to assist in decision making on investing into those innovation enablers that have potentially high impact on improving agile practices and addressing key stakeholder values.

Phase 2: ValidateIn this phase, two matrices derived in Phase 1 are used as inputs. To strengthen the internal validity of the proposed meth-od, we further propose to verify all the in-novation enablers (from Phase 1) through an internal company-wide survey. Likert-scale analysis may be used to develop the validated list innovation enablers. This validation increase company’s confidence in the identified innovation enablers.

Phase �: ExecuteIn this phase, validated innovation ena-blers (from phase 2) should be used as input. We propose to identify company-specific actions for implementing selected innovation enablers. Innovation enablers that have highest cumulative impact value (in phase 2) may be given preference. For all actions identified, measurement cri-teria should be established. This phase is executed in the real-world project and uses action research as an overarching research method. Main result of this phase will include specific innovation enablers with corresponding actions taken to ad-dress them and the results derived from implementing those actions.

Phase 4: EvaluateIn this phase, we propose to evaluate results from phase �. Results identified in phase � should be measured against the measurement criteria, established in phase �. This will bring up insights on ac-tions that really enabled innovation. This should now fed back to phase 1. More specifically, we propose to develop an agile innovation matrix demonstrating in-novation enablers (based on results upto phase 4) and actions that had high impact on enabling innovation. This matrix should be compared with the alignment matrix developed in phase 1. This will give clear strategic insights on how the company’s journey in agile innovation program and its novel but traceable status. The exer-cise can be repeated at regular intervals.

Utilization opportunityThe above method is open to all Flexi members for implementation in their re-spective companies. We too are available for full assistance in implementing cus-tomized version of agile-innovation pro-gram in your company. We also have tool support required for implementing the method. Finally, we are indeed interested in conducting empirical experiments on agile-innovation method. Please contact any of the authors listed below for initiat-ing discussion on making your agile-inno-vation journey smoother and more impor-tantly traceable!

About the authorsNilay Oza is a senior research scientist at VTT, Technical Research Centre of Finland. He conducts research, de-velops and manages Euro-pean research projects and offers advice to companies

as a member of VTT. Nilay is VTT’s leader in FLEXI project and recently he has been researching in the area of agile-innovation alignment, agile transformation, stakehold-

er values, distributed development, Green ICT and lean thinking. Nilay can be reached at nilay.oza(at)vtt.fi

Dr. Brian Donnellan a mem-ber of faculty in the Cairnes Postgraduate School of Busi-ness and Public Policy in the National University of

Ireland, Galway. His teaching and research interests lie pri-

marily in IS innovation, Green IS and Infor-

mation Technology Management.

Prior to joining NUI Galway faculty in 2004 he spent 17 years working in industry. While in industry he was responsible for the provi-sion of information systems to support New Product Development and the implementa-tion of Knowledge Management and Inno-vation systems. He is currently engaged in a number of industry and academic consor-tia focusing on Innovation Processes e.g. the Centre for Innovation and Structural Change (CISC) and the Innovation Value In-stitute (IVI) http://ivi.nuim.ie/.

Table 1: A Four-phase Agile – Innovation Alignment Method

An Agile – Innovation Alignment MethodNilay Oza , Brian Donnellan

4 5

Kati VilkkiImpacts Of Agile Transformation

We did a web-survey in Nokia Siemens Networks on what impacts people have seen of agile development methods. The survey was sent out to about 2450 people in December 2008. We got 658 responses and the response rate was 27%. Confi-dence level of results is within �.� %

We asked the following questions:

1— Role in product development

2— Length of experience with agile devel-opment

�— Organization and location

4— What Agile methods and practices are used

5—Satisfaction with support for agile transformation

6— What are the impacts of agile devel-opment compared to traditional devel-opment (this was asked in 18 different areas)

7— Satisfaction with the impact of agile development within own work

8— Would you go back to the old way of working

9— How did your organization get started with agile development?

In addition to these there were several open questions and also the possibility to give comments on the questions above.

Some of the respondents had only a cou-ple of months of experience with agile development; the longest experience was 4 years. Length of experience was not re-ally significant in terms of satisfaction or perceived impact.

Which agile practices are used?Product back-log and short time-boxed it-erations were the most widely used prac-tices (94%). 9�% reported using Scrum, while only 58% reported having self-or-ganized teams in use. This indicates very

early phase of Scrum adaptation, with only the Scrum process is in place, but not the fundamentals.

Agile engineering practices (Pair-pro-gramming, re-factoring, (A)TDD) were re-ported to be in use by 45% or less.

Sustainable pace was only used by 1�%.

Satisfaction on the impact of agile devel-opment varied depending on the amount of agile practices used; the more practic-es in use, the higher the level of satisfac-tion. To have a closer look at the impact of different practices on satisfaction, the re-spondents were divided into groups that were then compared to one another:

1— 42% of the survey respondents used the basic NSN agile practices; short time-boxed iterations, product backlog, con-tinuous integration, retrospectives and self-organized teams. This group is called basic agile.

2— 2�% had the basic NSN agile practices and some of the engineering practices in use, at least refactoring and TDD, ATDD or tests written at the same time as code. This group was called intermediate agile.

�—7% had as many agile practices in use to be equated to “industry standard” agile development or were “fully agile”

Satisfaction In general, a larger percentage of people were satisfied with the ongoing develop-

ments; 54% were satisfied with the impact within their own work while 24% were dis-satisfied. In basic agile group 60% were satisfied (21% very satisfied), in interme-diate 6�% (26% very satisfied) and in fully agile 80% (45% very satisfied).

Most people (65%) also wanted to contin-ue with agile development with only 21% of the respondents claiming that they would like to go back to the old way of working. In basic agile and intermediate 70% would not like go back, and in fully agile 80% (with only 11% wanting to go back).

This is very much in alignment with previ-ous results and the fact that none of the products that have started the agile trans-formation, have gone back to the tradi-tional mode of development.

ImpactsPeople were asked what impacts of ag-ile development compared to traditional development they have seen. Alterna-tives were: much improved, some-what improved, no impact, somewhat worse, much worse and I don’t know. At an av-erage 48% saw an improvement and 19% felt that things had gotten worse. The share of “I don’t know” was rather high, especially in cost of development and profitability –questions (more than 25%

About the authorKati Vilkki has long experience in running organizational change programs and work-ing as a change agent. Since 2005 she has

been involved in agile transforma-tions and is currently heading the agile transformation program in No-kia Siemens Networks.

answered I don’t know).

1—Profitability and business case of the product (�7% saw improvement (+), 17% felt it had got worse (-))

2—Developing high value features and functionality (49% +, 17% -)

�—Understanding customer needs and the value of a feature to customers (49% +, 10% - )

4—Visibility to actual status of develop-ment (71% +, 14% - )

5—Flexibility, ability to respond to chang-es (7�% +, 11% -)

6—Time to get releases or features out (42 % +, 2� % - )

7—Predictability of development (47% +, 2� % -)

8—Quality of code (�1% +, �2% -)

9—Early detection of bugs, errors and de-fects (64% +, 1�% -)

10—Productivity of development teams (42% +, 26% -)

11—Trust between product management and development teams (�9% +, 20% -)

12—Team work, communication and co-operation of development teams (69% +, 10% -)

1�—Level of technical competence (�8% +, 20% -)

14—Self-organization and autonomy of development teams (58% +, 10% -)

15—Sustainable pace and balanced work-load (��% +, 29% -)

16—Motivation and enthusiasm of the de-velopment team members (4�% +, 24% -)

17—Cost of development (20% + , 22% -)

18—Visibility to problems in e.g. tools, practices, plans (54% +, 14% -)

In the “basic agile” and “intermediate” groups 56% saw an improvement on av-erage and 18% felt that things had gotten worse.

The “fully agile” group was overall much more satisfied with impacts of agile de-

velopment. On an average, 70% saw an improvement and only 9% felt that things had gotten worse.

Quality of codePeople perceive that starting the agile transformation does not improve the quality of code; about �0% felt that qual-ity of code had improved and the same amount felt it had decreased. Having the NSN basic agile practices in use did not have a significant impact on this, just some more polarization; �6% felt quality had improved and the same amount felt quality had decreased.

In people’s opinion having the agile engi-neering practices in use improves quality of code a bit; 4�% felt quality of code had improved and �4% felt it had decreased. In fully agile 58% felt that quality of code had improved and 19% felt that it had de-creased.

This indicates that several agile engineer-ing practices and sustainable pace needs to be place before there is significant im-provement on quality of code.

How did you get started with agile?Also, the manner in which agile trans-formation is brought about was found to have a big impact on people’s satisfac-tion in all areas. 52% of the respondents answered the question, “how did your or-ganization get started with agile transfor-mation”, with the answer, “We were told to do it”.

This group was much more dissatisfied with the support they had got, less sat-isfied with the impact of agile and more much more inclined to go back to the old way of working than others.

1—40% of those who were “told to do it” were satisfied with the impact of agile de-velopment to own work and �6% were dis-satisfied. 70% of the others were satisfied, and 11% dissatisfied.

2—52% of those who were “told to do ag-ile” would not like to go back to the old way of working and 29% would like to go back. 79% of the others would not go back and 1�% would go back

“We were told to do it” group saw less positive impact than the others; of all the 18 areas mentioned before, more than 50% of this group saw improvement only

in “Team work, communication and coop-eration of development teams”. There is a huge difference to others; more than 50% of the others saw improvement in 1� out of the 18 areas.

The biggest difference was in “Motiva-tion and enthusiasm of the development team members”, where only 28% of “we were told to do it” saw a positive impact (compared to 60% in the other group). Of course, this is no surprise.

Conclusion We are still in very early phases of agile transformation as 58% of the respond-ents did not even have the basic NSN ag-ile practices in use to begin with. To bring about this change will take time and per-sistence. The amount of positive results depends on the number of agile practices in use, e.g. sustainable pace and agile en-gineering practices need to be in place for people to see improvement in quality of code.

In some organizations, agile development has been pushed heavily and therefore people are dissatisfied with the impacts. The way change is introduced has a big effect on how people perceive its impact. The more people can participate and in-fluence, the more positively they perceive the change – and the better the results are.

6 7

6 7

Managing traditional ag-ile projects is nowadays somewhat consolidated and the best practices are becoming standard across

the industry. However, current software development demands more than collo-cated teams to meet market needs. Scal-ing to large global projects requires often significant changes in management prac-tices. Management of an agile project in a multi-site, multi-company or distributed environment is presently evolving and there is a heavy demand for consolidat-ing the current best practices of project management in agile-in-the-large.

In order to gain detailed understanding on how the software industry – in particu-lar successful companies – manage their agile software development, University of Oulu team in Flexi project has developed FLEXI Project Management Survey (FLEXI PMS). The objective of the survey is to discover the current state of the art in ag-ile project management and provide solid data for the basis of further knowledge acquisition and development of project/company agile positioning. FLEXI PMS investigates the actual agile values, prin-ciples, practices and contexts. Special fo-cus is put on large, multi-site, multi-com-pany and distributed projects – the target area of the FLEXI project. Special atten-tion has been attached too on an “easy to answer” and “just on purpose” question-naire that takes only a few minutes time to answer. Therefore, the questionnaire is constructed to contain only the most criti-cal topics found in the field of distributed agile software project management.

Data gathered through the survey under-goes an exhaustive statistical analysis and comparisons with other research material. Quality of FLEXI PMS reference studies has been evaluated with regard to possible sampling bias as a consequence of not using a randomized sample – this problem can be ameliorated somewhat by applying samples based on the wide range of various FLEXI partners’ charac-teristics. The Flexi PMS sample is still not a strictly random sample.

FLEXI PMS consideration is based on three fundamental dimensions presented

in picture 1: the Agile Manifesto dimen-sion, the Stakeholder dimension and the Navigation dimension.

The Agile Manifesto dimension is a start-ing point for the survey including a con-text-driven approach. In addition, the di-mension has been extended to cover also agile tools for discovering opportunities and benefits gained through the use of supporting tools in distributed projects.

The second dimension, the Stakeholder dimension, is intended to extend con-ventional agile considerations to FLEXI viewpoint of multi-site, multi-company distributed software projects that are sometimes contradicting with the original agile assumptions.

Finally, the Navigation dimension covers the user process of FLEXI PMS includ-ing Knowledge Acquisition (engaged with project context) and FLEXI Naviga-tion (company/project positioning, which is engaged with project goals relative to agility level) stages.

The optimal length, time needed to com-plete, clarity, as well as fit for the purpose and attractiveness for various stake-holder roles were set in the development of the questionnaire as starting points that are considered to contribute to the usability and purpose of the survey. Im-mediate feedback is also provided for the respondents by generating and showing reports immediately after the respond-ents have completed answering the sur-vey. This offers opportunities for FLEXI PMS respondents to exploit the results in their agile development activity without any delay. The generated reports include e.g. �D frequency diagrams that provide information about their current agile state and future possibilities towards the opti-mal agile position in a form that is easy and quick to adopt.

The reports will provide the respondents the knowledge about the level of agility of their own project or organisational unit. And even more important: The survey will give them suggestions on how to increase the agility level and stakeholder’s involve-ment in their development activities.

The generated reports are: status report and navigation report. The status report

shows the agility level of the respondent’s project or organisational unit, and the navigation report gives a summary based of aggregated project data of the other respondents and compares the respond-ent’s data against the summary. Thus, the navigation report shows the ways how successful companies have been manag-ing their agile software development and, on the other hand, the adjustment pos-sibilities towards the optimal position for the respondent’s agile software develop-ment project.

Another important thing is related to sur-vey policy. FLEXI PMS provides adminis-trative, physical, and technical safeguards that ensure the confidentiality and integ-rity of any information given concerning individual projects. Therefore, any infor-mation identifying individual projects or organisational unit will not be available for any other parties and all responses will be handled confidentially.

Our purpose is to collect a large number of responses with the survey and inves-tigate how companies today manage ag-ile software development and apply agile values, principles, practices and tools in their everyday development activities and projects. We see this quite important as agile movement in software development has advanced a long way in a short time and an updated understand is needed as well as high quality analysis and studies on the reasons behind.

We encourage everyone interested in FLEXI PMS to go to the web site https://www.webropol.com/P.aspx?id=�256�6&cid=21694�17 and fill in the survey.

FLEXI PMS Helps to Define Agile Position

Anna Rohunen, Pilar Rodríguez,

Tommi Linna, Pasi Kuvaja,

Lech Krzanik, Jouni Similä,

and Markku Oivo

Kieran ConboySharon Coyle

Minna PikkarainenXiaofeng Wang

8 9

People over Process: Key People Challenges in Agile Development

The prevalence of agile methods has in-creased drastically in recent years, and there is a common perception that, while there may be some ‘teething’ problems experienced during the initial transition to agile, people are much happier, engaged and ultimately more productive in these environments. However, this belief may not always hold true. There are many seri-ous ‘people’ challenges that agile adopt-ing companies have encountered and strived to find solutions to address them. Our study has identified 12 challenges experienced by 18 large organisations on their journeys of agile adoption and tran-sition. These challenges are:

#1 Developer fear caused by transpar-ency of skill deficiencies

The adoption of agile methods can ex-pose the skill gaps of team members in a more blatantly obvious way, since there is increase in the visibility of what every-one is doing on the team. Pair program-ming, on-site customer, whiteboard all contribute to the transparency of skill de-ficiencies. Failures become very obvious, and it is hard for developers to hide. This transparency may cause discomfort, even fear of developers who have no sufficient skills required in an agile environment. It could become a potential challenge to productivity and team collaboration if the anxiety of these team members is not properly addressed.

#2 The need for developers to be a ‘mas-ter of all trades’

Agile is a significantly different approach than traditional ones, but the fundamen-tal software development skills, such as system analysing, designing, coding and testing, are not taken away by adopting agile methods. Rather, adopting agile methods exposes the lack of existing technical skills, and requires developers to develop more comprehensive and in-depth technical skills. Good coding skill is seen as a key success factor in agile environment. Other technical skills perti-nent to agile development include testing skill (automate testing, unit testing), inte-grating skill and refactoring skill. Mean-time, architecting and design skills, em-phasized in traditional methods, do not disappear; rather they become the skills that every developer should possess in agile development. Rather than being a “jack of all trade, master of none”, a de-

veloper in an agile team needs to become a “master of all trades”. The fact that ag-ile encourages blended roles, is depend-ent on voluntary contributions and em-phasises team as opposed to individual performance, means that team members may become a ‘jack of all trades’ but lack the opportunity to hone a smaller number of key skills e.g. Java certification. As a result, in the cases studied, some team members felt they were being disadvan-taged when competing for promotion or jobs in the marketplace.

#� The need for social skills

In an agile environment, social skills are just as important as technical ones. Being in an agile team does not mean working efficiently as individual only. Team mem-bers need to know each other well enough so that there is trust on what each other is doing. People need to be social. They need to get along well with each other. Each team member should be able to fit in with the team culture. Communication skill is one indispensable social skill re-quired in an agile environment. It is not only an ability to converse, but also the capability to express opinions clearly in team meetings, skill to use whiteboard to illustrate things and make them easy to understand. A lack of social skills may become an inhibitor of effective adoption and implementation of agile methods.

#4 The need of sufficient business skills

Agile methods emphasize a close rela-tionship between development teams and their customers. Constantly interacting with and gathering feedbacks from cus-tomers require developers have a given level of business skills as well as being good at developing software and as team players. A lack of business skills is partic-ularly evident in outsourced sites of some companies with distributed development teams.

#5 Reliance on developer motivation

Agile methods require a mindset different from that of traditional methods. People need to be flexible, open to changes, and willing to take risks associated with them. They also need to be attentive and reflex-ive, willing to learn new things and help others to learn. Agile needs motivated and committed team members. In addition, an open mind to innovation is also desired in an agile environment, since the lack of creativity can be a barrier to agility:

#6 Implications of devolved decision-making

Agile methods work better with autono-mous teams where team members are able to make decisions together without command and control from project man-agers. Decision-making should be shared among team members. They need to de-fine what works for them and needs to do things on their own so that they could do them in more flexible manners. There is no comfort zone and no manager to make the decision for them. Likewise, there is no comfort zone for project managers ei-ther. They need to deal with the anxiety of losing the traditional roles as manag-ers and to understand their new roles as facilitators in an agile team. In addition, since an agile team needs to move fast and generally works with incomplete and inaccurate information typified in a turbu-lent business environment, a team needs to be able to make decisions on the fly and constantly. However, team members should be also careful in leveraging the power of self-organization. Devolved decision-making needs them to be dis-ciplined. Contrary to the view that it is needed only in heavy-weight processes, discipline is also very much a concern of agile teams.

#7 The need for planning skills

Corresponding to the challenge that an agile team needs to be autonomous, in addition to devolved decision-making, developers in an agile team are also re-quired to conduct other project manage-ment activities that are traditionally seen as the responsibilities of project manag-ers. Among them planning is one of the most important activities. Contrary to the view that there is no planning in ag-ile processes, planning happens at all levels in an agile environment - product planning, release planning, iteration plan-ning and planning of the day. Although some upfront planning is always needed to manage requirements, the traditional way of planning a project upfront can-not be applied in agile environment. Both developers and stakeholders need to un-derstand and have ability to conduct agile planning at all levels. They have to think constantly what user story to take, what estimate to assign to a user story, etc.

#8 The need for agile compliant perform-ance evaluation

Agile methods advocate people inter-action and teamwork, helping others, transferring knowledge, etc. Yet team collaboration is not easy to implement if the performance evaluation mechanism is based on individual performances, as what many companies use today. Criteria for performance evaluation, particularly at junior levels, usually focuses on tech-nical skills and the ability to follow direc-tion whereas distinguishing factors in agile development, such as social skills, creative thinking and self-organisation, are neglected. Agile teams are very often evaluated according to traditional criteria, and so results are often not indicative of the true abilities of the team members. A lack of agile compliant performance eval-uation not only renders the career pro-gression problematic for developers, but for customers, who collaborate with agile teams, career progression can become an issue as well. For example, the role of on-site customer is perceived as being important to senior management, but the actual person doing the job can feel ag-grieved that they are not being rewarded properly.

#9 The need to understand and learn val-ues and principles of agile, not just prac-tices

Using agile methods properly is a chal-lenge to an adopting team. It is not easy to make the agile practices work for a team, e.g., it takes time to get product owners really work, backlog is not always visible, etc. People need to understand what agile really means and the values and princi-ples behind agile methods. Without this understanding, there is a risk of using the practices in a superficial or even false manner, such as teams in which members of the team have no idea what others are doing in the team, or projects that have called themselves agile simply because they do not have documentation.

#10 Lack of developer buy-in to agile de-velopment

Agile adoption and transition is not a guaranteed success even if developers acquire the necessary skills and capabili-ties. If people are not convinced by the ef-fectiveness of agile methods, and if they do not believe that agile is the way that they should follow, the agile transition process may well fall apart.

#11 Lack of suitably trained IT graduates

Very few third level institutions incor-porate agile methods and skills to any significant degree and students are usu-ally trained according to the traditional waterfall model. Furthermore, degree programmes tend to lean heavily (if not completely), toward intense technical or business skills but rarely incorporate both. Many of the organisations studied

could not, or at least have not, identified courses that apply and integrate both these skills. Therefore, they continue to hire graduate employees from the same program sources as when recruiting for wholly traditional, technically-oriented projects.

#12 Managing cultural conflict between development sites

For companies who have distributed de-velopment teams, there are a couple of specific issues that pose challenges to agile adoption. One is the cultural differ-ence between home and outsourced sites, which might not be necessarily cultural difference between the countries these of-fices reside in, but the difference between the organizational cultures these offices have. Another issue is that generally the outsourced sites do not have knowledge of agile methods. They need extensive training, which brings up the cost of de-velopment and to certain extent negates the benefit of outsourcing and implement-ing agile methods at outsourced sites.

Towards good practices to overcome people challenges

Training on agile methods is seen as a typical solution to fill in the skill gaps caused by agile adoption. Continuous, hands-on training is seen more beneficial than once-off text-book teaching. How-ever, training by itself cannot bring teams and organizations too far on their agile journey. Championing and coaching are complements of formal trainings. Several companies we have studied have agile champions and coaches who drive the agile adoption and implementation effort and collaborate with agile teams and help them use and keep using agile practices effectively.

Team-based performance evaluation can foster team collaboration. Several inter-viewed companies have developed bonus program that is team based rather than re-warding individuals. It is a sharing mode of bonuses. Evaluation is more team oriented, against a set of team goals. In addition to the evaluation of technical performance, communication or team spirit can also be parts of the evaluation, although measurement of social aspects of team work can be difficult.

Several companies have developed re-cruiting practices in order to hire right people to work on agile projects. For ex-ample, in one company, the job interview-ees are given a piece of code and asked to refactor it. They need to explain what the code is supposed to do. They also have to give a snapshot of what they would do at a stand-up meeting. They are also asked to develop a set of user stories and ac-ceptance tests based on an interview with a pretend customer. This mode of recruit-

ing exposes quickly the lack of technical and social skills of the interviewees. An-other company developed team recruit-ing, where a whole agile team, rather than only project manager, to recruit new team members. The team involves the potential new member into the team play and all team members evaluate the performance of the interviewee.

8 9

About the authorsKieran Conboy is a lecturer in in-formation systems at the National University of Ireland Galway. His research focuses on agile systems development approaches as well as agility across other disciplines. He is currently involved in many na-tional and international projects in this area, and has worked with many companies on their agile initiatives. His research has been published in various leading journals and confer-ences. He is also associate editor of the European Journal of Information Systems.

Sharon Coyle is a PhD student at the National University of Ireland, Galway (NUIG). Her research interests include ag-ile systems develop-

ment approaches, Contribution The-ory and Knowledge Sharing. Prior to joining NUIG, Sharon was a man-agement consultant with Accenture where she worked on a variety of projects for Government bodies and Financial Services institutes.

Minna Pikkarainen is a researcher and project manager in VTT Techni-cal Research Centre of Finland. Her research has been published in sev-eral journal and conference papers. She has worked in 18 industrial driv-en research projects collaborating with 14 companies in Finland and Ireland. Minna also participated as a key person in several large interna-tional ITEA project preparation work collaborating with large European level company networks.

Xiaofeng Wang currently works as a research fellow in Lero, the Irish soft-ware engineering research centre. Her research areas

include software development proc-ess, methods, agile software devel-opment, and complex adaptive sys-tems theory.

M. Ali Babar

10 11

Going Agile? Beware of Architecture-related Changes and Challenges!

Agile approaches have undoubtedly been gaining popularity an increasing number of companies as a mechanism for reduc-ing cost and increasing ability to handle change in dynamic market conditions. However, there is also a significant con-cern about the role and importance of architecture-related issues when using agile approaches. Many practitioners of agile approaches view software archi-tecture in the context of the plan-driven development paradigm. That is why they appear to consider upfront architecture design and evaluation of very little value to the customers of a system. On the other hand, software architecture researchers and practitioners appear to be sceptics of using agile approaches for developing large scale software systems.

Despite these opposing views about the role and importance of software archi-tecture in two camps, there is a growing interest in identifying the mechanics and prerequisites of bridging the gap between agile and architectural approaches. One way of briding this gap is to gain a good understanding of architecture-related changes and challenges when using agile approaches. The objective of this article is to shed some light on how the adop-tion of agile approaches may impact on architecture-related practices and the kinds of architectural challenges faced by software development teams. This article is baed on observations gathered from extensive interactions and discussions with dozens of practitioners developing large scale software systems using agile approaches. The exploration of the role of architecture and architecture-related practices in agile teams have been driven based on the activities (i.e., architectural analysis, architectural synthesis, and ar-chitectural evaluation) of a general design model, architecture documentation, and sharing of design decision practices.

Role of architect: When companies in-troduce agile approaches, there are

usually several changes in the role and responsibilities of software architects. The projects using agile approaches usu-ally have a role called solution architect, which is assumed by previously called software architects. However, the solu-tion architects take on more management oriented responsibilities, which may also include being a Scrum Master. A new role called “Implementation architect” can also be introduced. This role is usually responsible for getting the User Stories implemented and providing technical mentoring to developers. The implemen-tation architect can also be responsible for deciding about the timing and amount of re-factoring to be carried out.

Architectural analysis: An agile team usu-ally pushes most of the tasks related to architecture analysis phase (e.g., exam-ining context and defining problems) to-wards customers, who are responsible for providing Users Stories for which design decisions are made and implemented. Most of the design decisions made by the solution and implementation architects are based on the features to be delivered. That means there is no attention paid to quality attributes. Rather, the quality at-tributes may not get any attention if their achievement is not considered a measure of success.

Architectural synthesis: The agile projects that I usually come across apply two stages for designing solutions: software architects working with customers draw a very high level architectural roadmap; then solution and implementation archi-tects make the potential design decisions considering the User Stories and their pri-orities, budget, time, and other technical constratints. The designers in agile teams usually consider a limited number of well known solutions.

Architectural evaluation: The architecture evaluation is considered relatively less important in agile projects. A project man-ager may invite developers from another

project to look for serious design flaws at a very high level. We may not observe any change in this practice as a result of adopting agile approaches because many projects evaluate architecture inormally even before adopting agile approaches. Architecture evaluation is usually carried out for quality attributes. Agile followers claim that re-factoring can help achieve quality attributes. However, it is a com-mon observation that re-factoring, both at the code level and architecture level, help achieve the desired quality attributes to a certain extent such as improving main-tainability by fixing the structure.

Architecture documentation: Agile ap-proaches advocate “Working software over comprehensive documentation.” That is why there can be several chang-es in software architecture documenta-tion practices as a result of using agile approaches. However, these changes appear to be on the positive side of the practices as it helps in reducing the un-necessary documentation. There is usu-ally drastic reduction in the amount and detail of architectural documentation. Companies usually report �0-40% reduc-

About the authorDr. M. Ali Dr. M. Ali Babar is a Senior Re-searcher with Lero, the Irish Software Engineering Resarch Centre, where he leads the research projects on Software Architecture and Evi-dence-Based Software Engineering. He is one of the lead researchers on A-Cube (Architecture-Centric Agile Approaches) initiative, which aims to bridge the gap between agile ap-proaches and architectural practic-es. Prior to joining R&D, he worked in ICT for several years in Australia.

10 11

tion in resources required for documen-tation. Table 1 summarizes the architec-ture-related artifacts used by agile teams compared with architecture-centric teams for devising and implementing design so-lutions.

Communicating design decisions: One of the key architecture-related practices is communicating design decisions and ra-tionale underpinning them to all relevant stakeholders. Most of the agile teams use Wikis and design meetings for shar-ing design decisions. The Wikis are also used for smiliar objective by software de-velopment teams irrespective of software development methodology. However, ag-ile teams use Wiki more frequently and intensively without any formal templates or structure. Design decisions are also shared and explained on teams’ white-boards, which keep the design until it got implemented. Wikis are also used for communicating design decisions and their rationale to customers and mainte-nance team, who usually get the Wiki with the final release of the software.

Architecture-related ChallengesSoftware architecture plays a vital role in developing and evolving any business critical system. Not paying sufficient at-tention to architectural aspects usually results in several issues that can poten-tially have negative impact on architectur-al practices, artifacts or design decisions. Following paragraphs briefly describe the most commonly observed architecture-related difficulties development teams ex-perience when using agile approaches.

Incorrect prioritization of User Stories: One of the key architecture-related chal-lenges commonly experienced by agile teams is that User Stories may be pri-

oritized without taking the technical con-siderations into account. If critical inter-dependencies among User Stories are discovered later on, it usually requires significant re-factoring with consequenc-es for the whole structure of the software. One way of dealing with this challenge is to involve architects and developers in prioritizing User Stories in a group ses-sion, which is called “Feature Analysis Workshops.

Lack of consideration for alternative de-sign choices: When the emphasis is on achieving the required features within time and budget, development teams are forced to focus on a limited number of solutions. One risk of this approach is that architects usually miss out on a pos-sibly better design choice by not paying sufficient attention to upfront design. De-velopers may also find themselves in a dilemma as they are neither given upfront design nor time to come up with proper design. Since developers need to justify everything they do, so they tend to skip the consideration for alternative designs and implement whatever is known solu-tion.

One potential solution to avoid this situa-tion is to have an iteration for doing archi-tecturally focused work – Zero iteration, which can easily be combined with the “Feature Analysis Workshop.” Or there can be allocated time in each iteration for developers to think about different design choices.

Lack of focus on quality attributes: Lack of focus on quality attributes for making design decisions usually results in archi-tectural structures that can hardly meet quality requirements later on. Such sys-tems need huge budget and time for fix-ing quality attributes during maintenance projects. Since the satisfaction of qual-

ity attributes is usually not a measure of success that is why development teams normally do not pay any particular atten-tion to achieving quality attributes. One strategy to deal with this situation is to make the satisfaction of quality attributes a measure of success so development team has clear incentive for achieving quality attributes during the development project rather than leaving it for the main-tenance project.

Unknown domain and untried solutions: Most of the time it is a common obser-vation that new domain and untried so-lutions can present quite challenging situations. That is why agile approaches may not be appropriate when working in unknown domain, with new clients, or with untried solutions. If the domain and technologies are very well known and un-derstood, it is relatively less risky to start develoing features without giving much consideration to the architectural aspects in a particular domain and technologies being used. Hence, when working in an unknown domain with untried technolo-gies, a hybrid approach may be more suit-able to apply rather than pure agile. The agile approaches may be more suitable to use when clients and solutions are well understood.

Other architecture-related challenges commonly experienced are: 1) lack of skill set as agile is more suitable to really good developers who know the system very well and are able to craft sophisticated de-sign while implementing User stories with out having an upfront design activity; 2) Ad hoc and unplanned documentation of design decisions on Wiki usually result in several difficulties in finding the required information about the key design deci-sions. Such search can consume a lot of time and effort.

12 1�

Agile Principles and Software Product Line Engineering – How Could These Approaches Cooperate With Each Other?

IntroductionAgile Software Development (ASD) meth-odologies have been significantly accept-ed by industrial software companies1. Issues such as reduced time to market, adaptive planning, lightweight, and wel-come to changes, have led to the compa-nies to incorporate agile practices in their projects. ASD improvements are mainly based on adaptive planning in each it-eration (as opposed to plan-driven), con-tinuous delivery of valuable software by short time-framed iterations, and tacit knowledge processes with litter ware. However, very often companies need in-tegrate these agile practices with other al-ready consolidated software development methodologies. This may be the case of architecture-centric methodologies such as Software Product Line Engineering (SPLE). The role of the architecture for achieving systematic reuse in large scale software intensive systems is vital2, especially where their developments are products of the same family. SPLE takes advantages of common features among the products of a family (e.g. mobile phones, car elec-tronics or financial services) through the systematic reuse of these commonalities. This systematic reuse promises faster time-to-market, better quality and lower cost. The first step in a SPL development is the modelling of the common features that the products of a family share, and the modelling of variability that makes them different. This process is plan-driv-en, heavy, and that could be leveraged in the long-term (domain engineering). Since both commonality and variability have to be completely defined and planned at the initial stages of the process development, organizations have to make an up-front investment in the long term. Investments in requirements, architectures, and de-signs could be reused by product deriva-tion (application engineering). But as any other investment it might be paid off or not.It can be turned out that both approaches, ASD and SPLE, provide companies with benefits that are not the same. Many of their foundations are completely different. While SPLE supports systematic reuse through an intensive analysis of the com-monalities and variabilities of the product line and requires an up-front investment, ASD does not support systematic reuse because it is focused on immediate de-mands of customers. This means that ASD assumes that future changing sce-narios cannot be anticipated in any case, and the investment for the definition of the commonality and variability will not be paid off. Instead, ASD focuses on require-

ments at hand. Then, is it possible to take the benefits of both approaches? How could these approaches interact and work in cooperation with each other? Some au-thors assert that ASD and SPLE, which at first sight may seem contradicting, in fact complement each other�.

How to stretch SPLE to fit ASDA balance among improvements, benefits and investments has to be considered. This balance may be addressed roughly speaking: (i) replacing the up-front heavy domain engineering process by an agile iterative approach, and (ii) reconciling the long-term variability planning with the short-term customer satisfaction. So, the integration of both approaches consists of performing domain engineering and application engineering phases in an it-erative way. This should be done by pri-oritizing product features through models that evaluate the impact of changes in product lines. Practical guidelines and frameworks have to be defined to suc-cessfully support new life cycles that would integrate ASD and SPLE. (l) Replacing the up-front domain engi-neering by an agile iterative approachThe development of a product line re-quires an initial up-front investment to model commonality and variability and this investment might be paid off or not. SPL development could be enhanced per-forming the product line through an itera-tive approach according to agile princi-ples that believe in continuous delivery of valuable software. This iterative approach would consist of an iterative domain engi-neering phase and an iterative application engineering phase. This means, that the core assets of the product line are consol-idated in an incremental way and a partial product (a working product in agile ter-minology) is derived after each iteration. ASD is also enhanced because reuse is considered as any other agile principle. (ll) Reconciling the long-term variability planning with the short-term customer satisfactionA mechanism to bring together short and long-term benefits must be defined. This mechanism could be addressed to an iterative variability planning that sup-ports the systematic mass customization characteristic of product lines in agile development. This means, the variability modelling may be divided by short time-framed iterations on the basis of the most valuable combination of features for the customer at that moment. This process requires the prioritization of the variable

features to be considered at each itera-tion. To do this prioritization models that evaluate the impact of variability in the product line have to be defined.

About the authorsJessica Diaz is a PhD Candidate in Computer Science, all of them from the Technical University of Madrid (UPM-Spain). She is a researcher in System and Software Technology Re-search Group (SYST) at the Techni-cal University of Madrid. Now she is working as a researcher under a post-graduate official grant by the UPM Ed-ucation Council under its Research Personnel Training program. She is developing her PhD thesis working in enabling software product lines in agile contexts.

Jennifer Pérez is an as-sociate professor at the E.U. Informática of the Technical University of Madrid (UPM), Spain since 2007. She received her PhD degree in Computer Science from the Polytechnic University of Valencia (UPV) of Spain in 2006. She had a Research Professional For-mation grant funded by the Spanish Government to perform her thesis. She is recipient of the best thesis Award in Computer Science and Tel-ecommunications of the UPV 2006-2007. She is member of the Systems & Software Technology Group (SYST) of the Technical University of Madrid (UPM). Since 2001, she is participat-ing in several European and national projects related to Software Engi-neering and Software Architectures. Her research interests are focused on agile methodologies, software archi-tectures, CBSD, AOSD, SPLs, MDD and software evolution.

Jessica Diaz Jennifer Pérez

1 Chow, T. and Cao, D. 2008. A survey study of critical success factors in agile soft-ware projects. J. Syst. Softw. 81, 6 (Jun. 2008), 961-971

2 Muhammad Ali Babar, Pekka Abraham-sson: Architecture-Centric Methods and Ag-ile Approaches. XP 2008: 242-243

3 Hanssen, G. K. and Fígri, T. E. 2008. Process fusion: An industrial case study on agile software product line engineering. J. Syst. Softw. 81, 6 (Jun. 2008), 843-854.

12 1�

User Stories for Agile Product Line Engineering ToolingThis article outlines some desired re-quirements (expressed as User-stories) for Agile Product Line Engineering tool-ing based both on industrial customer feedback and research conclusions. The objective is to study and show the Prod-uct Line and Agile processes combina-tion from a practical point of view.

Product Lines and Agile?Product commonality exploitation and appropriate variability management are challenges that many software-intensive companies are facing in order to be com-petitive. Precisely, the use of a common set of assets for product derivation is the key idea of Product Line (PL) Engi-neering.

Furthermore, these companies should face another issue that affects their product family definition. This problem is in the spotlight of the Agile meth-odologies and consists in dealing with changing markets and, as consequence, changing products requirements. On the contrary, PL Engineering is com-monly seen as a very heavy weighted process with a strict planning right from the beginning. Therefore, the fact is that combining these two disciplines, in what is known as “Agile PL Engineer-ing”, is an actual challenge aligned with software-intensive companies’ needs.

Reactive techniques represent here an interesting approach. Basically, these techniques propose the implementation of only those assets needed in current products generation and deployment. In this approach, the PL scope grows with customer demands and the benefits of the extra work required to make those assets reusable will be obtained in fu-ture product deliveries. In this way, cus-tomer value is taken into account and at the same time, the PL is being enriched through new reusable assets.

As a summary, in Agile PL Engineering, for each iteration the team implements the most relevant PL assets while con-stantly delivering the most valuable com-bination of products for the customers. Many research efforts can be found in this field, some even include industrial success stories. Nevertheless, there are still a lot of challenges and PL devel-opment tools should be ready for the adoption of the proposed practices.

User storiesAs a PL development team member, I would like…

… advanced visualization features that show the whole PL architecture. It should be easy to distinguish between the already implemented assets and those that are identified or planned but have not yet been implemented. Also er-rors, warnings and inconsistencies in the assets’ structure and connections, previ-ously modelled, should be easily shown.

…a team working platform that in-cludes collaborative real-time editors, not only editing text-based assets, but also modelling assets through diagrams.

…an integrated Backlog system that allows an easy planning game for each iteration. In addition, iteration tasks should be directly related with assets and the PL tool features to be used for doing my work.

…to have a PL tool tailored to the role that I play in the PL development. Since many roles are involved in PL develop-ment, I would like a tool not polluted with irrelevant features.

… to have many refactoring features. For instance, changes or addition of vari-ability points of the PL domain should guide me through a wizard to update the transformation assets that interprets that variability. Also, changes in this domain variability model could affect current concrete product models.

…Validation features to validate the assets at very early development stages.

…Assets evolution management features that allows easily changing from one version to another.

…Automatic documentation genera-tion. In a Model-Centric approach, mod-els are active assets and at the same time they are also documentation themselves. Nevertheless, if it is required, I would like to generate text-based specifications of the PL, the assets and the concrete prod-ucts models.

As a Quality engineer, I would like…

… a waste diagnosis system that detects Waste in the architecture or in concrete assets and guides me through a resolution process. Examples of waste could be extra or never used product fea-tures.

…to be reported with useful PL metrics. Apart from the PL classic metrics, I am particularly interested in those related to the PL evolution as a whole.

As a Testing engineer, I would like…

…an integrated Testing platform that assures me that each product com-bination passes the unit, integration and functional testing. The testing as-sets should be explicitly identified and it should allow me to start a PL Test Driven Development.

… to have a Traceability model that relates the variability points of concrete products model to the parts of its gener-ated code.

As a Customer, I would like…

... a Decision taking editor to actively collaborate in the definition of my con-crete product. An editor that uses graph-ic representations of my domain-specific requirements will improve the interaction with the rest of the PL team.

… to get the optimal product from the PL given the quality attributes that I am interested in. This should be pos-sible including domain-relevant quality attributes inside the assets for product derivation.

ConclusionAgile PL engineering seems to be the right thing to do in some scenarios, but for doing it right the use of appropriate tooling is needed. The implementation of the presented user stories represents a competitive advantage for these compa-nies.

Jabier Martinez

About the authorJabier Martínez is a Research Engineer at the Embedded Soft-ware department of the European Soft-ware Institute. He is the Scrum Master of the PLUM (Product Line Unified Mod-eller) development team and also of the PLUM industrial usage projects.

14 15

System Operation Model to Drive Software-intensive System Development in Agile

Acceptance testing is an essential prac-tice in agile methodologies. Early ex-ecution of acceptance tests helps in achieving more agility in the system de-velopment process because on the one hand, development cost and time can be reduced by detecting and correcting cer-tain errors “better sooner than later”; and, on the other hand, the customer satisfac-tion can get a profit from this.

However, before executing acceptance tests, tests have to be written, and a test infrastructure produced and deployed. While for some kind of systems, writing tests and implementing the test infrastruc-ture systematically is relative easy, it is not always the case for software intensive systems. This article promotes the idea that, for software intensive systems, the modelling of the user / system interaction may significantly help system develop-ment. As it is explained within this article, user / system interaction models can be naturally derived from user stories, and it is possible to advantageously include them as part of the agile approach.

Software intensive systems are com-prised of components and software that controls the behaviour of individual com-ponents, inter-component interaction, and the interaction with other systems, software services, devices or sensors. We find examples of this kind of systems in automotive, avionics, energy, health-care, home automation, travel and leisure support systems, etc.

These systems are characterized by of-fering some kind of interface that allows people to interact with them. The interac-tion between people and the system can be defined in terms of inputs and outputs of the system, through a user-oriented software interface. It is possible to define a formal model that takes into account these interactions, and this has been car-ried out with the name of “System Opera-tion Model” [1][2]. The System Operation model comprises the characteristics of the system interaction that the user per-ceives: system components, connections among components, and, for each com-

ponent, perceptible properties, inputs and outputs. The modelling and specifi-cation of user / system interaction inter-faces provide the customer and (the rest of) the development team with a common language, an operations language. Model-ling of operations can be understood as a simple domain specific language (DSL), yet useful to build the system incremen-tally. Additionally, from this DSL, system component simulators can be derived. These simulators can become part of the acceptance testing infrastructure. The simulators can be generated automatical-ly or or semi-automatically. The simula-tor generation process can be performed at each new iteration. This generation is possible applying MDD (Model Driven De-velopment) techniques. In our research group SYST we have already created the first version of a tool named Espora for creating operation specific language, and the basis for generating simulated com-ponents.

According to our experience, user sto-ries provide an excellent basis for defin-ing the system operation model, and then the DSL. This language is common to the customer and development team. There-fore, system operations models can as-sist in driving the development process under an agile process.

In the project Flexi this approach has been used for the development of a sys-tem prototype for testing and operating biogas power generation plants. This development meant the evolution of an existing software system named TOPEN. Scrum was the agile methodology used to carry out this evolution project.

About the authorsPedro P. Alarcón is an associate professor at E.U. Informática, Uni-versidad Politécnica de Madrid, Spain. He has participated in several European and national projects related to Software Engineer-ing and System Testing and Valida-tion. He focused his PhD on system operations modeling and his present research interests include agile soft-ware development, system and soft-ware testing processes and tools, and system operation modeling.

Pilar Rodríguez is a researcher is a re-searcher in software engineering at the Department of Infor-mation Processing Science, University of Oulu. Before that, she has worked in several international and national projects in System and Software Tech-nologies Research Group at Techni-cal University of Madrid. Her research interests include software engineer-ing, software process assessment and improvement, agile development approaches and requirements engi-neering. She received her MS in In-formation Technologies by Technical University of Madrid, Spain.

Agustín Yagüe is an Associate Professor at E.U. Informatica (Infor¬matics Engi-neering), Universidad Politécnica de Madrid, Spain.His re¬search interests include software processes, software processes improve¬ment, project management, agile develop-ment ap¬proaches, system and soft-ware testing processes and tools. He is member of AENOR, the Spanish association for standardization.He is working in the technical commit-tee about “Information Tech¬nology” AEN/CNT71. Subcommittee SC-07: “Soft¬ware Engineering and Informa-tion Systems”.

Pedro P. Alarcón, Pilar Rodríguez, Agustín Yagüe

[1] Alarcón, P.P.: “Specification of a model of operation applicable to processes of de-velopment and operation of systems with software”. PhD thesis (in Spanish). Facultad de Informática, Universidad Politécnica de Madrid (2008).

[2]. Alarcón, P.P., Garbajosa, J.: “Identify-ing application key knowledge through sys-tem operations modeling”. Proceedings of ICCI’07, Lake Tahoe, California, IEEE CS Press (2007).

14 15

Industrial Agile Workshop in VästeråsWorkshop purpose Agile and lean development was the theme for an industrial workshop with more than 50 participants held in Västerås, Sweden in February. The work-shop, organized by the Swedish FLEXI consortium members Mälardalen Univer-sity and ABB, had a two-fold purpose: to disseminate information from the FLEXI project to industry, and to share experi-ences between workshop participants.

The workshop consisted of four parts. In the first, a general introduction of agile and lean was given, including a Scrum overview. The second part consisted of experiences from different companies. FLEXI results where presented in the third, and the workshop was concluded with a discussion in groups.

ParticipantsThe workshop attracted participants from a large number of companies including CC Systems, Combitech, Enea Zealcore, Ericsson, Saab Aerotech, Saab Systems, Scania, ÅF consult, and ABB. In addition, Vinnova, the funding agency responsible for the Swedish national FLEXI funding, was represented.

As some of the participants had none or very limited knowledge and experience of agile and lean, the workshop started with a tutorial, providing an overview of agile and lean product development. The main focus of the tutorial was the agile principles, and the components of Scrum as an example of an agile method.

Sharing experiencesThe second part of the workshop was highly interactive, with a discussion

sparked by a set of experience presenta-tions from Enea Zealcore, F-Secure and NSN. The discussion primarily covered topics that have been discussed fre-quently in the FLEXI project, and where we are currently trying to find, or in the process of finding, solutions to obstacles or challenges in scaling agile methods. The topics discussed included distribu-tion of teams, e.g. practicalities of how to run Scrum meetings with two locations in different time zones, how to manage Scrum teams as a part of larger projects where the majority of activities are run in a traditional way, and how to get a Scrum of Scrums organization to work.

FLEXI results presentedAs a response to the discussions around experiences, examples of the FLEXI project results were presented. Topics from WP1, WP2, and WP� were covered, with a specific focus on research results on innovation, product portfolio manage-ment, and the influence of agile develop-ment on project management, testing, and software architecture. Furthermore, the Innobar, PLUM, and Releaseious tools were demonstrated in a bazaar dur-ing a coffee break.

Discussion on applicabilityIn the final part of the workshop, the par-ticipants were divided into groups to dis-cuss whether the principles, methods, and tools that had been presented would be applicable in their respective organi-zations. In addition, the participants where asked to share any experiences of agile or lean methods. A general conclu-sion from these discussions is that the methods seem to be applicable in most

organizations, but that the questions raised regarding a larger context still need more answers.

As a concluding remark, the response from the participants was very positive. In particular, the sharing of experiences from FLEXI companies as well as be-tween the participants was highly ap-preciated. Also, the insight into what is coming from FLEXI was mentioned as beneficial. A similar event is planned for the autumn when the FLEXI project is closer to completion.

Stig Larsson,

Daniel Sundmark

About the authorsStig Larsson is Global Process Improvement Manager at ABB Sub-station Automation Products. He received his PhD in Computer Science and Engineering at Mälard-alen University. His professional ex-perience includes software product development for more than 25 years in different positions as software de-veloper, integrator, project manager and manager. In recent years Stig has focused on product development processes, trying to understand how product development can be made faster and easier. Special interests include distributed development and the symbiosis between architecture and processes.

Daniel Sundmark re-ceived his PhD in Computer Science and Engineering from Mälardalen Univer-sity in early 2008, and has since been work-ing there as a researcher. In his re-search, Daniel focuses on testing, monitoring and debugging of in-dustrial software systems. Special interests include debugging of mul-ti-tasking and multi-core systems, effectiveness and efficiency in soft-ware testing, and empirical research on software testing in general.

16 17

Improving Software Development Using CMMI Goals and Agile Practices

Minna Pikkarainen

There is an increasing need for software in all industrial domains in Europe [7]. One can see this growth as a part of eve-ryday life as software is more used in ambulances, hospitals, mobile applica-tions and home electronics. The need for software offers companies especially in small countries opportunities to work as software suppliers in international mar-kets [10]. In the situation of high competi-tion, the profits are going to the company that can most rapidly produce customer value. This demands an organizational ability to be agile and to produce error free software products.

Standards and models such as CMM/ CMMI (Capability Maturity Model Integra-tion) [�] provide ready, empirically evalu-ated solutions for the software process improvement. [6, 12, 14]. It is shown that the CMM based software process im-provement programs have brought com-panies even 28–5�% of improvements in lead time and 70 to 74% of improvement in quality measured by the amount of de-fects [6]. The use of CMM/ CMMI is, how-ever, highly criticized among the peo-ple in software enterprises. Often, CMM model based software process improve-ment programs are reported to be too time consuming and expensive [5]. Fur-thermore, needs of individual developer are often forgotten in the software proc-ess improvement programs [8]. Wrong use of CMM can even leads to a situation in which the developers implement more documents than the actual software code [2].

Agile methods have been increasingly used in software development compa-nies. For example F-Secure reported that the use of agile methods such as short cycles, continuous planning and daily meetings have brought them even 50% improvements in software quality [1] .One problem in the agile methods is their time-consuming deployment which can lead to the situation in which one half of the company does not know what the other is doing [4]. This is because the deployment of agile methods signifies a large change to companies [9]. Most of the companies, however, do not have a possibility to invest in the large process assessments or programs [11]. In gener-al, people, especially in industries seem to believe that “CMMI and agile methods are like oil and water” [15] like opposite elements that should not be mixed to-gether as a part of the software process

improvement. SEI [1�] has published a report arguing that there is compliance between the CMMI model and agile meth-ods. The validity of this argument has not, however, been proved as a part of the empirical research.

Goal of the work

The goal the research was to increase understanding in this research field. This was done by focusing on the research question: ‘How to improve software de-velopment process mediated with CMMI goals and agile practices from commu-nication perspective?’ The research was done step by step based on the case study method that was applied in four case companies. Two of the companies were doing devices for Telecommuni-cation area. Third company was doing information security systems whereas fourth company was working in highly safety critical, automotive system devel-opment field.

Findings

Hybrid, agile assessments provide practical improvement suggestions for software companies

In several companies, hybrid assess-ments were seen as a useful mechanism to find both agile and traditional improve-ment suggestions for software develop-ment process. When companies worked in the traditional manner, their biggest challenges were:

1—To produce software that do not ful-fil the needs of the customer or product management

2—Documentation driven communica-tion (message was disappearing on the way)

�—Developers working continuously ex-tra hours due to the fixed content, sched-ule and cost environment

4—High amount of defects in integration testing phase which was after years of development

5—Unmanaged changes (customers do not remember their own demands)

Due to provided assessments, all com-panies were able to significantly im-prove their working practices. In the new achieved process, for instance, content of the product (i.e both requirements and change requests) were analysed in sys-

tematic face to face meetings together with customers, product management and developers.

The results of Iteration retrospec-tives can be utilized as a part of the assessment data.

Iteration retrospectives were used in three of the case companies. In some companies the data of iteration retrospec-tives were collected and used also when in the analysis of the improvement needs of development teams during the as-sessments. This gave a much larger view of the project work in the longer period than the typical face-to-face interviews. Compared to the normal iteration retro-spectives, assessments helped teams to come together and share information about the challenges and solutions in-side and between the companies.

Agile software development is chal-lenging and needs to be improved using well established reference models.

It is possible to integrate CMMI and agile in a framework that helps assessors to evaluate the status of the software devel-opment teams. All of the evaluated teams had major challenges that need immedi-ate improvement to assure the rapid de-velopment of high quality software. Some of the challenges that was common to most of the agile case companies:

1—Component interface management is difficult in agile teams. There is a need for additional documentation of the com-ponents and their interfaces

2—Organizational level processes do not support agile-type software develop-ment

�—Customer and part of the manage-ment are not committed to agile develop-ment, they are not involved enough in the project planning and monitoring work

Some of these challenges might be pos-sible to solve using CMMI framework which for instance gives some practi-cal suggestions for feature dependency management, risk management and stakeholder coordination at organiza-tional level.

Dr. Minna Pikkarainen, VTT, Technical Research Centre of Finland

Acknowledgements:

This article is based on dissertation on Improving Software Development Proc-

A Research Agenda for Agile Software Development

Over the past ten years, since the first XP-conference at Sardinia in 1999, the idea of agile software development have spread to almost every corner in the software engineering field. Hardly no professional software developer have not at least heard about the basic ideas which have been described in a flow of books, papers, websites, conferences, workshops and training courses. Beside this huge interest and development in industry, researchers have followed the introduction of agile methods over these ten years – it is opportune to ask: what have we learned so far? And, how should research on agile software development proceed?

There exist a few reviews that seek to present an overview of the research that has been done. The most recent is a review of all studies of agile software development methods (excluding single techniques) from the very start and up to, and including 2005. It draws a rather de-pressing picture of the state of research on agile methods. Indeed, a large number of publications address agile software development methods in some way, but only a very few reports present results based on thorough empirical research. Consequently, only �� studies form the basis of the review, which grouped the findings in four thematical categories; introduction and adoption of agile meth-ods, human and social factors, (subjec-tive) perceptions on agile methods and comparative studies. More studies, cov-ering other aspects have off course been done since 2005, but the impression is that empirical research on agile methods are still immature – a situation that has to improve for the software industry to reach the potential that lies in agile meth-ods .

Trying to predict the need for future re-search is a difficult task as there are many factors to consider, such as technology development, the maturity of ongoing re-search, the market situation etc. To get a rough impression of the industry’s needs the FLEXI project did a simple survey at a FLEXI project meeting in Bilbao in Feb-ruary. All industry participants (1� com-panies) were asked to describe and pri-

oritize the three most important research issues for the near future. We grouped the answers and weighted them accord-ing to priority. The bar-chart shows the scores for the eight top issues.

ILLUSTRATION HERE

The top three issues clearly relates to

large-scale software development and software product development. This is aligned with the general impression of how the use of agile methods is evolv-ing; core practices and techniques are now well understood, the challenge lies in how to align this with the rest of the business. The FLEXI project have already dived deep into this complexity and the message from the industry is clear – con-tinue along that path!

Geir K. Hanssen

16 17

esses Mediated with CMMI and Agile practices, the defence was success-fully held in University of Oulu at 10.11.2008. Special thanks for supervi-sors: Pekka Abrahamsson and Samuli Saukkonen and opponent: Brian Fit-zgerald.

PhD thesis available at: http://www.vtt.fi/inf/pdf/publications/2008/P695.pdf

References[1] Agile Newsletter, “http://www.agile-itea.org,” (2005).

[2] Boehm and Turner, “Balancing Agil-ity and Discipline,” in Balancing Agility and Discipline -A Guide for the Perplexed: Addi-son Wesley, pp. �04. 200�

[�] Cmmi, “Capability Maturity Model® In-tegration for Development, Version 1.2, Technical Report CMU/SEI-2006-TR-008, http://www.sei.cmu.edu/publications/docu-ments/06.reports/06tr008.html,” CMU/SEI-2002-TR-002 ed: Software Engineering Insti-tute, (2006).

[4] Cohn and Ford, “Introducing an Agile Process to an Organization,” IEEE Compu-ter, vol. �6, pp. 74-78, (200�).

[5] Fayad and Laitinen, “Process Assess-ment Considered Wasteful,” Communica-tions of the ACM, vol. 40, pp. 125-28, (1997).

[6] Galin and Avrahami, “Are CMM Pro-gram Investment Beneficial? Analysing Past Studies,” IEEE Software, vol. 2�, pp. 81-87, (2006).

[7] Itea, “http://www.itea2.org/attach-ments/150/ITEA_SIS_in__the_future__Fi-nal_Report.pdf,” (2005).

[8] Laitinen and Fayad, “ Surviving a proc-ess performance crash,” Communications of the ACM, vol. 41, pp. 8�-86, (1998).

[9] Lindvall, Muthig, Dasnino, Stupperich, Kiefer, and Kähkönen, “Agile Software De-velopment in Large Organizations,” Com-puting Practices, vol. �7, pp. �8-46, (2004).

[10] Mccaffery, Pikkarainen, and Ri-charsson, “AHAA -Agile, Hybrid Assess-ment Method for Automotive, Safety Critical SMEs,” presented at ICSE 2008, Leipzig, Germany, (2008).

[11] Mccaffery, Taylor, and Coleman, “Adept: A Unified Assessment Method for Small Software Companies,” IEEE Software, vol. 24, pp. 24-�1, (2007).

[12] Niazi, Wilson, and Zowghi, “A ma-turity model for the implementation of soft-ware process improvement: an empirical study,” The Journal of Systems and Soft-ware, pp. 1-18, (200�).

[1�] Sei, “http://www.sei.cmu.edu/pub/documents/08.reports/08tn00�.pdf,” (2008).

[14] Stelzer and Mellis, “Success Fac-tors of Organizational Change in Software Process Improvement,” Software Process Improvement and Practice, vol. 4, pp. 227-50, (1998).

[15] Turner and Jain, “Agile Meets CMMI: Culture Clash or Common Cause,” presented at 1st Agile Universe Conference, Chigago, (2002).

About the author

Geir Kjetil Hans-sen works as a researcher on software process improvement and methodologies at SINTEF ICT, Norway’s largest

independent research institution. He has a M.Sc. degree in informat-ics from the University of Trondheim and � years of industrial experience. Currently he also holds a position as Ph.D.-student at the Norwegian University of Science and Technol-ogy. Contact him at SINTEF ICT, No-7465 Trondheim, Norway; geir.k.hanssen@sintef.no.

2009Dybå, T.; Dingsøyr, T.. Strength of Evi-dence in Systematic Reviews in Soft-ware Engineering, ESEM 2008, Kaiser-slautern, Germany,

Diaz, J.; Garbajosa, J.; Calvo-Manzano, J.A.. Mapping CMMI Level 2 to Scrum Practices: An Experience Report, Eu-roSPI 2009, Spain,

Tourwe, T., Codenie, W.,Boucart, N., Blagojevic, V. Demystifying Release Def-inition: From Requirements Prioritization to Collaborative Value Quantification , 15th International Working Conference on Requirements Engineering: Founda-tion for Software Quality , Amsterdam, The Netherlands, June, 2009

Díaz, Jessica; Yagüe, Agustín; Garba-josa, Juan. . A Systematic Process for Implementing Gateways for Test Tools, 16th Annual IEEE International Confer-ence and Workshop on the Engineering of Computer Based Systems (ECBS), San Francisco, CA USA., April 2009

Codenie, W., Gonzalez-Deleito, N., De-leu, J., Blagojević, V., Kuvaja, P, Simila, J. A Model for Trading off Flexibility and Variability in Software Intensive Product Development , Third International Work-shop on Variability Modelling of Soft-ware-intensive Systems , Sevilla, Spain, January, 2009

Hanssen, G. K.; Haugset, B.. Automated Acceptance Testing Using Fit, HICSS 2009, Hawaii, USA,

2008Jennifer Perez, Agustin Yague, Lourdes Riestra, Pablo Ortiz . Toward flexible acceptance testing tools using service discovery, 6th Workshop on System Testing and Validation, Madrid, Spain, December 2008

Järvilehto, M.V., Ritala, P., Similä, J., Hyysalo, J., and Kuvaja P.. Building a conceptual framework for communica-tive and involving innovation process, The 1st ISPIM Innovation Symposium, Singapore, 14-17 December 2008

Conboy, K.; Coyle, S.. People Over Process: The Implications of Agile for IS Skills and Human Resource Man-agement. Proceedings of the MISQe Workshop, International Conference in Information Systems, Paris, France, De-cember 13th, 2008

Conboy, K.. Study Of Tight Budgetary Control In Information Systems Projects, International Conference in Information

Systems, Paris, France, December 13th, 2008

Conboy, K.; Acton, T.; Halonen, R. Data Presentation for Agile IS Project Deci-sion-making, International Conference in Information Systems, Paris, France, December 13th, 2008

McHugh, O.; Conboy, K.; Lang, M.. For-mal And Informal Controls In Agile Sys-tems Development Projects, Internation-al Conference in Information Systems, Paris, France, December 13th, 2008

Martinez, J. & Vicedo, J.. PLUM (Prod-uct Line Unified Modeller) Eclipse based variability management tool, Eclipse Summit Europe 2008, Ludwigsburg, Germany, November 19-20, 2008

Tom Tourwe, Wim Codenie . Release definitie voor software-intensieve pro-ducten: een steeds weerkerend dilem-ma voor productmanagers, , ,

Nick Boucart, Wim Codenie, Tom Tour-we. Stemmen als release management van producten , , ,

Steyaert, P., Bollen, W. Eliminating Waste, XP Days Benelux 2008, Veld-hoven, The Netherlands, November 2008

Ana Petricic, Ivica Crnkovic, and Mario Zagar. Models transformation between UML and a Domain Specific Language, 8th Conference on Software Engineer-ing Research and Practice in Sweden (SERPS 08), Karlskrona, Sweden, No-vember 2008

Blagojević, V., Biot, O., Boucart, N., Codenie, W.. Is your team within the comfort zone of Scrum? , XP Days Ben-elux 2008, Veldhoven, The Netherlands, November 2008

Abrahamsson, P.; Conboy, K.; Wang, X.. European Journal of Information Systems Special Issue on Agile Proc-esses, , ,

Barry, C., Lang, M., Conboy, K. Wo-jtkowski, W., & Wojtkowski, G.. The Inter-Networked World: ISD Theory, Practice, and Education,

Kettunen, P.; Laanti, M.. Combining Ag-ile Software Projects and Large-scale Organizational Agility , , ,

Koponen, J.. Agile Release Planning in a Product Backlog Tool, , Finland,

Similä, J.; Järvilehto, M.:; Kuvaja, P.. Open Innovation and Agile Develop-ment from a Process Perspective, The XIX ISPIM annual conference 2008, Finland,

Similä, J,; Järvilehto, M.; Leppälä, K.;

Haapasalo, H.; Kuvaja, P.. Modelling and Evaluating Open Innovation as Communicative Action, , Finland,

Dybå, T.; Dingsøyr, T.. Empirical studies of agile software development: A sys-tematic review, , ,

Oinas-Kukkonen, Henry; Similä, Jouni; Pulli, Petri; Oinas-Kukkonen, Harri; Kerola, Pentti. Impact of Information Systems and Software Engineering on the Development Oulu ICT during 1985-1990, History of Nordic Computing 2, IFIP WG9.7 Second Working Confer-ence on the History of Nordic Computing (HINC2), , 2008

Hongyu Pei Breivold, Ivica Crnkovic, Ri-kard Land, Magnus Larsson. Analyzing Software Evolvability of an Industrial Au-tomation Control System: A Case Study, 3rd International Conference on Soft-ware Engineering Advances (ICSEA), ,

Oinas-Kukkonen, Henry; Kerola, Pentti; Oinas-Kukkonen; Harri, Similä, Jouni; Pulli, Petri. Information Systems and Software Engineering Research and Education in Oulu until the 1990’s, His-tory of Nordic Computing 2, IFIP WG9.7 Second Working Conference on the History of Nordic Computing (HINC2), , 2008

Wim Codenie, Nicolás González-Deleito, Jeroen Deleu, Vladimir Blagojević, Pasi Kuvaja, Jouni Similä . Managing Flexibil-ity and Variability: a Road to Competitive Advantage , , ,

Nick Boucart, Wim Codenie, Tom Tour-we . What is our next product release? May I have your votes please!, , ,

Séverine Sentilles, Aneta Vulgarakis, Tomas Bures, Jan Carlson, and Ivica Crnkovic. A Component Model for Con-trol-Intensive Distributed Embedded Systems, 11th International Symposium on Component Based Software Engi-neering (CBSE2008), Karlsruhe, Ger-many, October 2008

Rodríguez, Pilar; Alarcón, Pedro P.; Gar-bajosa, Juan . Identification of Hidden Requirements from Failed System Test Execution, 6th Workshop on System Testing and Validation, Madrid, Spain,

Rodríguez, Pilar; Yagüe, Agustín; Alarcón, Pedro P.; Garbajosa, Juan. . Agile Methodologies from the perspec-tive of functional and non-functional requirements specification, 13th Con-ference on Software Engineering and Databases (JISBD’08), Gijón, Spain, October 2008

Rodríguez, Pilar; Yagüe, Agustín;

Alarcón, Pedro P.; Garbajosa, Juan. . Agile Methodologies from the perspec-tive of functional and non-functional requirements specification, 13th Con-ference on Software Engineering and Databases (JISBD 08), Gijón, Spain, October 2008

Rodríguez, Pilar; Yagüe, Agustín; Alarcón, Pedro P.; Garbajosa, Juan. . Agile Methodologies from the perspec-tive of functional and non-functional requirements specification, 13th Con-ference on Software Engineering and Databases (JISBD 08), Gijón, Spain, October 2008

Kuvaja, P.;Similä, J.;Hanhela, H.. Soft-ware Production Line Adoption - Guide-lines from a case Study, IFIP-TC3 Con-ference CEE-SET 2008, Brno, Czech Republic, October 13, 2008

Sundmark, D.;Carlson, J.; Punnekkat, S.; Ermedahl A.. Structural Testing of Component-Based Systems, The 11th International Symposium of Component-Based Software Engineering, Germany, October 2008

Slattery, S., Rooney, M, Tracey, F., Staunton, C., McHugh, O. . A study of XP & Scrum: A Project Management Perspective, 3rd International Business Informatics Challenge and Conference,, Dublin City University, Ireland, Septem-ber 25th, 2008

Hongyu Pei Breivold, Ivica Crnkovic, Rikard Land, Stig Larsson. Using De-pendency Model to Support Software Architecture Evolution, 4th International ERCIM Workshop on Software Evolu-tion and Evolvability (Evol’08), ,

Sundmark, D; Thane H.. Pinpointing Interrupts in Embedded Real-Time Systems using Context Checksums , The 13th International Conference on Emerging Technologies and Factory Au-tomation, Germany, September 2008

Land, R.; Alvaro, A.; Crnkovic I.. To-wards Efficient Software Component Evaluation: An Examination of Compo-nent Selection and Certification, Euromi-cro SEAA SPPI Track , Italy, September 2008

Markus Lindgren, Rikard Land, Christer Norström, and Anders Wall. 1. A Method for Balancing Short- and Long-Term Investments: Quality vs. Features, 34th Euromicro Conference on Software En-gineering and Advanced Applications, Parma, Italy, September 2008

Séverine Sentilles, John Håkansson (Uppsala University), Paul Pettersson, and Ivica Crnkovic. Save-IDE – An In-

FLEXI publications

18 19

tegrated development environment for building predictable component-based embedded systems, 23rd IEEE/ACM International Conference on Automated Software Engineering (ASE 2008), L’Aquila, Italy, September 2008

Mikael Åkerholm, Kristian Sandström, and Ivica Crnkovic. Introducing Com-ponent Based Software Engineering at an Embedded Systems Sub-Contrac-tor, 34th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), Parma, Italy, Sep-tember 2008

Séverine Sentilles, Florian Noyrit, and Ivica Crnkovic. Collaboration between Industry and Research for the Introduc-tion of Model-Driven Software Engineer-ing in a Master Program, Educators Symposium at the 11th International Conference MODELS 2008, Toulouse, France, September 2008

Angelina Espinoza; Juan Garbajosa. Metamodel Hierarchy as a Supporting Paradigm for Defining Effective Trace-ability Methodologies, 16th IEEE In-

ternational Requirements Engineering Conference (RE08), Barceolona, Spain, September, 8-12, 2008

Hongyu Pei Breivold, Stig Larsson, Rik-ard Land. Migrating Industrial Systems towards Software Product Lines: Experi-ences and Observations through Case Studies, 34th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Software Proc-ess and Product Improvement (SPPI) Track, ,

Suominen, A., Jussila, J., Porkka, P., Vanharanta, H.. Interrelations of de-velopment needs between innovation competence and innovation culture, 6th International Conference on Manufac-turing Research (ICMR2008) , Brunel University , Brunel University, England, 9-11 September 2008

Moe, N. B.. Understanding Decision-Making in Agile Software Development: A Case-study, EUROMICRO 2008, Parma, Italy,

Moe, N. B.; Hole, S.. A Case Study of Coordination in Distributed Agile Soft-

ware Development, EUROSPI 2008, Dublin, Ireland,

Barry, C., Lang, M., Conboy, K.. Pro-ceedings of the 16th International Con-ference in Information Systems Devel-opment, ISD2007, NUI Galway, Ireland, August 29th-31st, 2007

Vladimir Blagojević, Wim Codenie, Je-roen Deleu, Olivier Biot . Beyond the Comfort Zone of Scrum , Research-in-progress workshop at the Agile 2008 Conference, Toronto, Canada, August 2008

Dingsøyr, T; Dybå, T; Abrahamsson, P.. A Preliminary Roadmap for Empirical Research on Agile Software Develop-ment, Agile 2008, Toronto, Canada, 4-8 August 2008

Haugset, B.; Hanssen, G. K.. Automated Acceptance Testing: a Literature Review and an Industrial Case Study, Agile 2008 Conference, Toronto, Canada,

Laanti, M.. Implementing Program Model with Agile Principles in a Large Software Development Organization, COMPSAC

2008, Turku, Finland, July 28 - August 1, 2008

Hongyu Pei Breivold, Ivica Crnkovic, Peter Eriksson. Analyzing Software Evolvability, 32nd IEEE International computer Software and Applications Conference (COMPSAC), ,

Vittorio Cortellessa (Università dell’Aquila), Ivica Crnkovic, Fabrizio Marinelli, and Pasqualina Potena. 2. Ex-perimenting the Automated Selection of COTS Components Based on Cost and System Requirements, July 2008

Suominen, A., Jussila, J., Vanharanta, H. . Hydro Power Plant – Metaphor for Innovation Culture, 2nd International Conference of Applied Human Factors and Ergonomics 2008, Las Vegas, Ne-vada, USA, 14 - 17 July 2008

Jussila, J., Suominen, A., Vanharanta, H.. Competence to Innovate?, 2nd Inter-national Conference of Applied Human Factors and Ergonomics 2008 , Las Ve-gas, Nevada, USA, 14 - 17 July 2008

Upcoming events 2009 Event Place Date Web

Open Agile Romania Romania, Bucharest, May 22-23, 2009 http://www.openagile.ro/

XP Day France 2009 France May 25-26, 2009 http://xpday.fr/

XP 2009 - 10th International Conference on Agile Processes & eXtreme Programming in Software Engineering

Sardinia, Italy May 26-30, 2009 http://www2.xp2009.org/xp2009/

CaiSE International Conference on Advanced Information Systems Engineering

Amsterdam, The Netherlands June 8-12, 2009 http://caise09.thenetworkinstitute.eu/

Profes 2009 Oulu, Finland June 15 - 17, 2009 http://www.profes2009.org/

Integrating Agile Conference Hoofddorp,The Netherlands June 18, 2009 http://agileconsortium.nl/en/conference.html

Agile 2009 Chicago, USA August 24-28, 2009 http://agilealliance.org/Agile2009/conference09.html

ESEA Euromicro International Conference on software engineering and applications - Service and Component-Based Software Engineering Track

Patras, Greece August 27-29, 2009 http://seaa2009.vtt.fi/scbse/

ICSEA International Conference on Software Engineering Advances

Porto, Portugal September 20-25, 2009 http://www.iaria.org/conferences2009/CfPICSEA09.html

EuroSPI European SPI Alcalá de Henares, Madrid, Spain

Sep 2009 http://2009.eurospi.net/

The IASTED International Conference on Software Engineering (SEA)

Cambridge, Massachusetts, USA

November 2 – 4, 2009 http://www.iasted.org/conferences/cfp-669.html

7th International Conference on Information Technology: New Generations ITNG 2010

Las Vegas, Nevada, USA April 12-14, 2010 http://www.itng.info

ICSE International

Conference on Software Engineering

Cape Town, South Africa May 2-8, 2010 http://www.sbs.co.za/ICSE2010/

18 19

PROUD PARTNERS OF AGILE 500

From idea to product in 6 months