A Scenario on Solving Pain Points
Purpose of the scenario
By reading this scenario, the reader will understand how to boost the progress of a software development endeavor. The progress is advanced by identifying and solving pain points using the Essence kernel. The scenario is not intended to give you a complete picture of the endeavor. It just provides the slice of information needed for supporting the training objectives.
Pre-conditions
To get the most out of this scenario, the reader should have knowledge of the Essence Alphas, States, and Checklists.
When to Apply
This scenario illustrates how to introduce Essence incrementally over a number of pain point intervention meetings. This is done in the context of an existing endeavor after the first product release. However, the incremental approach described in this scenario remains applicable at any time during the product lifecycle.
Essence Scope
The team focuses on leveraging the Alpha cards only. Other cards, like Activity Spaces and Competencies are not part of this scenario.
Reference Cards
The Alpha cards used in this scenario are part of the SEMAT kernel.
Background
A five-member team is in charge of developing an online university course management system involving management of administrative information, courses and student performance. Right now, the team is working on its second release and has just introduced Essence in their regular pain point intervention meetings. During the meetings, the team identifies pain points, uses the Essence cards to determine the endeavor's current and target states, and, finally, identifies appropriate tasks for remedying the pain points.
Pain Point Intervention Meeting 1 on May 15
Here is what happens on the first pain point meeting.
-
Pain Point Identification
The team brainstorms the endeavor's overall progress and health. The endeavor does not have any apparent challenges. However, at some point during the discussion, one team member mentions that a few faculty members are resisting the migration to the new system. They are still using the old wiki-based system and spreadsheets for managing course materials, assignments, and grades, as well as emails for communicating grades. As a result, they are not providing any feedback to the team. So far, only one out of thirty faculty members has given some feedback. This member is very unhappy about the new system and unsupportive to the team. His feedback is very negative. It often lacks concrete reasons and motivation.
-
Cards Selection
One team member suggests that, due to the stakeholders' resistance and poor feedback, the Stakeholders alpha should be investigated first. Indeed, this should help the team members better understand the nature of the stakeholders' problem. Consequently, the members have arranged all the Stakeholders alpha cards in sequences as shown in Figure 1.
Figure 1. Sequence of states for the Stakeholders alpha
-
Current State Identification – Stakeholders Alpha
Team members read through the Stakeholders alpha states. They start reviewing the checklist of the Recognized state card and come to the conclusion that the stakeholders have already been "recognized". Indeed, the important stakeholder groups that need to be represented have
Figure 2. Current and target states for the Stakeholders alpha
been identified, and the responsibilities of the stakeholder representatives have been defined for each group. The stakeholder groups that have been identified are Administrators, Faculty, and Students.
-
Target State Identification – Stakeholders Alpha
Members of the team move on to the next Stakeholders state card, the card describing the Represented state. They find out that, in contrast to the other groups, the faculty group is not represented since no faculty representatives have been appointed. The reason for not appointing them was the assumption that most of them would provide feedback spontaneously. This, however, has rarely happened so far.
To ensure that the faculty provides feedback, the team has agreed that there is a need for formally appointing faculty representatives. So, Represented becomes the target state for the Stakeholder alpha.
To facilitate status monitoring, the team separates the cards. As shown in Figure 2, they move the Recognized card to the left indicating the accomplished state and the Represented card to the right indicting that the target state is to be achieved in the near future.
-
Task Identification – Stakeholders Alpha
Using the checklist items from the Represented alpha state card, the team members discuss what needs to be done to achieve the target state and eventually remedy the identified pain point. They suggest the following action items:
-
Task 1: Appoint stakeholder representatives for the faculty group, including supportive and unsupportive faculty members.
-
Task 2: Agree on or modify the existing definition of responsibilities and collaboration approaches with the faculty representatives. Because of the iterative nature of the endeavor, the stakeholders need to agree on providing feedback on a regular basis.
While the team needs to focus on the faculty group at this point, it also acknowledges the importance of continuing to engage the representatives of other stakeholder groups such as Administrators and Students.
After identifying two new tasks (Task 1 and Task 2) and gaining a better understanding of stakeholder challenges, work on the endeavor continues. The main reason for not proceeding with the additional Essence alphas at this point is to avoid overwhelming the team with new activities that could be perceived as overhead. Additional alphas will be introduced incrementally during future pain point intervention meetings.