Modeling social aspects of (software) processes

The introduction of a new software process in an organization is a difficult and often risky proposition. This is especially true when adopting agile processes like Scrum that usually imply radical departures from traditional team structures, cooperation styles and relationships.

Unfortunately, descriptions of software processes (like this BPM-based view of SCRUM) focus on the sequence of process activities and on the artefacts generated in each activity but they mostly ignore the social aspects of the process, such as:

• What are the skills required to perform each role?
• Which are the most critical roles? What are the consequences if they don’t perform?
• Which other actors do I depend on in order to succeed in my goals? What do I depend on them for?

We believe this kind of knowledge is key to facilitate the adoption of a software process and, even more, to let software companies assess the chances of successfully enacting the process by checking (prior to process adoption) whether the social aspects of the process will be a good fit for the current team members structure and organization.

To explicitly represent these details of the software process we propose to complement existing process modelling approaches with a new perspective aimed at describing and analyzing the social and human aspects of the process. Our approach (see H. Chiniforooshan, J. Cabot, E. Yu: Adopting Agile Methods. Can Goal-Oriented Social Modeling Help?. 4th Int. Conf. on Research Challenges for Information Systems (RCIS’10)) makes use of thei* modelling framework for visualizing and analyzing relationships among social actors, particularly how they depend on each other to achieve individual and team goals.

The i* framework consists of two main models: the SD (Strategic Dependency) and SR (Strategic Rationale) model. Simply put, the first one focuses on the dependencies between the different actors/roles of the process while the second one looks at the internals of each actor to see how the actor fulfils the goals that have been assigned to him/her in the SD model. There are two kinds of goals: hard goals (or simply goals) representing the functional objectives, and soft goals, expressing qualitative objectives. Analysing this information helps to answer questions about the social aspects of the software process, as the ones mentioned above.

As an example, a (very simplified) SD model for SCRUM could be this one:

With this diagram, it is easy to see who the main roles of the process are (to simplify, in this case we just show the three main ones) and the dependencies between them. For instance, the team is in charge of developing the product increments but depend on the product owner for the prioritization of the product backlog and on the scrum master for the guidance and management necessary to properly follow the Scrum process. If a given actor does not deliver, all the other actors depending on them will be negatively affected and may not be able to accomplish their goals.

Once the SD is done we refine it to create the SR model. An excerpt of the SR model for the Scrum Master actor is the following.

Here we see a decomposition of the “Team to be managed” responsibility assigned before. As part of the decomposition we indicate the qualities (expressed as soft goals) that will help the Scrum Master fulfil the goal.

Again, representing this knowledge facilitates the evaluation of the adequacy of this process for the company.  For instance, any company willing to adopt Scrum should first check:

1. If there is somebody in the company that can play the role of Scrum Master (and the same for the other roles)
2. If that person has the qualities required to play that role successfully (does she have good relationship with the product owner? does she have good communication skills? ...)
3. Be prepared to invest the required time/money to cover the gaps found in the analysis of 1 and 2 or at least be aware of their consequences (cascade problems triggered by not satisfying the expectations of the other actors shown as dependencies in the SD model). E.g. a bad Scrum Master may fail at properly managing the team which then may cause the team to fail at delivering the incremental product updates, even if the Product Owner does a good prioritization of the backlog.

In this blog post we just scratched the possibilities of i* models for defining social and organizational aspects of (software) systems but hopefully you get an idea of the kind of “view” of the system/process these models can provide and the benefits of taking into account these aspects when thinking about adopting a new development process.