Keywords

1 Introduction

Within a context of volatility, uncertainty, complexity and ambiguity, enterprise designers need to continuously re-design the enterprise, re-evaluating the technologies that are available to digitize their operations. In accordance with the agile paradigm for information system design, enterprises need iterative design approaches to (re-)design their systems incrementally [1]. During information systems design, agile methods and practices may have to be tailored for contexts where scaling factors apply, especially regarding the elicitation and management of requirements [2, 3].

Since additional requirements elicitation practices should be incorporated when scaling factors apply [4], the organization construction diagram (OCD), associated with the design and engineering methodology for organizations (DEMO), could be used to represent a blue print of enterprise operation, creating a foundation for requirements elicitation and tracking during information systems development [5]. Research indicated that an additional story-card method (SCM) was needed to introduce the abstract OCD concepts to agile development stakeholders [5]. Although previous research experimented with the SCM, the method was applied in isolation, i.e. not within a real-world agile software development context. The main contribution of this study is to demonstrate how the SCM is used within an agile software development approach to solve existing deficiencies at a Fintech company.

Next, we briefly introduce the remaining sections of the article. Section 1 elaborates on the OCD, SCM and other methods and practices that were used at the Fintech company. Section 2 introduces Framework for Evaluation in Design Science (FEDS) evaluation design process that guided further evaluation of the SCM within a real-world context. In Sect. 3 we present a demonstration of the SCM and in Sect. 4 we present solution implementation- and evaluation results. Finally, we discuss our findings in Sect. 5 and conclude in Sect. 6.

1.1 The SCM to Compile an OCD

The SCM incorporates collaborative and easy-to-use technologies, i.e. sticky notes as story cards to facilitate collaboration and transformation of existing enterprise implementations (i.e. a concrete world) into more abstract (and concise) concepts of the OCD [5]. The 5 inputs and 10 method steps of the SCM is useful to transform a sub-set of implemented processes into a consolidated view of enterprise operations, depicted by the OCD [5]. We briefly introduce the OCD, i.e. the main deliverable of the SCM.

Dietz (in Perinforma [6]) acknowledges that a user’s needs for information system support starts with an understanding of their day-to-day operations. He presents four ontological aspect models that are coherent, comprehensive, consistent, and concise and that are useful to represent the essence of enterprise operation [7]. The organization construction model (OCM) is the most essential model and consists of three representations, the organization construction diagram (OCD) and the transaction product table (TPT) and the bank content table (BCT) [6, 8].

The OCD provides a graphical representation of actor roles (implemented by human beings) that are involved in a number of transactions. Each transaction is an instance of a particular transaction kind (TK), and every TK incorporates a single production act and multiple coordination acts. Dietz [6, 8] indicates that the coordination acts and production act are arranged according to a pattern, called the complete transaction pattern. For every TK, two actor roles are involved, one is the initiating actor role and the other one is the executing actor role. Although the executing actor role is responsible to execute the production act, both actor roles perform several coordination acts.

We explain some of these concepts, referring to the OCD that is depicted in Fig. 1. Every OCD represents some essential operations for a particular scope-of-interest. Figure 1 indicates that the benefits department was the scope-of-interest. Furthermore, multiple actor roles may be involved (indicated as rectangles), acting as an initiator (when linked to a solid line) or an executor (when linked to a solid line that ends in a filled diamond). Actor roles interact with one another via several transaction kinds (TKs). Figure 1 includes two TKs, namely T01 (claim evaluation) and T02 (claim payment). The diamond-disc representation of the TK indicates that every TK consists of a production act/fact (represented by a diamond) and multiple coordination acts/facts (represented by a disc). The actor roles are either classified as elementary or composite. An elementary actor role (indicated by a white rectangle) is the executor of only one TK, as exemplified by the evaluator in Fig. 1. A composite actor role, indicated by a grey-shaded rectangle, is the executor of more than one TK. By default, actor roles that are outside the scope-of-interest, are modelled as composite actor roles [6]. Therefore, Fig. 1 indicates that the broker and finance department are composite actor roles. The actor role within the scope-of-interest (i.e. the evaluator) may need to have access to production facts and coordination facts that are produced outside the scope-of-interest. Figure 1 indicates that the evaluator needs information access (indicated with a dotted line) to an in-house software system facts, i.e. production and coordination facts that are produced outside the scope-of-interest.

Fig. 1.
figure 1

An OCD for the benefits department

Full size image

The OCD provides a consolidated view of enterprise operation. Every TK on the OCD follows a transaction pattern. Figure 2 depicts the complete pattern of behavior that exists between an initiator and an executor when they perform a TK. Thus, the pattern depicted in Fig. 2 applies to T01 with the initiator being the broker and the executor being the evaluator. Yet, the same pattern is also followed for T02 where the initiator is the evaluator and the executor is the finance department.

Fig. 2.
figure 2

The complete transaction pattern, from [8]

Full size image

Perinforma [6] indicates that a TK may be classified according to three categories. A TK is original when the associated production act has the intent of creating an original/new fact. A TK is classified as informational if its associated production act merely recalls/interprets a previously-created original production facts. Lastly, a TK is documental when the associated production fact simply transmits/copies/retrieves/destroys the original fact. Usually, the OCD only represents TKs that are of the original sort [6], hence extracting only the essence of enterprise operation.

The OCD presented in Fig. 1 is the main deliverable of the SCM. Yet, the SCM starts by identifying existing operational activities that are performed in a particular sequence at an enterprise. Operational activities include TKs of all sorts, i.e. original, informational and documental. The SCM facilitates the process of analyzing the implemented operational activities, re-structuring operational knowledge into a consolidated OCD [5].

Once the SCM has been applied, every operational activity: (1) is traceable to a particular TK on the OCD, and (2) can be considered for semi-automation, transforming the activity into a user story [5].

A user story is a “general-purpose agile substitute for what traditionally has been referred to as software requirements” [3]. The next section presents a template to elaborate on the software requirements associated with a user story.

1.2 User Story Cards and the INSERT Criteria

Patel and Ramachandran [9] provided a template, called a user story card, that is based on the INSERT validation criteria. The INSERT criteria ensures that every requirement is Independent, Negotiable, Small-enough-to-fit-into-iteration; Estimable, Representative-of-user-functionality and Testable. Applying the INSERT criteria, the analyst has to complete ten fields per story card: (1) story card number, (2) project name, (3) estimation, (4) story name, (5) date, (6) story, (7), acceptance test, (8) note, (9) risk, and (10) points to consider [9]. Later, in Sect. 3.2, we also recommend that another field is added on the user story card, tracing each user story back to a TK on the OCD.

2 Research Methodology

The study applied the Framework for Evaluation in Design Science (FEDS) evaluation design process [10], applying the four-step process as follows:

Explicate the Goals of the Evaluation:

The main purpose of evaluating the SCM is to determine how well it achieves its expected environmental utility, i.e. using the OCD within an agile system development context within a scaled context to manage and trace requirements.

Choose the Evaluation Strategy:

In terms of the FEDS evaluation strategies, evaluation of the SCM requires iterative episodes of formative evaluation that follows the naturalistic paradigm, since the major risk of the SCM is social or user oriented. According to [10] naturalistic evaluation explores the performance of a solution technology in its real environment, e.g. within a real-world enterprise.

Determine the Properties to Evaluate:

As stated in [5], the SCM’s utility could be evaluated in terms of ability to address requirements elicitation criteria for agile development within scaled contexts. One of the utility properties, is the usefulness of the SCM within a real-world context.

Design the Individual Evaluation Episode(s):

The first evaluation episode involved 21 participants to experiment with the SCM, providing survey feedback in terms of its utility [5]. The positive feedback obtained in [5] gave the impetus to experiment further on the usefulness of the SCM within a real-world agile software development context as a second evaluation episode. The second evaluation episode was conducted and presented in this article. We used user acceptance tests and structured interviews to evaluate the usefulness of the SCM and to evaluate the newly-developed software solution and its ability to address some of the deficiencies evident at the enterprise. In addition, the participant-observer, experimenting with the SCM, provided some reflections on using and extending the SCM.

Additional evaluation episodes are needed to experiment with the SCM within different scaled agile contexts, as indicated in Sect. 6.

3 Story Card Method Demonstration

This section demonstrates the use of the SCM as part of a software development project. Section 3.1 provides background on the company and its problem context. Section 3.2 presents the agile software development approach that incorporated the SCM during the early phases of development, whereas Sect. 3.3 presents an application of the agile software development approach.

3.1 The Enterprise Context

A software development project was initiated by one of South Africa’s leading Fintech companies of which the benefits department interacts with various brokers that claim on behalf of claimants. The problem is that the benefits department used MS Excel to track claim evaluations. Since employees used the desktop version of Excel, worksheets could not be accessed simultaneously by the employees and the worksheets contained duplicate entry fields. Rapid growth in business created an urgency for digitizing all manual operations, reducing the lead time for claim payments to beneficiaries, and reducing the number of erroneous claim payments. Even though the benefits department used MS Excel, other departments used an in-house system to automate their processes.

3.2 The Adapted Agile Approach

One of the core values of agile software development indicates a preference for individuals and interactions over processes and tools [11]. Tools and techniques should encourage customer collaboration, enable change, ensure working software and minimize the use of documentation [12]. Yet, minimal documentation often creates problems in tracing requirements to their origin, especially when scaling factors apply [13, 14].

The software development team, working at the Fintech company, already followed an agile software development approach. An opportunity existed to experiment with the SCM, incorporating it within the existing agile development approach, addressing the deficiencies at the benefits department. Similar to the iterative and model-based agile software development approach presented by [15], the software development approach started with a scope definition, followed by two stages: (1) a combined problem analysis, requirements analysis and decision analysis; and (2) multiple iterations of design, construction & testing, review and delivery. The next section demonstrates the adapted agile software development approach, elaborating on the first stage, emphasizing the use of the SCM and user story cards.

3.3 Demonstrating the Adapted Agile Approach

This section elaborates on the problem analysis, requirements analysis and decision analysis of the adapted agile software development approach that was used at the Fintech company.

Problem Analysis Phase.

Whetherby’s [15] PIECES framework was used to extract information-system related deficiencies in terms of Performance, Information (and Data), Economics, Control (and Security) and Efficiencies. Additional problem analysis was also incorporated as part of the next phase.

Requirements Analysis phase.

Identified deficiencies resulting from the PIECES analysis, were converted into non-functional solution requirements. The functional requirements were primarily derived via the SCM. The participant-observer applied the 10-step SCM (see [5]) to extract the existing operational activities from enterprise participants. We shortly discuss an application of the 10-step method and also indicate two extensions for Step 1 and Step 10.

  • Step 1: Inquire from a colleague to explain a short process (about 10 to 15 activities) that s/he is involved with. Figure 3 illustrates the main output of Step 1. The participant-observer extended this step, also mapping out the process represented in Fig. 3 to a business process model, using the Business Process Model and Notation (BPMN) specification (see [16]). The extension allowed for critical analysis of the existing process, highlighting inefficient interaction between participants. Problem areas were identified, labelled (e.g. Problem A, Problem B) and described.

    Fig. 3.
    figure 3

    Example of a process to demonstrate method Step 1 of the SCM

    Full size image

  • Step 2: Take a picture (photo) of the process. See Fig. 3.

  • Step 3: Discuss with your colleague all the actors that are involved and write down composite actors on yellow sticky notes, adding a smiley face, keeping actors aside. The smiley face sticky notes are illustrated on Fig. 3.

    Fig. 4.
    figure 4

    An OCD with composite actor roles is the deliverables of the SCM

    Full size image

  • Step 4: Explain Dietz’s red-green-blue triangle of production acts, also explaining the complete transaction pattern for actor-collaboration regarding production acts. The participant observer briefly presented the concepts to the participants, only explaining the red-green-blue triangle of production acts. The complete transaction pattern was not explained, since it would be too time-consuming.

  • Step 5: Have a discussion with your colleague as to identify original production acts from his/her process (as mapped out with sticky notes in Step 1). The discussion and classification followed.

  • Step 6: Classify (in collaboration with your colleague) remaining acts as coordination acts vs. production acts. Additional classification was performed.

  • Step 7: Remove the original production act notes from the flat surface and phrase appropriate transaction kind descriptions (using adjective + noun) on red sticky notes that are positioned as diamonds on your A1 paper. Collapse initial production act notes underneath re-phrased transaction kind notes. Figure 4 illustrates the re-structuring of sticky notes according to the OCD-format.

  • Step 8: The remaining activities on your working space should be coordination acts or informational/documental production acts. Remove each of the remaining notes on your working surface and collapse them underneath the appropriate re-phrased transaction kind (red diamond notes) on your A1 paper. Figure 4 illustrates the re-structuring of sticky notes according to the OCD-format.

  • Step 9: Position the yellow actor role notes on the A1 paper, drawing in (with a black pen) the initiator actors (+initiating links) as well as the executing actors (+executing links) to the transaction kinds, completing a composite OCD. Figure 4 illustrates the re-structuring of sticky notes according to the OCD-format.

  • Step 10: Validate your composite OCD with your colleague. Validation was performed. The participant-observer extended this step, identifying those activities that had to be automated, using a red dot as illustrated on Fig. 4. The TK with the most red dots should be prioritized and had to form part of the same build cycle.

According to [5], the composite OCD, such as the one depicted in Fig. 4, needs further tailoring as to ensure that composite actor roles that form part of the scope-of-interest are converted into elementary actor roles. The final OCD was constructed and is presented in Fig. 1.

Each of the activities, earmarked for automation, was converted into multiple user story cards, adhering to the INSERT criteria and the user story card template presented in Sect. 1.2. The participant-observer also added a field called traceability. Each story card had to be traceable to a TK on the OCD (represented in Fig. 1). One of the user story cards, depicted in Fig. 5, linked to a Problem A and linked to TK T01 (claim evaluation) of Fig. 1.

Fig. 5.
figure 5

A user story card linked to TK T01

Full size image

Decision Analysis Phase.

During this phase, three alternative solutions were identified: (1) Extending the existing in-house software application to replace the existing Excel sheets; (2) Using blockchain technology to create smart contracts to validate and verify the details of the deceased and automate payment; and (3) Creating a web app to replace the existing in-house software application that is currently used by the company. A feasibility analysis matrix, used in accordance with [15], indicated that the urgency of a solution favored the first alternative.

4 Results

Since agile software development approaches value working software over comprehensive documentation [11], we had to ensure that the adapted agile approach produced working software. Section 4.1 reports on the acceptance test results for four implemented story cards. In addition, we wanted to reflect on the story-card-method and its ease-of-use within a real-world project. Section 4.2 provides some reflections on applying the SCM.

4.1 Acceptance Tests and Interview Results

As indicated in Sect. 3.2 the software development approach consisted of two stages. The second stage consists of multiple iterations of design, construction & testing, review and delivery. For the first iteration, four out of eight story cards were prioritized and used to construct user interfaces. The newly-developed user-interfaces were evaluated by four participants and acceptance tests were completed with positive results. Participants also had to answer five interview questions in terms of a five-point scale: strongly agree, agree, unsure, disagree and strongly disagree. Participants were encouraged to qualify their response. The results are presented per interview question.

  • Do you believe that the previous process had too many manual steps? Three participants strongly agreed, while the fourth participant agreed.

  • Has the new solution reduced manual steps by 50%? Two participants strongly agreed, whereas the other two participants agreed. Participants commented that the consolidation of data capturing on a single system and the use of auto-fill functionality for certain fields drastically decreased the number of manual steps.

  • Do you believe that the new process has reduced processing time of claims? All participants strongly agreed.

  • Is the new process better than the old process? Three participants strongly agreed, while the fourth participant agreed. Participants valued the automatic calculation of benefit amounts, replacing the manual entries.

  • Has the use of Microsoft Excel been eradicated? Three participants strongly agreed, while the fourth participant agreed.

4.2 Reflecting on the SCM

The participant-observer facilitated the SCM and provided some reflections in terms of the 10-step method presented in Sect. 3.3:

  • Steps 1 and 2: This step was easy to perform, since the participant-observer spent ample time at the company to observe the process. A company participant (the claim evaluator) confirmed the validity of the existing process as mapped out with sticky notes.

  • Step 3: This step was easy to perform and the company participant willingly provided inputs.

  • Steps 4 to 7: The company participant was not so interested to participate during the classification and re-structuring of activities, but preferred that the facilitator (i.e. the participant-observer) performed these steps. Still, the participant validated the classifications afterwards.

  • Step 8: The participant-observer valued this step, since it allows for a consolidated view of existing activities and a means to identify areas of improvement.

  • Step 9: This step was easy to perform.

  • Step 10: This step and its extension was easy to perform.

Although the participant-observer performed the SCM with ease, the company participants had difficulty in understanding some of the concepts.

The demonstration of the SCM led to two further extensions. Step 1 was extended representing the rudimentary sticky-note process flow with a process model according to the BPMN specification, using swim lanes and pools to indicate existing work allocation according to enterprise-specific roles. The extension also allowed for critical analysis of the existing process, especially in terms of inefficient interaction between company roles. The detailed process model helped to highlight problem areas that were labelled (e.g. Problem A, Problem B) and described.

A second extension was applied in Step 10, namely to use red dots to earmark story-cards for automation. The rationale is that story cards that belong to the same TK and earmarked for automation, should also be built during the same build cycle.

5 Discussion

Enterprise designers need to continuously re-design their enterprise, re-evaluating the technologies that are available to digitize their operations. Although light-weight agile software development approaches are favored by software development service providers, additional requirements elicitation practices should be incorporated when scaling factors apply, since design team members need to have a shared understanding of the operating context and high-level requirements. Research indicated that OCD could be useful to create a shared context for enterprise operation, linking detailed functional requirements to this shared context during software development. Although the OCD is concise, its associated concepts are abstract and an additional SCM is needed to transform existing enterprise implementations into an OCD. Since additional evaluation of the SCM was required, this study provided a real-world demonstration of the SCM within an agile software development context.

The SCM was incorporated within an agile software development approach. During its application, the enterprise designer (also the participant-observer) identified the need to further extend Step 1 and Step 10 of the SCM.

Two different methods were used for evaluation. First, we evaluated the agile software development approach, with the embedded SCM, to assess whether the approach rendered working software. User acceptance tests indicated positive results. We also used structured interviews, engaging with relevant participants at the benefits department, to assess whether some of the previous information system deficiencies have been addressed. Positive feedback was obtained.

The second evaluation method entailed some reflection on using the SCM. The participant-observer indicated that the SCM was easy to use. Yet, he fast-tracked some of the steps, reducing some of the explanations about OCD concepts. His reflections emphasized the conditional use of the SCM, i.e. that the facilitator needs sufficient knowledge on the theoretical concepts to provide additional explanations where needed.

6 Conclusion and Future Research

The SCM was useful when incorporated within an agile software development approach. Yet, as indicated by the demonstration and participant-observer’s feedback, the method may need further adaptation (e.g. extending Step 1 and Step 10) to ensure integration within an existing agile software development approach. In addition, the enterprise designer that facilitates the SCM, may need to adapt the theoretical explanations regarding OCD concepts, ensuring that participants will be able to validate the final OCD.

Since the SCM was useful within a real-world context where an agile approach is currently used, agile at scale projects, where different scaling factors apply should further validate the usefulness of the SCM within the agile software development context. The main deliverable of the SCM, the OCD, is useful to create a common understanding of the essential operations at an enterprise. The implementation-free OCD becomes the starting point for various different implementation options. Although this study favored further development of the in-house information system, the OCD can also be used as the starting point for implementing blockchain technology.