The process workshop - Semantic Scholar

The Process Workshop: A Tool to Define Electronic Process Guides in Small Software Companies Torgeir Dingsøyr, Nils Brede Moe SINTEF {torgeir.dingsoyr|nils.b.moe}@sintef.no

Abstract We discuss the use of electronic process guides in software engineering projects. We then present existing methods for constructing electronic process guides by defining a set of common processes for a company. Several approaches from the software engineering and management literature are presented. We then go on to propose a new method to construct process description in software engineering: using process workshops as a tool to reach consensus on work practice. In defining processes, we have found it effective to involve software developers – in order to get simple, realistic descriptions with accurate detail and ensure company commitment in an efficient manner. We describe our workshop-oriented method to define processes, which we have been using in small software companies, and show examples of results. We give a brief description of a case study where we defined processes and helped construct an electronic process guide in a small software company in Norway.

1. Introduction Software development is performed in a rather immature fashion in many companies, and problems of late and unsatisfactory delivery are not uncommon. Causes for immature development include problems with transferring competence from one project to another, difficulties establishing best practices, and the widely varying nature of the problems to be solved. Several companies are focusing on process guides, in order to deal with these problems and improve the quality of the software development process. In this article, we present a method for developing an electronic process guide. Companies who are motivated to get to CMM level 3 or to qualify for ISO 9001-2000 should be especially interested in reading this article, but the method applies to all companies who want to improve their software process. The

Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04) 1530-0803/04 $ 20.00 © 2004 IEEE

technique we are using is very simple and can be performed by anyone. We think it is important to involve the people that will use the process guide in the work of defining it. Such user involvement will ensure a process guide developed fast, with high quality, and deeply rooted in the organization. There has been much work in software engineering on technical systems to support software processes, like developing process modeling languages (see for example [1]), which are to describe software processes for systems that can support developers in carrying out software development (see for example [2]). Here, however, we focus on getting process models defined and discussed. This will often be published on a company Intranet, and is then referred to as electronic process guides.

2. The Role of Process Guides in Software Process Improvement Effectively disseminating process knowledge to process participants is crucial in any software process improvement effort. Process participants need effective guidance when process conformance is important, when a process changes frequently, and when new personnel join a project. Traditionally, this has been the realm of large organizations, and the way of describing and communicating processes has focused on printed guidebooks, standards, and procedure handbooks. However, such handbooks are more often seen as dust collectors than software process improvement facilitators, and especially so in smaller companies. There are be many possible reasons for this. In our experience, the main reason for this situation is that most handbooks are too large, too complex, and too expensive to maintain. Another reason is that the users are not involved enough in developing the handbooks. For process guides to be useful, they must not only be tailored to the specific needs of individual companies, but also be made available on the company’s intranet. The traditional process handbook shifts from a bulky pile of paper to a flexible on-line

structure allowing easy access to all relevant information. A process guide can be seen as a structured, workflow-oriented, reference document for a particular process, and exists to support participants in carrying out the relevant process. Whether in the form of a printed handbook or an electronic version, a process description in a process guide should include the following basic elements: • Input: description of artifacts (such as documents, program code) that must be available for performing the process • Activities: descriptions of “how things are done”, including an overview of the activities and details regarding the performance of each activity. • Roles: details regarding the roles and agents involved in performing the activities. • Related documents: details regarding the tools, templates and techniques used to support or automate the performance of an activity. • Output: description of artifacts produced in the process. An electronic process guide should provide all the information elements and relationships contained in a good paper-based process guide. In addition, it should capitalize on diagrams, tables, and narrative to provide an effective user interface. Also, it should make extensive use of hyper-links to support flexible navigation and direct access to supporting information such as examples and templates. For more information on the use of electronic process guides, see [3, 4]. There are many ways to develop a process guide. One is that an expert can collect information on how people work, analyze it, and develop a process guide, see [5]. Another option is to develop the process guide in a workshop where the users participate [6]. We here describe a method for defining process guides, which we have found to work well in practice. An assumption when using this process is that the people invited to the workshop are the people who are the real experts on how to perform the process – who also are the users of the process guide. We use simple models when working with processes to spend as little time as possible on syntax. Further, we consider the workshops themselves to be as important as the resulting process guide – in that they encourage company employees to discuss their own work practice.


3. Method The research reported in this article is from a large research project, Software Process Improvement based on Knowledge and Experience (SPIKE), where many companies cooperate with research institutions and universities in improvement activities. The collaboration is based on finding common improvement and learning goals, and working together to obtain the goals. The communication between contact persons in the companies and researchers is through meetings, telephone calls, and e-mail discussions. This research method is a kind of action research [7], where the researchers and participants from the companies have common goals: to improve software development, and learn from that experience. Together with the company, we discuss how improvement activities can be organized, and try it out. A potential problem with this kind of research is that it can easily be biased, in that everyone is interested in reaching the goals that are set up. Thus, we do not know if the same results would be achieved with another set of researchers, with other people from the company, or with another company in the same situation. But this kind of research is a way to get interaction with companies in a way that would not be possible if it was not so much in the company's interest.

4. Steps to Define a Process Guide We have defined processes in a workshop that can last from half a day to several days, depending of the size of the process, and the number of participants. A moderator invites participants and appoints a secretary to document the results. In addition to a meeting room, the workshop requires a collection of self-adhesive stickers in different colors, and walls that are covered with paper, where you can attach stickers and draw figures. A digital camera is useful to document the results of the workshop. We have also found it useful to bring large process worksheets: a sheet with boxes for input, activities, output, roles and related documents involved in the process (see Figure 3). We bring one sheet for each process that is to be discussed in the workshop. We define the process(es) in six steps and five substeps as shown in Figure 1:

Decide on process(es) to define

Define sequence

Invite participants

Identify activities

Define input and output

Process workshop

Find related documents Delegate responsibility for implementation

Define roles

Role-based reading of resulting process

Implement process in organisation

Figure 1. Steps to define a process in a workshop.

4.1. Decide which process(es) you want to define in the workshop Examples can be the test process or the development process for small software products. If you have a very large process you want to define, divide the work into a series of workshops. Firm


Global, a small company in Norway, designed an overall software development model as shown in Figure 2. In this case, it is natural to run process workshops on the analysis, design, code, module test, and integration phases, and divide each of these phases into sub-processes.

Figure 2. An overall model for the software development process in a small Norwegian software company. DP is an abbreviation for "decision point".

4.2. Invite participants Invite as many people as possible who will be using the developed process guide. If there are many participants, the people should be divided into groups. If you have group work several times, mix people differently each time. You can for example start by making groups of people who have the same work tasks, then later mix people who have different work tasks. There is no need for any preparatory work for the participants.

2.

3.

4.

4.3. Process workshop Before beginning the workshop, give a 15-minute presentation of what you are going to do if the participants have not done this before. Put a large sheet with a figure of the process worksheet (as in figure 3) on the wall – one for each process that will be discussed in the meeting. For each process you want to define, go through sub-steps 4.3.1 to 4.3.5: 4.3.1. Identify activities. Find the main activities of the process. We usually use the KJ process [8] (after Japanese ethnologist Jiro Kawakita) for brainstorming and documenting the result. The KJ is a creative group technique to organize and find relations between seemingly unrelated ideas. Do this as follows: 1. Give each participant a set of stickers and a thick pen. Ask them to write suggestions for


5.

activities on each sticker in large letters. Give people time to document 5-10 ideas. Ask participants to present their suggestions: Attach each sticker to the wall, and describe the activity. Do not let people criticize or discuss the ideas at this point. Group the suggestions: Let the participants come forward to the wall and organize the stickers into groups. Ask them to state why they choose to move the stickers. Formulate headings: Encourage participants to suggest headers that describe the stickers in each group. Try to formulate headings that also make sense to people who have not participated in the workshop. Look for relationships between groups, and arrange sub-topics under more general groups. Document the diagram on the wall with groups and supporting activities on stickers.

4.3.2. Define the sequence of activities: Take the activities from the previous phase and make a sticker for each. Place them on the activities-field of the process worksheet, where time goes from left to the right. Find a suitable workflow between the activities. 4.3.3. Define input and output Find the documents or artifacts that must be available (and possible preconditions that exist) to start the process, and the documents (and possible post conditions) that mark the

end of the process. Use stickers with other colors than for the activities to mark input and output, and attach them to process worksheet on the wall alongside the activities. Conditions that must be satisfied to begin or exit the process can be described in checklists.

4.3.5. Find related documents: Identify documents that already exist in the company, and new documents that could be helpful in carrying out the activities. Such documents can be templates, checklists and good examples of input or output documents.

Figure 4. A workshop participant adds an activity to a process worksheet.

4.4. Delegate responsibility for implementation

Figure 3. A process worksheet with input, activities, output, roles and related documents defined. 4.3.4. Define roles Find the roles (developer, project leader, manager, etc.) that should contribute to each activity – and define responsibilities.

Give someone the responsibility to make a draft process guide, based on the overall description of the processes developed at the workshop. Each activity must probably be described in much more detail than what appeared in the workshop. Divide the work between the participants!

4.5 Role-based reading of the resulting process After people have written draft versions of the process descriptions, it is helpful to ask the people who participated in the process workshop to read the resulting descriptions and comment on them. You can assign the most typical roles involved in the processes to individual participants, and ask them to point out any information that is lacking or irrelevant for this role in the description.

4.6 Introduce the process in the organization When the process description is ready, it has to be introduced to the organization (if not everyone was involved in developing it). You can use a pilot project


to gather further feedback before making the process available to everyone. You can organize a session on the process guide as a part of the kick-off meeting in the pilot project. A meeting where everyone in the company or a department participates can provide a good forum for telling people about the defined process. People from the pilot project can also participate, to share their experience of following the defined process. Of course, internal newsletters or Intranet-news are also good channels for informing about the process guide. Most companies choose to make the process guide available on their Intranet.

5. Tailoring the Process Workshop If there is a lot of established practice in the organization, it makes sense to focus mainly on documenting that practice rather than on introducing new work processes. If working practices vary little within the company then it does not require a lof of work to establish the process guide. But if working practices vary widely, you need to put more emphasis on introducing the documented processes. If there is little established practice in the organizations, you have to focus on establishing the most important processes first, and invest time in introducing and tuning the processes. We have applied this workshop in several small companies that develop software. It can also be used in medium-sized software companies, but we recommend that you then divide the work into more workshops – because the work processes are usually more complex in medium-sized companies. Can this way of defining processes also be used for processes other than those concerned with software engineering? We have tried it with software development processes and in the interface between software development and the market, but the method are general and can be applied to any kind of processes you would like to document. But we believe that the workshop only works when you are defining processes where the participants have first-hand knowledge how the processes are carried out – otherwise you risk ending up with an unrealistic description, which will be hard to get into practical use.

6. Case: A Satellite Software Company We have used the process workshop in working with a company that develops satellite software in Norway. We ran a total of three process workshops focusing on different parts on their development process, but which


involved people from the market and quality department as well as the development unit. In the first process workshop for product development, "initiation" was the one the company wanted to start with. The initiation process was defined to include "offer", "follow-up" and "blast off". The main activities identified in this step for the “blastoff” sub-process were: x

Appoint project manager

x

Organize “Handover meeting”

x

First project analysis

x

Allocate resources

x

Prepare for kick-off meeting

x Internal kick-off The workshops differed in length, but would usually last half a day. The researchers acted as moderators and secretaries. In addition to a meeting room, the workshop required a collection of self-adhesive stickers in different colors, and walls that were covered with paper, where we could attach stickers and draw figures. A digital camera was useful to document the results of the workshop. The output from the workshops was sorted according to the process elements discussed earlier. The output was then edited by two people responsible for introducing the software process in the company. After completing several processes, a new process guide was launched on the Intranet. We are currently monitoring the usage of this process guide through surveys, interviews with selected users and through studies of user logs.

7. Conclusion We have presented a way to develop process guides for software companies that have the following strengths: • It is simple – every user of the process guide can participate in developing it, as participants to not need to learn new modeling languages. That everyone can participate also gives commitment in the organization to actually make use of the process guide, as it is more likely to take into use something you have contributed to develop yourself. • It is efficient – to develop a process guide in a workshop consumes only a moderate number of person-hours and calendar time (usually about half a day per workshop and some time

for producing a draft process description and for role-based review). • It makes people discuss how they work – which fosters learning even before the process guide is available in the company. Through our process workshops we needed to use strict timeboxing because people were eager to discuss, which we often have found a problem in development departments. • It assures quality – the process guide is developed and reviewed by people who know how to do the work, and not how a consultant or staff person imagines the development processes to be (this can of course also be valuable, but can require more time because the external person has to learn about how things are done in the company). We recommend that companies that want to develop process guides focus on documenting how things are done in the beginning – and then later think about how to work smarter (do process "innovation"). This is because people should get used to working with the process guide before you introduce too many changes. It is also important to set priorities: you cannot define all processes that exist in the company, so you have to select the most important ones. Criteria for selecting the most important can be: processes that are problematic, processes that are used often, processes where execution differs between people to a large degree, or simply processes that are critical to the organization. A final piece of advice is to use the process definitions to develop measurements that can be made for the most interesting processes, to stimulate further improvement. There have been relatively few studies of electronic process guides in practice, and there is also little scientific material available on methods to design such guides. It is therefore difficult to compare the way of developing a process guide we describe here with other approaches, when it comes to criteria like efficiency and degree of user involvement. However, we are currently working on measuring use, perceived usefulness and a number of other characteristics about the process guide developed in the satellite software company. Until there are studies of the efficiency of design methods, our method should be treated as a proposal, and we would encourage other organizations to try it out, modify it, and compare it to other methods. Further work will be to conduct more process workshops and to follow the usage of the process guide over time.


8.

Acknowledgements

We are grateful to our contact persons in the satellite software company for contributing to our work. We also wish to acknowledge financial support from the Research Council of Norway, who partially fund the research project Software Process Improvement based on Knowledge and Experience (SPIKE). We also wish to acknowledge the anonymous reviewers for helpful comments. Finally, we wish to acknowledge Joe Gorman for reviewing the English language of the paper and Hans Westerheim for support with the practical work with the paper.

9.

References

[1] Reidar Conradi, M. Letizia Jaccheri, Process Modelling Languages, in Software Process: Principles, Methodology, and Technology, Lecture Notes in Computer Science, vol. 1500, J.-C. Derniame, B.A. Kaba, D. Wastell, Eds. Berlin Heidelberg: Springer Verlag, 1999, pp. 27 – 52. [2] Sjaak Brinkkemper, Motoshi Saeki, Frank Harmsen, Assembly Techniques for Method Engineering, in Advanced Information Systems Engineering: 10th International Conference, CAiSE'98, Pisa, Italy, June 1998. Proceedings. Lecture Notes in Computer Science, vol. 1413. B. Pernici, C. Thanos, Eds. Heidelberg: Springer-Verlag, 1998, pp. 381 – 400. [3] Louise Scott, Lucila Carvalho, Ross Jeffery, John D'Ambra, and Ulrike Becker-Koernstaedt, “Understanding the use of an electronic process guide,” Information and Software Technology, vol. 44, pp. 601 - 616, 2002. [4] Nils Brede Moe, Torgeir Dingsøyr, Tore Dybå, and Trond Johansen, “Process guides as software process improvement in a small company,” EuroSPI, Nürnberg, Germany, 2002. [5] Ulrike Becker-Koernstaedt, “Towards Systematic Knowledge Elicitation for Descriptive Software Process Modeling,” in Proceedings of the Product-focused software process improvement conference (PROFES), Lecture Notes in Computer Science, vol. 2188, F. Bomarius and S. KomiSirviö, Eds. Berlin Heidelberg: Springer Verlag, 2001, pp. 312 - 325. [6] Jarmo J. Ahonen, Marko Forsell, and Sanna-Kaisa Taskinen, “A Modest but Practical Software Process Modeling Technique for Software Process Improvement,”

Software Process Improvement and Practice, no. 1, vol. 7, pp. 33 - 44, 2002. [7] D. J. Greenwood and M. Levin, Introduction to Action Research: Sage Publications, 1998. [8] David Straker, A Toolbook for Quality Improvement and Problem Solving: Prentice hall International (UK) Limited, 1995.
