Transition to Agile Development

Transcription

1 th IEEE International Requirements Engineering Conference Transition to Agile Development Rediscovery of Important Requirements Engineering Practices Juha Savolainen Nokia Research Center Nokia Corporation Helsinki, Finland Juha Kuusela and Asko Vilavaara Nokia Devices Nokia Corporation Espoo, Finland Abstract Many organizations have started to use agile development processes to speed up the development cycle and to improve the ability of the company in reacting to changing requirements. Adopting agile practices may happen as a revolution where all old practices are removed or as a more gradual process. In this paper, we discuss lessons learnt in two agile transition processes. Based on our experience, agile processes can be used in embedded software development for products. The challenges include the varying size of user requirements, the role of system requirements, and architecturally significant requirements. It is difficult for large organizations to be agile. Work allocation for a large number of different teams with different competencies tends to decrease speed, and increase the role of design and management. We conclude that agile development in this context needs very skilled developers and has to be a combination of new and old practices. Agile processes differ radically from traditional process models and transition to agile processes can be used as an argument to remove nearly all existing processes. At first development teams will enjoy this freedom. Later they find out that the large-scale use of agile processes requires techniques that are not so different from more traditional approaches. The key challenges seem to be managing a large number of agile teams, dividing work among those teams, achieving the system-wide properties of the software, and guaranteeing the simultaneous releases of cross-cutting features. Keywords-agility; requirements engineering; best practices; I. INTRODUCTION Agile development promises have resonated in industry. Ability to shorten software development times, to bring visibility into the development process and hopefully to better satisfy customers have led to a wide adaptation of agile development practices in many companies. However, agility is not the first of promising approaches to solve software development problems. Many of the companies have seen the rise of software processes, where various improvements in software development have been pursued by adding more processes. Adaptation of agility can be seen as a counter force to the software process movement and software engineering in general. Based on our experience, a typical adaption of agility in many Finnish companies has been done by first removing all previous software development processes and starting agility from close to scratch. Thus the evolution of the development process can be seen as shown in Figure 1. Previously, there has been a constant rise of processes in many companies. For each identified problem, a new process step has been invented. This can lead to an overload of processes. Development teams natural response is to ignore processes that seem unnecessary. Process development becomes detached from the software development. Figure 1. The illustrative transition process from CMMI to agile methods Based on experiences from the large-scale adaptation of agile methods also the agile practices have evolved to better address co-operation between different development teams. Transition to the agile development gives insight into key practices of requirements engineering and their importance. Our experience shows how the lack of these practices hinders industrial product development. We also show how we applied requirements engineering practices to the agile development process in two industrial cases X/10 $ IEEE DOI /RE

2 II. AGILE DEVELOPMENT AND REQUIREMENTS Agile development has had a complex relationship with requirements engineering. For example, in extreme programming (XP) Beck [1] has claimed that traditional requirements are inhibitors to embracing change. The question is that if requirements change so often why to record or list them? A better solution is to get feedback from customers by having frequent small releases. These releases are based on user stories that promote a discussion with the customer on valuable functionalities. Agile community (especially XP) has seen traditional requirements management as artificial and not addressing true software development problems. At the moment Scrum [2] is the most popular agile method in industry. Scrum has requirements built in as a list of backlog items. A backlog is a prioritized list of all product requirements [2]. This means that a typical backlog contains items that vary on the abstraction level, detail, focus, and on how much design information they contain. Backlog items are implemented during a sprint that is a 30-day or shorter iteration cycle. An example of a backlog item for one sprint could be: This backlog item is minor design iteration. It represents a small change in the current user interface (UI) to match a new configuration. Most likely, a number of other backlog items would be implemented during the same sprint. Another backlog item could be: This backlog item describes a large feature that requires tens of man-years of effort to implement. This kind of feature requires new functionality in both hardware and software. Since the main use of backlog items is to allow defining and controlling the progress of sprints, large backlog items must be broken down to such scale that can be implemented in a single sprint. Ideally, there would be a single backlog and one team that prioritizes requirements, estimates work effort needed for the backlog items and finally implements the items using sprints. However, most large organizations have tens or even hundreds of teams that collaborate to create products. To scale up Scrum, it is possible to have multiple backlogs. Master product backlog contains all product requirements and individual team sprint backlogs contains copies of those requirements that are to be addressed by this team for the next sprint. Several alternative models and their combinations have been used to allocate requirements from the master product backlog to teams: 1. A product owner can place requirements from the master backlog to the team backlogs. 2. The team may pull requirements from the master backlog. 3. If Scrum teams are organized hierarchically a higher-level Scrum has the responsibility to distribute requirements from the master backlog to the teams. In industry, decisions regarding how to implement agile development are mostly driven by agile consultants. There is little accessible empirical evidence on how to scale agile practices in different industrial domains. Based on our experience, each large-scale adaptation of agility tends to be a mix of various agile practices combined with company specific traditions and practices originating from more disciplined software processes. In this paper, we describe our experiences in parts of Nokia where user requirements are represented using user stories, Scrum is used as the main development method and individual teams are aiming for agile development. It is important to understand that one can use Scrum without using agile methods. Scrum can easily be part of traditional iterative and incremental development methods. The authors have been in close co-operation with the organizational units applying agility and have performed informal interviews with key representatives of these organizations. Interviewed people include developers, architects, and people with process responsibilities. Two different large organizations have been in the focus of this paper. Both organizations have more than 500 developers and both develop mobile phone software. We have observed the development process in multiple projects. III. USER STORIES FOR USER REQUIREMENTS Agile development targets the rapid and frequent delivery of valuable, user visible functionalities. A popular way to describe user requirements in agile projects is to employ user stories. User stories describe valuable system functionality from user perspective. User stories as we have encountered tend to have two basic problems. Their implementation takes significant effort and their descriptions are imprecise. Significant effort means that implementation of a typical user story requires modifications to various different parts of the system and takes longer than one sprint. User stories can be divided into smaller requirements that in turn can be allocated to Scrum teams. However, those requirements cannot be user stories themselves. Correctly scoped user stories are minimal from user perspective. When they are divided into smaller elements those do not, taken independently, bring significant user value. That is, user stories cannot be divided into user requirements, they can be only divided into system requirements. Inability to understand this distinction may lead to serious problems [3]. Reported experiences in using agile practices are mostly collected from projects developing Internet services or other information systems. These systems often have a strong emphasis on user interaction and most requirements can be described in form of user stories. They can be built on standard hardware and on software stacks that are well understood. Established architectures can be used to achieve the key quality requirements. 290

3 Embedded systems can be quite different. They have a lot of technical concerns, often use in-house operating systems, and various tailor-made application frameworks. Products are often sold to the mass market where no single person can adequately represent all customers. Some projects have wanted to use only user stories to represent all requirements. Based on our experiences this is only partially successful and the type of the system and domain dictate whether this approach should be tried. User stories are good for specifying applications if functionality is exposed through the UI. For example: This user story directly connects to functionality available in the UI, which is directly connected to the functionality of the navigation application. It would be possible to formulate a system requirement from the user story. A system requirement could be: These two requirements are very similar. The conceptual gap between the user and system requirements in this context is small and only a little is lost by resorting only to user requirements. This tends to be true for most UI-heavy applications. Agile process works well with imprecise user stories. Implementation is the only true definition and iteration allows early feedback. This limits the impact of costly design errors. Agile process runs into trouble if distance between development and user increases. Nokia products form product families. Flexible frameworks are built to support variation in product properties. These frameworks do not directly fulfill user requirements; rather they support applications to do it. Therefore, framework development is driven by derived requirements. That is, requirements, which current and future applications have on the framework. Since most frameworks support many applications and multiple products, one must be able to estimate what requirements these will have. It is not enough to consider one product or even all present applications. One must be able to invent requirements based on the domain knowledge and current product roadmaps. Requirements for frameworks are not user requirements. Framework requirements are system requirements that are derived from the set of all user requirements of all products that the framework will support. These system requirements are heavily dependent on the scope of the framework. If the scope of the framework includes user visible shared application functionality, then user stories have better coverage on the framework. However, if the framework manages mainly system functionality then the distance between the user stories and system requirements of the framework can be great and user stories cannot be effectively used as the main requirements for the framework. It seems rather natural that user stories are not efficient in describing generic frameworks. We were more surprised to find out that user stories do not work well as a tool for defining differences between different products in the product family and thus cannot be used in planning the product roadmap. Key questions seems to be how to describe product identity and maintain that through agile development process. We are using personas (see e.g. [4]) and product intent descriptions in communicating the product identity to R&D teams. We have also embedded user interface designers into the R&D teams so that consistent product identity could be achieved. We don't yet know how well this will work on the long run. Finally, most embedded systems have a large number of hardware related components that may support communications, various hardware interfaces, and sensors. Here, the whole component may exist to fulfill only one user story: In fact, this component may only implement a part of such user story. Most likely some UI related applications such as the phone book might satisfy all the user visible functionality at the UI level of the phone for this user story. This means that user stories cannot be used for this type of components for anything else but setting the overall context of work. All real requirements for the component will be system requirements derived from standards, needed characteristics based on other components, and invented requirements. IV. USER STORIES AND WORK ALLOCATION Development methods must address the question on how to structure development teams and allocate work. Feature driven development [5] explicitly discusses advantages and problems concerning organizing development along the software structure. Advantages are clear responsibilities and relating expertise to particular pieces of code. A clear disadvantage is that other developers may have to wait if one component team is busy in other development task. When agile practices are used for large scale software development similar questions have to be addressed. Leffingwell [6] proposes dividing the Scrum teams along the architecture. In his approach teams become Define/Build/Test Component teams that can independently implement changes to their component. Larman approach is based on creating feature teams to address user stories [7]. These feature teams combine all the domain knowledge needed to implement the software. Larman explicitly recommends against component based teams [7]. Explicit component teams favor specialization against cross-functionality. Need to find work for component teams leads to invention of low-value backlog items. Having 291

4 component teams clearly contradicts with the basic XP value of shared code ownership. We have noticed that it is not possible to have truly multidiscipline teams that could comfortably and efficiently modify all parts of software. Embedded software covers such a wide range of software including signal processing, drivers, operating system resource control, frameworks, communication stack and application layers that some form of specialization has to be allowed. However, we do not advocate component teams. Agile software development does not seem to work well with component teams. Our compromise has been to create software area teams that more closely related to feature teams proposed by Larman. Some user stories concern only one area team but others involve several area teams and work has to be divided further. If shared code ownership is not used, then some method must be in place to divide work in user stories to the teams. In case of component teams, this activity becomes very similar to traditional component-based development process as shown in Figure 2. If domain or feature teams are used, then subsystems (in Figure 2) are replaced by domains or features. Nevertheless in all cases, user requirements must be refined into system requirements for each team. Figure 2. From user requirements to subsystem requirements In most of our implementation of the agile process user stories are very abstract and present a rather large piece of functionality. They have to be decomposed before they reach the Scrum team. Using more traditional terms this step is combination of requirements analysis and high-level design. One possible option is to use Scrum-Scrum teams. These are virtual teams having one representative from each Scrum team. The division of a user story into system requirements is a design step, since work division and allocation to specialized Scrum teams already significantly limits design space. The Scrum teams that will participate in the implementation should make division jointly. Scrum-Scrum team should document their decision with additional design material so that the co-operation of different Scrum teams would be possible. Note that sometimes more that one member from a Scrum team needs to participate to get expertise from all relevant areas. We have successfully used Scrum-Scrum teams. An alternative for Scrum-Scrum teams is to use dedicated software architects. These architects will perform requirement analysis and high-level design based on the user-stories. The result of this step is then communicated to Scrum teams with design documents and requirements. This process is close to traditional iterative development process. It is well understood and thus favored by traditional project managers. However, our experience suggests that it is not working very well in agile context. Architects tend to get detached from the realities of the implementation, their designs are less than optimal and Scrum teams have the tendency to ignore them. Since the Scrum teams themselves do the final decomposition into tasks, they can pay lip service to earlier decompositions and aim towards their own understanding of the original user story. Every mechanism used to bridge the gap between user stories and backlog tasks is inherently non-agile. It pushes customer representatives further away from the design and implementation. Customer requirements will be missinterpreted and the feedback cycle is prolonged. This must be remedied by requirements engineering practices such as requirements traceability. It seems that agile process has an inherent scalability problem that will decrease its benefits when applied to large projects. V. ARCHITECTURALLY SIGNIFICANT REQUIREMENTS Software architecture is the fundamental organization of software embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution [8]. The concerns regarding the maintenance and evolution of software architecture have to be addressed also by the agile development process. We have good experiences in maintaining the software architecture while implementing new features. If developers know the software design and guiding principles behind it well enough they will be able to implement their changes to the code with small impact on architectural coherence. Software architecture is maintained by collective code ownership, a disciplined way of development and common coding standards. In addition we have nominated special component guardians to ensure a good quality of critical components. Architecture evolution has been more problematic. Some requirements have architectural significance and require architectural change. Architectural change is seldom local. We have identified two different types of changes. Non-local change that can be addressed by defining a new design principle. Structural change that will require new components and changed interfaces. Here is an example of a requirement that is an architectural driver: Assuming that our device does not meet the requirement we will have to decrease power consumption. This can be addressed by improving the use of power saving features on 292

5 the processor and hardware level or by pooling communications so that the use of radio hardware is decreased. It can also be addressed by changing design guidance so that on every level all Scrum teams will decreased the consumption in their own code. Some of these changes will result in user visible changes (like decreased use of back light in displays). Others, like better-optimized algorithms, will not be visible. Here is an other example of architecturally significant requirement: Assuming that our device in it's current development stage does not possess this capability we will need to make a structural change. New user interaction methods have to be invented and a user interface framework designed and implemented. Large structural changes take rather long time to implement and cannot be addressed within a regular sprint. Other parts of software often are dependent on this change but cannot be updated before the change has been implemented and tested. This breaks the rhythm of continuous integration. Using backlogs implementation should be ordered so that continuous integration can be resumed as soon as possible. We have addressed the design needed for structural changes by having separate architects. They identify the need for architecture change, make a feasibility study for different alternatives and sketch a plan on how the change should be executed. This plan is communicated to the affected Scrum teams in cross-team design workshops. The final implementation plan is made in these workshops. The result of such a workshop is detailed prioritized tasks for each related feature team and combined with a design on how components should change and what new components and mechanisms should be introduced. Component guardians monitor the implementation of the change. Test suites needed to validate the impact on system level properties are implemented soon after the workshop. Architecture changes should be executed in reasonably short time. Many feature teams may be dependent on the results. We have faced some situation were inability to complete a significant framework in timely manner has slowed down the development of the entire product. VI. CONSIDERATIONS WHEN ADAPTING AGILITY The observations presented here indicate that many classical requirements engineering practices are important also in agile projects. We have reached the following conclusions. A. Agile methods require highly skilled people especially in requirements engineering While agile methods have emerged partly as a counterforce to software engineering in general, we cannot escape the fact that user requirements must be somehow converted to a running software system. By ignoring rigid process descriptions, detailed requirement specifications, and extensive architectural documentation - agile methods make the transition from user requirements to code a giant leap. Different specifications have been replaced by the product backlog that is just a flat list of all kinds of requirements. Lack of dedicated tools makes requirements engineering tasks much more difficult and asks for great skills in e.g. to distinguish between user and system requirements. Developers with the agile background may resist the idea of introducing traditional requirements engineering practices into the organization. We suggest introducing these practices incrementally so that they target a clear problem in the teams everyday work. For example, if teams have problems in managing backlogs and selecting what requirements are included in the sprint or how the master backlog can be divided into the team backlogs requirements triage [9] seems to work well. After a few successes, developers may start to appreciate new tools to improve their ability to handle requirements in the product backlog. B. Understand the type of the system you are creating and its implications for the requirements engineering and work division The deciding factor on how to adapt agile practices should be the system that you are building and the domain where you operate. 1) User-driven system with established architectures in their evolution The system has reached a point where its architecture has been established and it support the quality requirements. If you now have a reasonable small number of teams that have skilled developers with good understanding of basic user needs, an XP-type of agile process is a reasonable choice. This is especially true if your system is mainly implementing user visible functionalities and most of your own code is tied with user interface functionality. In this environment, focus on user requirements. Create minimal user stories and allow teams to pick a single story and implement that in one sprint. Enforce shared code ownership and keep all teams equal. You can mostly ignore system requirements, architecture documentation and focus on user requirement elicitation and interaction with your customer. Work division happens simply when teams pick a user story and implement it by changing all required components. 2) Embedded system with strict quality requirements and new innovative functionality Special quality requirements have to be addressed by dedicated software architecture. Consider using Scrum together with key requirements engineering practices. Allow centralized decisions to be made before work is allocated to the team backlogs. These decisions can take two forms. First, the decision can be taken in form of an architecture change. For example a new interface may be created, an interaction pattern enforced, or a new build system created. The second option 293

6 is to divide a user requirement into technical requirements of a domain, a component or a group of components. It is important that the people making these decisions have a good understanding about software architecture and requirements engineering techniques. The choice between making decisions in form of architecture or system requirements should only be dependent on whether the choice could be made now or whether it should be delayed.. If a decision has to be delayed then system requirements are the best way to describe it.. C. Try to preserve key practices when making the transformation to agile methods If at all possible, preserve key practices that are currently used when making the transition. For example, if you have already invested in traceability management, this can be a great asset in deploying the Scrum process. Similarly, investments in educating engineers in requirements elicitation and analysis are equally important in agile projects. It seems to be wiser to remove unnecessary processes and tools when making the agile transition than to start from scratch and add new practices. Trying to add completely new practices on top of agile development can do more harm than good. One can easily end up remove those properties of the agile practices that may make them successful. REFERENCES [1] K. Beck, Extreme Programming Explained - Embrace Change, Addison-Wesley, [2] K. Schwaber and M. Beedle, Agile Software Development with Srum, Prentice Hall, [3] N. Maiden, "User requirements and system requirements", IEEE Software, 25(2), 2008, pp [4] J. Pruitt and T. Adlin, The persona lifecycle - keeping people in mind throughout product design, Morgan Kaufmann, [5] S. R. Palmer and J. M. Felsing, A Practical Guide to Feature-Driven Development, New Jersey, Prentice Hall, [6] D. Leffingwell, Scaling Software Agility - Best Practices for Large Enterprises, Addison-Wesley, [7] G. Larman and B. Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Addison-Wesley, [8] IEEE, "IEEE/ANSI Recommended Practice for Architecture Descriptions of Software-Intensive Systems," IEEE, [9] A. Davis, Just Enough Requirements Management: Where Software Development Meets Marketing, Dorset House,