Architecture-Oriented Agile Approach for Sustainability Reporting
45
managing the entire backlog and sprint cycles; scrum master, who will be responsible
to managing the throughout the project, as well as stakeholder expectations, requirements compliance and potential risks and; the people involved in the execution, who
are responsible for the operationalization of all the actions.
After Phase 1 is planning the transformation project, defining the requirements that
need to be met, understanding their impact on the organizational system, prioritize
these requirements (e.g., using the MoSCoW tool), in order to classify them into
groups of importance for the project. After this, how the company will meet the
relevant project requirements is defined through the modeling of the aspects. These
aspects are correlated with the requirements in order to identify relationships with
each other. Since a requirement can be met for more than one aspect or one aspect
can fulfill more than one requirement. Besides, an analysis of risks can be performed
but should be aligned with the strategies defined in Phase 0. The second Phase
is diagnosing the organizational system to be transformed, assessing how well the
company already meets the defined requirements of the transformation project (e.g.,
creating the “AS IS” model). The third Phase is creating the “TO BE” model that
meets the defined requirements and provides a transition view on how the current
model can evolve and reach the project purpose. The fourth phase is driving change
based on the SCRUM method, in which an architecture requirements backlog is kept,
and gradual changes are realized according to it, helping involved people organize
how change is conducted. In this phase, the current model is updated according to the
incremental changes that are implemented, until the current model reaches or is close
enough to the future model. In the fifth and final phase, the results of the application
of the whole procedure are evaluated—whether the current model reached the future
model, whether the project purpose was accomplished, and how the current model
may be further developed. Figure 1 presented the procedure.
The procedure is based on the SCRUM method because it is one of the most
used approaches to agile methodology. This framework focuses on what has already
been developed to obtain sequential increments, generating precuts and services
from the items of higher priority to the ones with minor priority. It requires constant
communication between participants (Paschek et al. 2016).
SCRUM’s main idea is to make systems flexible enough to adapt to changes
in requirements, resources and technologies to achieve value-added results. In this
way, it allows the development of several processes and techniques, consisting of the
stages of planning of the iterative cycles (SPRINTs), execution of these cycles, daily
meetings for follow-up, meetings for SPRINTs review and retrospective meetings.
Therefore, SPRINTs represent the set of activities that are executed sequentially in
each iteration (Raj et al. 2015).
Also, in each phase, there is a set of worksheets that are used to operationalize the
procedure; however, for each project, different worksheets will need it. Therefore,
first, it is of paramount importance to define each of them. Table 1 presents a list of
worksheets that could be used in each of the phases of the procedure.
Nevertheless, it is not an obligation using them once this definition must be made
by the project team, as the worksheets must fit the project purpose and be aligned
with the intent of each phase of the procedure.
45
managing the entire backlog and sprint cycles; scrum master, who will be responsible
to managing the throughout the project, as well as stakeholder expectations, requirements compliance and potential risks and; the people involved in the execution, who
are responsible for the operationalization of all the actions.
After Phase 1 is planning the transformation project, defining the requirements that
need to be met, understanding their impact on the organizational system, prioritize
these requirements (e.g., using the MoSCoW tool), in order to classify them into
groups of importance for the project. After this, how the company will meet the
relevant project requirements is defined through the modeling of the aspects. These
aspects are correlated with the requirements in order to identify relationships with
each other. Since a requirement can be met for more than one aspect or one aspect
can fulfill more than one requirement. Besides, an analysis of risks can be performed
but should be aligned with the strategies defined in Phase 0. The second Phase
is diagnosing the organizational system to be transformed, assessing how well the
company already meets the defined requirements of the transformation project (e.g.,
creating the “AS IS” model). The third Phase is creating the “TO BE” model that
meets the defined requirements and provides a transition view on how the current
model can evolve and reach the project purpose. The fourth phase is driving change
based on the SCRUM method, in which an architecture requirements backlog is kept,
and gradual changes are realized according to it, helping involved people organize
how change is conducted. In this phase, the current model is updated according to the
incremental changes that are implemented, until the current model reaches or is close
enough to the future model. In the fifth and final phase, the results of the application
of the whole procedure are evaluated—whether the current model reached the future
model, whether the project purpose was accomplished, and how the current model
may be further developed. Figure 1 presented the procedure.
The procedure is based on the SCRUM method because it is one of the most
used approaches to agile methodology. This framework focuses on what has already
been developed to obtain sequential increments, generating precuts and services
from the items of higher priority to the ones with minor priority. It requires constant
communication between participants (Paschek et al. 2016).
SCRUM’s main idea is to make systems flexible enough to adapt to changes
in requirements, resources and technologies to achieve value-added results. In this
way, it allows the development of several processes and techniques, consisting of the
stages of planning of the iterative cycles (SPRINTs), execution of these cycles, daily
meetings for follow-up, meetings for SPRINTs review and retrospective meetings.
Therefore, SPRINTs represent the set of activities that are executed sequentially in
each iteration (Raj et al. 2015).
Also, in each phase, there is a set of worksheets that are used to operationalize the
procedure; however, for each project, different worksheets will need it. Therefore,
first, it is of paramount importance to define each of them. Table 1 presents a list of
worksheets that could be used in each of the phases of the procedure.
Nevertheless, it is not an obligation using them once this definition must be made
by the project team, as the worksheets must fit the project purpose and be aligned
with the intent of each phase of the procedure.