Chapter 17 Case Study Construction Phase

.docx

School

Seneca College *

*We aren’t endorsed by this school

Course

200

Subject

Industrial Engineering

Date

Jan 9, 2024

Type

docx

Pages

Uploaded by EarlFieldViper35

Chapter 17. Case Study: Construction Phase The project is 90% done. I hope the second half goes as well. —Unknown Chapter 12 , “ Case Study: Inception Phase ,” introduced the AgileGrocers Point of Sale (PoS) Case Study. The focus of this chapter is the continuation of the project into the Construction phase for the PoS system. Our goal is to show what to expect in typical construction iterations. Your organization’s experience and the techniques and agile practices that you choose to apply will definitely differ, depending on many things such as your culture, need for governance, capabilities, and experience. CONTINUING OUR SCENARIO WITH THE AGILEGROCERS POS CASE STUDY We have just completed our one-week Inception phase. The following Monday, the team meets at 9:00 a.m. for two hours to plan the first two-week iteration of the Construction phase. Figure 17.1 shows the team as it looks when we start the Construction phase. Ashok, Ann, Brian, Katherine, and Gunther have joined the team as team members. Their specialty is programming, but each of them also has other general strengths in areas of testing and analysis. Using the DAD framework, we realize that in an enterprise IT environment, we usually need to collaborate with people outside our immediate team to get the work done. We need to draw on the expertise and skills of people acting in these secondary roles, but we are not sure who yet.

Figure 17.1. The AgileGrocers project team As described in Chapter 1 , “ Disciplined Agile Delivery in a Nutshell ,” each phase and iteration has a 3C rhythm of coordinate, collaborate, and conclude. For our case study, the initial coordination activities for the phase focus on proving that the architecture works. Planning the First Construction Iteration As facilitator of the planning session, Mark started with some basic resource planning for the team to verify their time commitments to the project for the new iteration. For the team to be able to commit to delivering a set of features for a particular iteration, we need an understanding of the availability of each team member. Ideally, every team member should be solely committed to one project. When team members work on more than one project at a time, their productivity goes down dramatically, and the rest of the team

doesn’t feel that these people are truly committed to the iteration outcome. For each of the team members we need to determine how many “ideal hours” per day they can dedicate to tasks that they are responsible for. This is similar to the Kanban technique of using constraints to limit the work to which the team can commit. Time that each person spends in meetings or helping other team members complete their tasks is not included in their estimate of daily ideal hours. A typical number might be five or six hours per day. Mark displays the simple spreadsheet of Table 17.1 via a projector. He uses this to tally the hours for each team member for each day of the iteration. Prior to the meeting Mark asked the team members to have their personal calendars available for the purposes of the planning session. The resource planning part of the meeting unfolds as follows: Table 17.1. Ideal Planning Sheet Hours

Mark: Let’s start with Pete, our architecture owner. Pete, I hope that you are dedicated solely to this project. Pete: Yes, I am, but I have an off-site strategic planning session next Tuesday and Wednesday. I also have approximately one hour per day that I need to handle administration, meetings, and emails. I will also be helping some other team members with their tasks for probably about two hours per day. That leaves about five hours per day to work on my own work items. Mark: Okay, I’ll mark you down for five hours per day then. Any vacation or other leaves of absence in the next three weeks? Mark: Ashok, how many ideal hours can you dedicate to your tasks? Ashok: I have no leaves of absence planned, and I think that I can do six productive hours per day against the tasks I volunteer for. Brian: You can make mine the same, please. Mark: Okay, Gunther? Gunther: Well, I would normally also say six hours per day, but this iteration I will be pairing with Katherine to do non-solo development of a few stories together. She is new to Java and our environment so working together will be an opportunity to bring her up to speed. So in effect, I am only working half time on tasks dedicated to me. Mark: That is a good practice as it helps to spread skills and knowledge throughout the team. When we decompose our work items into tasks in a few minutes, only one person can take ownership of each task, so you and Katherine will need to take some tasks each and split your time between your own and the other’s. Katherine: Okay, then I too will sign-up for three hours per day to complete tasks that I own. Mark: Sounds good. Mark: Louise, I assume that you will be busy this iteration managing the work item list, clarifying requirements and priorities with other stakeholders, and other tasks. So you won’t be doing any tasks directly related to implementing the work items? Louise: Actually, I should have some free cycles to help create acceptance tests. Probably about three hours per day. Mark: Excellent! While classically in mainstream agile, the product owner is not a direct contributor, practically speaking, if you want to

roll up your sleeves and help with tasks, there is nothing wrong with that. Louise: Okay. And I promise not to tell other team members what to do or how to do their tasks <grin>. Mark: That’s right. We need you to tell us what needs to be done, and in what priority , not how to do it. We trust the team members to know the best way to meet your needs in the most efficient way. Well, I can see from our resource sheet that our team contributors have a total of 250 hours in the iteration to do productive work related to work items, and that based on ten working days in the iteration, we should be able to knock off about 25 hours per day of work. Let’s proceed to reviewing the work item list and pick our work for the iteration. Effort Versus Duration Note that hours in our planning sheet are not hours of effort. If Ashok is working on a difficult bit of code that is expected to take two hours and asks Gunther to pair program the code fragment, the task is “owned” by Ashok and counts for two hours, not four. It is a duration number, not effort. This is an example of why Pete cannot commit to six ideal hours per day. He is working on other things not related to his specific tasks that he has volunteered for. PLANNING THE ITERATION’S WORK At this point, after having determined the team’s capacity to do productive work via “ideal hours,” Mark turns over the meeting to the product owner, Louise. Louise brings up the work item list (called a backlog in Scrum) that she created in IBM Rational Team Concert (RTC) and displays it to the team on the projector. Louise: This list shows what needs to be done, in priority order. For each item in the list, there is a relative point estimate. We know from our estimating that there is a total of 314 points to be delivered over the next 12 iterations. That is approximately 26 or so points per iteration. However, we know from experience that additional work items will be discovered, or that our initial estimating was overly optimistic. So Mark has suggested that the actual amount of work is probably about 10% to 20% more. So let’s round up the work to 360 points, indicating that we need to

complete about 30 points for each of the 12 iterations to finish on schedule. This allows for some contingency. Louise continues: From our estimating session we thought that the “Complete purchase transaction” story was 30 points all by itself, and I know that it is not realistic to complete this in the first iteration of our project! A story of this size is commonly known as an “epic.” I have broken this epic down into five separate smaller user stories, and moved all but one of them lower in the work item list to be built in future iterations. In the first iteration, I would be happy to see the framework of a basic PoS transaction working. Mark: Our risk list that we have posted on the wall shows that we are concerned that we may not be able to achieve 3-second response time when validating a payment transaction. Perhaps we should add a work item to the list to validate that our architecture can support this requirement? Louise: I don’t see this as big value for me. I will need it at some point, but it is not as important to me as some reports for example. Mark: I understand that system performance may not seem as high value for you, but for us techies this can be difficult. We need time now to figure this out, as the solution may be easy, but could also be extremely expensive and time consuming. We just don’t know. This work item is one of the highest risks on the project so we want to deal with it now. Hopefully fast response time is easy to accomplish, but if not, at least we discover this now and have time to figure out a solution. Does that make sense? Louise: I guess so. You know, I went to a Scrum course, and they told me that I am the boss. I get to decide priorities of anything that they put in the backlog (and you now call a work item list). So are you saying that I need to talk to Pete the architect about risky bits that he needs to add as priorities to my backlog? Oops. Work item list? Pete (architecture owner): Precisely. Louise, you and I need to work closely on this project. I need to help you prioritize work items in the early iterations. I need to inject some “tricky bits” as high priority items in your list so that we can figure out how to do this stuff. We need to balance these bits with your high value stories, which I like to call “juicy bits.” DAD calls this balancing the risk-value lifecycle practice. Once our team has figured out how to deal with the technically challenging parts of this project, we can focus on delivering the highest value stories to you in each iteration. A key

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help