NEWSLETTER 2/2008 • Contents:

This is the third issue of Flexi Newsletter. By the time this news-letter is published the the project Flexi will have crossed its equator, continuing and, as important, consolidating the ex-

pansion of agile to ever higher levels in global organizations. At the same Flexi is committed to the small, tackling those apparently low level issues that finally help organizations to address agile innovation successfully. The contents of this issue reflects all these facts.

Inside View columnist, Kent Beck, discusses how it is possible Mov-ing Into the Future by Honoring the Past; it should make us think twice. Large, global corporations issues are addressed in Kati Vilkki´s article in which she presents her experience in Nokia Sie-mens Networks on large scale agile transformation in Juggling with the paradoxes of agile transformation or how to survive in a large scale agile transformation – Part I. A complementary perspective

is introduced by Stig Larsson from ABB in Sharing technology in a distributed environment. To complete this analysis, a description of a number of NSN’s agile experiences: Giant is developing agilely and Agile in the Large.

We have also an article on What is our next product release? May I have your votes please! in which some problems to choose the right set of features to be included in a release are analysed. This is continued by an article that analyses why User stories and traditional requirements do not match, and A reflection on where we think we are in automated acceptance testing, and where we actually are: Automated acceptance testing – what’s on? And FLEXI Products & Technologies Suite: The Pipeline metaphor explained, provides some insight on the project methodological approach.

Juan Garbajosa, Editor-in-chief, Flexi Newsletter

agile in the large and very large

REAKTOR INNOVATION BOARD

Inside View: Moving Into the Future by Honoring the Past • Juggling with the paradoxes of agile transformation or how to survive in a large scale agile transformation • Sharing technology in a distributed environment • Nokia Siemens Networks’ agile experiences • What is our next product re-lease? May I have your votes please! • User stories and traditional Requirements not always match • Automated acceptance testing – what’s on? • FLEXI Products & Tech-nologies Suite The Pipeline metaphor explained • Reaktor Interview • Flexi Publications • Upcoming Events

� �

Moving Into the Future by Honoring the Past

INSIDE VIEW

Kent Beck

Agile development often requires a fundamental rethinking of current prac-tices. To those required to

change, this can seem like a revolution. Looked at another way, though, these changes can be an opportunity to revisit corporate truths, to strengthen them and adapt them to a new context. The rest of this brief note will examine this process in more detail.

Imagine a web-site developer working for a long-established hardware firm. When he encounters a problem with an error message on the site, he follows the established procedure for making changes, specifying in detail the pro-posed change and routing it through a sequence of commitees for review be-fore implementation.

Extensive vetting of each proposed change isn’t an effective approach to

web development. Customers annoyed with the error message and with several alternative sites will switch in far less time than it will take for a string of com-mitees to refine and polish a response. The market needs a quicker response.

An agile team has the capability of pro-viding a quicker response, supported by

integrated testing, incremental design, and a team social structured tuned to embrace change. However, they quickly become able to produce changes at a faster rate than their organization is prepared to handle. The market and its need for responsiveness stands in con-flict with the organization and its need for order, predictability, and the embed-ded wisdom of established practices.

Some teams respond to this conflict by revolution, throwing over established practices and instituting practices that suit their own needs and those of the market. This slows (and sometimes stops) the acceptance of agile devel-opment, as the rest of the organization struggles to understand these strangers in its midst. Agile teams have an alterna-tive, though, one that meets the needs of the organization as a whole as well as their needs and those of the market.

The sequence of review commitees cited above meets a variety of needs. By stepping back, noting these needs, and honoring these same purposes, the team can find practices that address a broader community. In this case, the review commitees not only refine a solution, they also inform and allow participation by a large number of peo-ple. While in web development, unlike hardware development, it is common to iterate on a solution rather than wait for concensus, the corporate need to inform and include a wide community remains. Saying, “We need to go fast, so just let the programmer decide,” ignores this need, setting up the team for failure.

Treat mismatches of existing practice and agile development as an opportu-

nity to go back to the corporate roots. Discover the history and purpose of current practices. Sift those practices through the sieve of agile development, keep what is still relevant, discard what is not, and (importantly) introduce new practices that serve the important pur-poses of the discarded practices.

In doing this, we have found it valuable to separate practices, which are concrete and context-specific, from principles and values. While the practices may change substantially in applying agile develop-ment, and some new principles will be required (such as the principles of itera-tion cited above), the values of the or-ganization are unlikely to change.

How can our programmer faced with an awkward error message proceed? Part of the purpose of the existing practice of review commitees is to make sure eve-ryone with a stake in the project knows about changes. Perhaps this need could be met by broadcasting changes to in-terested parties. The development team would accept the responsibility for re-cording the purpose and consequences of each change along with implementing them. Another purpose of the existing practice is to inform each change with multiple perspectives. Perhaps with the addition of iteration, this need could be

met by having two or three people col-laborate on the change. The goal in both cases is to serve the spirit of the existing practice, to meet the needs of the organization, and to take advantage of the new capabilities offered by agile development at the same time.

About the author:Kent Beck is the founder and director of Three Rivers Institute (TRI). His career has combined the practice of software development with reflection, innovation, and communication. His contributions to software develop-ment include patterns for software, the rediscovery of test-first program-ming, the xUnit family of developer testing tools, and Extreme Program-ming. He currently divides his time between writing, programming, and coaching. Beck is the author/co-author of Implementation Patterns, Extreme Programming Explained: Embrace Change 2nd Edition, Con-tributing to Eclipse, Test-Driven De-velopment: By Example, Planning Extreme Programming, The Small-talk Best Practice Patterns, and the JUnit Pocket Guide. He received his B.S. and M.S. in Computer Science from the University of Oregon.

New

Retained

Discarded

Practices Principles Values

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 definition, 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.

We would also appreciate if you could inform colleagues or other people you know who might also be interested in receiving our newsletter.

� �

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

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 Systems and Serv-ices (SiS).ITEA 2 stimulates and supports projects that will give European industry a lead-ing edge in the area of SiS (in which software represents a significant seg-

ment in terms of system functionality, system development 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 investment . This ambition is based on experience in ITEA, the need to further close the gap

in R&D investment (3% of GDP, Lisbon objective) and the ever growing impor-tance of SiS.As one of the main EUREKA cluster programmes ITEA 2 has close links with other EUREKA projects and the Frame-work Programmes of the European Commission. Our projects are support-ed financially by all 37 members of the EUREKA framework.

Juggling with the paradoxes of agile transformation or How to survive in a large scale agile transformationKati Vilkki

In my key note speech in XP 2008 conference I talked about some of the paradoxes I have observed in the agile transformation first in Nokia Networks and now in Nokia Siemens Networks during the past 3.5 years. In this article I want share my experiences of working with some of the paradoxes as a change agent in our agile transformation.

Paradoxes of agile transformationTo me agile transformation is about making a paradigm shift in the way we see product development, to chal-lenge many of the fundamental beliefs we have about the nature of software development, about the best way to manage people and to run programs. It is first and most a cultural and mind set change – and full of paradoxes.

I have found complexity theory very useful framework to use in change management; our approach is a com-bination of agile values and principles and complexity theory applied to change.

Cultural changeOrganizational culture needs to change in any big transformation and it also has a huge impact on how to

drive changes. E.g. in some organizational cultures it is possible to start by inviting people to a training session and then encourage any one interest to start trying the practices out. In other cultures this approach does not work at all; people would not do anything without an order, permission or at least letter of recommendation from their managers.

In order to change the culture the change process has to reflect the desired result. A good starting point in ag-ile transformation is to think about how the agile values and principles could be applied to the change process.

Those parts in organizational culture, which really need to be changed, are the ones, which will block the change and stop the transformation process. Paying attention to these parts in the culture pays off. E.g. if your starting point is ad hoc, hacking type of development, then you should pay special attention to building enough struc-ture and discipline into the change process.

In big organizations, which have long history in water-fall development (like ours), one of the main cultural obstacles is big releases –thinking; heavy upfront plan-ning (with analysis paralysis) and the inability to change anything because everything needs to change and eve-rything is connected – and you can’t change everything at once in a big organization. The most important thing

there is to get started with something: with one or two teams, with some practices – with anything the get the learning process going, and then grow from there. We have tried to promote “start next Monday” –thinking.

Another aspect of organizational culture, which often requires change, is “command and control” type of management. This is often so inbuilt in management structures and in thinking, that it is very difficult to know where to start changing it. One good place is in setting the transformation team; it should include people from all functions and all levels of the organization. We often have to do quite a bit of convincing to get developers and testers invited in agile kick-off workshops, where organizations discuss and plan how to get started.

Similar enough and different enoughThe key messages of the change and the way of de-livering them have to be different enough and similar enough to the existing culture. If the message is too distant from the current reality, people will perceive it as unrealistic and do not trust the change. On the other hand, there has to be real change and the message has to reflect that.

This also means that the change message has to reflect

� �

the changing reality and that the message changes as we proceed. To give an example: we started by talking about agile and iterative development, and the empha-sis was on “iterative”. At that time this message was different enough. When the concept of iterative was understood and we had some experience, we moved the emphasis on agile practices. Now we are talking about agile and lean and extending the scope outside of product development.

The balance between similar enough and different enough is a dynamic one. There should all the time be some tension, but only as much as the organization can handle. If the tension becomes too big, the anxiety in organization becomes too great and the there is big risk that the transformation is stopped.

One of the key things for a change agent to do is to all the time observe the tension and the anxiety level in organization. Different organizations, teams and in-dividuals have also different pain thresholds; some can tolerate more “change pain” than others.

The interesting thing about changing the culture is that in order to change it you have to challenge some ba-sic belief and values. Actions reflect values and values become real in actions. Therefore it is so important to continuously think about on what kind of values our ac-tions indicate – and what kind of actions would better reflect the new values we want to introduce.

The biggest difficulty in making a cultural change is that we all are results of our own organizational culture; we live it, we breath it and we take it for granted. It’s very difficult to even start observing your own organizational culture, because it is so natural and self-evident for us. One of the great advantages of working with external consultants is that they see the culture from the out-side.

We have good results of external and own agile coaches working together. Internal coaches know the organization, the product and the people and this com-

bined with the out-side view and knowledge from other organizations, which an external has, works well. This way we also learn as an organization more.

In my key note speech in XP 2008 conference I talked about some of the paradoxes I have observed in the agile transformation first in Nokia Networks and now in Nokia Siemens Networks during the past 3.5 years. In this article I want share my experiences of working with some of the paradoxes as a change agent in our agile transformation.

Learning processAgile transformation is always a learning process for the whole organization. As an organization we need to learn about

1. What agile and lean means; values, principles, mind-set

2. How to do agile development; methods, practices, tools

3. How to lead agile and lean development and how to lead the transformation

The whole organization needs to learn, and learning proceeds step by step. I have found it useful to talk about the learning pyramid. One part of the transfor-mation project is to support learning at all levels with training, coaching, facilitating learning from own expe-rience, creating networks etc. Taking care of our own learning in the transformation team is of high priority.

Proceeding in the change means that the whole or-ganizations should move up in the learning pyramid. The change will proceed faster after the critical mass has been reached. One can’t jump directly to being an expert, it takes time. You have to practice and learn from your experience. The organizational learning goes faster if you have some practitioners and experts avail-able – bringing in outside knowledge speeds up the learning process.

There are actually learning pyramids within pyramids: e.g. different agile practices, lean-thinking, agile and lean management, working with and in self-organized teams have their own learning pyramids.

The available training and coaching solutions need to develop over time as the organization learns more. To give an example: we started with a 1-day training called “Introduction to Agile and Iterative”. We are still giving the same training, but the contents have changed a lot. In the beginning the main focus was “water-fall bash-ing” and proving that agile development is possible in our environment. The main question we answered in the training was “why should I do this”, even though also the “what does this mean in practice” and “how to get started” were also addressed. Now the focus is on “what does this mean in practice”. Our experience is that people find it very insulting if they have already “bought agile” (or perceive that they have) and we try to sell it to them again.

� �

Barely enough clarity within confusionParadoxes often cause anxiety; people would like things to be “either – or” and are likely to create false dichotomies. There are a lot questions like: Should we have global processes and tools or should teams own their processes? Should this be a top-down or bottom-up change? Should one start by changing the values or by introducing new practices? Questions, to which the answer is a “yes”, or a more sophisticated “it de-pends”.

Of course, in some organizations this is totally unac-ceptable – you just have to give a clear answer. But at the same one should try open people’s eyes to the complex nature of reality: neither an organization, prod-uct development nor the agile transformation is a sim-ple or even complicated system; they all are complex systems. If people can accept this,

You can’t control change, but you can engage in it. Change is not a predictable, repeatable process. A key part of the change process is to observe the response; what people hear and understand and what they actu-ally do after hearing your message. And based on your observations revise the message and how it is deliv-ered.

The uncertainty of change is that we need to start before we know exactly what the target is. I often use the metaphor of navigating in heavy fog: we know ap-proximately which direction the island is, but don’t know the full route. If we sit and wait for the fog to disappear (which by the way never happens in big changes), we waste a lot of time. It is much better to start moving, take the first step and then check the direction again.

Top down and bottom upSome things in the agile transformation should be driven bottom-up and some things require top-down approach.

Adoption of e.g. XP-practices and Scrum can (and should) be bottom-up. However, management should be only half a step behind, since e.g. setting up con-tinuous integration requires typically some investment decisions and using Scrum requires often significant changes in management practices.

Bottom-up approach hits its limits when organizational boundaries should be changed or removed, e.g. form-ing truly cross-functional teams. Lean transformation requires top-down approach, because one team does not have control or even work in the whole value-stream.

Changes in organizational values, management cul-ture and behavior require actions from managers and a top-down approach. Organizational culture and management practices should enable self-organization and empowerment, and implementation of them hap-pen bottom-up. Empowerment is a state of mind and a way working; a choice each individual makes. Self-organization requires that teams agree on their ways of working and that people choose to be self-organized.

Of course self-organization has to be supported by management, too.

In the best case top-down and bottom-up approaches are sufficiently synchronized and balanced and drive towards the same direction. In the worst case there is big mismatch on what is being driven top-down and what bottom-up; e.g. more command and controldrive top-down and agile driven bottom-up will cause signifi-cant problems.

It’s a big challenge for management to support the change sufficiently and not to over-drive it. Manage-ment should provide support (training, coaching) for the agile transformation in teams, remove impediments and focus on changing the management practices.

How you make a change a big company? The bad news is: one person at a time. The good news is that you don’t have to do it alone, if you create networks of people. We have e.g. Scrum master network, local net-works at most sites, agile coach -network and continu-ous integration network. People learn from each other and support each other.

About the author

Kati Vilkki has long experience in running

organizational change programs and work-

ing as a change agent. Since 2005 she has

been involved in agile transformations and

is currently heading the agile transformation

program in Nokia Siemens Networks.

� �

In product development organizations becoming or be-ing distributed, sharing technology between different products and product families is a challenge. This is one factor that needs to be taken into account when the transformation to an agile way of working is started. This article describes different aspects needing atten-tion in the transition.

The reuse that is the target for sharing technology can be achieved through several different techniques. These range from product line management, where a number of products are created from a set of core assets, to the use of internal open source within the company where a more free usage of available components is possible. We have observed that, regardless of the type of shar-ing used, a number of aspects are critical for the usage of shared technology. These include a common vision for the organization regarding the shared technology, a defined way of how decisions are made, and an agreed way of working with the common assets. Other crucial areas are architecture, maintenance, and information exchange. The vision and decision model will affect the other aspects but are unfortunately rarely developed before the more technically related cooperation areas. It is important that the development of the solutions for the different aspects is synchronized. One example is that the vision is needed and should be known by everyone to help ensure that the decision model is ac-cepted in all sharing organizations.

A common visionTo establish the frames for sharing of technology be-tween two or more organizations, the overall business visions and strategies for the organizations should pro-vide a basis. A specific vision is needed for the sharing as this will guide the participating stakeholders when deciding on details in the cooperation. The objec-tives and strategies for shared technology need to be agreed, documented, and communicated. The vision, objectives, and strategies should be common for all or-ganizations participating in the sharing. The vision can also be used as additional stakeholders show interest to use the shared technology. It needs to include guide-lines on the purpose of sharing technology, the busi-ness model for sharing, and criteria for what to include in the technology that should be shared. An example of what is included in the vision is that the purpose is to share communication solutions between the different products, that the development of the components that are shared should be done by one of the organizations, that the cost for this development is shared based on actual volumes.

Decision modelDecisions made to manage and develop the shared technology may affect all parts of the organizations basing products on the shared assets. How decisions related to for instance release plans, common process-es, and major changes to the shared technology should

be managed needs to be defined. In the example, a Configuration (or Change) Control Board (CCB) can be established that handles change requests related to the communication solutions, with the instructions to let the biggest business impact to have priority. In this CCB, the rules need to be clear, e.g. that consensus should be reached in the decisions.

Working with shared technologyThe parts of the organizations working with the shared technology need to agree on how working procedures should be established and maintained. A common process for all areas across all organizations is normal-ly not feasible. Rules for how interaction between the different parties working with the same technology is however required. Four areas are specifically affected when technology is shared. Requirements for a specific product may be related to the shared technology or the exclusive features for that product. We need conse-quently a method to distinguish requirements that are affecting the common technology from requirements specific for a product. An example of how this is done is to have a team consisting of system architects and product line managers to investigate the impact on the system. Interface definitions need to be documented and handled in a common way as the products using the shared technology depend on stable descriptions. Configuration management aspects include the defi-nition of shared repositories, and rules for additions, changes, and deletions. One important part of this is the definitions for how baselines are managed. Finally, verification and validation activities need to be control-led as other parties depend on the quality of the shared technology. This typically involves the definition of com-mon testing tools and methods.

Maintenance:

The maintenance area is highly affected by the vi-sion and the decision model chosen. As solutions are developed, and the results are transferred to shared repositories, resources are needed for the execution of managing error and to perform preventive mainte-nance. The business model will determine how the cost for this should be handled. In our example, the main-tenance costs are part of the overall costs, and also maintenance should be based on business considera-tions. Proposals of refactoring can as an example give future benefits in the ease of adding new communica-tion interfaces.

Architecture:Software architecture solutions affect the quality char-acteristics of the software system. The requirements that are common for the products that share technol-ogy will ideally determine the possible and necessary architectural solutions. However, we have observed that shared technology is most often based on already existing solutions. Decisions on the development of the

architecture will give us the basis for how the technol-ogy sharing can be developed. A modular architecture enables different teams to work on different parts of the system independently. We need to continuously ana-lyze the software architecture with the shared technol-ogy vision in mind and investigate whether the architec-ture can easily be adjusted to the changing business requirements.î

Information Exchange:For all the areas above, the timely exchange of infor-mation is crucial. Information regarding shared tech-nology is typically divided in many repositories. It is necessary that the users and developers of the shared technology have access to sufficient information. To understand what mechanisms are needed, it is advisa-ble to define a communication plan, covering the needs from different stakeholders. In addition to this, tools for information sharing are needed. Our experience is that it is efficient to establish and maintain a portal for the access of data, and complement the current informa-tion with meta-data regarding the components that are provided in the repositories for shared technology. The establishment of these tools needs to be synchronized with the rules for additions, changes, and deletions of the shared technology.

ConclusionThe development of the different areas described above will simplify and enhance the possibilities to share technology. The decisions made for how to work in these areas include deciding roles and responsibili-ties, detailed way of working, and should also include a description of what should happen if the sharing is terminated.

Sharing technology in a distributed environment

Stig Larsson

About the authorStig Larsson is a Senior Principal Engineer at ABB Substation Auto-mation. He received his PhD in Computer Sci-ence and Engineering at Mälardalen University. His professional expe-rience includes software product development for more than 25 years in different positions as software developer, integrator, project manager and manager. In recent years Stig has focused on product development processes, trying to un-derstand how product development can be made faster and easier. Special interests include dis-tributed development and the symbiosis between architecture and processes.

� �

Nokia Siemens Networks’ agile experiencesGiant is developing agilelyKati Vilkki, who is heading the agile transformation pro-gram in Nokia Siemens Networks (NSN), has seen how agile development has grown from small experiments to a common practice in her own organization.

Agile methods were experimented with in Nokia Net-works in early 2005. Bottom-up approach was used in introducing agile to the organization; Vilkki and her colleague Bas Vodde started talking about agile values and principles, about the methods and practices and worked with teams who volunteered to try agile meth-ods out.

- Our starting point was to gain experience on how agile methods and practices can be used in our devel-opment environment and how to do the transformation in a big organization, Vilkki recalls.

- At that time many people thought that agile meth-ods can only be used in small scale development with only few teams. Many also doubted whether agile would fit in telecom type of industry.

- From the beginning our motto has been: be agile, don’t do agile. We have focused on the values and principles and on creating understanding about what agile and lean means. This is the core, even though the practices are also important. There is no one prac-tice which would fit all and teams have to find their own combination of practices.

Kati and Bas expected to have only a couple of pilot groups, but as early as the first year ten projects took agile methods into use.

- Our results were far beyond our expectations; the speed surprised us.

According to Vilkki, only one and a half years later, Nokia Networks had already passed point of no return; adaptation had been so rapid that there was no guest ion of going back to waterfall.

After the merger of Nokia and Siemens telecom units in 2007, agile transformation was included in the NSN strategy and the current transformation program was started. At this point more and more organizations started also top-down activities to ensure that there were able to utilize also the business benefits of agile development.

NSN’s experience of agile development has been en-couraging. Nowadays about one fourth of R&D is using agile methods, and an additional one third is starting the transformation. Agile development is one of the main street development modes in the organization.

Agile in the LargeKati Vilkki sees two dimensions in expanding agile; ag-ile transformation has expanded both in organizational coverage (more and more products are using agile methods) and in scope. First it was just in R&D, then also program and product management, now also HR practices (e.g. target setting and incentive structures) are changing and next customer and supplier interfac-es. These two dimensions are connected; expanding in scope requires that there is large mass of users, which creates pressure to change surrounding structures. Large organizational coverage requires expansion in scope, otherwise one individual team or product hits the boundaries quickly. In big organizations this takes time.

- I see agile as a way of applying lean thinking to software development. Lean looks at the whole value-stream and all parts of organization, agile at software development.

Benefits of agile transformation have not been meas-ured systematically at NSN level, but of course all products that are doing the transformation follow their results. However, it is very difficult to compare situation “before and after agile”, because so many changes are going on simultaneously

- For me personally the best metric has been that not a single organization has wanted to go back to wa-terfall. All of them have reported some positive develop-ment - not in the same areas, though. Vilkki notifies.

All of the products in NSN have had problems in their agile transformation, it is a big change in ways of work-ing and impacts eventually all roles in product develop-ment and even wider. It has an impact on organizational structures, needed competencies and culture.

Continuous integration is very difficult especially in leg-acy products which include loads of old code and typi-cally quite little test automation. Partially it is a technical problem, but even more it is a cultural thing. Develop-

ers are used to keeping the source code in their own computers, working on big chunks at a time and not to check code in until everything is “ready”.

- Another big challenge is to achieve genuinely prior-itized backlog and especially splitting big features into smaller items. That requires close cooperation between R&D and product management.

- Five core practices have emerged during the transformation; these practices set up the organization-al frame-work for agile transformation. The core prac-tices are short time-boxed iterations, prioritized product back-log, continuous integration, self-organized cross-functional teams and inspect and adapt in use. These practices are not enough alone, they should be com-plemented with agile engineering practices. However, teams should be able to choose which practices they use, Vilkki notes.

NSN has developed methods for scaling up Scrum to large organizations and products. Additionally they have noticed that a lot of coaching and training is need-ed for the change to happen.

- For me the most important reason for agile trans-formation is still to create an environment where people can use their full potential. Thus they, as individuals, are much more creative, and can thrive. From organi-zation’s point of view it means better products. Software business is mostly human-oriented business, Vilkki em-phases.

About the authorTommi Linna is a research-er in software engineering at the Department of Infor-mation Processing Science, University of Oulu. His present research interests include software process assessment and improve-ment and innovation tools. Prior to assuming an academic career, he worked in software industry for 5 years.

Tommi Linna

� �

Product evolution is a large fraction of the software business. However studies on agile not so often have coped with product evolution. Product evolution im-plies an existing asset of knowledge in terms some or all of the following: code, requirements specification, software and system architecture, etc. This article discusses the relationship between user stories and traditional requirements.

The study is focused on the evolution of TOPENprim-er. TOPENprimer is a domain specific environment, i.e. a product, for testing, monitoring, operating and operating remote complex systems made of intercon-nected elements. The project consisted in the required evolution of TOPENprimer to support a new applica-tion domain. For that, the software process used was SCRUM. The target application domain was a biogas power production plant that had to be tested and monitored. This plant produces electric power from slaughter house wastage. The evolution to a new do-main implies a well identified number of changes. On the one hand this limits the scope of the study but on the other makes the study manageable.

A measurement plan was defined. This plan included the observation and measurement/estimation of the level of agility considering the objectives reached in each sprint and the effort spent. From a product point of view, and taking the end of each sprint as a sign-

post: the functionality evolution, the product-quality level, impacted classes and product size. Finally the team’s methodology adoption-level considering sev-eral indicators; one of them was the satisfaction of the people involved. This plan was specially designed to minimize the intrusion into the development process.

As long as documentation on the TOPENprimer re-quirements was available, it was possible to compare the functionality and customer needs described in ag-ile terms, with compared with the traditional require-ments specification for the old domain.

One of the problems identified is that non-functional

requirements, either appeared too late in the devel-opment process, or were not identified. This fact has been highlighted before. However in our case it was possible to go further. Actually two main perspectives could be identified during the requirement elicitation: the customer view and the team view. Figure 1 shows them graphically. The customer perspective is func-tionality oriented leaving some product aspects out of its visibility, such as technological ones. At the other side, the development team perspective, depicted as a grid area, covers some requirements derived from the customer needs and some others of which the

User stories and traditional Requirements not always match

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

Figure 1 System view from the team and customer perspectives

About authors: Pilar Rodríguez is a researcher in Sys-tem and Software Technology Research Group at Universidad Politécnica de Madrid. Her research interests include software engi-neering, agile develop-

ment approaches and requirements engineering. She received her MS in Information Technologies by Universidad Politécnica de Madrid, Spain.

Agustín Yagüe is an Associate Professor at E.U. Informatica (Infor-matics Engineering), Universidad Politécnica de Madrid, Spain.His re-search interests include

software processes, software processes improve-ment, project management, agile development ap-proaches, system and software testing processes and tools. He is member of AENOR, the Spanish association for standardization.He is working in the technical committee about “Information Tech-nology” AEN/CNT71. Subcommittee SC-07: “Soft-ware Engineering and Information Systems”.

Pedro P. Alarcón is an associated professor at E.U. Informatica (In-formatics Engineering), Universidad Politécnica de Madrid, Spain. He focused his PH.D. on system operations mod-eling and his present research interests include agile software develop-ment, system and software testing processes and tools, and systems operations modeling.

� �

Automated acceptance testing – what’s on?

Let’s begin with the conclusion: While showing great promise, customers are not as involved in creating au-tomated acceptance tests as you would believe from reading the back page of the Fit book[1]. You shouldn’t struggle to keep a full test coverage when using AAT – rather isolate the most important places, and spend your time there. If you manage to do this, indicators point to this helping the developers’ internal level of confidence. Beware though, as passing AAT does not mean that the software produces code that is actually usable by the customer!

As part of a Norwegian research project, two research-ers from SINTEF (Geir Kjetil Hanssen and the author) started poking into one of the current buzzwords, namely automated acceptance testing. This is a rela-tively new approach to testing in agile projects, which holds a great promise. While unit testing has had its share of tools for automation (such as JUnit and NUnit) this has been lacking on the business logic and GUI layer. With the use of tools such as Fit and Selenium respectively, this will supposedly be a forgotten time. But what is currently written in the research community on this? We performed a literature review on the area, and mapped this with a case study interviewing project members in two projects in a Norwegian SMB. The re-sults were presented at the Agile 2008 conference in Toronto, Canada in August [2].

First a few words on what AAT in principle is. By hav-ing access business logic tests, and being able to run these with a few clicks of a button, you can make sure that your code still adheres to the rules defined in the requirements.

Results from the literature review show that very little is known on the effects of AAT, and there has been very few empirical studies on the topic. Our findings can be summed up as (the referenced article contains a fuller description): Learning Fit takes a short time, and it seems suited to describe at least simple require-ments. This is based solely on student experiments. When using tools such as FIT, beware not to let the tool dictate the communication between customer and developer, rather let it facilitate it. For the ones strug-gling to organize huge sets of Fit tests – there is hope. One report describes how they were able to make their own fixtures to help solve this mess. If the Fit test runs start turning more and more blood red, don’t create new tests. You should struggle to keep the test specifica-tions alive. They may be used by new developers as a great entrance point to understand the domain. On

the other hand, developers should beware that focuss-ing too much on the Fit tests themselves may actually lead to more defects getting through, and keep focus away from the actual needs of the customer. Try also to keep the tests human readable, one of the key points of using these kinds of tests is to use them as commu-nication between customer and developer. Abstraction can lead to obfuscation for less technologically-savvy people.

When you are used to unit testing, you are also prob-ably used to making the code to pass the test quite fast. Making an acceptance test pass can take quite some time. This makes it difficult to sort out the important re-gression failures from unimplemented features. If that’s a problem, look up ‘FitClipse’. Even if you create a Fit test, and you code to make it pass, it does not mean that you are finished with the work and have a happy customer. You might still have other things to do, such as measuring performance criteria and technical writ-ing. This can be difficult to remember when having so much focus on green and red signs. Further, the pass-ing tests do not equal having solved the customers’ real problem. Melnik and Maurer describe it as being lulled into a ‘false sense of security’.

The author is currently starting his PhD thesis looking into this area of research. His main motivation will be how to include customers in defining such require-ments, as it seems this will be a valuable tool develop-ers should add to the box.

1. Mugridge, R. and W. Cunningham, Fit for Developing

Software:FrameworkforIntegratedTests.�00�:PrenticeHall

ProfessionalTechnicalReference.

�. Haugset, B. and G.K. Hanssen.AutomatedAcceptance

Testing:ALiteratureReviewandanIndustrialCaseStudy.in

Agile,�00�.AGILE‘0�.Conference.�00�.

customer may not be aware of at all because of their nature. These include platform constraints, technological issues, and even development meth-odologies. As it can be shown in figure 1, there are some areas without any visibility. This is because of at the beginning of the project all the require-ments are not available. And some of them, but not always all, come out while the project is flowing.

In a traditional approach, the perspective of the product is in general the same than that of the development team. In agile methodologies, and as a result of a higher interaction between devel-opment team and the customer, the perspective of the product is the union of both, i.e. customer and development team. Therefore, the product invisible areas are smaller than in conventional approaches. Nevertheless, during the experiment we have checked that very often the customer fo-cus mainly on what the system must functionally do, but he lacks from a sufficient vision on another aspects that are not linked to the functionality like, for example, resources use, maintenance, portabil-ity, safety, security or design. We have learnt from experience, and we should not forget experience, as Kent Beck points out in his column, that con-sidering non-functional needs too late may be too expensive, and increasing unnecessarily the cost of the product.

How to respond to this? One possibility, perhaps too radical, is to facilitate the consideration and the introduction of non-functional issues. Team mem-bers can cross-check user stories with respect to non-functional needs patterns and the possible underlying restrictions, perhaps as check-lists. In this way non functional needs might be indentified during project development. Given the importance of this perhaps could be done when defining the sprint backlong and when the sprint is evaluated.

One of the characteristics that makes this job more difficult is that non-functional requirements are transversal or horizontal with respect to functional requirements. That is a non-functional require-ments may be associated to many user stories. Second, user stories may be derived from other user stories, with a higher level of granularity.

As a conclusion, user stories and traditional re-quirements do not match. A better understanding of how they are related is required to improve product development.

References

Rodriguez, P., Yagüe, A., Alarcón, P.P., Garbajosa, J., “Agile Methodologies from the perspective of functional and non-functional requirements speci-fication” In Spanish. 13th Conference on Software Engineering and Databases (JISBD’08)

Børge Haugset

About the authorBørge Haugset is a re-search scientist at SIN-TEF ICT in Trondheim, Norway, and has been there since 2001. He is currently starting his PhD study at the Norwegian University of Technology and Science (NTNU). Current research focuses on customer requirements and acceptance testing.

10 11

FLEXI Products & Technologies SuiteThe Pipeline metaphor explained

It was in Limerick where all the partners got together and envisioned the FLEXI Products & Technolo-gies Suite (FPT Suite) as a big Pipeline. It makes

sense, we promise! But maybe an explanation about this metaphor is still necessary. Let us open the work package 4 and introduce you briefly to the FPT Suite that represents both the integration of the project work packages outcomes and the results that European soft-ware intensive industry will take from the FPT Suite.

IntroductionThe outcomes from the FLEXI Project are emanating right from the start and totally we expect more than thir-ty outputs from the different partners. These outcomes, which are inside each section of the Pipeline, have different natures, mainly consisting on new products, new functionality and modules for existing products, and data/projects derived as results of industrial trials. Many of them have been already shown in previous is-sues of this newsletter.

The Pipeline sections represent different stages of a product development coinciding with the areas of inter-

est of the FLEXI project work packages. The pipeline starts with the Innovation stage where the ideas for new products are gathered and ends (in 6 months!) with market-ready products and the case-studies run-ning. Later we will explain each stage in detail, but first we would like to refresh your physics a little bit for a complete understanding of the metaphor:

The fluid flow experiments the Bernoulli’s principle. This principle, together with the continuity equation, gives name to the Venturi effect. That means that the liquid flows with less velocity when the section is bigger and due to this, the pressure is higher and the tube in the upper side of the section has more fluid than a section with less diameter. Specifically, this represents the amount of results that an organization will take from the stage. For instance, as you can see in the figure, the amount of ideas is greater than the number of de-veloped products. The nature of each result depends on the stage so, now that the meaning of the Pipeline can be appreciated as a whole, we will focus on each section.

Innovation sectionResults: IdeasOn an innovation culture, the ideas emerge from every part of the organization. It doesn’t matter whether these ideas are good or not so good. At this stage, the point is to have as many ideas as possible inside the FLEXI Innovation Process Framework and the objective of the rest of the stages is to allow a fast market introduction of the innovation. Since this introduction sometimes only can be achieved with a correct management of possible partnerships, this evaluation is also an objec-tive of this stage.

Release definition sectionResults: FeaturesOnce we have all the ideas for new products, or for new releases of existing products, and the partners are ready and motivated, it is time to focus on one product and to start its requirements definition. The FLEXI Re-lease Definition Decision Framework defines a method-ological approach for the identification of new release features and the selection of the ones that optimize market parameters and stakeholders perspectives.

Agile in the large sectionResults: Products and Products LinesAfter the Market shaping Innovation and the Flexible Product & Portfolio Management of the previous sec-tions, an Agile Product Development and Integration is the last step to achieve FLEXI’s ultimate goal: a High Performance Business. In this stage the product re-quirements encounter an architecture suitable for agile in the large development and management.

Trials and dissemination sectionsResults: Knowledge and reportsOnce the product is in the market, the trials and the lessons learnt begin to emerge. These experiences are unavoidably transformed into knowledge and the results can be spread to the community.

ConclusionThe FLEXI FPT Suite packages all the results of the FLEXI Project. Nevertheless these results are less than the ones that the European software industry would take from the FPT Suite. The pipeline showed here represents the methodological and tool support (frameworks) that will permit a Flexible Global Product Development and Integration.

About the authorJabier Martínez joined the em-bedded software department at ESI after his graduation from the University of the Basque Country. Since then he has been involved in the FLEXI project. Currently he combines its management with the development of PLUM that aims to be the solution for applying software product line techniques to support agile

Jabier Martínez

Work

package 4

Results: Ideas

Features

Products and

product lines

Knowledge

Reports

Section: WP1Innovation

WP2Release

definition WP3Agile in

the Large

WP5Trials

WP6Dissemination

10 11

What is our next product release? May I have your votes please!

Defining the next product release: the Release Definition ChallengeProducts are seldom fully finished in one shot, but rather follow an iterative development cycle: different product increments are released over time consisting of a mixture of features, bug fixes, change requests and technical refactorings. Usually, product builders are confronted with a large number of requirements that can be included in the next increment. Implement-ing them all at once is impossible, because of limited available resources, time restrictions or conflicts in the wishes formulated by the stakeholders. Choices have to be made and priorities have to be set.

The release definition challenge lies in identifying those requirements that provide the most value at a particular moment in time and realising them in the next release. Release definition —the definition of up-coming releases in a product roadmap — fulfils a stra-tegic role. Making incorrect choices for a release may significantly impact the competitiveness of software intensive companies in a market driven environment.

Taming the Challenge: voting to the rescue!Voting is a popular way of addressing this problem of selecting from a huge list of potential requirements those that provide the most value. The idea is quite simple: the list of requirements is presented to differ-ent stakeholders, and each of them is asked to cast their vote on those requirements that he/she believes is most valuable. The requirements that get most of the votes are selected for inclusion in the next re-lease. Several popular incarnations of this idea have surfaced: the Buy a Feature innovation game1 , the Release Planner web application2 , variants of the Planning Poker technique3 , etc.

Voting systems are very attractive for different rea-sons. First of all, they are easy to understand and relatively simple to organise. Second, they recognise that knowledge of the value of a requirement is dis-persed inside an organisation, and they allow to tap into that collective knowledge by involving many dif-ferent stakeholders. Last, many different voting vari-ants exist4, so an appropriate one can be found for any context. Examples include approval voting which allow only yes/no answers, as well as more complex systems such as cumulative voting or instant-runoff voting.

Taming the Challenge: is voting the rescue?Despite these advantages, voting systems do have particular quirks and hardly touch the core of the re-lease definition challenge.

Casting a sincere vote for the most valuable require-ments requires that each and every requirement is considered, and that the different advantages and disadvantages of realising these requirements are carefully balanced. This is of course quite time con-suming, especially if the list of requirements is large. The typical solution to scale up voting so that it can deal with large lists, is to make an initial pre-selection of requirements for which stakeholders can vote. This of course creates a chicken-and-egg problem: voting is used as a selection mechanism to select the valu-able requirements, but at the same time, it requires an initial selection to be made up-front in order to be workable.

Even if the list of requirements is small, voting re-quires omniscient people. Casting a sincere vote on a particular requirements means that you understand each and every requirement in the list, and that you genuinely assume that this one particular requirement has the most value. Not surprisingly, this assumption does not always hold. The day developers become advocates of requirements that improve strategy or that sales become proponents of architectural re-structuring requirements is not yet upon us.

It is interesting to observe the creative ways in which people use the voting system to guide the results in the direction they prefer. They employ clever strategy and tactics, all because they want to avoid an unwant-ed result, rather than achieving the best result. Such “cheating” or tactical voting is unavoidable, whatever voting system is selected, and beats the assumption that stakeholders always handle in the company’s best interest and vote for the best requirements with the most value. Cases are known where somebody does not vote for his preferred requirements, because he assumes others will vote for it anyway, only to find out that others assumed the same, resulting in the (good) requirements that everybody agreed upon not being considered valuable.

As if matters are not yet sufficiently complicated, one can question whether a voting system is really able at all to differentiate between requirements. Voting does not reveal the underlying rationale of why a require-

ment is valuable. Suppose two requirements get the same amount of votes: one requirement doubles the market share at a huge development cost, while the other one halves the maintenance cost but does not attract a single customer. Which of these two require-ments is the most valuable and should be realised?

ConclusionVoting is often promoted as a solution to the release definition challenge, as it is a lightweight solution to select the requirements for the next product release, that takes into account the opinion of many different stakeholders. Although voting systems contribute to the solution, installing a voting system by itself is not sufficient to address the release definition challenge.

Nick Boucart, Wim Codenie & Tom Tourwé

1 Innovation Games: Creating Breakthrough ProductsThroughCollaborativePlay,LukeHohmann,Addison-Wesley,�00�.

�http://www.releaseplanner.com

�AgileEstimatingandPlanning,MikeCohn,PrenticeHall,�00�.

�http://en.wikipedia.org/wiki/Voting_system

About the authorsWim Codenie is programme coordinator of the software engineering team of Sirris. He has 6 years of academic research experience in ob-ject-oriented software devel-opment. Before joining Sirris he was active in the industry mainly in the area of software product develop-ment. He has a major interest in Agile Methodolo-gies, Software Architecture, Risk Management, and Software Variability.

Tom Tourwé works for the Software Engineering group of Sirris, that focuses on the chal-lenges faced by Belgian soft-ware intensive product builders. Before joining Sirris, he was an assistant professor at the Eind-hoven University of Technology, where his research focussed on software quality, evolution and re(verse)-engineering.

Nick works for the software engineering group of Sirris, the collective center for the Bel-gian technology industry. The Software Engineering group fo-cuses on the challenges faced by Belgian software intensive product builders. The group conducts industry driven research around those challenges and actively participates in different (international) research projects on these topics. Nick’s focus is mostly on flexible software devel-opment and on community driven innovation for software intensive product builders.

1� 1�

JG: Reaktor Innovations was selected as the best workplace in Europe this year. What does this award mean to you?

TL: We are really happy with the prize, because the results of the Best Workplaces study are based directly on employee feedback. We had a strong gut feeling that our employees are happy with us, and employee turnover has been minimal. In eight years, only four employees out of over 100 have left us. Winning first the Finnish and then the whole European series was still quite a big surprise.

We are really very happy and proud to get this kind of recognition, and it has brought us a lot of publicity. However, the work will go on as always. We find new things to improve every day.

JG: Some details about your company may be of interest to readers. When did RI start? How many employees do you have? What is your main busi-ness activity? Where do you operate?

TL: We started in 2000, and the following years were challenging for IT businesses, to say the least. How-ever, we believed that by investing in quality, people, and world-class technical expertise we would be able to build a successful expert organization. We have suc-ceeded in doing this. Now we are one of the most suc-cessful IT businesses in Finland. In 2007, the compa-ny’s net sales were 9.3 million euros, and the business has always been profitable. At the moment, Reaktor has over 100 employees.

Our core expertise is in software development and all of its components. We help our customers to create and acquire better software than before.

In addition to our technical expertise, we know a lot about leading software development and expert or-ganizations. We are one of the European pioneers in Agile software development. In addition to software production, we help our customers to benefit from Agile methods.

Our customers are large and international companies from different business fields. We operate mainly in Fin-land, but we offer coaching services globally.

Our headquarters are in Helsinki. In addition, we have offices in Jyväskylä, Seinäjoki, and Buenos Aires.

JG: Your company has been growing steadily since its creation in a fiercely competitive, highly technological sector. What do you think is the key to your success?

TL: Simply put, investing in expertise, people, and quality. According to studies, the difference in produc-tivity between good and mediocre software develop-ers is more than tenfold. Our goal is to gather the best experts in the field under the same roof, and create an environment for them where they can foster and develop faster than anywhere else.

We always want to succeed in all of our projects. Failed projects are insanely expensive and also re-ally grueling for the people working on them. This has made us think about success in a much wider con-text than just the realization of the schedule and the plans. Our mode of operation is based on very close, long-term customer relationships. When our custom-ers succeed, we succeed.

JG: Let’s return to RI business. Your company coaches other organizations in Agile discipline and methodologies. Is there a way to adopt Agile successfully in an industry?

TL: Yes, absolutely. To implement and use Agile meth-ods successfully, you need deep knowledge, experi-ence, and appropriate management skills. The knowl-edge and experience are now pretty easily available, and it’s possible to get results quickly.

However, maximizing the benefits may require massive changes in the organizational culture and way of think-ing. Firstly, software development should be seen as a craft (as it really is) that takes years or decades to master. After that we can start thinking about the kind of organization where this kind of learning and a path from journeyman to master can happen. This requires the right kind of organization, values, and leadership.

In the end, the question boils down to how we can be-come better at software development. I see Agile as a very good framework for continuous learning and improvement.

JG: If I understood you correctly, “real agility” re-quires some help from innovation as well. What, then, is the role of innovation in this “ever-grow-ing” agile environment?

TL: Agile is based on continuously looking for better ways to work. Both the software teams and the rest of the organization are involved in this development work. Innovation is needed, and it happens on many different levels. Of course, this requires the courage to experi-ment, continuous reflection, and rapid feedback.

JG: Sometimes Agile is identified with specific practices such as “discard architecture if you want to be agile”. Do you think this is the right approach to agility?

TL: This is one of the most common misconceptions about Agile methods. In Agile methods, the focus is on quality in particular, both in the codebase and the architecture.

REAKTOR INTERVIEW

ReaktorInnovations(RI)hasbeennamedasthewinnerofthe100BestWorkplacesin

Europecompetitionforsmallandmedium-sized(�0-�00employees)organizations.Juan

Garbajosa interviewed Timo Lukumaa, co-founder and Chief Operating Officer of RI.

Timo Lukumaa is co-founder and Chief

Operating Officer of Reaktor Innovations.

Timo has over ten years of experience

in roles ranging from programming to

projectmanagementtoleadinganexpert

organization.AfteradoptingAgiledevel-

opmentmethodsatReaktoryearsback,

TimoandReaktorarenowhelpingother

organizationsintheirmigrationtoAgile

1� 1�

Unlike in the waterfall model, for example, architectural design happens as a function throughout the project. The approach is the same as in the other iterative soft-ware production methods, such as Unified Process. The best architectures are created through evolution. The most important thing is that the architecture of the finished software is good and appropriate for the pur-pose.

JG: Do you think that the way software is being developed is changing because of the adoption of Agile discipline and methodologies?

TL: Yes. You could say that Agile methods are more visible in the work at the team and developer level than the previous software processes. The work is done in a close-knit team and it’s very disciplined.

Agile methods take the nature and complexity of software development into account better than the traditional plan-driven methods do. Flexible and quick responses to unpredictability improve the chances of success. Of course, flexible response puts more pres-sure on the whole value chain.

JG: Could we say, therefore, that Agile is impacting product development as a whole, not just software development?

TL: Definitely. Agile has an effect on product manage-ment, management, HR, contracting, and budgeting, for example. In the end, Agile also affects the way of working with customers; for example, it can mean re-leasing more often and having more active customer involvement.

JG: An industry intending to adopt Agile may have concerns about embracing change, as change may lead to instability. What would you say? Is it possi-ble to be agile and address large software-intensive systems at the same time?

TL: With large software-intensive systems, there is al-ways high complexity and, therefore, unpredictability. A plan-driven approach can create an illusion of control that really doesn’t exist. In my opinion, a flexible re-sponse and an empirical process improve the chances for success. We and many other people around the world have a lot of good experiences from large soft-ware projects done using Agile methods.

JG: RI experience may be valuable to organizations that are thinking about introducing Agile. Do you have any advice for them?

TL: Agile is currently the best way to do software devel-opment. I recommend it warmly. Seeking expert help

will help you to avoid common pitfalls and will give you a chance to learn from the experiences of other organi-zations. Agile is a great framework for continuous learn-ing, improvement, and innovation. If you need training or Agile coaches, we are happy to help.

About the authorJuan Garbajosa is a professor of software engineering at Infor-matics Engineering School, Technical University of Madrid (UPM). His research interests include proc-ess and product mod-elling, and process

automation. He is currently convenor of ISO/IEC JTC1 SC7 WG20 Software and System Bodies of Knowledge and Professionalism. Before that he spent more 15 years serving in industry.

The tenth edition of Agile and XP conference returns to its origin in Sardinia

The International Conference on Agile Processes and Extreme Programming in Software Engineering is the oldest and most reputed confer-ence in the field. Its first edition was held in Cagliari, Sardinia, in 2000 and was called “International Conference on Extreme Programming and Ligthweight Processes in Software Engineering”, because the term “Agile” had not been yet proposed – it emerged in 2001 at a meeting in Snowbird, Utah, where the Agile Manifesto was born.

In 2000, XP was the prevalent agile methodology, and gave the name to the conference, called for short “XP2000”. The conference gath-ered together 145 researchers and professionals from about 15 countries, and was a big success. A by-product of it was the book “Extreme Programming Examined”, the fourth of Addison-Wesley “XP Series”, which is one of the best-selling book series in the history of computer science.

After two other editions held in Sardinia in 2001 and 2002, the Conference went to other European sites. In the U.S.A. an Agile Conference was established in 2001 (then named Agile Universe), following the success of XP2000. The U.S.A. conference has a more professional and less research-oriented flavor with respect to XP conferences.

Next year, the tenth edition of the Conference, XP2009, will return to Sardinia in the wonderful Pula tourist resort.

The Conference will gather together researchers and practitioners in the Agile software engineering field, and will constitute a unique op-portunity to meet, exchange ideas, contribute insights and results, and advance the state of the art of Agile Methods.

1� 1�

2008Pasi Kuvaja, Jouni Similä and Hanna

Hanhela. Software Product Line

Adoptiojn - Guidelines from a Case

Study. CEE-SET 2008 Conference.

P. Rodriguez, P. P. Alarcón, A. Yagüe, J.

Garbajosa. Metodologías ágiles desde

la perspectiva de la especificación de

requisitos funcionales y no funcion-

ales. Accepted in 13th Conference on

Software Engineering and Databases

Gijón (Spain), October 7-10, 2008

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,

History of Nordic Computing 2, IFIP

WG9.7 Second Working Conference

on the History of Nordic Computing

(HINC2), 2008.

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

Salo, O.; Abrahamsson, P. Agile meth-

ods in European embedded software

development organizations: a survey

study of Extreme Programming and

Scrum, IET Software, Pikkarainen, M.;

Haikara, J.; Salo, O.;

Abrahamsson, P. The Impact of Agile

Practices on Communication in Soft-

ware Development, Empirical Soft-

ware Engineering,

Pikkarainen, M; Mc-Caffery, F; Rich-

ardson, I. Agile Hybrid assessment

model for safety critical automotive

industries, ICSE 2008, Leipzig, Ger-

many, May 10-18, 2008

Radu Dobrin; Ivica Crnkovic et.al..

GENESIS - A Framework for Global

Engineering of Embedded Systems,

SEESE Workshop 2008, Leipzig, Ger-

many, May 13, 2008

Välimäki, A.; Kääriäinen, J. Patterns

for Distributed Agile Project Man-

agement – a Case Study, I-ESA 2008

(Interoperability for Enterprise Software

and Applications conference), Berlin,

Germany, March 26th – 28th 2008

Jessica Díaz; Agustín Yagüe; Pedro P.

Alarcón; Juan Garbajosa. A Generic

Gateway for Testing Heterogeneous

Components in Acceptance Testing

Tools, 7th IEEE International Confer-

ence on Composition-Based Software

Systems (ICCBSS’08), Madrid, Spain,

February, 25-29, 2008

PhD Thesis. Daniel Sundmark, Struc-

tural System-Level Testing of Embed-

ded Real-Time Systems, Västerås,

Sweden, February 15, 2008

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

Communicative Incentives in Con-

sumer Innovation Brokering, Pro-

ceedings of Hawaii International Confer-

ence on System Sciences (HiCCS-41),

Waikoloa, Big Island, HI, USA, Jan-08

2007Pikkarainen, Minna;Passoja, Ulla; Abra-

hamsson, Pekka; Mäntyniemi, Annukka.

Identifying Suitable Agile based Solu-

tions for Plan-Driven Software Devel-

opment, Software Process Improve-

ment and Practice,

Hanssen, G. K.; Fægri, T. E.. Process

Fusion - Agile Product Line Engineer-

ing: an Industrial Case Study,

Abrahamsson, P.; Salo, O. Agile wind

is blowing in software engineering (in

Finnish), Systeemityö,

PhD Thesis. Stig Larsson, Key Ele-

ments of Software Product Integra-

tion Processes, December, 2007

Mestad et al.. Building a Learning Or-

ganization: Three Phases of Commu-

nities of Practice in a Software Con-

sulting Company, 40th Annual Hawaii

International Conference on System

Sciences, Hawaii/USA,

Wang, X.; Pikkarainen, M. Agile Prac-

tices in Use from an Innovation As-

similation Perspective: a Multiple

Case Study, ISIS 2007, Montreal,

Canada, December 9-12, 2007

Thesis. Jussila, Jari, Innovation Com-

petence, Master of Science Thesis, Fin-

land, 12/12/2007

Thesis. Suominen, Anu, Innovation

Culture Framework, Master of Science

Thesis, Finland, 12/12/2007

Patrick Steyaert; Nico Marine; Boris Glo-

ger. SCRUMMING the Software Proc-

ess – Bottom-up Improvement with a

Top-down Vision?, XP Days Benelux

2007, Mechelen, Belgium, 15-16 No-

vember, 2007

Alain Abran; Juan Garbajosa; Laila

Cheikhi. Estimating the Test Volume

and Effort for Testing and Verifica-

tion & Validation, International Confer-

ence on Software Process and Product

Measurement (IWSM 2007), Palma de

Mallorca, Spain, November, 5-8, 2007

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

V,; Similä, J.. Managing Customer

Involvement in the Context of Transi-

tion to Open Innovation. Extended ab-

stract for work in progress., Proceedings

of MCPC 2007, The World Conference

on Mass Customization and Personali-

zation, MIT Cambridge/Boston, October,

2007

Moser, R.; Abrahamsson, P.; Sillitti, A.;

Succi, G.. A case study on the impact

of refactoring on quality and produc-

tivity in an agile team, CEE-SET 2007,

Ponzan, Poland, October 10-12, 2007

Santiago Estela. Flexible Global Prod-

uct Development and Integration,

SQS internal meeting., Haro (La Rioja)

Spain, 2007-10

Santiago Estela. Flexible Global Prod-

uct Development and Integration /

AgileREQ tool, 6th International Con-

ference on Software QA and Testing on

Embedded Systems, QA&TEST 2007.,

Bilbao Spain, 2007-10

Kantola, Jussi; Tuominen, Aulis; Chang,

Yoon; Vanharanta, Hannu. The produc-

tization operations reference (POR)

model, The 4th International Confer-

ence on New Exploratory Technologies

2007, Republic of Korea, 25-27.10.2007

Vanharanta, Hannu; Kantola, Jussi; Kar-

wowski, Waldemar. Achievement driv-

ers of small and medium-sized enter-

prises, The 4th International Conference

on New Exploratory Technologies 2007,

Republic of Korea, 25-27.10.2007

Vanharanta, Hannu; Suominen, Anu;

Jussila, Jari; Kantola, Jussi; Karwowski,

Waldemar. Constructs and concepts

in management decision making, The

4th International Conference on New

Exploratory Technologies 2007, Repub-

lic of Korea, 25-27.10.2007

Siniaalto, M.; Abrahamsson, P. Does

TDD Improve the Program Core?

Alarming Results from a Comparative

Case Study, CEE-ST 2007, Ponzan,

Poland, October 10-12, 2007

FLEXI publications

1� 1�

Jussila, Jari; Suominen, Anu; Vanharanta, Hannu;

Kantola, Jussi. Building Innovation Culture, Creative

Futures Conference 2007, Finland, 10/10/2007

Stig Larsson; Anders Wall; Peter Wallin. Assessing

the Influence on Processes when Evolving the

Software Architecture, 9th International Workshop

On Principles of Software Evolution, Cavtat, Croatia,

September, 2007

Stig Larsson; Petri Myllyperkiö; Fredrik Ekdahl. Prod-

uct integration improvement based on analysis of

build statistics, the 6th joint meeting of the European

Software Engineering conference and the 14th ACM

SIGSOFT symposium on Foundations of software en-

gineering, Dubrovnic, Croatia, September, 2007

Abrahamsson, P.; Baddoo, N.; Margaria, T.; Messnarz,

R. (eds.). EuroSPI2007, EuroSPI2007, Pottsdam, Ger-

many, September 26-28, 2007

Siniaalto, M.; Abrahamsson, P. Comparative Case

Study on the Effect of Test-Driven Development on

Program Design and Test Coverage, ESEM2007,

Madrid, Spain, September 20-21, 2007

Korkala, M.; Abrahamsson, P. Communication in

Distributed Agile Development, EUROMICRO2007,

Lübeck, Germany, August 27-31, 2007

Hongyu Pei-Breivold; Magnus Larsson. Component-

Based and Service-Oriented Software Engineer-

ing: Key Concepts and Principles, 33rd Euromicro

Conference on Software Engineering and Advanced

Applications (SEAA), CBSE Track, Lübeck, Germany,

August, 2007

Oinas-Kukkonen, Henry; Kerola, Pentt; Similä, Jouni;

Pulli, Petri; Oinas-Kukkonen, Harri. Impact of IS and

SE Research and Education on Development of

Oulu ICT in the Latter Half of the 1980’s, History of

Nordic Computing 2 – HINC2. Extended Abstracts. IFIP

WG9.7 Second Working Conference on the History of

Nordic Computing., Turku/Finland, August, 2007

Salminen, Tapio; Vanharanta, Hannu. Holistic interac-

tion between the computer and the active human

being, 12th International Conference, Human Compu-

ter Interaction International 2007, China, 22-27.7.2007

Münch, J., & Abrahamsson, P. (eds.). PROFES 2007

proceedings, PROFES 2008, Riga, Latvia, July, 2007

Kim, Ji Young; Chang, Yoon Seok; Park, Ji Sun; Chung,

Ki Yeon; Vanharanta, Hannu; Kantola, Jussi. Clas-

sification of supply chain performance measures,

HAAMAHA 2007, Poland, 9-12.7.2007

Haikara, J. Usability in Agile Software Development:

Extending the Interaction Design Process with Per-

sonas Approach, XP2007, Como, Italy, June 18-22,

2007

Gert Leroy; Nico Marien; Patrick Steyaert. “SCRUM-

bled” CMMI: Process Improvement in Smaller Com-

panies, 12TH Annual European Systems and Software

Engineering Process Group Conference, Amsterdam,

The Netherlands, 11-14 June, 2007

Upcoming events 2008 - 2009

Event Place Date Web

4th AgileNorth Conference Preston, UK November 13, 2008 http://www.agilenorth.net/

Agile Development Practices Orlando, Florida, USA November 10-14, 2008 http://www.sqe.com/agiledevpractices/

XP-Days Germany Hamburg, Germany November 27-29, 2008 http://www.xpdays.de/2008/de/index.html

Agile Bootcamp for .NET:

From Journeyman to Master Series

Austin, Texas January 28-30, 2009 http://www.headspringsystems.com/training/

6th International Conference on Information Technology : New GenerationsITNG 2009

Las Vegas, Nevada, USA April 27-29, 2009 http://www.itng.info

STAREAST 2009

Software Testing Analysis & Review Conference

Orlando, Florida, USA May 4-8, 2009 http://www.sqe.com/StarEast/

Software & Systems Engineering Essentials 2009

Berlin, Germany May 26-27, 2009 http://2009.see-conf.de/

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

Better Software Conference & EXPO 2008 Development Lifecycle Practices

The Venetian · Las Vegas, NV June 8-11, 2009 http://www.sqe.com/BetterSoftwareConf/

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

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

PROUD PARTNERS OF AGILE 500

From idea to product in 6 months