http://www.diva-portal.org

Postprint

This is the accepted version of a paper published in Journal of Systems and Software. This paper hasbeen peer-reviewed but does not include the final publisher proof-corrections or journal pagination.

Citation for the original published paper (version of record):

Ali, N b. (2016)

FLOW-assisted value stream mapping in the early phases of large-scale software development.

Journal of Systems and Software, 111: 213-227

Access to the published version may require subscription.

N.B. When citing this work, cite the original published paper.

Permanent link to this version:http://urn.kb.se/resolve?urn=urn:nbn:se:bth-11153

FLOW-assisted value stream mapping in the early phases of large-scale softwaredevelopment

Nauman Bin Ali∗, Kai Petersen∗, Kurt Schneider +

∗Blekinge Institute of Technology, Karlskrona, SwedenEmail: {nauman.ali, kai.petersen}@bth.se

+Software Engineering Group, Leibniz Universitat Hannover, GermanyEmail: kurt.schneider@inf.uni-hannover.de

Abstract

Value Stream Mapping (VSM) has been successfully applied in the context of software process improvement. How-ever, its current adaptations from Lean manufacturing focus mostly on the flow of artifacts and have taken no accountof the essential information flows in software development. A solution specifically targeted towards information flowelicitation and modeling is FLOW. This paper aims to propose and evaluate the combination of VSM and FLOW toidentify and alleviate information and communication related challenges in large-scale software development. Usingcase study research, FLOW-assisted VSM was used for a large product at Ericsson AB, Sweden. Both the process andthe outcome of FLOW-assisted VSM have been evaluated from the practitioners’ perspective. It was noted that FLOWhelped to systematically identify challenges and improvements related to information flow. Practitioners respondedfavorably to the use of VSM and FLOW, acknowledged the realistic nature and impact on the improvement on soft-ware quality, and found the overview of the entire process using the FLOW notation very useful. The combination ofFLOW and VSM presented in this study was successful in systematically uncovering issues and characterizing theirsolutions, indicating their practical usefulness for waste removal with a focus on information flow related issues.

Keywords: Case study research, Value stream mapping, Lean software development, information flow modeling,Process improvement

1. Introduction

Value stream mapping (VSM) is a Lean practice thatmaps the current state map (CSM), identifies value-adding and non-value adding activities and steps, andhelps to create a shared action plan for an improvedfuture state for the process i.e. a future state map(FSM) [1] [2] [3] [4]. VSM looks at both the materialand information flow [2]. In software development, anequivalent analysis of material flow will look at the flowof “work items” e.g. a requirement, use case or a userstory through the process (referred to as artifact flow).Contrary to simply the scheduling information that iscaptured in terms of “information flow” for productionprocesses, for software development it will be perti-nent to capture documented/verbal, formal and informalcommunication. Furthermore, information, knowledgeand competence required to carry out the value-adding

activities in the software development process have tobe identified and analyzed.

The current adaptations of VSM have had a high fo-cus on artifact flow, identifying waiting and productivetimes [1] [3] [5]. No particular challenge occurs here ifthe communication structure is relatively simple. How-ever, in the more complex setting of the studied orga-nization, it became equally important to focus on theinformation flow and explicate it since most of the chal-lenges identified with typical VSM analysis were re-lated to information needs and documentation.

The aim is to achieve an information flow that lever-ages the Lean principle of “pull’ such that one processproduces only what another process needs [2]. The ex-isting guidelines and notation for VSM [2] [3] do not al-low capturing the information flow. As a consequence,we cannot identify value-adding and non-value addingactivities required to streamline the process of value cre-ation. There is a need for a systematic, lightweight ap-

Preprint submitted to Journal of Systems and Software August 12, 2015

proach that could supplement VSM, without a lot ofoverhead. Furthermore, the notation used should besimple and intuitive without requiring additional train-ing of practitioners to understand and analyze the infor-mation flows visualized using it.

Information flow modeling (FLOW) has been pro-posed as a systematic method to analyze and improvecommunication in software development processes byconsidering all types of experience and informationflows in the organization [6].

We propose to combine value stream analysis withFLOW. As both share a focus on capturing and improv-ing information flows, their combination can yield po-tentially useful results. FLOW applies a systematic ap-proach and a structured yet simple graphical notationto identify and capture the flow of information betweenpeople, documents, and activities. It covers and com-bines formal, informal, documented and verbal infor-mation flows in a complex communication structure;hence, it can compensate the inability of existing VSMnotation to capture this aspect of information flow insoftware product development.

To evaluate the usefulness and scalability of usingFLOW to assist VSM, we conducted case study researchin a large-scale product development at Ericsson AB.We conducted six value stream workshops, with two re-searchers (first two authors) acting as facilitators, andthe third author (who is the inventor of FLOW) as anexternal observer.

The remainder of the paper is structured as follows:Section 2 presents related work. Section 3 describes theresearch method. Section 4 presents how FLOW can beused to assist in a typical value stream mapping activ-ity. Section 5 reports the application of FLOW-assistedVSM in the case company. Section 6 presents the re-sults of the study and a follow-up six months after itsconclusion. Section 7 reflects on the experience of ap-plying FLOW-assisted VSM and Section 8 concludesthe paper.

2. Related work

The related work for this study has three mainthemes: first the broader theme of software process im-provement using agile and Lean methods, second is theuse of VSM and third is the use of FLOW for mappingand improving software development process.

2.1. Process improvement in Lean software develop-ment

The primary focus of lean process improvement is theidentification of bottlenecks hindering the efficient flow

of the process. Therefore, different measures and visu-alizations have been proposed.

Staron and Wilhelm [7] investigated the method andmeasures employed by Ericsson to identify bottlenecksin the development process. It is stated that the companyon the basis of the Lean concepts of VSM and queuesdeveloped these methods and measures. With a simi-lar intention as Staron and Wilhelm, Petersen et al. [8]have proposed and evaluated visualizations to identifyand resolve bottlenecks in the development process andto follow-up on the degree of success of the resolutions.During this study, the time-line analysis (delineating theproductive vs. waiting times) and cumulative flow dia-grams were used to analyze the process. Cumulativeflow diagrams can be used to guide the identification ofroot-causes to explain the reasons for the observed bot-tlenecks (cf. [9] as an example).

The work by Staron and Willhelm [7] acknowledgesthe underlying contribution of VSM but that was not theobject of their study. While the earlier work on identifi-cation of bottlenecks by Petersen et al. [9] and [8] usesthe typical visualizations used in a value stream analy-sis, but it does not use the VSM as a framework to guidethe improvement activity in the organization.

2.2. Value stream mapping

Rother and Shook [2] presented the guidelines to con-duct VSM for manufacturing processes where both ma-terial and information flow are mapped. Realizing thedifferences in product development and manufacturingMcManus [3] adapted VSM for this new context. Mc-Manus [3] developed a manual for applying VSM forproduct development, which is the foundation of thiswork along with its extension by Khurum et al. [1].

Two applications of VSM were reported in the con-text of software product development [1], [5]. Mujtabaet al. [5] have reported a VSM for product customiza-tion process where the goal was to reduce the lead-time.Khurum et al. [1] identified value aspects that are nottraditionally considered, but have to be evaluated ona case to case basis, based on what each organizationconducting the VSM consider important from their cus-tomers’ perspective. In both cases, VSM was done onmature products that have been on the market for a num-ber of years. In this study, we apply VSM in the contextof a new large-scale software product development dis-tributed across sites in multiple countries.

Poppendieck and Poppendieck [4] also provide abrief three-step process to do a VSM. However, theoverwhelming focus of analysis in these guidelines ison developing a time-line of progress through a process

2

and making a distinction between waiting and produc-tive time (c.f. [1] [4] [5]). The aim of Lean is to en-sure that a process should make only “what” is requiredand “when” it is required by the next process [2]. Thetime-line analysis focuses primarily on “when” in theaim above and seems to overlook the “what” aspect i.e.what information needs exist that should be fulfilled.

In this study, we complement the time line basedanalysis of work items, which is typical in VSM, withthe use of FLOW methodology to identify and analyzeinformation flows in the case of large-scale softwareproduct development.

2.3. Information flow modelingMany established software process models focus on

documents only [10]. Verbal or informal communica-tion, and the use of experience in sophisticated activi-ties are, however, often neglected. In industrial reality,however, many requirements, decisions, and rationalesare communicated informally, via phone, meetings, orpersonal email. The FLOW method offers a graphicalnotation (Figure 3) and a modeling approach that coversand combines documented (solid) and non-documented,verbal, or informal (fluid) flow of information. Tradi-tional plan-driven software development tends towardssolid information propagation, whereas agile or flexibleapproaches rely on direct communication [11], of fluidinformation.

Both solid and fluid information flows have comple-mentary advantages and weaknesses. Solid informationis typically stored in documents, files, recordings, orother kinds of permanent media. Creating and retriev-ing information takes longer and requires more effort,but does not rely on the creator, and can be performedat a later point in time and by many people. Fluid in-formation flows faster and often more easily: phonecalls, chats, or short messages do not get formally docu-mented, but convey information as well. Fluid informa-tion is typically stored in a person’s mind. Therefore, aface symbol is used to visualize it.

Many companies need to mix and adjust elementsfrom both ends of the spectrum and try to find an overalloptimum. FLOW was created to capture, visualize, andimprove situations consisting of a complex network offluid and solid information flows. Experience is consid-ered an important special case of knowledge that mustbe present when difficult activities occur and importantinformation is routed through the organization [12].

At the beginning of a FLOW analysis, the currentcommunication channels and network of informationflows must be identified. The FLOW method [12] [13]offers a technique based on interviews. This technique

has been applied to medium-sized groups in severalcompanies. Rather complex networks of solid and fluidinformation and experience flows were identified, mod-eled, and discussed with domain experts. In one case, arepository was mined as an indicator of document-based(solid) information flows to complement interview re-sults [14]. The FLOW elicitation technique has not yetbeen applied to elicit and model complex informationflows in very large organizations. Building the model isthe first step towards improving the overall informationflow. FLOW interviews were optimized for individuals.An important research question was, therefore, whetherthe interview technique could be transferred directly toa larger group of people (workshop), and how it neededto be adapted.

Several researchers have investigated dependenciesand dynamics of software projects including the impactof information flowing through projects: Pikkareinen etal. [15], for example, investigate communication in ag-ile projects and their impact on building trust. The focusof their work is on the impact of agile communicationpatterns on project success.

Winkler [16] uses the term information flow, too. Hefocuses on dependencies between artifacts. An artifactis a part of a document. His main interest is traceabil-ity of requirements. Winkler considers only document-based requirements and information flows. He uses dif-ferent ad-hoc illustrations to discuss flow of require-ments. Berenbach and Borotto [17] present require-ments project metrics. All metrics are based on solidinformation only. However, information flow withintheir Formal Requirements Development Process couldbe modeled in FLOW. Some of their metrics could beextended to refer to fluid information, too.

Data Flow Diagrams (DFD) were designed to modeldata flow within computer systems [18], but they canalso be used to model data flow in a software process.The main drawbacks of using a DFD to model infor-mation flows for our purposes are a lack of distinctionbetween solid and fluid information, lack of symbols tocapture fluid information and a lack of intuitive symbolsto represent human stakeholders.

UML offers a wide range of diagram types. UML Ac-tivity Diagrams were designed to model processes usingcontrol flows, which is not the intention when captur-ing information flow. The drawbacks of using ActivityDiagrams to model information flows include: no dis-tinction between solid and fluid information, no meansof explicitly modeling experience, no visual clues likefaces, documents, many details and labels are irrelevantfor information flow, and activities are forced in a se-quence or order. Those who want to use UML to im-

3

plement FLOW can use UMLs profiling mechanism toovercome these limitations.

Requirements Centered Social Networks (RCSN)were specifically designed for requirements engineering[19]. RCSNs are generated automatically and thereforeonly captures a few types of informal communication,such as e-mails and chat protocols. The following areits other main drawbacks if used for information flowmodeling: 1) They are designed to visualize the net-work for a single requirement so they can only repre-sent a single concrete case and not recurring flows. 2) Itlacks means to express experience. 3) Too many differ-ent node shapes are confusing.

In principle, information flow can be seen as an as-pect of a process. Process models such as BPMNor BPEL or workflow models such as Little-JIL [20]would, therefore, be an alternative to FLOW models.However, the scope of FLOW models is smaller, andthe focus on fluid and solid information is more spe-cific than in those models that are more general. In ad-dition, the symbols of a FLOW model were carefullyselected to visualize human and document-based storesof information. Process models tend to emphasize se-quence and coordination of control flow more than theflow of information. The latter was considered moreimportant for this work.

In Table 1 a comparison of several competing no-tations with FLOW is provided. It shows that certainmodel mechanisms from such notations can be used toaddress information flow aspects. However, this will re-quire more or less severe violations of modeling rules orredefinition of symbols to capture information flow syn-tactically. Moreover, experts familiar with the originalnotation may find it difficult to work with the new se-mantic meaning of such an adapted visualization. Dueto these reasons use of the FLOW notation is recom-mended whenever flow of requirements and informationis the main focus [21].

Just as we argued that FLOW supports informationflow analysis in the VSM, FLOW can benefit fromVSM’s systematic way of reflecting on wastes and iden-tifying improvements. Besides the systematic approach,the time-line based analysis can help quantify the im-plications of challenges in information flow in softwaredevelopment. Hence, both VSM and FLOW have syn-ergies and may be even more successful in combination.

3. Research methodology

This study aimed to use and assess FLOW-assistedVSM for the improvement of large-scale software prod-uct development process. In particular, to assess the

ability to capture complex information flows and iden-tify improvement opportunities in the development pro-cess. The scope of the process investigated in this studywas restricted to the specification and design phases.

RQ: How useful is the combination of FLOW andvalue stream mapping in large-scale software devel-opment? The following sub-research questions wereposed to answer it through a case study at Ericsson AB,Sweden, where VSM supported with FLOW was ap-plied and evaluated:

• RQ1.1: Can the interview-based technique forFLOW be transferred directly to a larger group ofpeople (in a workshop setting), if not, how can itbe adapted?

• RQ1.2: Which wastes and improvements couldbe identified with the combination of FLOW andVSM?

• RQ1.3: How do practitioners perceive the processand outcomes for the VSM supported by FLOW?

3.1. Context

The case company is Ericsson AB, Sweden, which isan ISO 9001:2000 certified telecommunication vendor.The product that was studied is still under developmentand has not had a release to the customer yet.

At the time of this study, the product under investiga-tion was a solution comprising 12 subsystems, the num-ber has since then grown even further. The developmentunit has over 2500 employees in 10 different centers ofexcellence, which are located in Germany, Sweden, In-dia, China, Canada, and the US. Teams use agile prin-ciples and practices in development, e.g. writing userstories, working in fixed length sprints (time boxing),and cross functional teams, etc.

3.1.1. Product development process overviewThe overall process is conceptualized in Figure 1.

The process starts with the identification of an oppor-tunity for the organization to exploit e.g. a new poten-tial market, increased customer retention if the productis compliant to certain standards. It is formulated asa Business Opportunity (BOP). Based on the businesscase, a decision to persist further with the developmentof a BOP is taken.

High-level analysis of the accepted BOPs with theconsideration for the product anatomy, technical re-quirements and the business context is performed. Thisresults in more detailed specifications in the form of oneor more business use cases (BUCs).

4

Table 1: Overview of FLOW and other competing notations for denoting information flows (based on Schneider et al. [21]).

FLOW DFD UML ActivityDiagram

Little-JIL RCSN

Dia

gram

Mainpurpose

Process improvementby considering solidand fluid flows alike

System design Process design Processprogramming

Req. Engineering(RE) awareness

Mainfocus

Information, in partic-ular requirements

Data Activities Steps Social network

Informationstore

Person (fluid),Document (solid)

Data store,External

Data store stereotype Parameters, Agents Persons

Con

cept

s Informationflow

Dashed arrows (fluid)Solid arrows (solid)

Data flow arrow Data/object flow edge Parameters withcontrol flow

Communicationflow

Distinctionof solid andfluid

Different symbols(see Figure 3)

No Through stereotypes No Style/color ofarrow

Explicitexperience

Explicit edge color No Association stereo-types

Parameter Type No

Cha

lleng

es When usedfor infor-mation flowmodeling

No Stakeholder as pro-cess, data store, orexternal? Labelingrules violated.

Requires stereotypingfor symbols, extendedmeaning etc.

Fine-grained sym-bols lead to a verydetailed model,as it was a pro-cess programminglanguage

Notation is notfully defined,many symbols.

Opportunityidentification

Service and System level specification

and designImplementation Verification Release

Scope of the current VSM

Figure 1: Overview of the product development process in the case company.

BUCs are the work-item used to plan, control andmanage development process in the company. A de-tailed analysis of BUCs is performed and the systemsthat are required to implement the BUC are identified.A further detailed analysis by the system teams involvedin the implementation of a BUC produces more de-tailed system level artifacts called business sub-use case(BSUCs). At this level, the system teams take on theresponsibility of implementing the BSUCs for their sys-tems.

3.2. Scope of the process investigatedThe complexity and large scale of the product devel-

opment entailed that it was impossible to cover the en-tire process in sufficient detail to analyze it for the chal-lenges and improvements (with over 12 subsystems andalso the number of geographical sites involved) in sixworkshops.

Thus, it was decided to limit the current VSM activityto the “design and specification phase at both BUC and

BSUC study level” of the overall product developmentprocess. Furthermore, this phase is of critical impor-tance as the allocation of work and coordination to reachthe product goals through individual systems (which aredeveloped in geographically distributed sites) dependson this phase. Additionally, the organization is facinga lot of challenges in this phase. Lastly, as it is a newproduct, none of the BUCs have reached the verificationphase and beyond yet (see Figure 1).

The teams primarily responsible for the specificationphase at BUC level are located in the chosen site. Oneof the system development team (responsible for BSUClevel analysis) is also collocated at this site. Thus, wewere able to cover the entire specification phase withcoverage of both the service i.e. BUC and system i.e.BSUC level in the chosen site.

Thus, due to the scale of the product and reasonslisted above it was not possible to start with an end-to-end VSM of the entire development process. However,

5

after the completion of this study, VSM was conductedfor several of the individual sites to get an end-to-endperspective.

3.3. Data collection

The two main sources of data were: the six work-shops that were conducted as part of VSM and the cor-porate data on work items. This data included releaseplans, number of BOPs, BUCs and BSUCs their status,time spent in each phase, priority, number of impactedsystems, initial size estimates, categorization as func-tional or quality requirements. We relied on extensivenote taking, pictures of the white board and collectionof yellow stickers for collecting data during the work-shops. Notes from the researchers were corroboratedand compiled into reports before the subsequent meet-ing where a summary was presented.

The first two authors of the study were acting as VSMfacilitators who were responsible for data collection,moderating workshop sessions, analyzing the collectedinformation and presenting the results. The third authorserved as an expert on FLOW and observed and dis-cussed the process that was followed during the VSM.

One practitioner served as the “VSM Manager” whohad the upper management support and could sanctionthe resources and time necessary to successfully com-plete the VSM activity. Five other practitioners were in-volved who were present during the workshops. Thesepractitioners were chosen due to their knowledge andexperience of the process and also their stakes in it.

Table 2 lists the roles and experience of the partic-ipants in the VSM workshops. The participants werechosen with the scope of the process and diversity ofroles in mind for the following reasons: 1) No practi-tioner alone knows all the pertinent details for the end-to-end process 2) their involvement helps to develop aconsensus on the current way of working, 3) identifyingchallenges as even if there are individuals well versedwith the process they may not be aware of the challengesthat the people working in the phase have to face, 4) pri-oritizing of challenges, otherwise we may sub-optimizeby concentrating on a phase and not considering theend-to-end target 5) help to get the commitment on im-provement actions and plan.

Furthermore, data about progress tracking for BUCsand BSUCs was extracted by individual system own-ers and was given to the researchers in spreadsheets. Arelational database was created to reconstruct the linksbetween BUCs and their break down at system levelBSUCs. Lastly, examples of BUC and BSUC outputwere analyzed to triangulate the practitioners’ opinion

Table 2: Participants of the VSM workshop

Role and responsibilities Experiencewith theproduct

Experiencewith thecompany

Line manager, part of core team, sys-tem management

1.5 14

System manager, working on service-level analysis and system design

1.5 19

Program manager, budgets, prioritysettings, staffing requests

0 21

Architect, System design, requirements 3 20Project Manager 0.6 14

and perception of the quality of artifacts in terms of theircontent and level of detail.

To answer RQ1.3, in the last workshop, the practi-tioners were asked to filled out a questionnaire (witheight questions see Figure 11) anonymously. A sevenpoint Likert scale was used to collect their feedback onstatements that attempted to assess both the process forconducting FLOW-assisted VSM and its outcome. Ta-ble 3 maps the questions to the aspect being evaluated.

Lastly, a follow-up meeting was conducted wherethe product development team presented the status re-garding implementation of the identified improvements.This provided another reflection point for assessing thepractical usefulness of the FLOW-assisted VSM appli-cation in the case company.

3.4. Validity threats

This section reports the validity threats to the findingsof this study and what measures were taken to alleviatethem. The limitations of the study are also discussedhere.

Reliability related threats influence the repeatabilityof a study e.g. dependence of the research results on theresearchers who conducted it would diminish the relia-bility of a study [22]. To avoid inaccuracy in capturedinformation (information and views captured during theworkshops), two researchers took notes while the thirdresearcher was moderating the workshops. These notesand their interpretation were triangulated among the re-searchers. Also, the results of the previous workshopwere presented to the practitioners at the start of each

Table 3: The aspects evaluated in the questionnaire.

Question Evaluated aspect Perspective

Q1, Q2, Q3, Q4 Outcome VSM + FLOWQ5, Q6 Process VSMQ7, Q8 Process FLOW

6

subsequent workshop to identify any misinterpretationsby the researchers.

Internal validity is dependent on researchers’ aware-ness or ability to control the extent of a factor’s effectwhen investigating a causal relation [22]. Internal va-lidity of the results was increased by the involvementof multiple practitioners having various roles and re-sponsibilities in the development process. Multiple datasources were used in this study, the expert opinion onchallenges where possible was triangulated with actualprocess metrics e.g. the perception of under-estimationof required effort was validated by comparing the esti-mated time and the actual time spent on analysis. Sim-ilarly, number of closed BUCs and BSUCs were usedto validate the frequent reprioritization and quality ofinitial analysis.

Ericsson promotes continuous improvement in soft-ware development at all levels. We are aware that someparticipants in VSM related workshops were participat-ing in other ongoing improvement initiatives. Thus,there is a risk that the challenges and improvementsidentified in this study cannot be solely attributed to theintervention in this study. Their involvement in multipleinitiatives would have indeed influenced some findingsof this study as well. But due to the different focus ofthe initiatives, while there were some overlaps betweenthe outcomes of the study, a majority of the participantsagreed that the use of FLOW-assisted VSM lead to newinsights into the process that they did not have before.

Construct validity reflects whether the measures usedby researchers indeed represent the intended purpose ofinvestigation [22]. The opinions of practitioners on theprocess and outcomes of the VSM were collected us-ing a questionnaire. To reduce the risk that questionsmight be misunderstood, the researchers were presentduring this session to answer any clarification questions.Furthermore, to reduce the influence that our presencemay introduce and to encourage honest opinions, prac-titioners were asked not to put any identification infor-mation on the filled questionnaires. Furthermore, usinga semi-structured format, complementary themes wereexplored in a group discussion after the practitionershad filled the questionnaire.

External validity is concerned with the generalizationof the findings of the study outside the studied case [22].

Both methodologies, FLOW and VSM, have been in-dividually validated in industrial studies. While theirproposed combination has only been studied here onone product, however, it has been shown that the use ofFLOW successfully addresses the limitations of VSM.The context of the study, the process of combiningFLOW with VSM and under what conditions this com-

bination becomes useful has been defined in sufficientdetail for other practitioners to judge the relevance fortheir unique context.

4. FLOW-assisted VSM

The conventional VSM notation [2] is insufficient tocapture the details of the knowledge intensive softwaredevelopment processes. This limitation has not beenaddressed in the adaptation of VSM for product devel-opment VSM either where the additional informationcaptured is just regarding the iterations [3]. Figure 2illustrates the notation used by Poppendieck and Pop-pendieck [23] to draw a value stream map. For eachactivity, the time taken in processing (while a team ora person is actively working on a request) and the to-tal calendar time spent on a request is used to calculatevalue-adding time. Similarly, the waiting times in back-logs between various activities are calculated and cap-tured with this notation.

Process step or activity

Process step or activity

Process step or activity

Value adding time

“i” number of iterations

Non-value adding

“x” units

“y” units

“z” units

Figure 2: VSM notation (based on [23]).

As discussed in Section 2 FLOW is a methodologythat systematically captures and visualizes channels forinformation flow and allows the identification of sub-optimal communication paths [12]. Its simple notation,ability to identify and visualize both documented andundocumented channels of information, make it a prac-tical and relevant complement for use in conjunctionwith VSM.

The notation used by FLOW is presented in Figure 3.The notation is intentionally kept very simple. It is sup-posed to be used on a white-board or a piece of paperto discuss current and desired situations. An activity issymbolized by a rectangle with several incoming andoutgoing flows. The rectangle acts as a black box andhides internal details of the activities and flows. It canbe refined by another FLOW diagram [24]. The sim-plicity of the notation makes it more scalable comparedto more complex modeling notations. A FLOW model

7

State of Information

Solid

Fluid

Document

Group

Storage Flow

DocumentDocumentDocument

Person

1 2…n Information ExperienceActivity

ActivityIn*

Out* In*Out*

Control*

Control*

* : 0…n flows

Content (optional) Content (optional)

Content (optional) Content (optional)

Figure 3: Symbols used in the graphical FLOW notation.

mainly depicts the network of information flow (people,documents, etc.) and the types of channels used.

The original FLOW notation as presented by Schnei-der et al. [21] and used in previous industry applications,uses slightly different symbols for documents and per-sons. A document is usually represented by the docu-ment symbol available in PowerPoint; a person is repre-sented by a Smiley. Both symbols are readily availableand do not require any specific editor. The stick fig-ures and document symbols used in this paper are morefamiliar to the industry participants. This advantage ex-ceeded the conformance with previous applications ofFLOW.

VSM has five distinct steps; Figure 4 lists the stepsand the main activities in each step (for details pleasesee [1]). FLOW can be used in step S2, to elicit theCSM. However, we consider that it may not be neces-sary in every case to use FLOW for establishing a CSM.For example, if the challenges are related to long wait-ing times for items in backlogs, redundant reviews etc.then it may not be necessary to model different typesof information, stakeholders and competence. So, de-pending on the challenges identified in step S3 (see Fig-ure 4), we can decide whether the use of FLOW is justi-fied. Thus, if there are challenges related to knowledgemanagement or information flow, as was the case in thiscase study, then there is a utility of FLOW to identify theinformation needs, bottlenecks, broken communicationpaths and thus help in eliminating waste and creating aFSM in step S4.

In particular, the amount of information and its va-riety grows with the number of persons/sites involved,hence this has to be understood as well. Also, the infor-mation flows have to be understood to help explain whycertain waiting times (i.e. the time when “work items”that move through the process are inactive) exist in aprocess.

In the context of VSM, we can benefit from FLOWin the following ways:

• First we can use it for eliciting the informationflows in the product development process.

• Secondly, its graphical notation can be used to rep-resent the current state map.

• Lastly, it can be used to identify and reason aboutchanges in the current process to derive and docu-ment the FSM with improvements.

Five aspects listed in Table 4 are elicited for each ac-tivity in the FLOW elicitation technique. They refer tothe incoming and outgoing flows of an activity (see Fig-ure 3: activity symbol) and ask for the details of eachflow.

In this research, we used FLOW to materialize theLean principle of pull” for information-flow in the prod-uct development process. The idea is to use the pull-based approach starting from the down-stream phaseand identifying what information and experience are re-quired from an upstream phase of the process. In pre-vious applications, the order of FLOW interviews didnot consider the position of activities in the develop-ment process. Instead, the availability of intervieweeswas the primary concern.

Within FLOW interviews, the order of flows aroundone activity is usually:

• What are the activities you are involved in? Eachone is detailed afterwards.

• What does this activity produce, and where do theygo? The out-going flows respond to the pull ofdown-stream activities.

• What input is needed in order to produce this out-put, and where do you get it from? Very similar todata flow diagrams, there must be a source (incom-ing flow) of every information.

8

S1.A1. Identifying key stakeholdersS1.A2. Defining the purposeS1.A3. Defining the teamS1.A4. Training the teamS1.A5. Bounding the problemS1.A6. Defining and understanding the value and value creation

S1. Initiation

S2.A1. Drawing the zeroth mapS2.A2. Identifying tasks and flowsS2.A3. Collecting dataS2.A4. Evaluating valueS2.A5. Understanding iteration

S2. Current process map

S3.A1. Identifying waste

S3. Waste identification

S4.A1. Eliminating wasteS4.A2. Drawing a future state mapS4.A3. Re-evaluating value

S5.A1. Performing retrospective analysis

S5. Retrospective

analysis

Legend: ActivityStep

S4. Process Improvement

Figure 4: Overview of the VSM process based on [1].

• Who helps or directs the activity? The activity maybe controlled and supported by checklists, guide-lines, or experience. It is equally important tomodel where that experience is supposed to comefrom even if it is a person bringing this experienceto the table (fluid experience).

• What tools or support do you need for performingthe activity?

The questions are designed to crosscheck incomingand outgoing information with the receiver or source,respectively. Inconsistent answers indicate either incon-sistent terminology (spec vs. requirements document),incomplete knowledge of the source or target, or mis-understandings among co-workers, e.g. as one of thepractitioners said: (I always thought our BUC would beused by system teams as high-level input to do a detailedanalysis).

While eliciting information for each aspect in Table 4a distinction should be made between the current prac-tice and the ideal practice e.g. when covering the con-tent aspect, two sets of questions should be posed:

1. What information do you need? The aim here is toidentify the desired state of the process.

2. What information do you currently get? This ques-tion aims to explore the current state.

Once this has been done for all the aspects of eachof the activities in the CSM, one may compare the cur-rent state with the desired state to identify what is un-necessarily produced and what is missing. Similarly,having identified the personnel involved in each activ-ity we can identify situations where there is an infor-mation overload on some key personnel. Other critical

Table 4: Elicitation tool based on FLOW used for each activity

Aspect Questions

Tasks What are the main tasks in this activity? e.g. writeuser stories

Roles Who should be involved in this activity?Output What is the output of the activity? e.g. test casesIntput What is the input to the activity? e.g. user storiesContent Details of the input required?Who/What Who has the information needed for this activity?

What is the source of information?Competence What competence/knowledge sources are required

to facilitate this activity? e.g. architectural exper-tise, knowledge repository

questions could include reflection on whether we wantcertain channels to be fluid or solid. The strengths andweaknesses of each type must be balanced, given thatwe are now looking at a globally distributed contextwith geographical and temporal distance can we avoiddocumenting the decision about the priority of BUCs ina local spread sheet.

5. Application of FLOW-assisted VSM

In this section, we report the results of applying thefive step VSM process assisted by FLOW (as presentedin Section 4).

5.1. Initiation

Since the product is relatively new (no BUCs havegone beyond the implementation phase) and very large,it was decided to reduce the scope of this VSM activityto the “specification” phase of the process. Another mo-tivation was that all the necessary stakeholders for this

9

phase were located in Sweden. The specification phaseis responsible for formulating the work package, whichtakes the form of a Business Use Case (BUC) based onthe business opportunities (BOPs) that have been identi-fied (see Section 3.1 for an overview). The practitionersinvolved in the specification phase were also involvedin a high-level analysis to identify dependencies, setpriorities and indicate which individual systems wouldbe impacted and therefore should be involved in furtheranalysis and design of the BUC.

After negotiation with the product management theVSM goal for this product was to “reduce the lead-timefor end-to-end development process with a focus on im-provements in the specification phase”.

Besides the scale and other challenges listed above,we wanted to analyze the end-to-end development pro-cess to wasteful information that is not really requiredin the process downstream. So, we started with the “re-lease” phases (see Figure 1 for an overview of the pro-cess) and wanted to “pull” the information needs fromthere onto the phases upstream. However, this provedtoo ambitious due to the size and complexity of systemsinvolved in the product.

Therefore, we not only had to revert to the originalscope of the VSM activity, but we also started with thefirst activity in the process that is the specification of aBOP and identified what information should it containand what competence is required to define BUCs fromit and we continued so on and so forth for rest of theactivities in the specification phase.

We started the other way around as to refine thethings, it was easier to start from the beginning. At thestart, the information need is simpler and on a muchhigher abstraction level and that made asking whatneeds to be added, at least for this complex case workbetter.

5.2. Current state map

In first workshop with all the participants, an intro-duction to VSM, its process, prior experience of us-ing it (especially in the case company), the goal for thecurrent VSM activity and the rationale behind it werebriefly presented. “VSM Manager” specifically relatedthe company’s goals and to the goal of the VSM andencouraged participation in the workshops as an oppor-tunity to effect the future way of working.

After the introduction, we start with a very high-levelview of the development process in the company (as dis-cussed previous in Section 3.1 and shown in Figure 1).Then the participants were asked to draw the currentstate map on the board by following the work package

i.e. a Business Use Case (BUC) through the process (inthis case from “opportunity identification” till the de-velopment starts on the respective BUCs see Figure 1).With group participation, one typical BUC is followedthrough the process and the activities and tasks in thecurrent process are mapped. The outcome of CSM fromthe first workshop is presented in Figure 5.

The process starts with the high-level analysis andbreakdown of BOPs into BUCs by the core team. Thena team lead by a BUC author consisting of test manager,project manager and representatives from impacted sys-tem teams perform detailed analysis (called BUC study)on individual BUCs. A core team contact person is usedif there is a need for further elaboration on BOP or to as-sess if the detailed BUC specification is in line with themarket need. BUCs cover service level concerns thatare inter-system interactions etc. These BUCs are thenassigned to dependent system teams that perform BSUCstudies to address system level concerns and ensure thatvarious system development teams are able to developand test in a coordinated manner. This is a typical pro-cess view that will be a starting point for VSM. How-ever, in the next section when we look at the challenges(Table 5) this view is insufficient to address them.

5.3. Challenges

Both qualitative and quantitative information wasused to identify challenges in the current process.

5.3.1. Expert opinionOnce the CSM was done, the participants were asked

to reflect on the challenges that impede the product fromreaching the goal of reducing the lead-time. To encour-age participation, each practitioner was asked to writedown at least three challenges on “sticky notes”. Oneby one, they were asked to read out the challenges theyhave listed, to give a brief description of the challengeand to place it on the CSM. The next participant woulddo the same and if there was an overlap with the al-ready identified challenge they will be put the “stickynotes” together. This was supplemented by VSM facil-itators’ notes of challenges that were mentioned by theparticipants earlier while creating the CSM. An over-lap here could have meant that something is perceivedas a greater challenge than others. However, we knewfrom past experience that this only highlighted that acertain challenge was better known and talked about inthe company.

Therefore, once the consolidated list of challengeswas created, it was prioritized in terms of the impedi-ment or hindrance it poses to achieving the stated goal.

10

Business opportunities (BOPs) and

technical requirements

BusinessUse

Cases (BUCs)

BSUC study

Core Team

Initiation Start-up Presentation Finalise Review DoneWorkshopWorkshopWorkshop

System teams

BUC Study

Author, Core Team contact, Test Manager, Project Manager, Impacted system team (s)

High level

analysis

Figure 5: Current state map

Table 5: Perceived priority in terms of the hindrance these challengespose to reach the stated goal.

ID. Challenges Votes

1. Lack of high-level analysis and documentation ofbusiness opportunity analysis and breakdown toBUCs

12

2. Lack of documentation/ guidelines/ template/ scopefor system-level analysis

10

3. Lack of a common understanding of what informa-tion and the level of detail should be the outcome of aservice-level analysis

10

4. Incomplete architecture models / specification / func-tional baseline

10

5. Utilization of correct competence 46. BUC not updated/ Neither treated as an alive doc-

ument nor have an alternative document to trackchanges

2

7. Lack of end-to-end BUC responsibility 18. Incomplete information model 19. Quality of business opportunity document (Require-

ments instead of Business Opportunities)10. Challenges in communication with acquired compa-

nies having different maturity levels in the Telecom-munication domain.

The 100-dollar method was used to create a prioritizedlist of the challenges [25]. Each participant had tendollars to spend on the list of the challenges, payingmore for the challenges they believe are major hurdlesto achieving the stated goal. This collective prioritiza-tion was useful to avoid any personal biases of partici-pants and to get a consensus on what is collectively con-sidered important. The challenges identified, and theirrelative priorities are listed in Table 5.

Moreover, a rudimentary root cause analysis wasdone for the top four challenges to understand the rea-sons behind the challenges. These are summarized inTable 6.

Given that most of the challenges were related to doc-umentation, understanding information and competenceneeds it was evident that existing notation for describ-ing the current state map (as shown in Figure 5) willbe insufficient. Besides, the typical timing based analy-sis [26] [3], it was decided to utilize FLOW [12] thatsystematically captures information flows in the soft-

ware development process. The current state map (asshown in Figure 5) was used as a list of activities thatbecame input for FLOW where details of each activitywere further elicited.

Lessons learned: If we find challenges in a CSM re-lated to: documentation, lack of common understand-ing, or unsatisfied information needs, it points to theneed to conduct information modeling in the contextof value stream mapping analysis.

5.3.2. Quantitative analysisFigure 6(a) shows the estimated time required for

completing the analysis and the actual time taken tocomplete it. While Figure 6(b) shows the distributionof lead-times of various BUCs for the analysis.

By analyzing the lead-time for this phase, it was iden-tified that unlike the typical initial estimate about thehigh-level study which should at most take 6 time-unitsin reality even the median value of actual time spentwas higher than that with the worst lead-time of 23 timeunits (see Figure 6). This was consistent with the gen-eral perception (expressed in the workshops by practi-tioners), that the initial estimates are very inaccurate andunderestimate the required effort.

This may explain another observation about the cur-rent way of working, i.e. why the SPM team would notprovide a prioritized list of BOPs and assign more workthan the capacity of the analysis team (as expressed bypractitioners in the workshops and also reflected in thelong lead-times). Thus, the mismatch is because of theSPM team’s expectation that the analysis is not an ef-fort intensive task (as seen by the consistently under-estimation of effort required as shown in Figure 6) whilethe reality is very different. Furthermore, the consistentunder-estimation raise the question, whether the BUCsare broken down to the appropriate scope?

By looking at the release plan and current statuses ofvarious BUCs we were able to identify two wastes:

1) Instead of “build integrity in” more immediate fo-cus is on delivering functionality: very few i.e. less than18% of non-functional requirements were assigned tothe upcoming release while a majority was assigned to

11

Table 6: Challenges and the reasons behind them.

ID. Challenge Reasons

1. Lack of high-level analysis and docu-mentation of business opportunity anal-ysis and breakdown to BUCs

Due to time constraint, there is a lack of documentation with over-reliance on the peoplein the core team. This sometimes also leads to inconsistent responses from within the coreteam.

2. Lack of documentation/ guidelines/template/ scope for system-level studies

Underestimated the need, had “hoped” that development can start without doing this levelof analysis. Also, there is a lack of awareness that this analysis has to be done.

3. Lack of a common understanding ofwhat information and level of detailshould be the outcome of a service-levelstudy

It was decided early on that service-level analysis (BUC study) will be kept on a high-level. However, contrary to this directive the expectations of the system teams responsiblefor system development are different (they expected much more detailed level of analysisand specification). Between the service-level analysis which is relatively high-level andthe system-level analysis which only covers the analysis for intra-system level details, adetailed analysis of inter-system level is missing for BUCs that require more than onesystem to deliver.

4. Incomplete architecture models / speci-fication / functional baseline

Underestimated the work, complexity and time it will take. Also, the value of havingthese for the product was underestimated to facilitate analysis and later on design anddevelopment. When reflecting on the causes, practitioners recollected statements like“we will do it later” or that the product is “based on a legacy system so there is noimmediate need” for these documents. Another reason is weak governance i.e. to manageand enforce such standards based on the information needs.

0

5

10

15

20

25

Lea

d tim

e

BUCs%

Actual Estimate

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 18 23

Freq

uenc

y

Actual lead time

a) Comparison of actual and estimated time required for analysis b) Distribution of BUCs based on lead-time

Num

ber o

f BU

Cs

Unique BUCs Lead-time (actual)

Lead

-tim

e

Actual time

Estimated time

(a) Comparison of actual and estimated time required for analysis

0

5

10

15

20

25

Lead

tim

e

BUCs%

Actual Estimate

0

2

4

6

8

10

12

2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 18 23

Freq

uenc

y

Actual lead time

a) Comparison of actual and estimated time required for analysis b) Distribution of BUCs based on lead-time

Num

ber o

f BU

Cs

Unique BUCs Lead-time (actual)

Lead

-tim

e

Actual time

Estimated time

(b) Distribution of BUCs based on lead-time

Figure 6: Analyzing the estimated and actual time spent on BUC analysis

Function

Quality

Figure 7: The trend in prioritization of Non-functional requirements

a later release. The approach is roughly visualized inFigure 7 where the current focus is on delivering func-tionality.

2) “Partially done work” instead of taking one itemthrough the process: There were slightly fewer ongoingBUCs that were assigned to the subsequent two releasesthan the number of BUCs where some work has been

done. For release 1 and 2: 45% of all the BUCs wereassigned high-priority for development. However, only47% of the BUCs being investigated belonged to thisgroup. Similarly, 33% of the BUCs that have been ana-lyzed did not belong to the high priority group. The rea-son for such a high number was mostly re-prioritizationdue to the changing market for this new product.

6. Results

In the following sections we have reported the resultsof the study in alignment with the research questions.

6.1. The use of FLOW interview-based technique(RQ1.1)

In this study, using the typical VSM process [1] thetop four challenges identified by the practitioners wereall related to information needs and flow in the organi-zation (see Table 5). The existing VSM notation and

12

method are incapable of investigating and improvingsuch challenges. For example in this case, the level ofdetail in the current state map (see Figure 5) was insuf-ficient to discuss solutions to the top four challenges.Therefore, we decided to use the FLOW notation andmethod to fill this gap in current adaptations of VSM.

The focus of the study was the specification phaseand utilizing the Lean concept of “pull” [27] we wantedto identify what information will be required by down-stream phases that must be created in the specificationphase. The idea was to make a conscious decision inthe upstream phases about aspects like which analysesto perform, in what detail, whether to document the re-sults and what media to use for dissemination. Thus,avoiding any unnecessary analysis and documentation.

Therefore, to “optimize the whole” [23] we startedwith the release phase of the product and identified whatactivities are performed during this phase. Then usingthe FLOW elicitation template the inputs required forthose activities were listed and relevant information likethe sources and state were elicited. During this work-shop, there were two main findings:

• First, we realized that applying the “pull” principleon the selected scope i.e. starting with the activi-ties in the release phase and essentially identifyingwhat needs to be documented and how in the spec-ification phase did not work (see Figure 1 for anoverview of the development process).

• Secondly, we found that eliciting the informationand structuring it in the form of FLOW elicitationtemplate (see Figure 8) on the fly did not work wellin the workshop setting. It was not the template butrather the attempt to structure information whileeliciting that became a problem in the workshopsetting.

Although conceptually it made sense to identify theinformation needs in the last activity of the entire devel-opment process and then pull that required informationfrom the preceding phase all the way to the start of thedevelopment process, but due to the following reasonsit did not work in our case: 1) the scale of the prod-uct development (we lost most of the participants in thediscussions, as such only the practitioners responsiblefor that phase were aware of the detailed tasks, inputsand outputs) 2) because it is a new product still underdevelopment and none of the BUCs have reached eventhe service level testing yet, we realized that soon it be-came an exercise of assuming what information needswill exist and what and how the required information isassumed to be delivered.

ContentWho/WhatInput Tasks Roles Competence Output

Current state

Future state

What do you need?

What do you have today?

Figure 9: Elicitation of information based on FLOW template in aworkshop setting.

The reason for the second observation we consider isthat structuring the information on the white-board inthe FLOW template form was not adding value. In aworkshop setting, it became very difficult to moderatee.g. some people were now listing outputs and someonementioned an input and the discussion started on that.

Based on these two observation, we made twochanges to our approach, we decided to focus only onthe scope of the current VSM i.e. the “specification”phase instead of the end-to-end development processand we used FLOW in the background, guiding the elic-itation and to structure and report the findings and re-sulting process maps (made using the FLOW notation)to the practitioners.

Therefore, taking the activities in the current statemap (see Figure 5) one by one we elicited the sixcolumns on a white-board as depicted in Figure 9. Hav-ing elicited this information we used FLOW notation tovisualize it. Thus, researchers acted as the interface be-tween FLOW templates and practitioners thus avoidingthe need to train practitioners with the FLOW templatesor methodology.

6.2. Improvements and the future state map (RQ1.2)

Based on the analysis reported in Section 5.3 the fol-lowing considerations were highlighted when creatingthe future state map and action plan for improvements.Section 6.2.1 lists the contributions of a typical artifactflow done as part of VSM and Section 6.2.2 identifiesthe contribution of performing information flow analy-sis using FLOW as suggested in this study.

13

MetadataInterviewer:Interviewee: Date:Context details:

Function/Person Content State (solid

or fluid) Media

Function/Person Content State (solid

or fluid) Form

Function/Person Content State (solid

or fluid) Form

Function/Person Content State (solid

or fluid) MediaActivityFunctionPersonTasksMisc.

Control

From To

Support

Figure 8: Interview-based elicitation form used in FLOW

6.2.1. Improvement considerations derived from typicalVSM analysis

The data on waiting times and productive time wasnot collected in the company for this product thereforethe typical time-line analysis (as shown in Figure 2),which is done as part of VSM activity could not be per-formed. However, the analysis was guided by the prin-ciples of Lean and what is typically considered waste inLean software development [4]. In the remainder of thesection, we highlight the principles and wastes that ledto insightful discussions and improvement proposals forthe process.

According to Poppendieck and Poppendieck [4] thetwo ways to reduce cycle time for a process are toachieve a steady arrival rate for work and to look at howthe work is processed and remove variability in the pro-cessing time.

For this product, we found that the requirements werehanded over in large batches and without adequate pri-oritization. The perception was that there are a highnumber of service-level analyses (BUC studies) beingdone in parallel and it was seen in the data as well (seeSection 5.3.2). There were as many ongoing and com-pleted service-level analyses that were not even highlyprioritized as the ones with a high priority. This wasdone without taking into consideration the capacity ofthe organization. Therefore, the current push based ap-proach should be replaced with a pull driven approachthat takes into account the capacity of the developmentorganization and the priority of the business opportu-nity.

One indication of too many ongoing studies is re-flected by the dissatisfaction with the quality of infor-mation about the breakdown of BOPs to BUCs (see Ta-ble 5). Another indication is the sheer overwhelming

feeling that the teams have of working with service-level analyses (BUC studies). Yet another quantifiablemeasure is the fact that none of the BUCs have reachedthe system-test or the service-test levels in the productdevelopment life-cycle.

When seeking explanation for the reasons behind cer-tain challenges, it was noticed that a majority of thechallenges were due to the secondary importance givento the documents necessary to ensure the non-functionalattributes of the system. For example, in Table 6, whenasked about the reasons why architectural model andfunctional baseline were not created in time, the rea-sons include that the value was underestimated or thatthere was a time pressure. A similar mindset towardsquality was noticed in the release plan where functionalrequirements were prioritized over non-functional re-quirements (see Figure 7).

Furthermore, the consistent under-estimation (seeFigure 6(a)) raised the question, whether the BUCs werebroken down to the appropriate scope?

For the future, the key improvements identified wereas follows:

• Release frequently and take in smaller batches [4].“Do not keep piling up work that cannot be usedimmediately” [4]. This ensures a continuous flowof requirements instead of batches/chunks of busi-ness opportunities

• Improve prioritization of business opportunitiesand BUCs to address the issue of parallelism

• Efficiently deliver new BUCs to the developmentorganization (pull driven) also helps to address theissue of parallelism. No need to keep piling upBUCs (through hastened BUC studies) if the de-velopment organization does not have the capacityto implement them.

14

6.2.2. Improvements derived from the use of FLOWLesson learned: The current state map (see Fig-ures 1 and 5) did not allow us to analyze the processin sufficient detail to address the identified challengesin the process (see Table 5). With these process de-scriptions, we could have modified the process a biton a high-level, however, improving it would nothave been possible without the awareness of addi-tional information in each step of the process.

With the improvement suggestions (as discussed inSection 6.2) and key challenges that were related to in-formation needs (see Section 5.3) in consideration, theFLOW methodology was used. Using the high-level listof activities (see Figure 5) as input, the FLOW method-ology helped to systematically elaborate and visualizethe state and storage of information, and also the infor-mation and competence required to perform these activ-ities. This facilitated to identify causes for certain issueswhere the flow of information was broken and to iden-tify concrete improvement actions.

Figure 10 shows the outcome of the VSM activity us-ing the FLOW notation. This figure is not intended toexplain the development process at Ericsson, rather theintention is to give a flavor of the size and complexityof the process being analyzed. Also, any practitionersapplying the proposed approach can see what can be ex-pected as an outcome from it. The improvements in theprocess are coded in blue color and are listed below:

• The information required to define a business op-portunity (BOP) was established

• Prioritized list of BOPs based on the market win-dow by the product management team.

• Acceptance criteria for an initial BUC definition tobecome sufficient for detailed analysis were estab-lished. This entailed that the core team should pro-vide a statement about the scope, list of impactedsystems. A non-technical description of the high-level value, i.e. what do we want to achieve withthis BUC. Furthermore, analysis of the informationmodel and architecture should be made availablefor service level analysis (BUC study).

• Involving product managers after initial analysis tovalidate if the understanding of BOP is correct andthe direction of BUC specification is aligned withthe expectation in the BOPs.

• Identified what is missing in the detailed BUCs thatneeds to be added for system teams to perform sys-tem level analysis.

• Added an activity between service level analysisand system level analysis that should cover the

inter-system concerns in more detail for BUCs thatrequire more than one system to deliver. The BUCanalysis lead along with the impacted system-teams is required to develop an initial specificationof inter-system interfaces and a preliminary sched-ule for development.

• It was decided to involve the Cross FunctionalTeams early on in the BSUC study activity.

• Detailed list of tasks that should be performed aspart of the system-level analysis (BSUC study)were detailed as well.

Furthermore, with the visualization of overall infor-mation flows other challenges that were not visible be-fore were highlighted. For example, it was observedthat the prioritized list of BUCs was not available to allthe sites and was maintained in a spreadsheet. Simi-larly, given that the quality of architecture descriptionwas considered an issue, it was visible that the resources(only two persons whom are assigned to communicatewith all the system teams and to maintain/update thearchitecture description apart from their other commit-ments being part of the core-team) were insufficient.

Figure 10 shows the final version of this analysis. Theitems in blue are what have been identified as improve-ments in the current process, which included: assign-ment and clarification of roles, establishment of newactivities, artifacts and details of their content and theneed for competence.

This simple representation provided sufficient sup-port to analyze the process further and identify addi-tional challenges, e.g. deciding about what informationshould be documented and where it is more optimal torely on face-to-face communication.

Compared to the current state map (see Figure 5) thatwas drawn without the use of FLOW methodology, itis visible that these improvements could not have beenidentified and conceptualized without the use of FLOW.

6.3. Practitioners’ perspective (RQ1.3)To elicit practitioners’ feedback on the process and

outcome of FLOW-assisted VSM a questionnaire wasused. The questions along with the responses are de-picted in Figure 11.

Regarding FLOW, overall the practitioners perceivedthat its use led to more insightful discussions and shouldbe used at the company. No negative opinion was ex-pressed regarding further its further use in the com-pany for process improvement (see response to Q8).For question Q7 three practitioners agreed that the useof FLOW led to more insightful discussions while onepractitioner disagreed with the statement.

15

Service level (BUC study)

- Six step process- Update inform

ation model

-and service docum

entation - BUC Dependencies

Software Product m

anagement (SPM

)

Create BO

PBusiness opportunity (BO

P) Custom

er priority:Custom

er (source):Detail: Value:

Lead Architect

Prioritisation Negotiation

Prioritised list of BO

P

Core team

High-level analysis

- Breakdown of BOP to BUCs

- Dependencies- System

impact

- Additions

- Is it worth continuing to the next step with a certain BO

P?

2 Architects from

system

teams

Initial BUC in Mingle

- Impact analysis

(systems, inform

ation and architecture)- Scope- Rationale

BUC Analysis lead

Update information m

odel

2 mem

bers of Core team

Information m

odel

Update Architecture

Architecture(Anatomy)

2 reviewers from

Core team

System team

Detailed BUC

Solution overviewIm

pacted PACs, Im

pacted interfacesIm

pacted Services

System-level (BSUC

study)

- Technical solution - Collaboration with other system

s- Interface specification- Awareness of other ongoing BUCs' developm

ent- Follow the BUC priority- Identify BUC driver for the future

System

team

EPICS, US, Inter and intra-system

Specification

- Dependencies- Using input from

the architectural work (how do things fit)- Coordination to specify interfaces- Agreem

ent on scheduling

- Initial specification of Inter-System

interfaces

- Preliminary plan for

alignment of schedules

System

teamBUC Analysis lead

Prioritisationfor BUCs

Development

team

CFT

Update Service docum

entationService Docum

entationSystem

team

ActivityDocum

ent

Changes and additions are highlighted with blue color

Comm

unication through people

Comm

unication through documents

Legend:

Test managem

ent teamCore-Team

contactDependent BUC Analysis leadProject organization Team

Architecture team

Figure10:Future

statem

ap

16

Q1. We have gained new insights about our software development processes that we did not have before.

Q2. The improvements identified will help in improving the software quality.

Q3. The improvement actions identified will be implemented in the future.

Q4. The improvements identified are realistic to implement.

Q5. I do not prefer VSM to other software process improvement activities that I have participated in earlier.

Q6. I would like to see VSM used more extensively at the company

Q7. Overall more insightful discussions resulted from separation of sources (people /documents) of information and what information is required.

Q8. I would like to see FLOW as an analytical tool for process improvement more intensively used at the company

Response Strongly disagree Moderately disagree

Count of practitioners for each response type

Slightly disagree Neutral Slightly agree Moderately agree

2 4

2 31

11

1 1

1 3

1 3

1 5

4 1 1

1 1 1 3

4 2

Figure 11: Feedback questionnaire results for the six practitioners.

While expressing their feedback on the outcomeof use of FLOW one practitioner found the notationand the final outcome where the end-to-end processoverview, artifacts (key information items), and stake-holders is visible on one sheet is really good “Best out-come of the exercises”. Another remarked, “it is goodto depict stakeholder interaction in the process”.

Similarly, as seen in responses to questions Q5 andQ6 in Figure 11, the practitioners received VSM largelypositively. Only one practitioner disagreed with the con-tinued use of VSM and use of VSM as the preferredmethod for process improvement in the company. How-ever, since no information about the other improvementactivities that the participants may have previously beeninvolved was elicited, and due to the anonymity of ques-tionnaire respondents, we could not investigate the neg-ative feedback further.

Questions Q2 - Q4 had no negative response fromany of the practitioners showing an overall agreementthat the improvements identified in the workshops willlead to improved software quality. The results also showconfidence in the improvements being realistic to imple-ment (see responses to Q2 and Q4 in Figure 11. Besidesthe agreement on the realistic nature and a likely posi-tive impact of the improvements, only two practitionersthink that they will be implemented in the organization.

Interestingly, in a follow-up at the company sixmonths after the conclusion of this study (see Section6.4) it was found that contrary to the skepticism ex-pressed by the practitioners the improvements had beenimplemented in the organization.

There were mixed responses to the statement thatthey gained new insights into their development process(see question Q1 in 11). Half of the respondents agreedthat they did gain new insights and two disagreed. Itis noteworthy that this is still a positive result, as ev-

eryone needs to have the same understanding for sucha large process. Thus, half of the participants gainingnew insights is important to assure an end-to-end per-spective where everyone knows what information theyshould provide, or shall receive and facilitate its flow.

One criticism expressed by a participant was that “theimprovements identified were less than what they hadexpected from the VSM activity” she also commentedthat there was a “high overlap” during the workshopsthat were spread overtime.

Two practitioners commented that the workshophighlighted the break in the flow and brought focus toit. Other positive comments highlighted the “granular”level at which analysis was done and how it helped tofocus on optimizing towards the overall flow instead ofsmall improvements.

6.4. Follow-up after six-monthsThe practitioner who acted as the “VSM Manager”

during this study conducted a follow-up and reportedthat almost all the improvements listed in Section 6.2have now been implemented which address the top.Such as:

• “One slider” implemented in BUC study to giveoverall summary of business needs and impact onsub-systems – Challenge 1 in Table 5

• Assigned BUC responsibility for the entire lifecy-cle – Challenges 6 and 7 in Table 5

• To deal with parallelism related problems, a con-straint on number of BUCs being developed con-currently has been introduced

• Mechanism to deal with dependency, structure onhow to handle cross-PAC dependencies is now inplace. Interface descriptions are to be defined be-fore concluding a BUC study – Challenge 3 in Ta-ble 5

17

• service and system models and governance forthese models have been established – Challenge 4in Table 5

• BSUC study process has been established – Chal-lenge 2 in Table 5

Furthermore, having seen the value that VSM analy-sis can bring they have also collecting data on back-log size and waiting time and it has been connectedto the generic measurement dashboard in the company.The process is still not “pull driven” which is a com-pletely different way of thinking and is not intuitivelyobvious. We are often used to thinking in processingbatches. Having said that, the changes that have beenimplemented to lay the groundwork, e.g. having thequantitative data on waiting times that will now be col-lected, will help to motivate the transition in the teams.

Typically, companies are hesitant to make an invest-ment in change, unless they are fully convinced of thebenefits. Since, almost all the improvements identifiedin this study have been implemented it shows their con-fidence in the process that was followed in the study andits outcomes.

7. Reflections

FLOW methodology was used to guide elicitationand its notation was used to structure information andrepresent the process using it. The simple notation waseasy to adopt for us and practitioners shared the sameopinion about the process. It helped us to identify pointsthat needed further clarification and to pinpoint peopleand artifacts that may be potential bottlenecks in theprocess.

Key lessons from using FLOW to assist VSM in thiscase are the following:

• The scope cannot be too broad in such a large prod-uct, instead of the entire end-to-end process startwith individual phases and still have practitionerscovering various perspectives from the overall pro-cess.

• The maturity is a factor, and people had a tendencyto fall back on the old processes they already knowand put them into the future state map (i.e. hard tothink on a ”green field”).

• The notation should not be enforced on the partici-pants, this is something that the researchers shoulddo on the background.

• Even for a very large-scale process, we could ac-curately capture the future state map on a level thatthe practitioners agree and commit to the findings,

and this could be represented on a single A3 (i.e.the whole process)

• The companies having a similar structure (multi-ple products, need for break-down from abstract tomore detailed and then allocating to sub-systems- SoS approach - can benefit from some learningswith regard to how to actually structure the pro-cess)

• Information that was elicited in just a few work-shops could most likely not have been gathered bykeeping on the abstraction level of the current statemap, and that the distinction between informationflow types etc. helped to critically appraise the pro-cess and identify bottlenecks e.g. the new activ-ity that is added to bridge the information gap be-tween service level analysis and system-level anal-ysis (see Figure 10).

• Overall, the experience indicates that the approachscales. This was shown with the ability to capturesufficient detail of the process in six workshops tocapture the current way of working, analyze it, andreach consensus on what challenges to address andhow to address them for a large scale product (for adiscussion on the scale, see the context descriptionin Section 3.1).

• Based on the experience from this case, the combi-nation of VSM with FLOW can be useful in caseswhere the development process is not well defined,if there are challenges related to information ex-change, or if the organization is involved in dis-tributed development.

Having diversity in participants that gave a sample ofvarious stakeholder roles from the teams involved in thespecification phase of the product development processat the company enabled a systemic end-to-end view ofthe specification phase and in general the concerns thatlater phases may have. Their participation ensures thatthey understand the problems and challenges in otherareas that they may not directly be working in. Also, ithelps to get a buy-in from stakeholders who may needto do additional work in the future to improve the qual-ity and reduce the lead-time for another process thatconsumes their output (although it may not reduce theirlead-time). In short, it helps to achieve the end-to-endperspective within the specification phase and avoids thepitfalls of sub-optimizing in silos, although we couldnot reach the same goal for the entire product develop-ment process.

Using “sticky-notes” to identify challenges ensuredparticipation and gave everyone the opportunity to bringup the challenges they face and consider as a hin-

18

drance. Furthermore, by using a variant of the 100 Dol-lar method for prioritization [25] where each participanthas an equal opportunity to highlight what they consideris crucial to address if the organization is to reach thestated goal. In this study, it was seen that although somechallenges generated a lot of discussion, but they werenot high-up on the prioritized list.

Quantitative analysis (see Section 5.3.2), not a lot ofdata was available as the process was not well definedand it took considerable effort to extract data from dif-ferent sites and to we had to manually connect the datafrom different silos. Yet the utility became apparent notonly to triangulate the qualitative input from the practi-tioners (e.g. the amount of parallelism in the process)but also to identify new challenges that they had notidentified (prioritization of functional requirements overnon-functional requirements).

Apart from the participation in workshops and mak-ing data available to researchers no further investmentwas required from the practitioners. From the organi-zation, the investment takes the form of ensuring thatthe practitioners are available for the workshops. Forresearchers, taking on the role of facilitators the invest-ment includes understanding the context, familiarizingwith the technical jargon, data analysis, reporting of re-sults and conducting the workshops. In this study, ittook approximately 16 hours of workshop time to arriveat the FSM.

7.1. Reflections from the FLOW expertFrom the perspective of FLOW, the combination with

VSM brought a number of insights: In previous cases,FLOW had been used in a series of interviews. In eachinterview, one person was asked about his or her con-crete activities, and their output and input information.In between two interviews, the graphical FLOW modelwas updated and extended accordingly. In several cases,flows between two activities were not described consis-tently from both sides. Other flows were not mentionedat all, leading to “dangling” flows, or obviously unclearflow of information. All those cases triggered focusedin-depth questions in the next interviews. Thus, graphi-cal flow models were not shown in interviews, but usedin the back office to prepare and focus subsequent in-terviews. Final FLOW models were only displayed toparticipants after the series of interviews. There wasa summary workshop around the FLOW diagram thathad emerged, with a number of observations by the re-searchers. Activities for improvement were derived inthose final discussion workshops. Due to the size andtime restrictions, bilateral interviews were not an op-tion in the case described in this paper. There were

too many parts to be discussed and too many people tobe involved. Trying to fold a series of interviews intoa single workshop (or maybe two workshops) did notwork well, as outlined above. In particular, there wasno opportunity to update a FLOW model and then re-flect on inconsistencies, dangling flows, and the like.The adapted solution used here relaxed the scheme ofasking for outgoing, incoming, controlling flows a little.Keeping those aspects in mind helped to elicit importantinformation. Doing it in a more informal way than dur-ing typical FLOW interviews was advantageous for theworkshop setting.

The state map in Figure 10 is large and rather com-plex, but not exceptional for a final FLOW diagram.Initial FLOW models tend to be very simple, cover-ing only one or two activities and their related flows.The models grow with every person interviewed. Fig-ure 10 was not updated iteratively after each interview,but drawn in one step after the workshops that servedfor eliciting information. Once the FLOW state map inFigure 10 existed, however, it was used in a very sim-ilar way as previous FLOW models in other cases dur-ing the final discussion workshop: Participants wouldpoint to it, step up to it, correct it, and refer to informa-tion flows without necessarily calling them informationflows. The diagram helped focus discussions and gain agood overview. Such a large diagram is difficult to drawfrom scratch, i.e. from the textual notes alone. However,this adapted variant of information gathering and visual-ization was obviously more appropriate in this context.This new approach of creating a FLOW model will feedback into the FLOW methodology.

8. Conclusion

We have presented a process for conducting VSMthat performs both the typical artifact flow analysis andadditionally the information flow analysis. For latter,we have utilized the FLOW approach to overcome thelimitations of existing VSM method and notation. Theprocess for FLOW-assisted VSM and its outcome arepresented in this paper to help other researchers and in-dustry practitioners to apply it in their context.

A case study that was conducted to evaluate the use-fulness of the combination for a large-scale product atEricsson AB has contributed to answer the following re-search questions:

RQ: How useful is the combination of FLOW andvalue stream mapping in large-scale software develop-ment? In cases, such as the one reported in this paper,where the challenges are mostly related to communica-tion and information flows, the use of FLOW methodol-

19

ogy will be beneficial to provide a systematic approachto identify, visualize and evaluate information flows.

For new product development, where the processesare less mature and the product is still in its infancy,a typical quantitative analysis of waiting times for arti-facts is often not possible and perhaps not as important.The more significant aspect is to establish a process thatencourages taking the end-to-end perspective and im-proving the flow of information and artifacts through theprocess.

FLOW provided a systematic approach to elicit, vi-sualize and analyze information flows. The lightweightapproach with intuitive notation provided the necessarysupport missing in the current VSM to analyze informa-tion flow and effectively streamline the value stream

VSM provided a broader framework that brings a sys-tematic approach of reflecting on the value stream toeliminate waste and identifying improvements. WhileFLOW was successfully used to elicit and model in-formation flows. Furthermore, the artifact flow analy-sis, where the time-line for the value stream is assessed,which is typical in VSM, helps to quantify the implica-tions of challenges in information flow.

RQ1.1: Can the interview-based technique for FLOWbe transferred directly to a larger group of people (in aworkshop setting), if not, how can it be adapted? Asshown in Section 6.1 the content elicited in the typicalFLOW interviews was found sufficient for informationflow analysis. However, in a workshop setting the elic-itation mechanism had to be adapted to the situation.Presence of multiple practitioners posed a challenge asthey had multiple perspectives and understandings ofthe process due to their different roles in the organiza-tion. Instead, we used it to our advantage by putting theelicited information on a white board (as shown in Fig-ure 9). This helped to develop consensus on both thecurrent and the desired state of information flow in theprocess.

RQ1.2: Which wastes and improvements could beidentified with the combination of FLOW and VSM?

Using VSM assisted by FLOW helped to create aspecification process, identify stakeholders and arti-facts, and detailed content of these artifacts. Thiswas essential for the processes that consume the out-put of the specification phase. This approach identifiedimprovement opportunities in the current process andhelped visualize them in the future state map.

It was found in this study (see Section 6.2) that therewere challenges and improvements that were uniquelyidentified through typical artifact-flow analysis (typ-ically done in VSM) and information-flow analysis(atypical of VSM in software development).

RQ1.3: How do practitioners perceive the processand outcomes for the VSM supported by FLOW? In ananonymized questionnaire, practitioners responded fa-vorably to the use of VSM and FLOW and would like tosee its continued use in the company. They were all pos-itive about the realistic nature and the likely benefits ofthe identified improvements on software quality. How-ever, there was a fairly weak agreement on whether theuse of VSM and FLOW generated new insights abouttheir process.

Another significant benefit of FLOW notation wasits simple yet powerful notation that was intuitive andeven for a large scale product development process, anoverview of the entire process could be represented ona single sheet of paper This was highlighted by the par-ticipants of this study.

Acknowledgment

The authors would like to thank Kennet Kjellssonfrom Ericsson AB, Sweden who facilitated this work.We are also grateful to all the practitioners for their par-ticipation and feedback. This work has been supportedby ELLIIT, a Strategic Area within IT and Mobile Com-munications, funded by the Swedish Government.

References

[1] M. Khurum, K. Petersen, T. Gorschek, Extending value streammapping through waste definition beyond customer perspec-tive, Journal of Software: Evolution and Process 26 (12) (2014)1074–1105.

[2] M. Rother, J. Shook, Learning to See: Value Stream Mappingto Add Value and Eliminate MUDA, spi edition Edition, LeanEnterprise Institute, Brookline, Mass., 1999.

[3] H. L. McManus, Product Development Value Stream Mapping(PDVSM) manual, Massachusetts Institute of Technology, 77Massachusetts Avenue, Cambridge, MA, 1st Edition (2005).

[4] M. Poppendieck, T. Poppendieck, Lean software development:an agile toolkit, Addison-Wesley Professional, 2003.

[5] S. Mujtaba, R. Feldt, K. Petersen, Waste and lead time reductionin a software product customization process with value streammaps, in: Software Engineering Conference (ASWEC), 201021st Australian, IEEE, 2010, pp. 139–148.

[6] K. Stapel, E. Knauss, K. Schneider, Using FLOW to ImproveCommunication of Requirements in Globally Distributed Soft-ware Projects, in: Proceedings of the Workshop on Collabora-tion and Intercultural Issues on Requirements: Communication,Understanding and Softskills (CIRCUS), Ieee, 2009, pp. 5–14.

[7] M. Staron, W. Meding, Monitoring bottlenecks in agile andlean software development projects - a method and its industrialuse, in: Proceedings of the 12th International Conference onProduct-focused Software Process Improvement, PROFES’11,Springer-Verlag, Berlin, Heidelberg, 2011, pp. 3–16.

[8] K. Petersen, P. Roos, S. Nystrom, P. Runeson, Early identifica-tion of bottlenecks in very large scale system of systems soft-ware development, Journal of Software: Evolution and Process26 (12) (2014) 1150–1171.

20

[9] K. Petersen, M. Khurum, L. Angelis, Reasons for bottlenecksin very large-scale system of systems development, Informationand Software Technology 56 (10) (2014) 1403–1420.

[10] A. Rausch, C. Bartelt, T. Ternit, M. Kuhrmann, The V-ModellXT Applied - Model-Driven and Document-Centric Develop-ment, in: Proceedings of the 3rd World Congress for SoftwareQuality, 2005.

[11] A. Cockburn, Agile Software Development, Addison Wesley,2002.

[12] K. Stapel, K. Schneider, Managing Knowledge on Communica-tion and Information Flow in Global Software Projects, ExpertSystems - Special Issue on Knowledge Engineering in GlobalSoftware DevelopmentSubmitted for consideration to.

[13] K. Stapel, K. Schneider, FLOW-Methode - Methodenbeschrei-bung zur Anwendung von FLOW, Tech. rep., Fachgebiet Soft-ware Engineering, Leibniz Universitt Hannover (2012).URL http://arxiv.org/abs/1202.5919

[14] N. Zazworka, K. Stapel, E. Knauss, F. Shull, V. R. Basili,K. Schneider, Are Developers Complying with the Process: AnXP Study, in: Proceedings of the 4th International Symposiumon Empirical Software Engineering and Measurement (ESEM’10), IEEE Computer Society, Bolzano-Bozen, Italy, 2010, bestPaper.

[15] M. Pikkarainen, J. Haikara, O. Salo, P. Abrahamsson, J. Still,The impact of agile practices on communication in software de-velopment, Empirical Software Engineering 13 (3) (2008) 303–337.

[16] S. Winkler, Information flow between requirement artifacts.results of an empirical study, in: Requirements Engineering:Foundation for Software Quality, Springer, 2007, pp. 232–246.

[17] B. Berenbach, G. Borotto, Metrics for model driven require-ments development, in: Proceedings of the 28th InternationalConference on Software Engineering, ICSE ’06, ACM, NewYork, NY, USA, 2006, pp. 445–451.

[18] T. DeMarco, Structured Analysis and System Specification,Prentice Hall, Englewood Cliffs, NJ, 1979.

[19] I. Kwan, D. Damian, M.-A. Storey, Visualizing a requirements-centred social network to maintain awareness within develop-ment teams, in: Proceedings of the First International Workshopon Requirements Engineering Visualization, IEEE, 2006, pp. 7–7.

[20] A. Wise, Little-JIL 1.5 Language Report, Tech. rep., Depart-ment of Computer Science, Univ. of Massachusetts, accessed:2015-02-21 (2007).URL http://laser.cs.umass.edu/techreports/06-51.pdf

[21] K. Schneider, K. Stapel, E. Knauss, Beyond documents: Visu-alizing informal communication, in: Proceedings of the 2008Requirements Engineering Visualization, REV ’08, IEEE Com-puter Society, Washington, DC, USA, 2008, pp. 31–40.

[22] P. Runeson, M. Host, Guidelines for conducting and reportingcase study research in software engineering, Empirical softwareengineering 14 (2) (2009) 131–164.

[23] M. Poppendieck, T. Poppendieck, Implementing lean softwaredevelopment: From concept to cash, Addison-Wesley, 2006.

[24] K. Schneider, D. Lbke, Systematic Tailoring of Quality Tech-niques, in: World Congress of Software Quality 2005, Vol. 3,2005.

[25] P. Berander, P. Jonsson, Hierarchical cumulative voting (hcv) -prioritization of requirements in hierarchies, International Jour-nal of Software Engineering and Knowledge Engineering 16 (6)(2006) 819–850.

[26] K. Petersen, C. Wohlin, Measuring the flow in lean softwaredevelopment, Software: Practice and Experience 41 (9) (2011)975–996.

[27] J. P. Womack, D. T. Jones, Lean thinking: banish waste andcreate wealth in your corporation, Simon and Schuster, 2010.

21