Rébecca Deneckère
email: rebecca.deneckere@univ-paris1.fr

Elena Kornyshova
email: elena.kornyshova@cnam.fr

Adrian Iacovelli
email: adrian.iacovelli@gmail.com

Progressive Integration of Method Components: A Case of Agile IS Development Methods

Keywords: Situational Method Engineering, Method Component, Agile Method, Progressive Integration, Experience Report I

Situational Method Engineering aims at constructing methods adapted to a given situation, either by a construction from a set of predefined method components or by a customization of an existing method using different techniques: configuration, extension, reduction, and so on. However, these techniques are still limited in practice, as considered complicated and heavy to implement. In this paper, we describe a practitioner experience of a gradual integration of different method components (issued from agile methods of software development). In a real case of a development company, we have practiced and observed the progressive introduction of agile method components instead of the construction or customization of methods in one go. We discuss the lessons learned from this experience and define different research perspectives.

INTRODUCTION

Situational Method Engineering (SME) argues that a method to be used for the development of a system must be aligned with the context of the project because the situation of each project is different and requires a different methodological support. For this purpose, SME promotes the situation-specific method construction on the fly by reusing parts of existing methods generally designed as autonomous components and stored in method repositories. Whereas many different SME approaches exist, their implementation in practice is difficult as companies are slow to adopt these approaches and techniques even though they acknowledge the significance of the role that methods play in their engineering activities.

A way to use SME in a smoother way should be to implement the components progressively, one at a time, and to wait for the users to be accustomed to the first changes before going to another one. We propose in this work the result of an experiment we performed in a company already using some project management features but wishing to improve the software development processes eventually by introducing an agile method of software development. This company didn't want a too rapid change by implementing an agile method right away and it was then proposed to implement the features one by one, on an incremental and progressive way. The goal of this work was to verify if a progressive integration of method components was possible and if it induced a better acceptance by practitioners.

We first studied the method used by the company in order to identify the missing project management features. We then selected a set of method components corresponding to these features. An integration plan was defined on a long term (two years long) to fit the acceptance/reluctance of change in the company. The method engineer responsible for the experiment was part of the company and helped the integration along the way. Good results were obtained as all the method components had been nicely integrated in the original method.

Section 2 states the context of the company used in our experience while section 3 explains the theoretical background of the work. The case experience is explained in Section 4 and Section 5 states the lessons learned from it. Section 6 concludes this experience and proposes future works.

II. ORGANIZATIONAL CONTEXT

The company capitalizes more than 10 years of research and development in Cloud computing and Big Data. It is specialized in the development of complex information systems, with a particular emphasis on healthcare IT, ehealth and biomedical research.

The company was working on several projects at the same time and was using a project development method mostly based on a classical development method. The team had a weekly meeting to discuss the tasks to be done during the current and next weeks. New tasks could be added and the members of the team discussed their feasibility. The team has used a google doc to save and to share the minutes of weekly meetings. A new version of the googledoc was created each week. The tool RedMine 1 was used to manage the project but its usage was limited to the definition of the high-level tasks and the decomposition of these tasks into sub-tasks. The duration of task realization was also recorded in RedMine. This organization of project management had several problems. The first problem was the bad definition of tasks. The identified tasks were of very high level and not detailed enough. In addition, their formulation was quite informal (no specific formalism used, fuzzy formulations which conducted sometimes to misunderstandings).

The follow up of the project constituted the second problem. The time used for a given task was specified in the googledoc. Thus, the project progress was observed. However, it was done only at the high level of the tasks hierarchy and the data were not always up-to-date.

The third problem was the lack of a specific tool to support the project management activities. In addition to the difficulties to obtain the follow up statistics, the problems of the googledoc were: it was not possible to know why a task runs slowly and is not finished at time; it was not possible to measure the team productiveness.

Another problem concerned the customers' new requirements and feedbacks. Their management was not structured around a specific procedure. No meeting dedicated to the relationships with customers was set up. Each new customer requirement/feedback was treated in real-time without managing the priorities (as a result leading to the delay of other tasks) or put aside for an undefined period. The follow up of feedbacks to the customers was also complicated.

All these problems were related to the lack of specific project management method and/or tool. In addition to these internal problems, it was necessary to have a formal project management approach to have a better image in the face of customers. In fact, the customers are more confident to work with companies using a well-known method/tool and could more easily renew contracts.

The above-mentioned problems implied discussions inside the team about introducing an agile method of software development. However, the team members were reluctant to the adoption of such a method. In fact, the current solution surely was not perfect, but it was functioning and gave results. The team members were against to take a step forward as it required too much effort and time for a weak chance of success. It was then that we intervene and proposed a progressive way to introduce the changes in the method by integrating small method 1 http://www.redmine.org/ components one by one in the method, until all the desired agile features were integrated.

III. THEORETICAL BACKGROUND

This section proposes a rapid overview of the works on agile methods, Situational method engineering and the use of SME for agile methods.

Agile ISD methods. The concept of agile methods appeared at the beginning of the millennium with the launching of the agile manifesto in 2001 [START_REF] Beck | Manifesto for Agile Software Development[END_REF]. As stated in [START_REF] Software | An Introduction to Agile Software Development[END_REF], while the publication of the manifesto did not start the move to agile methods, which had been going on for some time, it did signal industry acceptance of agile philosophy. Several agile methods have been defined and worldly communicated since then, as Lean Software Kanban [START_REF] Anderson | Agile management for software engineering: Applying the theory of constraints for business results[END_REF], Extreme Programming [START_REF] Beck | Extreme programming explained: embrace change[END_REF], Scrum [START_REF] Schwaber | Agile Software Development with Scrum[END_REF], Crystal [START_REF] Cockburn | Agile software development[END_REF], DSDM [START_REF] Stapleton | DSDM -Dynamic system development method[END_REF] among others. A 2013 survey [START_REF] Versionone | 8th annual state of agile development survey[END_REF] states that 57% of its respondents work in companies where there are 5+ teams practicing agile and 38% have 10+ teams. These figures indicate that the agile momentum has taken off and that its successes are being embraced at the enterprise level.

Situational Method Engineering and Method components. Situational Method Engineering (SME) was introduced in early nineties [START_REF] Brinkkemper | Methodology Engineering: A Proposal for Situation Specific Methodology Construction[END_REF]. This field of researches argues that the method to be used for the development of an information system must be aligned with the situation of the project. As a matter of fact, the engineering situation of each project -its context -is different and requires a different methodological support. For this purpose, SME promotes a construction of situation-specific method by reusing parts of existing methods generally designed as autonomous components and stored in method repositories. Today, many different SME approaches exist (e.g. assembly-based [START_REF] Ralyté | An Assembly Process Model for Method Engineering[END_REF]), extension-based [START_REF] Deneckere | Approche d'extension de méthodes fondée sur l'utilisation de composants génériques[END_REF], configuration-based [START_REF] Karlsson | Method Configuration: The eXtreme Programming Case[END_REF], process tailoring [START_REF] Rossi | Managing evolutionary method engineering by method rationale[END_REF], model driven engineering [START_REF] Cervera | A Model-Driven Approach for the Design and Implementation of Software Development Methods[END_REF] and serviceoriented [START_REF] Guzélian | SO2M: Towards a Service-Oriented Approach for Method Engineering[END_REF] [START_REF] Iacovelli | Approche orientée service pour la configuration de méthodes outillées[END_REF].

SME for Agile Development Methods.

Agile methods are usually defined as a set of best practices and behaviors. Since the agile manifesto, lots of books and documents got out to explain these best practices -for instance [START_REF] Shore | The art of agile development[END_REF] [START_REF] Deneckere | Approche d'extension de méthodes fondée sur l'utilisation de composants génériques[END_REF] or [START_REF] Cohn | Agile estimating and planning[END_REF] -but all these documents lack a clear explanation of the processes to apply, on the statement that you have to be agile to do agile. But the fact that there isn't a formal process doesn't mean that the agile developments aren't structured, it is just that there is a transition away from a completely rigid and formalized process. In [START_REF] Meyer | Agile!: The Good, the Hype and the Ugly[END_REF], Bertrand Mayer states "the typical agile book is a succession of alternating general observations and personal anecdotes of project rescues and project failures. These anecdotes are usually entertaining and sometimes enlightening, but a case study is only a case study, and we never know how much we can generalize". In this jungle of tasks, principles, advices and recommendations, new users of agile methods are sometimes lost in all the possibilities that are offered to them, with no clear understanding of the argumentation to choose one alternative over the others. For instance, [START_REF] Meyer | Agile!: The Good, the Hype and the Ugly[END_REF] mentions that "every agile team in the field makes up its own cocktail of agile practices, rejecting the ones that do not fit -until now, however, each organization and project has had to repeat for itself the process of sorting out the gems from the gravel." This behavior is common to other fields and the use of other kind of methods (development methods, deployment methods, design methods, etc.) and the SME domain can help to solve this issue.

Agile methods have already been studied in several works in the SME domain. [START_REF] Qumer | Construction of an Agile Software Product-Enhancement Process by Using an Agile Software Solution Framework (ASSF) and Situational Method Engineering[END_REF] showed in a case study that a situational method engineering approach together with an agile software solution framework (ASSF) can be used to create a feasible and usable hybrid software development method. This can be done by combining agile and formal practices and for a specific situation in large software development organizations. In [START_REF] Karlsson | Method Configuration: Adapting to Situational Characteristics While Creating Reusable Assets[END_REF], the Method for Method Configuration has been proposed as a method engineering approach to tailor a specific agile method: eXtreme Programming. One of the conclusions was that XP does not initially provide an extensive coverage of different project paths so it was a bit difficult to obtain contributing ideas from the developers. Moreover, this study used only one agile method, which makes it difficult to generalize. [START_REF] Abad | Towards tool support for situational engineering of agile methodologies[END_REF] [23] provides a basis for the application of assembly-based SME to the development of agile methodologies. A method base is proposed that contains the necessary agile method fragments derived from prominent agile methods, conform to the Software Process Engineering Metamodel (SPEM 2.0), and can be plugged into CAME tools which implement this metamodel, including the Eclipse Process Framework Composer (EPFC).

We have elaborated a set of method components dealing with the high level representation of the agile methods and a detailed view of components corresponding to the launch phase of the following agile methods: Scrum [START_REF] Schwaber | Agile Software Development with Scrum[END_REF], XP [START_REF] Beck | Extreme programming explained: embrace change[END_REF], DSDM [START_REF] Stapleton | DSDM -Dynamic system development method[END_REF] and Crystal Clear (2004). These components are integrated in the method family called Agile Project Launch (APL) method family. The agile method components were firstly described in [START_REF] Iacovelli | Approche orientée service pour la configuration de méthodes outillées[END_REF] and then developed in [START_REF] Deneckere | Famille de méthodes: la flexibilité au coeur du processus de construction de méthodes[END_REF].

IV. CASE DESCRIPTION

During the period covered by this study, five components of agile methods were integrated progressively. Thus the whole integration process includes five steps (or stages). The agile components identified by the method engineer as corresponding to the method requirements are: Plan the project with Sprint planning meeting, Plan the project with Planning game, Plan the project with Product Backlog, Manage the project with Daily meeting and Manage the project with Burndown chart. The established integration plan is presented at Figure 1.

The predefined order of the integrated components was defined according to two criteria:

• The requirement emergency for a given functionality and

• The acceptance rate by the team members. In the next sub-sections, we describe the integration of these five components using the following template: Context, Component, Process, Feedback.

Context: description of the situation in the company and of the motivation for the usage of a given component.

Component: description of the integrated component at the given stage. Each of five agile method components is illustrated on a summary figure.

Integration process: description of how the component was integrated, specifying the particularities of the method component usage and, if relevant, option of the selected component.

Feedback: description of the users feedback on the new features.

Between the five integrated components, four are atomic (representing the most detailed activities of the agile method functionality) and one (Plan project with Product Backlog) is composite as it is composed of three other agile method subcomponents.

A. Component 1: Plan the project with Sprint planning meeting

Context: The team was using a google document to plan all the project tasks. However, even if all the project team members shared the document, this process was a bit fastidious to handle as it was filled in a hectic manner after the meetings. The goal here was then to find a tool supporting this task on a better way.

Component:

The component 1 (illustrated on the figure 2) explains how to use the new features associated with sprint meetings. Each sprint meeting, the set of the identified project tasks is studied and a state is affected to each of them. Manual or electronic colored post-its are used to visually improve the differentiation between the different states. New tasks can be defined from the initial user stories and added to the set with a duration estimation of their integration into the project.

Integration process: A Redmine add-on allows to handle numeric post-its with the managing of a table of post-it corresponding to the Redmine tasks. The tool also allows to link the stories to the high level tasks identified at the beginning of the project. This add-on had been tested by the method engineer and integrated in the project process. No other integration has been made until this change has been completely accepted by all the members of the team (3-4 months duration).

Feedback:

The planning came from the management of a googledoc to the filling of story tasks during the meetings.

One interesting finding was the fact that the meetings, far from being longer, due to the task filling usually made at another time, became a bit shorter. The new feature was proved very efficient to collect all the information. Moreover, it was also proved more efficient as it handled the tasks time estimation, which was not taken into account in the original Google document.

Component 1 -< {Requirements}, Plan the project with Sprint planning meeting> Description: The goal of this component is to define the tasks within each user story and to provide the follow up of the tasks execution and of the global advancement of user stories of the project. The goal is to help the project manager to handle the tasks by having a clear vision of their life cycle.

Source situation: Planning of tasks

Target situation: Planning of tasks Process for each sprint planning:

1. Quick review of the user stories delivered

•

Make demonstration of the users stories achieved during the sprint.

•

Update the state of each task: Ready, Assigned, Terminated, Expired, Forwarded, Finished, Failed.

•

Make retrospective (analysis of the continuous improvement).

•

Update the status of the user stories "Assigned" using different colors of post-it.

2. Review of the user stories to deliver.

• Description of the user stories to implement. The product owner describes what he wants for the next sprint. The team banter back and forth with the product owner, asking clarifying questions and driving away ambiguity • Identify a sprint goal: a one-sentence description of the overall outcome of the sprint. If a work does not directly tie to the sprint goal, then it is not done during the sprint. 3. The team decides how the work will be built.

•

Plan tasks for the new user stories with the estimation of the tasks duration.

•

Describe the sprint.

B. Component 2: Plan the project by planning game

Context: This component was required since the beginning by the team members as it is one of the technics quickly identified as 'agile'. It was then the second component to be integrated. The use of a tool was also required as there was a member of the team who was working on a distant way and it was then necessary to work on digital cards instead of physical real cards.

Component:

The aim of this component (illustrated on the figure 3) is to integrate a game play in the planning of tasks with the use of what is called a 'poker game'. All the requirements are written on cards and the game helps to estimate the duration of their development. Each team member has the opportunity to speak and to express himself until the team agrees on the estimation. The requirements are then regroup into deliverables.

Integration process: RedMine already had a planning tool called 'Planning Pocker' so it was just a matter of introduce it to the team, explain the process of the prioritization and supervise the first uses in the project.

Feedback:

The acceptation of the team of this new way of planning was quite quick as it was already one of their main requirements. The team was eager to use planning poker and all the team members were very satisfied of this new way to plan and prioritize the tasks.

C. Component 3: Plan the project with Product Backlog

Context: The team wanted to have the possibility to handle the tasks on a more long term. The stories were created week after week with no specific meeting for the tasks estimation. High level tasks were created at the beginning of the project but there was missing a level of granularity between the high level and the low level tasks. The missing functionality of project management was a correct and a complete use of the backlog.

Component: This component (illustrated on the figure 4) explains how to use a backlog to plan the project. The backlog contains the list of all the necessary project functionalities. It is initiated at the beginning of the project but its elaboration can be pursued through all the development. The backlog can be considered as the team referential on the matter of the project requirements. As Component 2 -< {Requirements}, Plan the project with planning game > Description: The goal is to help the project manager to estimate the time needed to implement users' requirements and to establish the first schedule of deliverables. This component uses the Poker Game technique originally introduced in the XP agile method and used later in other agile methods.

Source situation:

Requirements list

Target situation:

Identified and scheduled deliverables.

Process:

1. Write each user requirement on a card. Usual cards have numbers on them following the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks use similar progressions. The reason for using the Fibonacci sequence is to reflect the inherent uncertainty in estimating larger items, which means that the numbers are to account for the fact that the longer an estimate is, the more uncertainty it contains.

2. Evaluate the ideal time (ideal time in weeks that the project team would need to implement the given requirement) to implement each requirement using the cards. A Moderator, who will not play, chairs the process. The Product Manager provides a short overview. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. Each individual lays a card face down representing his or her estimation (units used vary -they can be days duration, ideal days or story points). During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring. People with high estimates and low estimates are given a "soap box" to offer their justification for their estimate and then discussion continues. Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the "consensus vote", although the Moderator can negotiate.

3. Group the cards on the table to constitute deliverables (each deliverable is a group of requirements to be delivered to the customer), without ordering requirements within a deliverable.

4. Calculate the delivery dates in function of the estimations of time for requirements for each deliverable. The component objective is to help the project manager and the stakeholders to identify and manage the software requirements. The backlog is then used through the project to have a good view on the tasks developments.

Sub-components:

• Plan the project with an Estimating meeting • Plan the project with continuous Backlog input

• Plan the sprints with Backlog

Source situation:

Project requirements

Target situation: Product Backlog

General process to use the backlog:

1. Identify high level requirements at the beginning of the project and put it in the backlog.

2. Put the stories in the backlog.

3. On an everyday basis, if a requirement is identified as not necessary, delete it from the backlog. On the contrary, if a new necessary requirement is identified, add it to the backlog.

4.

Use the backlog to regularly plan the sprints. Integration process: The used tool had a backlog functionality that wasn't used by the team and that has been integrated in the process. The unfinished tasks are now put in the backlog, as well as the stories not planned for the incoming week. The backlog is filled at the beginning directly with the client in a specific meeting dedicated to this process step and updated during the development.

The integration of this component was decomposed in three phases (corresponding to the three sub-components): first, the backlog was only used for the high level requirements defined at the beginning of the project (for at least 6 months). Then, the stories were put in the backlog on a regular basis when they were coming up, on an informal way (6 months). Finally, the backlog was used to plan the sprints (2 months).

Feedback: After more than a year, the backlog is now used on a complete way. There are several types of meeting that had been integrated in the project development process:

-Estimating meeting (with the client) to create the stories (with the poker planning technique), report on the project velocity and make some demonstrations. -Start of sprint meeting to prioritize the stories with the client. -End of sprint meeting to evaluate the work done and make some demonstrations to the client.

1) Sub-component 3.1: Plan the project with an Estimating meeting

Context: High level tasks were created at the beginning of the project but there was just put on a Googledoc with some informal description. As the objective was to get rid of the googledoc, it was necessary to use another way to store the requirements.

Component: This component (illustrated on the figure 5) explains how to use a backlog to initially plan the project. The backlog contains the list of all the necessary project functionalities and is initiated at the beginning of the project with the client. The backlog can be considered as the team referential on the matter of the project requirements.

Integration process:

The used tool had a backlog functionality that wasn't used by the team and that has been integrated in the process. The backlog is filled at the beginning directly with the client in a specific meeting dedicated to this process step.

The integration of this component was long (6 months) as the team was quite reluctant to use the backlog. It was then necessary to integrate it carefully and without too many changes in the process.

Feedback: An estimating meeting with the client) is now used in the projects development process to create the stories (with the poker planning technique).

2) Sub-component 3.2: Plan the project with continuous Backlog input Context: The team only used the backlog at the beginning of the project to store the high level requirements. They wanted to have the possibility to handle the tasks on a more long term. High level tasks were created at the beginning of the project but there was missing a level of granularity between the high level and the low level tasks. The project manager needed a more detailed use of the backlog.

Component: This component (illustrated on the figure 6) explains how to use the backlog through the project. The backlog contains the list of all the necessary project functionalities and its elaboration can be pursued through all the development. The backlog can really be considered as the team referential on the matter of the project requirements through all the project development.

Integration process:

The tool had a backlog functionality used at the beginning of the project. The stories are now put in the backlog on a regular basis when they are coming up, on an informal way. Again the integration of this component was quite long. Even with an acceptance of the backlog functionality at the beginning of the project, the team was quite reluctant to use the backlog on an everyday basis. It was necessary to accustom them to this functionality for 6 months before going further on.

Feedback: This functionality helped a lot the team to handle the stories that were coming up through the development. The backlog is now used not only for the high level requirement but also for the low level ones and the link between them is much clearer to all the team members.

3) Sub-component 3.3: Plan the sprints with Backlog

Context: The team filled the backlog on a regularly basis but they didn't used it completely to plan the sprint on a regular way.

Component: This component (illustrated on the figure 7) explains how to use a backlog to plan the sprints. Two meetings have to be implemented for each sprint in order to compare what has been done to what is yet to be done.

Integration process:

The backlog was already used to put all the requirements (high and low level). The unfinished tasks are now put in the backlog, as well as the stories not planned for the incoming week. It took two months to integrate this functionality.

Feedback: After the integration of three different subcomponents (3.1, 3.2, 3.3), the backlog is now used on a complete way. Two meetings were integrated in the process: Start of sprint meeting (sprint planning meeting) and End of sprint meeting (review sprint meeting). The sprints are now of two weeks on a regular basis and the client has been integrated on a better way in the meetings.

Sub-component 3.1 -< {Project requirements}, Plan the project with an Estimating meeting> Description: The component objective is to help the project manager and the stakeholders to identify the high level software requirements. Looking at the problem description, the team identifies some high level requirements that will be refined later on in the process. There is no predefined formalism for the backlog; it can be a table or a text document, a database or even a set of post-its. Each item has to be described on an atomic way (only one requirement for each item). The Product Backlog contains features, bugs, technical work and knowledge acquisition.

Source situation:

Project requirements

Target situation:

Product Backlog Process to initiate the backlog:

1. Identify high level requirements at the beginning of the project and put it in the backlog.

2. Put the stories in the backlog. The component objective is to help the project manager and the stakeholders to manage the software requirements in real-time. After its initial definition, the backlog is updated on a day-to-day basis. Once the backlog gets larger, it may be necessary to group the backlog into near-term and long-term items.

Source situation:

Project requirements, Product backlog

Target situation:

Product Backlog Process to use the backlog:

1. On an everyday basis, if a requirement is identified as not necessary, delete it from the backlog. 2. On the contrary, if a new necessary requirement is identified, add it to the backlog. The component objective is to help the project manager to correctly plan the sprints. The product backlog is used to handle the requirements and to indicate which tasks are under way, finished or to be done. Two meetings are introduced at the beginning and at the end of each sprint to evaluate, with the product owner, which stories have to be developed for this sprint and what has been done already.

Source situation:

Product backlog

Target situation: product backlog, Sprint

Process to plan the sprints with the backlog:

1. At the beginning of the sprint, make a sprint planning meeting to prioritize the stories with the product owner. This meeting helps to define the sprint goal: a short sentence describing what the team plans to achieve during the sprint. The team and the product owner write it collaboratively. The sprint backlog is the other output of the sprint planning. It is a list of the product backlog items the team commits to deliver and the list of the necessary tasks.

2. At the end of the sprint, make a sprint review meeting to evaluate the work done and make some demonstrations to the product owner. The success of the sprint will later be assessed during the sprint review meeting against the sprint goal, rather than against each specific item selected from the product backlog. The project team was quite small so its members usually met and talked around the coffee machine. However, as there was a team member working remotely, it was difficult to have a real efficient communication between all the members. The tool used helped to have information about the advancement state of all the tasks but some crucial details were missing, only evocated in an informal way outside the official meetings.

Component: This component (illustrated on the figure 8) explains how a daily meeting (or stand-up meeting) can be put in place. The team meets once a day, always at the same time to share the development advance. This meeting is usually scheduled for short time. If a point seems to take too long, the team put it away to be discussed with only a sub-part of the team. This meeting allows sharing all the important information about the development. More than team-building exercises, regularly communicating, working, and helping each other build effective teams. This is also linked with team members helping each other with shared obstacles.

Integration process: Meetings were planned regularly to improve the communication between all the team members, with a direct internet access for the team member working remotely.

Feedback: the meetings improved a lot the communication between the team members, essentially concerning the developer who was working remotely and who is now completely aware of all the information about the project.

Component 4 -< {Task planning}, Manage the project with Daily meeting > Description:

The goal is to help the project manager to handle the project by organizing a short meeting (less than 15 minutes) everyday. The whole team should attend the meetings. All the important things about the development can be shared (pitfalls, new requirements). The daily commitments allow team members to know about potential challenges as well as to coordinate efforts to resolve difficult and/or time-consuming issues.

Source situation: Sprint

Target situation: Sprint Process:

The daily meeting should not excess 15 minutes. If something should take longer, then plan another meeting to discuss about it. The meeting can take place with participants standing up to remind people to keep the meeting short and to-the-point. This meeting should take place at the same time everyday. All team members are asked to attend, but the meetings are not postponed if some of them are not present.

1. All the team members share their advance on the development. They talk about progress since the last day, the anticipated work until the next one and any impediments, taking the opportunity to ask for help or collaborate.

2. To help, the team members can ask themselves three questions: What did I accomplish yesterday? What will I do today? What obstacles are impeding my progress? It may not be always practical to limit all discussion to these three questions but the goal is to stick as closely as possible to them.

3. Obstacles are written on a board, which is publicly visible, identifies raised obstacles and tracks the progress of their resolution. This board can be updated outside of the daily meetings and serves as a more immediate and less confronting way to initially raise obstacles.

E. Component 5: Manage the project with Burndown chart

Context: It was difficult for the project team to have a longterm view on the incoming sprints. The information was there but sometime disseminated when the same story was in several sprints so it was difficult to have a good time evaluation on the different sprints. Progress on a project can be tracked by means of a burndown chart, updated at the end of each sprint.

Component:

The component (illustrated in the figure 9) shows how to use a burn down chart to have a better view of the incoming works. It results in up-to-date project status being, it encourages the team to confront any difficulties sooner and more decisively.

Integration process: Redmine had this functionality in its toolbox. However, the team didn't use it as the planning wasn't correctly implemented at the beginning of this project. Now that the planning information is completely filled on the tool, the functionality can be used on a more efficient way. The daily meeting helps the team members to enter correct information on a regular way.

Feedback: This component has been integrated quite recently but the first feedbacks are good. The team has a better estimation of the remaining works and is able to have a better planning of the tasks/sprints. engineer outside the development team to convince the team to accept the changes.

Common ground. This kind of integration is only possible if there is only one project at the same time or if all the development teams agree to modify the development method at the same time. There are sprints for each project and it would be very difficult to use different methods at the same time for the same people. A common ground is necessary to handle correctly the developments.

VI. CONCLUSION AND FUTURE WORKS

This experience showed that a progressive integration of new method components in a development method is possible and can be nicely accepted by the development team.

In this experiment, the integration leaded to an increasing efficiency. The company can now claim, in total honesty, that they are using the SCRUM methodology in their projects. The team is happy to work now with a more formalized process, they have improved their meeting duration, their task estimations, and their marketing relationships. The clients have an access to a part of the tool information so they are much more involved in the development process.

The integration has been made on two distinctive ways. First, the method engineer integrated the planning and estimations tasks on a slowly and very gradual way. The change improved the week meetings as they came from during 3 hours to 2 hours then 1h30 (for a team of 5-8 people). This improvement was mainly due to the fact that there were no more discussions about things already everybody agreed on. It was a matter of formalizing in the tool what already existed in the Google document. Second, the method engineer integrated the problematic of the backlog and burndown chart. As the first changes had been happily accepted by the team, it was quite easier to introduce new techniques into the development process. These changes improved the middle-term estimation of the tasks, a closer relationship with the client, and a quicker and more efficient sharing of the information.

Our future works will be to handle new experiments in other companies to see if we reach the same results and if we can improve the method components. New experiments would allow to understand for which kind of projects the progressive integration is appropriate and which are the factors for a successful integration of method components. We intend to organize new experiments using a formalized evaluation protocol in order to gather the information about efficiency of the suggested approach.

VII. REFERENCES

Fig. 1 .

 1 Fig. 1. Plan of the Agile Method Components Integration.

Fig. 2 .

 2 Fig. 2. Component 1: Plan the project with Sprint planning

Fig. 3 .

 3 Fig. 3. Component 2: Plan the project with Planning game

Fig. 4 .

 4 Fig. 4. Component 3: Plan the project with Product Backlog

Fig. 5 .

 5 Fig. 5. Component 3.1: Plan the project with an iniital Product Backlog

Fig. 6 .

 6 Fig. 6. Component 3.2: Plan the project with Product Backlog

Fig. 7 .

 7 Fig. 7. Component 3.3: Plan the project with Product Backlog

Fig. 8 .

 8 Fig. 8. Component 4: Manage the project with Daily meeting

Component 5 -< {Task planning}, Manage the project with Burndown chart > Description:

The goal is to help the project manager to handle the project with a better view of the incoming works. A burndown chart is a graphical representation of work left to do versus time. The burndown chart is an essential part of any agile project and is a way for the team to clearly see what is happening and how progress is being made during each sprint.

Source situation:

Task Planning, Backlog

Target situation: Burndown Chart Process:

1. Construct the burndown chart:

The burndown chart is a graphic with two axis. The horizontal axis represents the sprints. The vertical axis corresponds to the amount of work remaining at the start of each sprint (in whatever unit the team preferstory points, ideal days, team days, etc.). a. The project start point is the farthest point to the left of the chart and occurs at day 0 of the iteration. b. The project end point is the point that is farthest to the right of the chart and occurs on the predicted last day of the project/iteration c. The ideal work remaining line is a straight line that connects the start point to the end point. At the start point, the ideal line shows the sum of the estimates for all the tasks (work) that needs to be completed. At the end point, the ideal line intercepts the x-axis showing that there is no work left to complete. d. The actual work remaining line shows the actual work remaining. At the start point, the actual work remaining is the same as the ideal work remaining but as time progresses; the actual work line fluctuates above and below the ideal line depending on this disparity between estimates and how effective the team is. In general, a new point is added to this line each day of the project. Each day, the sum of the time or story point estimates for work that was recently completed is subtracted from the last point in the line to determine the next point.

Interpret the burndown chart

a. If the actual work line is above the ideal work line, then there is more work left to do than originally predicted and the project is behind schedule. b. If the actual work line is below the ideal work line, then there is less work left than originally predicted and the project is ahead of schedule. During the period covered by this study, the planned agile method components were integrated progressively. Thus the integration included five steps as the integration of method components was done consecutively. The integration of components did not follow their logical order from the initial agile method. We can say that all selected method components come from SCRUM essentially, but some of them are also present in other agile methods. The logical sequence of SCRUM and other agile methods would suggest the integration of these components at the same time.

V. LESSONS LEARNED

A. 5.1. Positive results

Progressive integration of methods components possible. The integration of the method components in the original method succeeded. The team now uses an enriched method containing the new required features.

Method components acceptance.

It seems that a gradual integration leads to a better acceptance of new methods. A smooth change, continuous on a long period of time, allows to introduce the changes one little step after one little step, until the desired amount of change is reached (or if there is a complete opposition to a change, which will have to be handle correctly). At the end of this specific experience, all of the missing SCRUM techniques have been introduced to the project team.

Better consideration of the team priorities. We studied the features required by the changes needed in the method, but we also studied the change reluctance of the project team. We then prioritized the components by taking into account the importance of each feature and the easiness of its acceptation.

B. 5.2. Limitations

Method Engineer. A method engineer who was also part of the development team conducted the integration. It was then easier for us to forecast the potential problems and to realize a smoother integration, adapted to the development team. It will certainly be more difficult for a method


Emmanuel Siéfert
email: emmanuel.siefert@espci.fr

Etienne Reyssat

Benoît José Bico

Programming curvilinear paths of flat inflatables

teaching and research institutions in France or abroad, or from public or private research centers.

Inflatable structures offer a path for light deployable structures in medicine, architecture and aerospace. In this study, we address the challenge of programming the shape of thin sheets of high stretching modulus, cut and sealed along their edges. Internal pressure induces the inflation of the structure into a deployed shape that maximizes its volume. We focus on the shape and nonlinear mechanics of inflated rings and, more generally, of any sealed curvilinear path. We rationalize the stress state of the sheet and infer the counter intuitive increase of curvature observed upon inflation. In addition to the change of curvature, wrinkles patterns are observed in the region under compression in agreement with our minimal model. We finally develop a simple numerical tool to solve the inverse problem of programming any two-dimensional curve upon inflation and illustrate the application potential by moving an object along an intricate target path with a simple pressure input.

Tension field theory | Wrinkling instability | Programmable structures

A new domain of application for pneumatic structures has emerged with the current development of soft robotics actuators (1). Uni-directional bending of elastomeric pneumatic structures can be easily controlled by internal pressure (2), and recently more general complex shape-morphing was achieved [START_REF] Siéfert | Bio-inspired pneumatic shape-morphing elastomers[END_REF]. As they rely on large material strains, these structures are based on elastomers, and therefore have a relatively low stiffness, which makes them unsuitable for large scale structures and heavy loads. In contrast, stiff inflatables may be obtained by stitching flat pieces of thin but nearly inextensible material. As a first example, sky lanterns were invented during the third century in China (4), then rediscovered and scaled up by the Montgolfier brothers for ballooning in the 18th century. Since then, stiff inflatables have been widely used in engineering [START_REF] Wielgosz | Deflections of inflatable fabric panels at high pressure[END_REF], medicine [START_REF] Serruys | A comparison of balloon-expandable-stent implantation with balloon angioplasty in patients with coronary artery disease[END_REF], architecture and aerospace [START_REF] Jenkins | Gossamer spacecraft: membrane and inflatable structures technology for space applications[END_REF][START_REF] Pagitz | The future of scientific ballooning[END_REF][START_REF] Schenk | Review of inflatable booms for deployable space structures: packing and rigidization[END_REF]. Here, we show how to shape-program slender "flat-inflatable" structures which are extremely easy to manufacture : two identical patches are cut in thin sheets and sealed along their boundaries [START_REF] Ou | aeromorph-heat-sealing inflatable shape-change materials for interaction design[END_REF]. Common examples from everyday life are Mylar balloons. Although they are easy to manufacture, predicting the 3D shape of such flat-inflatable structures, i.e. maximizing a volume that a thin inextensible sheet can encompass remains a challenge due to geometrical constraints. Indeed, changing the Gaussian curvature, i.e. the product of both principal curvatures of a surface, implies a distortion of the distances within the surface. In the case of thick elastic plates, local stretching or compression may accommodate changes in metrics. However, inextensible sheets behave nonlinearly: they can accommodate compression by forming wrinkles, but cannot be stretched. Tension field theory, the minimal mathematical framework to address this problem, has been developed to predict the general shape of initially flat structures. While solutions have been found for axisymmetric convex surfaces [START_REF] Paulsen | What is the shape of a mylar balloon?[END_REF][START_REF] Mladenov | The mylar balloon revisited[END_REF][START_REF] Ligaro | Equilibrium shapes of inflated inextensible membranes[END_REF] and polyhedral structures [START_REF] Pak | Inflating polyhedral surfaces[END_REF][START_REF] Pak | Profiles of inflated surfaces[END_REF], predictions in a general case remain an open issue and have been addressed numerically in the computer graphics commu-36 nity [START_REF] Skouras | Designing inflatable structures[END_REF]. In a seminal paper, G.I. Taylor described the shape 37 of an axisymmetric parachute with an unstretchable sail [START_REF] Taylor | On the shapes of parachutes[END_REF], 38 a solution also appearing in recent studies on the wrapping of 39

Significance Statement

Inflatable structures are flat and foldable when empty and both lightweight and stiff when pressurized and deployed. They are easy to manufacture by fusing two inextensible sheets together along a defined pattern of lines. However, the prediction of their deployed shape remains a mathematical challenge, which results from the coupling of geometrical constraints and the strongly non-linear and asymmetric mechanical properties of their composing material: thin sheets are very stiff upon extensional loads, while they easily shrink by buckling or wrinkling when compressed. We discuss the outline shape, local crosssection and state of stress of any curvilinear open path. We provide a reverse model to design any desired curved twodimensional shape from initially flat tubes.

D R A F T

droplets with thin polymeric sheets [START_REF] Paulsen | Optimal wrapping of liquid droplets with ultrathin sheets[END_REF][START_REF] Kumar | Wrapping with a splash: High-speed encapsulation with ultrathin sheets[END_REF][START_REF] Paulsen | Wrapping liquids, solids, and gases in thin sheets[END_REF].

We study macroscopic structures made of thin quasiinextensible planar sheets heat-sealed along a desired path using a soldering iron with controllable temperature mounted on the tracing head of an XY-plotter (10) (Fig. 1A, see

Materials and Methods). We focus on simple configurations

where pairs of identical flat patches forming curvilinear paths of constant width are bonded along their edges. When inflating a straight ribbon, we trivially obtain, far from the extremities, a perfect cylinder of circular cross-section. In contrast, inflating a flat ring results into complex features.

We observe for instance an out-of-plane instability in the case of closed paths and the presence of radial wrinkles and folds (Fig. 1B,C). We show in this article that inflation induces an over-curvature of the outline, through a detailed study of its cross-section. We first describe the cross-section of axisymmetric annuli. We then extend our analysis to open rings to predict the position of compressive zones and the change in intrinsic curvature. We finally devise an inverse method for programming the outline of any arbitrary inflated curved flat path and illustrate the strong workload capacity of these actuators by displacing an object along a complex path with a simple pressure input. Closed rings. We first consider a swim ring configuration: a planar axisymmetric annulus of inner radius R and width w.

Results and Discussion

We describe the cross section of the inflated annulus in the (er, ez) plane as [R + r(s), z(s)] with the curvilinear abscissa s ∈ [0, w] (Fig. 2). We assume that the structure is in a doublyasymptotic regime: the sheet may be considered as inextensible following Laplace law and reads:

91 dϕ ds = - p C (R + r) [1]
92 where tan ϕ is the slope of the cross section with respect to er. 93 Using the geometrical relation cos ϕ = dr/ds, differentiating 94 [1] shows that the shape of the section is the solution of the predicted by the geometrical model, decorated with alternating wrinkles and crumples [START_REF] King | Elastic sheet on a liquid drop reveals wrinkling and crumpling as distinct symmetry-breaking instabilities[END_REF][START_REF] Paulsen | Geometry-driven folding of a floating annular sheet[END_REF], everywhere except at the inner edge of the structure (Fig. 3A and Supplementary Fig. S2). However, we observe that the global structure does not remain in-plane upon inflation and tends to buckle out of plane, exhibiting either diametrically opposed localized kinks for very thin sheets and R * ∼ 1, or a regular oscillating shape for relatively thicker sheets, R * > 1 and high enough pressures (see Fig. 1, Supplementary Movie 1, Supplementary Fig. S2).

Coiling of open rings. These observations suggest the existence of geometrical frustration in closed inflated rings, which is reminiscent of the buckling of rings with incompatible intrinsic curvature [START_REF] Moulton | Morphoelastic rods. part i: A single growing elastic rod[END_REF], or of the warping of curved folds [START_REF] Dias | Geometric mechanics of curved crease origami[END_REF]. This constraint is readily assessed when a cut is performed on the annuli (and both ends sealed), thus removing the closing condition. With this additional degree of freedom, the structures remain in-plane, but the curvature of their outline increases, which results into an overlapping angle ∆α (Fig. 4A). Considering a cut in the (er, ez) plane, the pressure force acting on one half of the ring is 2pA where 2A is the area of the two cross sections. In the closed configurations, the membrane tension balancing this separating pressure force is entirely supported by the inner seam, all others points of the membrane being under hoop compression. On a single cross section, the pressure force induces a residual torque with respect to the inner seam.

For an open ring, having a free end and no external loading imposes a vanishing internal torque in any cross section of the structure. The initially unbalanced pressure torque induces the curvature of the structure until two symmetric lines of tension appear and provide internal torque balance (Fig. 4D).

Counter-intuitively, pressurizing curved structures increases their curvature.

We show in the Supplementary Information that overcoiling is associated with an increase of the enclosed volume and assume that the optimal coiling is determined by the inextensibility condition. Wrinkles are absent along a band of finite width, highlighted in blue. The red line corresponds to the theoretically calculated profile (within the limit of inextensibility)

and the red crosses mark the positions of the tensions lines for R/w = 3.

assume that, far from the ends of the open annuli, the family 163 of profiles calculated for closed rings remains valid. How-164 ever, the current shape profile r1(s) corresponds to the new 165 aspect ratio R * 1 = R1/w. The local projected perimeter of 166 the structure at the curvilinear coordinate s is thus equal 167 to P α (s) = 2π(1 + α)[R1 + r1(s)]. Due to inextensibility 168 condition, this perimeter is bounded by its initial value in the 169 flat configuration P(s) = 2π(R + s). We represent in Fig. 3B 170 the normalized difference

171 u * = [P α (s) -P(s)]/2πw = (1 + α)r * 1 (s * ) -s * [3] 172
as a function of the non-dimensional abscissa s * , imposing 173 α for the case of R * 1. As described previously, u * is 174 always negative for α = 0, that is, all material points are 175 under azimuthal compression except for the inner point s * = 0 176 (Fig. 3B). As α is increased, the curve u * (s * ) presents a 177 secondary maximum which increases. This maximum even-178 tually reaches 0 at a position s * tens for a particular value 179 tens α (Fig. 3B). Beyond this point, u * is partly positive, which 180 breaks the inextensibility condition. As the open structure 181 is inflated, we thus expect α to take the value tens α , for 182 which mechanical equilibrium is attained with two additional 183 up-down symmetric lines of tension along the membrane. Al-184 though in Eq. ( 3) the profile r1(s * ) depends, in principle, on 185 α, we assume here that this dependence remains modest.

1 1 + α = max s>0 r * (s * ) s * [4] 192
As an illustration, this value can be directly computed in

  Programming curvilinear paths of flat inflatablesEmmanuel Siéfert a , Etienne Reyssat a , José Bico a , and Benoit Roman a a Laboratoire de Physique et Mécanique des Milieux Hétérogènes, CNRS, ESPCI Paris, PSL Research University, 7 quai Saint Bernard, 75005 Paris, France, and Sorbonne Universités, Université Paris Diderot This manuscript was compiled on September 7, 2019

Fig. 1 .

 1 Fig. 1. Flat sealed inflatables. (A) Heat sealing of two sheets together along a desired path using an soldering iron mounted on an XY-plotter. (B) Photograph of an experimental realization of inflating an annulus of inner radius R and width w, with R/w → 0. Wrinkles appear and two diametrically opposed kinks are observed. (C) For R/w 1 the inflated structure buckles smoothly out of plane. Both structures are made of Thermo-Plastic-polyUrethane coated nylon fabric.

Fig. 2 .

 2 Fig. 2. Sketch of the inflated ring with the definition of the parameters and coordinates,where R + r is the radial distance to the axis of symmetry, z the height, s the curvilinear coordinate along the membrane in the (er, ez) plane, and tan ϕ the local slope of the profile.

Fig. 3 .

 3 Fig. 3. Cross-section of a closed inflated annulus. (A) Profile picture of a closed inflated annulus, the axisymmetry of the structure being constrained by two plates to prevent out-of plane buckling. The ring is made of a 16 µm thick polypropylene sheet of inner radius R = 25 mm and outer radius R + w = 130 mm. Dashed lines correspond to the theoretical cross sections. Note that the wrinkles extend through the whole torus. (B) Theoretical (solid lines) and experimental (triangles) rescaled cross sections of inflated closed rings for various aspect ratios R * /(1 + R * ) with R * = R/w. r * = r/w and z * = z/w correspond the rescaled radial and vertical coordinates, respectively.

95

  classical non-linear oscillator ODE for ϕ(s):96 d 2 ϕ ds 2 = -p Ccos ϕ,[START_REF] Shepherd | Multigait soft robot[END_REF] 97 which must be complemented by boundary conditions. Symme-98 try with respect to the plane z = 0 imposes z(0) = z(w) = 0, 99 which leads to the boundary condition w 0 sin ϕds = 0 for 100 equation 2. A second imposed condition is that the inner seam 101 D R A F T remains under tension, which leads to r(0) = 0. The force balance normal to the surface of the sheet (equation 1) provides the corresponding condition for ϕ: dϕ/ds(0) = -R p/C. The absence of radial force at the outer seam imposes ϕ(w) = -π/2. A detailed justification of these boundary conditions and of Eqs.1, 2 may be found in Supplementary, using variational techniques. The equation is solved with standard shooting methods, which determines the constant p/C. Using cos ϕ = dr/ds and sin ϕ = dz/ds, we translate the solution ϕ(s) into the corresponding z(r) profile. Denoting dimensionless lengths with the subscript * , we display the dimensionless shapes z * = z/w vs. r * = r/w in Fig. 3B (solid lines) and compare them with experimental profiles (triangles in Fig.3B and image in Fig.3A) for values of the aspect ratio R * /(1+R * ) = R/(w +R) ranging from 0.05 to 0.95. For slender geometries, i.e. R * = R/w 1, the section of the torus is a circle, as expected for a straight elongated balloon. For smaller values of R * , the section presents a singular wedge along the inner radius of the torus (Fig. 3A-B and Supplementary information). The agreement between calculated and measured profiles is remarkable without any adjustable parameter. The toroidal structure is, as

Fig. 4 .

 4 Fig. 4. Overcurvature of an open torus. (A) A circular annulus cut and sealed (upper image) curves more upon inflation (lower image) and exhibits an excess angle ∆α. (B) Dimensionless perimeter difference u * as a function of the curvilinear coordinate s * for various overcurvature strains α , in the case R w (circular section upon inflation). u * = 0 in the flat state; green line, upon inflation with α = 0; red line, for ∆αtens 137 • (the red cross indicates the abscissa s * tens under tension); dashed blue line, for α = 0.5 (this solution is not physically relevant since it implies azimuthal extension). (C) Experimental and theoretical (dashed line) target curvature change as a function of the ratio R/w. Triangles: experiments with 16µm thin sheets of polypropylene; diamonds: experiments with 4µm thin sheets of polyethylene. (D)

Fig. 5 .

 5 Fig. 5. Inverse problem for getting any curved shape. (A) and (E), target path; (B) and (F), normalized target and rest curvature, for a given path width w, κtar and 1/R * as a function of the curvilinear coordinate v * = v/w of a portion of the target path, highlighted in (A) by a dashed box. The curvature of the flat path is computed using the prediction for curvature change plotted in Fig. 3C, that is according to equation [4]. (C) and (G), flat path computed by the inverse model on top of a photograph of the experimental realization. (D) and (H), same path under pressure, fitting closely the target curve (see supplementary Video 3 and 4). (I) manipulation of a mug. Upon inflation, the lightweight arm deforms along a predicted path within a few seconds, passing an obstacle to carry the mug on a platform (supplementary Video 5).

193275

  the limit R w, where the section is almost circular and 194 the profile follows r * = 1 π [1 -cos(πs * )]. Searching for the 195 maximum of the function r * /s * leads to the transcenden-196 tal equation πs * sin(πs * ) = 1 -cos(πs * ). The numerical 197 solution gives s * tens 0.74 and consequently α 0.38, i.e. 198 ∆αtens 137 • . The curvature varies accordingly from 1/R to 199 (1 + α)/R 1.38/R. 200 In Fig. 4C, we compare the experimental measurement of α 201 conducted with polymer sheets with the theoretical predic-202 tions from equation (4), and find a very good agreement with 203 experimental data for R/w > 2. The predicted position for the region under tension (red crosses in Fig. 4D) also matches the observed region free from wrinkles. Nevertheless, this region is actually not limited to a line but presents a finite width. We interpret this difference as a consequence of the finite stiffness of the sheet, as described in a seminal paper by King et al.(21) in a simpler geometry, and of the simplifying assumption that the profile of the structure is strictly similar to the axisymmetric closed configuration. Inverse Problem. Having rationalized the change in curvature upon inflation, we propose to use our geometrical model to inverse the problem, i.e. to determine the path of width w leading to an inflated structure of an arbitrary desired 2D shape with free ends. For a given target curve (Fig. 5A & 5E), we first numerically calculate the curvature κtar(v * ), where v * denotes the curvilinear coordinate along the path to be programmed normalized by the width w (Fig. 5B & 5F). The same parametrization may be used in the flat state since the D R A F T inner edge does not stretch nor contract upon inflation and of curvature R * (v) of the corresponding flat ribbon is then 224 obtained by solving numerically the relationship We fabricate the curved balloons by displaying two thin sheets made 276 of the same thermosealable material (TPU (thermoplasticurethane) 277 impregnated nylon fabric, mylar, polypropylene), covered by a sheet 278 of greaseproof paper, in the working area of an XY-plotter (from Makeblock). A soldering iron with controllable temperature (PU81 from Weller) is then mounted on the tracing head of the plotter (Fig 1A). Using the dedicated software mDraw, we "print" the desired path designed with any vector graphics software. Playing with both temperature and displacement speed of the head, one can simply seal or additionally cut along the path. The envelopes obtained are then connected to the compressed air of the laboratory and inflated. The pressure is then set at typically 0.1 bar, to ensure that we remain in the regime of interest (quasi-inextensible, compression modulus negligible) for our structures with a width on the order of 10 cm, of thickness t of typically 10µm and of Young modulus E of the order of the GPa. Cross sections are measured by drawing a radial line on a transparent mylar balloon, a photograph from the side is then taken and the line extracted. S, DasGupta A (2018) Symmetry breaking during inflation of a toroidal mem-

| www.pnas.org/cgi/doi/10.1073/pnas.XXXXXXXXXX Siéfert et al.

Siéfert et al. PNAS | September 7, 2019 | vol. XXX | no. XX | 3

| www.pnas.org/cgi/doi/10.1073/pnas.XXXXXXXXXX Siéfert et al.

brane. Journal of the Mechanics and Physics of Solids 121:328-340.

| www.pnas.org/cgi/doi/10.1073/pnas.XXXXXXXXXX Siéfert et al.

α that satisfies the inextensibility condition (2), which is shown in Fig.4Bof the main document.Emmanuel Siéfert, Etienne Reyssat, José Bico, Benoît Roman

ACKNOWLEDGMENTS. This work has been partially funded by

the french ANR SMART. We thank Corrado Maurini for enlightening discussions.

Supplementary Information for

Supporting Information Text A. Derivation of the equations based on volume maximization. We consider two superposed flat rings, sealed on their edges, of inner radius R and outer radius R + w. We assume that when inflated, the membrane is inextensible, but that, being infinitely bendable, it may freely accomodate excess of material with wrinkles. We are interested in the resulting inflated overall shape (and not on the detail of the morphology of the wrinkles). This surface is assumed to remain axisymmetric, with the inextensible meridian always under tension, whereas azimuthal compression could occur on this surface (by forming wrinkles in the actual membrane). The section of the torus is described by the curvilinear coordinate s along a meridian, the vertical coordinate z(s), the radial coordinate R + r(s), and the angle ϕ of the tangent to the meridian line with respect to er (Fig S1A). The shape of the section is assumed to be symmetrical with respect to the er axis. In this framework, the equilibrium shape corresponds to the shape which minimizes the energy U = -pV , or equivalently, which maximizes the volume V of the toroidal shape obtained by rotational symmetry (1). The volume reads

In the radial direction, inextensibility is simply ensured by the limits of the integral, because we assume that meridians are not wrinkled i.e. that the membrane is not compressed anywhere in the radial direction. In the azimuthal direction, inextensibility imposes the following inequality ∀s, P (s) ≤ P 0 (s), [START_REF] Shepherd | Multigait soft robot[END_REF] where we have defined the apparent perimeter P (s) = 2π(R + r(s)) of the circle passing through a point s of the section, and P 0 (s) = 2π(R + s) its initial perimeter. Here this continuous inequality can be greatly simplified in the following way : the radial inextensibility imposes that ∀s, r (s) = cos ϕ ≤ 1, and thus P (s) ≤ P 0 (s). Therefore Eq. [START_REF] Shepherd | Multigait soft robot[END_REF] is satisfied if and only if P (0) ≤ P 0 (0), or equivalently if and only if r(0) ≤ 0. An optimal solution must equalize the inequality constraint for at least one curvilinear coordinate, and from the previous equation it must be at s = 0. The inextensibility condition [START_REF] Shepherd | Multigait soft robot[END_REF] thus reduces to the boundary condition:

Dividing lengths by w, the Lagrangian for the optimization problem may be written in terms of non-dimensional variables and parameters denoted by * . We choose here z(s), r(s), and ϕ(s) as independent functions for our optimization problem, for the sake of computation simplicity. The problem is now to maximize

where ( ) stands for derivatives with respect to s * . A and B are two Lagrange multipliers enforcing the geometrical relations (r * = cos ϕ; z * = sin ϕ), that we shall interpret later. Using classical variational methods, we get the following system of equations for the maximization :

together with the boundary conditions A(1) = 0 because r * (0) = 0 is fixed as seen above (equation [START_REF] Siéfert | Bio-inspired pneumatic shape-morphing elastomers[END_REF]), whereas r * (1) is free. We also have the boundary conditions z * (0) = z * (1) = 0 from symmetry. We do have the four needed boundary conditions to solve the system of four first order ODEs. It is however interesting to show that these equations are equivalent to equations [1,[START_REF] Shepherd | Multigait soft robot[END_REF] of the main article and related boundary conditions.

Differentiating the last equation in the set of equation [START_REF] Wielgosz | Deflections of inflatable fabric panels at high pressure[END_REF] and using the other relations to simplify, one gets the equation:

It can be easily shown by direct differentiation that the quantity sin ϕ/B is a constant (using again [START_REF] Wielgosz | Deflections of inflatable fabric panels at high pressure[END_REF] and [START_REF] Serruys | A comparison of balloon-expandable-stent implantation with balloon angioplasty in patients with coronary artery disease[END_REF]). Hence equation [START_REF] Serruys | A comparison of balloon-expandable-stent implantation with balloon angioplasty in patients with coronary artery disease[END_REF] shows that dϕ/ds is strictly proportional to (R + r), and we have recovered equation [1] of the main part of the article where the constant sin ϕ/B corresponds in physical terms to p/C. The boundary conditions may also be expressed as function of ϕ(s). z * (0) = z * (1) = 0 simply imposes that 1 0 sin ϕds * = 0, and the condition r * (0) = 0 inserted in [START_REF] Serruys | A comparison of balloon-expandable-stent implantation with balloon angioplasty in patients with coronary artery disease[END_REF] leads to

Finally, evaluating the last equation in the set of equation [START_REF] Wielgosz | Deflections of inflatable fabric panels at high pressure[END_REF] at s * = 1, and knowing that B = C/p sin ϕ, z * (1) = 0 and A(1) = 0, we obtain that ϕ(1) = -π/2.

of 7

Emmanuel Siéfert, Etienne Reyssat, José Bico, Benoît Roman

We may also interpret Lagrange parameters A and B that appear in the variational equations by separating an angular sector of the system with an imaginary cylindrical cut of radius R + r0 and considering the force exerted by the portion r > r0 on the part r < r0 (see Supplementary Fig. S1B). A and B are simply the horizontal and vertical projection of this force. B = C/p sin ϕ, [START_REF] Jenkins | Gossamer spacecraft: membrane and inflatable structures technology for space applications[END_REF] is the vertical projection of the dimensionless membrane tension per unit angular sector. The total dimensionless horizontal force

also includes a contribution of the pressure on the section in addition to the projected membrane tension. B. Results interpretation. We can solve this boundary value problem using Matlab function bvp4c varying the only non dimensional parameter of the system, the ratio inner over outer radius R * /(R * + 1) and compare the results with cross sections measured experimentally (see Fig. 3B in the main manuscript). The theoretical predictions (solid lines) are in remarkable quantitative agreement with the experimental measurements (triangles). For slender rings, that is when R * /(R * + 1) → 1, the cross-section tends to the trivial cross-section of a straight inflated path, a circle. However, when R * /(R * + 1) → 0, the cross-section strongly deviates from a circle and a singularity appears at the inner point s * = 0. One intuitive way to grasp the idea of this shape is the following: the volume of a toroidal shape is the product of the area of the cross section times the length OC from the center of symmetry (O) of the torus to the centroid (C) of the cross-section. When the ring is highly slender, R * 1, the length OC ∈ [R * , R * + 1] is nearly independent of the cross section. The volume optimization reduces thus to the legendary problem of Queen Dido of Carthage, that is, maximizing a surface given a fixed perimeter length, a circle. However, when R * → 0 (OC ∈ [0, 1]), the position of the centroid is crucial for the volume optimization problem: the system pays a loss in the area of the cross-section in order to push the centroid away from (O), leading to this asymmetric cross-section shape.

A B

C. Open rings.

Inflating such objects with one more degree of freedom, we observe that they remain in-plane, but that the curvature of their outline tends to increase (see Fig. 3A of the main text). The open-end condition now allows for an overlapping angle ∆α to be determined. The previous expression [1] for the volume V is only modified into (1 + α)V , where we have noted α = ∆α/2π. We may use the modified Lagrangian (1 + α)L in the minimization, and recover the same set of equations [START_REF] Deng | Clefted equilibrium shapes of superpressure balloon structures[END_REF]. However the perimeters now include overlapping portions of circles with total length P α (s) = 2π(R + (1 + α)r(s)). The inextensible boundary condition for the inner line now imposes R1 = R/(1 + α). We see that the value of the strain α determines the radius of the curvature of the inner circle and the shape of the section (within the previously calculated family). Finally the free parameter α may be determined by maximizing the corresponding volume V ( α), provided the sections obey the inextensibility condition (2) for each of their points. The volume is numerically found to be an increasing function of α. The optimal solution is thus expected to have the maximum