A Scenario on Kick-Starting a Project

Purpose of the Scenario

By reading this scenario, you will understand how to use the Essence's kernel to help a team figure out where it is and what it needs to focus on next.

Pre-conditions

To get the most out of this scenario, you should have knowledge of the Essence Alphas, States, and Checklists.

When to apply

The approach presented in this scenario describes events that occur at the beginning of a project. It can, however, be used at any time during a project to enable a team (1) to checkpoint the current project state, and (2) to determine the goals to be addressed in the near term.

Essence Scope

This scenario 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.

Project Background

HomeWare Retailer is a medium-sized retail hardware store chain offering quality hardware products for building, improving and maintaining homes through 800 retailers. Its IT system, Retailer Information System (RIS), was originally sized to support 850 retailers online. However, the business strategy is to expand the retail chain to include 200 additional retailers.

RIS cannot easily be scaled up. It is a legacy application that was developed about forty years ago. Although it still works well, it is very old and it lacks documentation. All its business rules and requirements are embedded in the code base. Users access the application through an ms-dos based "green screen" terminal emulator. All its code is written in COBOL and access to its database is made directly from the code. There is little or no layering or modularization of the software architecture and the system is brittle. Hence, the system needs to not only be scaled up but also modernized. For this purpose, HomeWare Retailer has started a new project with the mission of modernizing RIS.

Team Background

At the start of the project, three team members Cynthia, Fred and Sam are involved. They are all very experienced, but come from different backgrounds and they have never worked together before. All of them have good knowledge of Essence through school or having read papers or books. Cynthia, Fred and Sam have decided to use Essence as a starting point.

Introducing Essence – Dedicated Essence Meeting

To establish the status of the project, the team starts its work by having a dedicated Essence meeting. They decide to use all the Alpha cards in a planning poker manner [2].

  • Fred: We have decided to use Essence to jumpstart the project. So let's walk through each of the seven Alphas and determine our status.

 

  • Cynthia: Ok. I have Alpha state card decks, one for each of us.

 

Cynthia hands an Alpha state card deck to Fred and one to Sam, and keeps one for herself.

Opportunity Alpha Discussion

The team cannot start with all the cards simultaneously. Therefore, they decide to start walking through the Opportunity Alpha first and then to determine the order of choosing the next Alphas.

  • Sam: It doesn't matter what order we use. Let us start with the Opportunity Alpha unless anyone has a better idea. By the way, Fred, what is our opportunity?

 

  • Fred: Right now, the RIS system only supports a limited number of users and is difficult and too costly to maintain. With the current maintenance cost, we cannot afford to evolve it with new functionality. So, by modernizing it, we will be able to expand our user base and it will be cheaper to evolve and maintain it in the future.

 

  • Sam: Ok, let us now play planning poker. What are the rules?

 

  • Fred: Each of us should individually go through the first few states of Opportunity and determine its state by deciding which checklist items have been accomplished. Remember, a state can only be achieved if all of its checklist items are fulfilled. We should then pull out the state card indicating the state we believe we have achieved.

 

After a few minutes, everyone completes their individual assessment and shows his/her card. All the team members raise the Opportunity Value Established Card, as presented on the lefthand side of Figure 1.

 

  • Sam: Ok. We are all in agreement.  Cynthia, would you explain your reasoning behind why you think we have achieved the Value Established state, but not yet the Viable state?

 

  • Cynthia: It is pretty clear that we need a new system because the old system is no longer maintainable, and that we understand the value the new system offers to our stakeholders. The desired outcomes are clear. But, we don't yet know all the risks and we don't yet know if we can develop and deploy this new system within the constraints we have, including the schedule and budget constraints that have been given to us.

 

Figure 1. The Value Established and Viable states in the Opportunity Alpha

Sam and Fred nod their heads in agreement.

  • Sam: It looks like we have consensus on where we are with the Opportunity and what we need to do next. Should we discuss now how to get to the Opportunity Viable state and plan for it?

 

  • Fred: I think we should wait until we have assessed all the other Alphas, and then, we can develop a plan. In this way, we will be confident that we have full coverage before prioritizing.

 

  • Cynthia: Ok, I agree. But, let us capture some action items for the Opportunity Alpha now so that we won't forget what we have been thinking about when assessing it.

 

The team agrees that the action item should be to identify and assess risks (see Figure 2). They then decide to move on and assess the Stakeholder Alpha.

 

        

Figure 2. Action item being the result of walking through the Opportunity Alpha

Stakeholder Alpha Discussion

The three team members follow the same planning poker rules with the Stakeholder Alpha and show their cards. As shown in Figure 3, Fred and Cynthia both raise the Stakeholder Recognized card, but Sam does not raise any card at all.  

 

                     

Figure 3. The Recognized state of the Stakeholders Alpha

 

  • Sam: I don't think we have achieved the very first state Recognized. But we are close, very close. What we have achieved is an agreement on the stakeholder groups. They are our HomeWare IT Management, our current users of the legacy system and our customers. We have also achieved HomeWare Management agreement to fund the effort by giving us a-not-to-exceed target budget. However, we have not achieved the last checklist item in this state which says, "The responsibilities of the stakeholder representatives have been defined".

 

Fred and Cynthia nod their heads in agreement as they put the Recognized card back. As an action item, the group decides to define the responsibilities of the stakeholder representative (see Figure 4).

 

        

Figure 4. Action item being the result of walking through the Stakeholders Alpha

Requirements Alpha Discussion

The team decides to move on with the assessment of the Requirements Alpha. After a few minutes, they complete their individual assessments and show their cards. Fred, Cynthia and Sam all raise the requirements Conceived card. They are all in agreement that they have not achieved the Bounded state (see lefthand side part of Figure 5). Fred starts the discussion.

Figure 5. The Conceived and Bounded states in the Opportunity Alpha

  • Fred: I'll explain my reasoning on why we have achieved Conceived and not the Bounded state yet. We have identified and agreed on the stakeholders who will fund the system and we have identified a clear opportunity. So, I don't see anything missing in the Conceived state. However, I don't think we have bounded the requirements yet. It is still not clear what success means for the new system. Does it mean that we have just modernized the existing legacy system and the new system can do everything that the old system can do? Well, to some extent, yes. But, what about the capabilities in the old system that no one uses anymore? Shouldn't we define new requirements for removing those capabilities?

 

  • Cynthia: I agree, but that is not the only reason we haven't bounded the requirements yet. What about the new user needs? Shouldn't we define new requirements for them as well?

 

  • Sam: You are both right. Yes, we need to define requirements for implementing the new capabilities as well as requirements for removing the unwanted ones. However, we have one big problem here. The legacy system is not documented and we do not have the overall picture of the requirements it implements. Therefore, we should start with capturing those requirements first. This should be our highest priority. So, let us start with it right away!

 

  • Cynthia: Hold on Sam! We have agreed to do the full assessment of the seven Alphas first and then to decide what to do next. You may be right that capturing the already implemented requirements should be our highest priority, but I think we should proceed as we have agreed. We should get the full picture of where we are on all the seven Alphas first. Right?

 

  • Fred: Right, I agree with Cynthia. Besides, this assessment isn't taking us that long. If we find out that we have other priorities as well, it may cause us to make a different decision.

Sam agrees and the group determines the next action items. As shown in Figure 6, the action item is to capture the legacy system requirements.

        

Figure 6. Action item being the result of walking through the Opportunity Alpha

Software System Alpha Discussion

The next Alpha chosen by the group is Software System. As usual, the group members assess the Software System and show their results. Fred and Sam raise the Architecture Selected card (see Figure 7). But, Cynthia doesn't raise any card.

 

  • Cynthia: Let me explain my thought process. I agree that most of the checklist items have been met. We have made our choices concerning the architectural criteria, hardware platform, programming languages and technologies, but we have not reviewed them. We have no idea what technical risks may be hidden behind all this. 

 

  • Fred: What technical risks are you concerned about Cynthia?

 

  • Cynthia: I can't answer this question right now. To modernize a software system is always a risky business. In my opinion, before making any decisions about system organization, we have to identify all possible technical risks.

 

                   

Figure 7. The Architecture Selected state in the Software System Alpha

Fred and Sam both nod their heads in agreement. Then, as shown in Figure 8, the group determines the next action item, to capture key technical risks.

  

Figure 8. Action item being the result of walking through the Software System Alpha

Team Alpha Discussion

As a next step, Cynthia suggests to move on and assess the Team Alpha.

  • Fred: Well, in our case, the Team is just the three of us. Let's assess ourselves then.

After a few minutes, the team members complete their individual assessments and show their cards. All of them raise the Team Seeded card (see Figure 9).

  • Sam: It looks like we all agree. Let me explain why I think we have achieved the Seeded state, but we haven't yet reached the Formed state. Our mission is clear, and our constraints have been given to us. We've all been told that it is only the three of us that are dedicated full time to this project and that we won't get any help in the near future. All the other developers who might be able to help us are fully committed to other efforts. Therefore, we need to figure out how to do this job without any additional help. We all know our responsibilities as a team so it seems to me we have met the full checklist criteria for the Seeded state. However, we haven't yet discussed our individual responsibilities. Therefore, I don't think we have reached the Team Formed state.

       

Figure 9. The Seeded and Formed states in the Team Alpha

Fred and Cynthia nod in agreement and the team members capture the next action item (see Figure 10).  They agree that they need to define the individual responsibilities of each team member.

 

             

Figure 10. Action item being the result of walking through the Team Alpha

 Work Alpha Discussion

The team members are satisfied with their progress. They think they are moving along well and that the planning poker game is being helpful in determining where they are on this project. They decide to work on the Work Alpha next. After having completed their assessments, no one raises any card.

 

                   

Figure 11. The Initiated state in the Work Alpha

  • Sam: We all agree that we haven't reached the first state Work Initiated (Sam points at the Initiated Alpha card shown in Figure 11). I think we are almost there. We meet all but two of the checklist items. We know who is funding the effort and who will accept the result. Our management has given us constraints on the budget and schedule. However, we haven't bounded the requirements yet. So, we don't yet know the results required of the work, and the priority of the work is not clear.

 

  • Fred: I agree with your assessment Sam. But, management has said that it is up to us to figure out how to get this job done. Here, we have some flexibility. At a minimum, we must provide the essential capabilities that the retailers rely on within the legacy system. But after that we have the freedom of deciding on what to do next.

Fred and Sam nod in agreement. As shown in Figure 12, the team's next action item is to capture the minimum essential capabilities that the new system must provide.

 

               

Figure 12. Action item being the result of walking through the Work Alpha

Way of Working Alpha Discussion                              

The last Alpha to be assessed is the Way of Working Alpha.  After assessing it, no one raises a card.

 

                           

Figure 13. The Principles Established  state in the Way of Working Alpha

  • Fred: It looks like once again we are all in agreement. I will explain my thinking on our way of working. We have already discussed the way we want to work. We will be using Scrum since we all have experience with it. It is very important that we plan frequent demonstrations to the stakeholders to make sure that we are addressing their needs and have them all on board with where we are going. We have also decided on a work management tool because we have used it before and it worked out well on our last project. But, we haven't fully met all the checklist items for the first state (Fred points at the Principles Established Alpha card, see Figure 13) because the stakeholder representatives have not yet been assigned. So, we don't have their agreement on the selection of Scrum and the work management tool.

 

Cynthia and Sam nod in agreement and the team captures the next action item. As shown in Figure 14, the item deals with getting stakeholders assigned and getting their agreement on the team's way of working and tool selection.

 

      

Figure 14. Action item being the result of walking through the Way of Working Alpha

Action item Summary

After having analyzed the Alphas, the team studies their action items listed in Figure 15.

  • Cynthia: Since we have agreed to use Scrum, these action items should be input to our first sprint planning meeting.

 

  • Fred: Sounds like a plan!

 

Figure 15. Action items being the result of walking through all the Alphas

Moving Forward

The team plans to reassess where they are with the seven Alphas as part of their Scrum retrospectives, and any new target states will be part of setting their goals in the sprint planning meeting.

Takeaways

What the reader should learn from this scenario is how to use the Alphas, and Alpha state checklists to determine where they are and what needs to be done next. Since the team is using Scrum, the prioritization of the actions and assignment is not covered in this scenario since that will be done as part of the Scrum process. The planning poker process used by this team is one way that teams can use the Alphas, but it is not the only possible way as Essence does not prescribe how the kernel must be used.

Summary

This scenario illustrates how Cynthia, Fred and Sam use Essence for establishing the status of the newly launched project and for determining what needs to be done next. The project's mission is to modernize and scale up Retailer Information System (RIS).  

At the start of the project, the team members involved have decided to use Essence as a starting point. To find out the project status, they held a dedicated Essence meeting during which they used all the Alpha cards in a planning poker manner. Because the team could not start with all the Alphas simultaneously, they therefore decided to start walking through one Alpha at a time and determine its status. For each Alpha, they then determined action items that were, in turn, used for planning next steps.

References

 [1] Essence – Kernel and Language for Software Engineering Methods, OMG Document Number: ad/2013-02-01, Standard document URL: http://www.omg.org/spec/Essence/1.0, http://semat.org/wp-content/uploads/2013/02/Essence_final_submission_18Feb13.pdf, 2013.

[2] Planning Poker, Wikipedia, http://sv.wikipedia.org/wiki/Planning_poker, 2013.

 

Download

Kick-starting a project scenario