Chapter 17 Case Study Construction Phase
docx
keyboard_arrow_up
School
Seneca College *
*We aren’t endorsed by this school
Course
200
Subject
Industrial Engineering
Date
Jan 9, 2024
Type
docx
Pages
42
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
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
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
differentiator of DAD versus some other agile methods is that we recognize that it is a mistake to deliver high value work items without resolving essential technical challenges early in our project. And we figure these technical things out not by doing elaborate designs, but rather building code related to actual implementable stories to prove that we have mitigated these risks.
Louise: Like a proof of technology prototype?
Pete: Our preference is to validate our architecture by doing this work against actual stories so that we have something we can keep at the end. However, sometimes we do indeed do these prototypes, known as “spikes” to explore candidate design solutions. This can be
a valuable learning opportunity for the team.
Louise: That makes sense. Now I understand why you asked me to move some of my items such as printing the receipt, lower down the
list into other iterations so that he could work on some high risk items in the first iteration. By the way, I added my own work item into the list. It is item #6 “Run a workshop and identify the needs for
operational reports.”
Mark: I have no problem with you inserting the reports workshop into your work item list as a high priority, first iteration work item. From the risk list, we can see that the users are not really sure what kind of reports they need. This is a different type of risk, related to delivering a solution that meets the needs of our stakeholders. It is important that we get a better understanding of what they want before we get too far into this project. It may mean that we have to insert additional stories into our work item list based on what you discover in your work item list, which is why we added some contingency into our estimates.
Brian: Wait a minute! That sounds to me like you are letting Louise change scope on us! Shouldn’t we lock down the requirements list right now?
Mark: Um . . . no. Agile methods have long since realized that it is pretty much impossible to have an accurate requirements document
at the beginning of the project. So a better approach is to build some contingency into the budget and schedule, expecting a degree
of change to naturally occur, and continually evolve the requirements through “grooming” your work item list as the product owner’s understanding of the true requirements evolves over the life
of the project.
Louise continues: Okay, so with our revised work item list I have highlighted the first four work items that add up to 30 points for implementation in this iteration. My hope is that you can complete the work items up until this point. Of course I understand that this is your first iteration, so the amount of work you can complete is a bit unknown at this point. Mark, do you think that this is a good estimate?
Mark: My role is not a project manager, but speaking on behalf of the team, they are probably a bit unsure of what they can accomplish until they go through an iteration or two. How about we go to the next step and have the team do some planning among themselves by identifying the tasks that they need to do to complete these work items and how long they are going to take?
Louise: Shouldn’t you be listing tasks and assigning them to the team members?
Mark: Actually, no. On an agile project I recognize that the team can best make these decisions among themselves. I trust them, and they trust each other to do this properly. They truly know better than
I what it takes to complete these work items, and how long it will take. I don’t “manage” them. My job is to facilitate this process and remove any impediments that interfere with them delivering work items to you. If I have any spare cycles, however, I plan to help in any way I can. I might help model some requirements, build some tests, or perhaps write or review some code if possible. I will do anything I can to help the team meet their commitments to you.
Ashok: Mark, it is good that you have built a buffer in for unplanned work items, but you have assumed that we can deliver 30 points of work items in each iteration. What if we discover after a couple of iterations that we can only deliver 20 points per iteration?
Mark: That is an excellent question. This is where traditional project management comes in. DAD, or any agile method is not a silver bullet, but what it does do is expose the truth of what we can accomplish early in the project. If we find that we can only deliver 20 points, then we have some basic and traditional choices to make;
we can promise to deliver fewer work items (reduce scope), add additional iterations (increase schedule and budget), add resources (people), or compromise on quality (take shortcuts). But . . . we don’t know what is possible until we get through a few iterations. So
let’s not jump to any conclusions until we have some real metrics from which to make these decisions.
Lessons from the Trenches—Planning for Release Contingency
When setting expectations with your stakeholders about how much
work you can deliver from the work item list (WIL), it pays to be conservative. Given your expected velocity in terms of number of relative points of work that you can deliver, multiplied by the number of Construction iterations should
give you an idea of where
in the backlog you run out of schedule. However, our experience is that the WIL will change dramatically from the original version created early in your project. Stuff always gets added to the list. Sources of “point creep” usually include defects deferred to future iterations, unexpected refactoring or do-overs, inaccurate relative point estimates for items, and new or changed stories. We typically
either add extra iterations to deliver the additional work items, or set the expectation that original scope will probably need to be cut by 25% if the schedule is to be adhered to. Of course, when items are added to the list, items below the priority of these new items are pushed down in the stack. The product owner understands that
this usually requires removing items at the bottom of the list for this
release altogether to make room for new items. We encourage our product owners to manage the scope of the release just like a project that uses a traditional approach.
What do we do with defects? Should they be added to the work item list? Our approach is to fix defects in the iteration that they are
found, and treat them as tasks in the iteration. However, there are times where for various reasons, defects need to be carried over to
subsequent iterations. In these cases, we add the defect to the WIL. Most agilists consider a defect a type of change, similar to a requirement, that must be prioritized by the product owner like any other story. Therefore we reserve some contingency points available to deal with defects added to the WIL.
Mark adds: Okay, team, Louise has presented the first four work items as her highest priorities (depicted in Table 17.2
). Now we—
that is, you
—need to determine how we deliver them and how much
effort it will take. Hopefully we have enough time in this iteration to deliver them. We will do some estimating to find out. But before we do, Louise, can we please go through each of the work items for this
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
iteration and explain how they should work and what you are expecting? I believe that you wanted Janice, the domain expert from
the business, to join us for this part of the planning session so that she can answer any tricky questions about the functionality. I just texted her while you were talking, and she says she is on her way.
Table 17.2. Highest Priority Work Items Showing First Four
Work Items to Be Delivered in the First Iteration
Janice arrives with Sue, the store manager representative.
Louise: Welcome, Janice!
Janice: Hi, Louise. I have brought Sue along. She has 20 years experience working in our stores and has been asked to represent the store managers when we define the requirements for the new
system. As you know, Sue is also going to move into this work area to be closer to the team to be available to provide details on the requirements as well as give feedback as the system is developed. I can’t be here full-time, but I am always available on chat if you need
me to pop by.
Louise: That’s wonderful. It is great to have the domain expertise readily available to our team members. Welcome, Sue.
Louise then describes each of the work items for the iteration. Janice
adds clarification on certain details in response to questions from the team. Fortunately, Louise has been preparing for this planning session by making sure that her work item list is well prioritized and formed (sometimes called “grooming” the backlog in Scrum).
Louise also came to the meeting with a list of acceptance criteria for
each of her priority work items. She will consider the work items complete when they meet these criteria. By thinking about testing before
implementing the work items, it is easier for the team to understand what they need to do to make the project owner happy. Table 17.3 shows an example of these acceptance tests for the “As a
cashier I can scan bar codes” user story:
Table 17.3. Example Acceptance Test Criteria
During the discussions about each work item, Janice draws screen mockups on the whiteboards as thought starters for the user interface. For each item the team spends a few minutes discussing among themselves how it would work. They agree that they can use the existing data model as a start, with some redesign required. Mark listens as Ashok asks Pete “are we allowed to change this
database schema? Isn’t that Gary, the DBA’s, responsibility?” At this
point Mark interjects:
Mark: Yes, that is part of AgileGrocers’ overall governance strategy for this project; the data administration group will be responsible for database changes that eventually end up in production. Contrary to what you may have heard out there in the agile world, sometimes our teams need to collaborate with people outside
the team. If you create a task in your plan to review your suggested database changes, I will make sure that Gary is available to do the review immediately so that there is no roadblock for you.
At times during the team’s discussions of how they are going to implement a work item, the team gathers around the whiteboard to model storm the solution. They sketch a simple class diagram, showing the key entities and their relationships, so that the entire team is naming their classes consistently. These examples of doing screen mockups and designs on a whiteboard are examples of Agile Modeling in practice.
Once the team agrees to an approach for the first work item, which is about scanning items, Pete asks Mark, “Okay, we think we know how we’ll structure a PoS transaction and how we will capture scanned items. What now?”
Work Item Breakdown and Estimation
Mark: We’ll I’m not your project manager, I am just here to help. We need to take this work item and disaggregate it into a set of tasks. So I would like you to write the names of each task that you will do for this work item on a separate sticky note, with a number of hours that you think it will take for that task. Decide among yourselves who should do each task and put that person’s initials on the task. Each team member should make sure that they don’t sign up for more hours of tasks than they have committed hours for in the previous part of this planning session. For instance, Ashok has 60 hours available that he can commit to his own tasks, so the total hours for the tasks that he plans to do should not exceed that or he is over committing.
The team then works together to do the task identification and estimating for the scanning work item that Louise has just reviewed.
Louise does not participate in this planning, but is there to answer or
clarify any questions that the team has about the work items.
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
While the team is doing their estimating, as they complete their sticky notes with tasks and estimates, they pass them to Mark, who enters them as tasks in the planning section of RTC. The review of each work item, modeling, task identification, and estimating continues for each of the planned four work items.
Completing the Estimating Session and Sanity Check
After the estimating completes, Mark quickly adds up all the hours for the tasks that the team has identified to complete. The hours add up to 210, which is a lot less than the 250 that the team said they had available to do tasks in the iteration. The choice now is whether to add another work item into the iteration. Based on Mark’s experience he suggests that we don’t add another work item in this iteration, as often the estimates may be overly optimistic, or more likely, unplanned tasks surface during the iteration. Also, the scope of the work item may turn out to be larger than thought in this estimating session. After this sanity check that the work is achievable in the iteration, according to the team’s
plan, not Mark’s,
Mark asks the team whether they “commit” to delivering these four work items based on what they know. The team agrees to this commitment.
The iteration planning finishes around noon. Mark had ordered pizza for the team in case the planning session ran late. The team uses the lunch to have discussions on how they are going to jump into their work in the afternoon.
Over lunch Ashok says to Mark: You have said that project, iterations, and even days have a 3C rhythm of “Coordinate, Collaborate, and Conclude.” Is what we did this morning the “Coordinate” for the iteration?
Mark: Precisely. This afternoon, the team will begin collaborating to achieve the iteration’s goals.
Ashok: Awesome.
After lunch the team jumps into their work. For each of the tasks that each team member starts to work on, they change the status of
the tasks to from “not started” to “in progress” and assign themselves as owner.
Lessons from the Trenches—Planning for Iteration Contingency
Mark has seen that iterations always
have unplanned tasks. Handling them can be tricky as adding new tasks with hours to the taskboard makes it difficult to track progress against the plan on the burndown chart. There are many variations to handling this situation, but this is Mark’s approach. Realizing that change happens, he ensures that the team undercommits in terms of tasks
planned compared to available ideal hours in the iteration. For instance, in this iteration, the team’s planned hours totaled 210 against 250 hours available for the iteration. So Mark often creates an extra sticky note (or a task in RTC) for contingency hours. In our
case Mark created a contingency task of 40 hours (250-210). The number may seem high, but the team is new to this agile approach,
and new teams tend to forget tasks that they need to do or be too aggressive with their estimates. In future iterations, as the team gets better at planning their iterations, he will let them create tasks that consume most of their ideal hours available, and reduce the contingency task accordingly. The contingency task hours are treated like any other task being added into the total planned hours
that goes into creating the burndown chart. Now when an unplanned task surfaces, for instance, “refactor the Account class
—ten hours,” it is added to the board, and the hours on the contingency task are reduced by the same amount. This approach keeps the burndown progress looking healthy and helps avoid team members’ resistance to being honest and surfacing an unexpected task in fear of making the burndown look bad. Having new tasks visible on the board helps to make sure that similar tasks are not forgotten in future planning sessions. In fact, for manual taskboards, Mark uses a different color sticky note for newly added tasks so that they are extra visible to the team and hopefully not forgotten in the next planning session.
The Morning of Day 2: 9:00 a.m.—The Daily Coordination Meeting
The next morning, in the work room where the collocated team works, they all stand up at 9:00, and gather around the taskboard, which is being projected from RTC. Mark has sent an email to the stakeholders inviting them to come and watch the meeting but has asked them not to interrupt the meeting to ask questions. Several stakeholders, including Dean (the sponsor), Janice (the
domain/business expert), and Terry (the enterprise architect) show up and stand behind the team who is gathered around the projected
taskboard.
Dean: Why is everyone standing?
Mark: We hold the meeting standing up to stress that it is a short meeting with a degree of urgency to complete and get back to productive work. The classic weekly status meeting sitting around the table with coffee and donuts has gone the way of the dinosaur in
our new agile world.
The team wants to have a quick 15-minute planning meeting to plan
their day’s activities, and questions from people outside the team would make it difficult to finish the meeting in 15 minutes. This daily
coordination meeting (alternatively called daily stand-up, or daily Scrum) constitutes the coordination
component of the 3C rhythm for
the day.
As Mark starts the daily coordination meeting for each day after the first day of the iteration, he first reviews the progress of the team in the previous day.
Lessons from the Trenches—Big Visible Charts
For the purposes of this book’s case study, we have shown hand-
drawn burndown charts. Tools like RTC provide automatic burndown (or burnup) charting as part of its customized dashboards. However, even when using tools like RTC, Mark finds that updating a manual burndown chart is so simple (once per day)
that he usually has a hand-drawn burndown chart on a whiteboard in the team room so that it is always visible to the team. If you don’t
feel like hand drawing your burndowns, an alternative to consider is to display key metrics on a specific monitor, effectively a virtual “wallboard,” all day long. This virtual wallboard shows key metrics such as your iteration burndown, defect trends, build status, and so
on.
Tracking Iteration Progress with Iteration Burndown Charts
Starting on the second day of the iteration, part of Mark’s responsibility at the daily coordination meeting is to review the team’s progress against their plan. A common visual chart to show
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
this progress against plan is the iteration burndown chart. Mark has hand-drawn the iteration’s burndown and posted it in the work area as shown in Figure 17.2
.
Figure 17.2. Iteration burndown chart
Before going around the room in the normal, “3 question” format of the daily stand-up meeting, Mark reviews the team’s results overall from the day before:
Mark: Good morning, team. I have updated the iteration burndown as you can see. We got off to a slow start yesterday, but that is mostly due to spending the morning in the planning session. We expect to knock off 25 hours during the day, but we only knocked off
13. The green line that I have drawn for our progress is above the straight blue line, which indicates our expected burndown trend if we are on schedule. As you can see, we are trending above the expected burndown line, but we have technically only done one-half day of work, so I am sure that we can make it up. This is normal for the first day of the iteration; hopefully we can complete more hours today.
Coordinating the Day’s Work
Now, after having reviewed the team’s overall progress for the previous day, Mark continues by asking each member to answer three questions: What did they do yesterday, what do they plan to do today, and do they have any issues or blockers that are stopping them from making progress on their work items?
Mark also asks team members to do a little “look-ahead planning” (a
practice we highly suggest) and consider dependencies on their upcoming work items. For instance, Ann may need some changes made to a database table before she can start working on a new user story two days from now. In this case it would only be fair to ask Gary the DBA (external to the team) to approve the database change so that Ann can make the change in the team’s sandbox database. In this particular case, Ann should mention this dependency in the daily meeting in advance so that Mark can contact Gary and get the change approved in time so that she can stay focused on their current tasks, but be ready to start the next story.
Ashok: Okay, I’ll start. As we all know, yesterday morning was used up with the iteration planning session. So I didn’t actually work my expected six hours per day yesterday due to Mark’s planning overhead <chuckle from team>. I think, Mark, that next iteration, you should reduce our ideal hours available on the first day of the iteration because of this.
Mark: Duly noted. I will record it in our retrospective log so that we learn this lesson and action it.
Ashok points out the task “model PoS transaction collaboration”: I started working on this task yesterday afternoon. I have moved it from “not started” into the “in progress” column as you can see. It should not take more than another hour. As you can see, I am doing it on the whiteboard on that other wall <points to the other wall where there is a draft of a UML communication diagram>. I originally estimated the task as three hours. Even though I worked on it for two hours, there are still two hours remaining. I changed the
time remaining for the task in RTC to two hours. Is that correct?
Mark: Yes, it is. The time remaining should be actual time, not the original time minus time spent. What we are really concerned with is
how much is remaining, not expended.
Ashok: Okay. When I am done with that task, I will create any new classes, their operations, attributes, and signatures. I called that task “code classes,” which should take me the rest of the day. I have
no impediments blocking my progress. However, Pete, can I ask you to spare 15 minutes this afternoon to review my model before I commit it to code?
Pete: Sure. Thanks for the heads up.
Ann continues the meeting with her update. She mentions to Louise that she has a few questions about the current user story that she is
implementing.
Louise: Sure, what are your questions?
Mark: Pardon me for interrupting, but this meeting is not the place for detailed requirements or design discussions. Let’s get through our planning, and then you two can work together on your questions.
Louise nods.
An important part of a team lead’s responsibilities is to ensure that the daily meeting runs efficiently so that meeting time is minimized and team members can get back to working on their tasks.
When it is Pete’s turn to give his update, he mentions that RTC has just released a patch that the team could use, but he is unsure what the procedure is to download it and get it installed for the team. He asks if he should spend some time surfing the Net to figure out where to get the update.
Mark: No, Pete, I don’t think that is a good use of your valuable time.
I will talk to Terry and find out what the policy and procedure is for getting the update installed. I’ll write this as an issue on our Issue List on the whiteboard. Hopefully when we have our daily meeting tomorrow, I can strike this issue off as dealt with.
This is an example of a team lead’s responsibility to remove any impediments (or blockers) on behalf of the team. Unlike traditional project managers who often find procedures such as status and time
reporting steal productive time from the team, an agile team lead reduces
bureaucracy and time wasting tasks for the team wherever they can. Team leads also prod the team to do this as well. This is one reason why teams will take a team lead over a traditional project manager any day.
The team finishes giving their updates to each other and goes back to work. Janice has been watching the meeting with interest and has
some questions, but she knows not to interrupt the team’s meeting. Now that it is over, she approaches Louise and asks her questions.
Janice: Thank you for answering my questions, Louise. Do you mind if I also sit in on your discussions with Ann?
Louise: If you can spare the time that would be great.
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
Mark: Wonderful. This is an example of just-in-time ad hoc meetings that spawn between the team and interested stakeholders after the stand-up meeting. This is the power of daily communication between the team and stakeholders without the need for time wasting emails. I have seen many potential miscommunications avoided when these type of things are caught by interested observers at our daily coordination meetings.
Lessons from the Trenches—Teams Report to Each Other
Mark finds that when he coaches new teams, and they give their update, they tend to face him as they answer their three questions.
Mark repeatedly reminds the team that it is their
meeting, not his. They are not reporting to him. They are reporting to each other. They have made commitments to each other and to the product owner, not the team lead. So Mark asks them to point out what they are doing on the taskboard and talk to each other. It is a powerful team dynamic once they realize that they own the success of the iteration and start working together as a team. The team lead helps to streamline their processes. Once the team becomes comfortable with the basic idea, other team members can
take on facilitation responsibilities and pick up new skills.
Collaborating Throughout the First Day
Once the team has finished coordinating their day’s work, they spend the rest of the day collaborating to complete their work items.
During early afternoon, the team gives Louise an interim build to do some acceptance testing. She discovers that scanning an item is displaying 0.00 for the price, yet she knows that the item’s price is in the system.
Louise: Mark, I discovered this problem with the scanned price. Should I enter it into the company’s defect tracking system? We can then start prioritizing these bugs and assigning them to different team members. I hear that is called “defect triage” and that sounds like a cool job for me.
Mark: Well, Ann wrote the code for that this morning, and she is sitting two desks away from you. Why don’t you just tell her what you found.
Louise: I suppose that is a more agile approach. I’ll go talk to her. . . .
Ann, I found this defect. Can you fix it in the next few days?
Ann: Why don’t I fix it right now, and you can retest in 15 minutes.
Louise: Wow, that is quick turnaround. Quicker than the time it would take me to log the defect!
Ann: Before I fix the defect, though, I am going to code a unit test to
detect this defect. As part of our continuous integration practice, we will automatically run this test on a regular basis. Should the problem ever recur due to some other change, we will catch it before it gets to you. This gives us confidence to make changes to our code base without having to do extensive manual regression testing.
Concluding the First Day
As part of concluding
the day, the team focuses on stabilizing the application. Any new code written during the day was tested by the team member who wrote it. They did this by integrating their new code with a snapshot of the system that they have in their own developer sandbox. When the developer is satisfied that his changes
not only work as expected but don’t break the rest of the system, he
delivers his changes to the shared code base (or “trunk”) known as the integration stream. This delivery fires a build of the system and automatically runs all the developer unit tests to ensure that the changes have not broken other parts of the system.
A key responsibility of every developer is to ensure that new unit tests are written to support any new code, and that these tests are added to the suite that is run in the integration stream every time a new piece of code is checked in/delivered. Ideally, the team adopts the test-driven development (TDD) practice whereby the tests are written before
the actual code is written. This ensures that the tests are not forgotten, or neglected due to time pressures. The practice of building and integration testing continually for each new code delivery is called continuous integration and is a key agile practice that all teams should incorporate. Having working, consumable software on a regular basis (ideally daily) would be impossible without this practice.
Toward the end of the day, critical defects are fixed. The team decides to defer some minor defects so that they can concentrate on getting the remaining stories implemented, with hopefully some
time to fix the minor defects toward the end of the iteration. In these cases, they log the defects in RTC as work items so that they don’t lose track of them, and so that they can be prioritized like any other work item.
Day 2
Mark spends some time with Paula, a test lead assigned to this project.
Paula: Hello, Mark. I have been told that I and one of my fellow testers have been assigned to this project to do independent testing. Why are we meeting so early in the project? Shouldn’t I be joining the team when the application is built and ready to test?
Mark: Actually, on an agile project we have features to test as early as one week into the project. If there are problems, we save a lot of time and effort catching them early. It will reduce our user acceptance testing required significantly at the end of the project, and we expect far fewer problems to be found. In fact, we expect the testing at the end of the lifecycle to be more of a formality.
Paula: Why don’t I just join the team as a tester?
Mark: Well, we do indeed have a significant focus on testing within the team. However, there can be a tendency for team members to be biased to testing “happy paths” of testing and not consider more esoteric scenarios. Having someone outside the team adds a degree
of confidence that the testing process is not compromised.
Paula: Where can I find the requirements documents?
Mark: We don’t produce much in the way of requirements documents on an agile project, as we find that they are costly to produce and usually don’t reflect the true needs of the solution. The effort to write a requirements document, as well as the cost and resulting delays to keep these documents up to date, can discourage change to any requirements. This is not an efficient way to work. Therefore, we rely more on discussions with our domain experts in lieu of written requirements documents.
Mark continues: We would prefer to spend time writing acceptance tests based on what our stakeholders tell us as we implement the actual functionality, and ideally just before we do so. These tests are
like requirements and are used to validate that the system meets the stakeholders’ expectations. Louise has some experience writing these tests and she can provide you with some samples. Louise is
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
busy, so I can walk you through the technique, and then you can spend some time thinking about other tests that she has not covered.
Day 3
On the third day, Gunther realizes that he needs to do a task that is not on the taskboard and asks Mark what to do.
Gunther: I need to spend two hours reviewing the existing database schema and the related data dictionary documentation, but I forgot to identify this task in our planning workshop. Should I add a sticky to the taskboard for this?
Mark: Sure. It is typical to discover new tasks that need to be done. That is why we planned to do 210 hours of work when the team actually has about 250 ideal hours available. We have about 40 hours of contingency built into the plan to do this unplanned work. Let’s categorize this as an “unplanned task” in RTC, so that when we
do our retrospective at the end of the iteration we can observe the degree of work that we did not plan for and perhaps learn and plan better for the next iteration.
The Next Several Days
Work continues over the next several days following the daily pattern that we have described.
During the daily coordination meetings, as part of reviewing the team’s progress, Mark reviews any outstanding issues that have been prominently displayed using sticky notes on a whiteboard. Having them displayed this way ensures that they are not forgotten and are dealt with in a timely fashion. Clearing these issues is a critical part of a team lead’s role.
As new capabilities become available, Janice and Louise spend part of every day running manual “smoke tests” to ensure that from a functionality point of view, the system works as expected.
Midway through the iteration, Janice informs Louise that they completely forgot a few stories. Ann is panicking, and Mark steps in to help out.
Janice: We absolutely have
to have these stories in the first release of the system.
Mark: Well, in that case, let’s add them to the work item list in the priority that you and Louise agree upon. It will obviously mean that
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
the other items will go down in priority, and some may not make it into the final release. But let’s defer that discussion until we have a better idea of how we are progressing.
Janice: Since these are high priority items, can we get the team to stop working on some of their current items and work on these instead?
Mark: No, that would not be wise. It is a good practice to not add new work items to the current iteration since the team already has committed to a given set of items. We don’t change scope during the iteration. If, for instance, it is a material addition to an existing story that we are working on, we add an additional story to the work
item list, and they can start working on it in the next iteration.
Louise: Mark, I also have some bad news. In discussing some of the future planned stories in more depth with Ann, we have discovered that some of them are far more complicated than we thought and in fact quite different from the way we originally understood them. So the relative estimates for them are too low. What should we do?
Mark: Well, the good news is that we now have a better understanding of the requirements. It is a good thing that we didn’t spend a bunch of time in a traditional manner to document the wrong requirements. I recommend that you adjust the relative point estimates for these stories in your work item list. Again, it means that some more work in the list may not get implemented, but we will see.
Louise: Janice, I have to admit that I am getting a bit frustrated that you aren’t answering my emails promptly when I have questions about the requirements. It means that I can’t give timely answers to the team sometimes. And I take a long time typing up those emails.
Janice: I am usually at my desk, but sometimes I take my laptop to another desk or to work in a quiet corner of the cafeteria.
Louise: Well, that explains why you don’t answer my phone calls.
Janice: And often I make a point of not reading my email so I can get
my other work done.
Louise: Ahhhhhh!!!
Mark: Hang on. Can I suggest something different? Janice, I believe that you have IBM Sametime
®
on your desk for instant messaging/chat (IM)? Louise, why don’t you just ping Janice when you have a question? Or better yet use RTC as it’s integrated with
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
Sametime and then the chat can be automatically logged against the corresponding work item. That is probably quicker than typing up a long email.
Louise: I guess we could try that. But then I wouldn’t have an audit trail of the decision in case Janice changes her mind.
Mark: Actually, modern chat tools allow you to save and file your conversations so that shouldn’t be a concern. And to be honest, making a decision to be more trusting reduces the need for elaborate time-consuming audit trails.
For the remainder of the iteration, the team collaborates to complete their work items.
Day 7
Dick, the internal auditor, pays a visit to Mark.
Dick: I understand that you are doing an agile project. I want you to understand that my job is to make sure that you follow our processes. I insist that the application be verified by doing some testing by an independent party.
Mark: I actually agree with you, Dick. We have asked Paula to independently test our application so that the verification process is not biased by our own team members.
Dick: Excellent. Additionally, I will want to have a weekly meeting with you to review progress, risks, issues, and adherence to schedule. I’ll set up a weekly meeting in my office.
Mark: Well, Dick, we have no secrets on this project; all of our work is transparent. We talk about all of these things in our daily coordination meeting, and our metrics are both posted on our walls, as well as viewable via a dashboard in RTC. Please feel free to attend our meetings to observe how our project is progressing. If you are unsure about anything that you hear, stay behind after the 15-minute meeting, and I would be happy to clarify any details.
Day 8: The Team Has Fallen Behind Their Plan
As can be seen from Figure 17.3
, the team has fallen behind and has
an open discussion during their daily coordination meeting on Day 8 about their progress.
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
Figure 17.3. Iteration burndown chart toward the end of the
iteration
What’s the Purpose of the Iteration Burndown Chart?
Iterations are by design, short in duration. A two-week iteration is just ten business days. We cannot afford to determine whether we are behind schedule on merely a weekly basis. An Iteration burndown chart is a simple way of tracking progress on a daily basis by plotting “burned down” hours. We plot the number of total remaining hours of work for all work items on the Y axis against the
day of the iteration on the X axis. Every day we plot a new value based on the total task hours remaining in the iteration and draw a line from the previous day’s plotted value. (If you are using a tool like RTC it automatically plots the new day’s value.) The straight line on the chart depicts the expected burndown trend if the team is
on track to complete all their task hours by the end of the iteration. On the last day of the iteration, the number of hours should have burned down to zero. Values plotted above the burndown line indicate the project is behind schedule; below the line and you are ahead of schedule. This amazing yet simple technique keeps the team focused on progress versus objectives.
At the beginning of the iteration, you should know what your expectation is for burning down hours/per day. For instance, in our case, for this iteration we have written tasks that add up to 250
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
hours (including contingency). Since we have a ten-day iteration (considering the statutory holiday), we can expect to knock off 25 hours/day from our tasks.
Mark: Team, this is no surprise, as we have seen from our burndown that we are increasingly falling behind on this iteration. With only three days remaining in our iteration it is obvious that we are not going to get all four of our work items completed. It does seem achievable that we can complete everything except programming the interface to the SAP system for sending payroll details. Let’s concentrate on getting the other three stories into a stable and tested build in preparation for our iteration review on Friday with Dean and some other interested stakeholders.
Dean is in attendance at the stand-up meeting, and while he knows that he isn’t supposed to interrupt, he can’t help himself:
Dean: Wow, we are falling behind already. I guess this agile approach isn’t working too well!
Mark: Well, Dean, we are indeed disappointed that it appears right now that we won’t meet our commitment to Louise; however, to be fair, this is our first iteration, and the team is just learning how to work together in the most effective and productive manner. We have
learned some lessons to streamline our work. We will discuss them more at our retrospective on Friday so that we make sure that we adopt these process improvements for our future iterations.
Louise adds: And I have to admit that I wasn’t as organized as I had thought during this iteration. Turns out that I didn’t understand exactly what Ann (our store manager representative and domain expert) really wanted in these stories, and the team had to wait for me to get answers. They also had to redo some work because I had given them the wrong information.
Mark: I’ll add that frankly, we bit off more than we could chew in terms of number of points worth of work items that we can realistically deliver in an iteration. We call that velocity. I am hopeful that as the team adapts to become more productive from iteration to iteration, their velocity increases so that they can take on more work. For the next few iterations, however, we will assume that we have a lower velocity and will accept fewer points of work items to commit to delivering.
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
Dean: Remind me again why this is better than the traditional approach?
Mark: In agile, we accept the reality that teams don’t know at what pace they can deliver work until they start working together and get
comfortable with the domain, technology, and people aspects of the project. Likewise, Louise will admit that she doesn’t really know exactly what the end solution will look like until she starts to see and
use increments of the solution.
Concluding the First Iteration
In the last few days of the iteration, the team is focused on “hardening” their work—that is, focusing on fixing the quality of their work rather than building new functionality so that it is at a minimum suitable for a demonstration, but preferably a potentially shippable, consumable solution should the stakeholders wish to deploy it as it is.
Iteration Review
On the last day of the iteration, the team books a one-hour iteration review meeting (called a Sprint review in Scrum) in the work area with interested stakeholders to demonstrate the team’s accomplishments for the iteration. A PoS system is available in the work area to do the demonstration. The team is in attendance for this short meeting. (It is their work area after all!) It is good to have the team present to take credit for their work, receive feedback about how they are progressing, and ensure that they are meeting the stakeholders’ expectations. Mark asks Ashok to lead the demonstration of the solution’s new features.
This meeting is more than just a demo—it is an opportunity to get feedback from the stakeholders on their perception of the project and the recent iteration in terms of meeting their expectations. The demo is a good way to show objective progress, but the review is also an opportunity to discuss other topics related to the project.
Mark facilitates the meeting.
Mark: First of all, let’s review our progress against our plan. I would like to congratulate the team on its accomplishments for this iteration. We were able to complete three of the four planned work items in the iteration. The team in fact worked some overtime to get
this much work accomplished. However, we don’t want to continue this pattern of overtime as it is inconsistent with the sustainable
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
pace agile practice. The team will burn out if we keep this up. Rather, we will adjust our expectations for the number of “points” of
work items that we can deliver (velocity) down from 30 to 25 points since that is what we delivered in this iteration. I am optimistic that, as we learn to work more effectively, we can increase our expected velocity, but we will wait until we have evidence that this is possible before we commit to do so.
Louise: But if we reduce our expected velocity, doesn’t this mean that if we extrapolate this out for the remaining 11 iterations, that we will not be able to complete all of our planned release work items?
Dean: Looks like we’re off to a rough start!
Mark: That could possibly be true. But having a lot of experience with agile projects, I added some contingency into our plan so that we do have an extra iteration in the schedule to be able to handle flexibility in our productivity and project scope. If we maintain a pace of 25 points over the 12 Construction iterations, that means that we will deliver 300 of the 314 identified points, which is 95% of the expected functionality. I am still optimistic that we will be able to
improve our velocity. In most projects, it takes some time for the team to learn to communicate and work most effectively. In the next
meeting the team will discuss ways of working better together. We expect to reap the benefits of these improvements for the remainder
of the project.
However, I do anticipate more points of stories and other work items
to be added to our list. So we may have to make some difficult trade-offs regarding scope if we are to deploy on our planned dates. I will keep track of additional points of scope and plot it on a ranged burndown chart so that we can show a realistic team velocity of what our team can deliver during an iteration.
Dean: I have a waterfall project going on as well. They are three months into the project, and the project manager tells me that they are on schedule. We are one month into this project, and you are already behind!
Mark: Respectfully, how do you know that you are on schedule for the other project? Do you think that the remainder of the schedule is
accurate considering the team of developers has not even been hired, and you probably don’t know how productive they will be? When will you see some of your solution working?
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
Dean: The Microsoft
®
Project plan schedule says that we will have a working system in six months.
Mark: Well, we are about to show you a working, tested piece of your solution now, and we are four weeks into the project. We will continue to show you increments of the solution every two weeks, and if you need to deploy something to your users, we can do that at any time. With your waterfall project, early deployment is not an option.
Dean: Well, let’s see what you have done <frown>.
Louise: Ashok will now demonstrate what we have accomplished during this iteration. Ashok?
Ashok demonstrates scanning of items, including weighing of produce items. He also demonstrates that while they were able to verify payment for debit and credit transactions they take roughly 6 seconds, not the 3 that were expected.
Louise: Yes, this was disappointing. However, I now realize that my requirement expectations might be a bit unrealistic. So I am changing the acceptance criteria to 6-second response time.
Mark: I understand that, while the PoS transaction works, the team had to take some shortcuts and also had no time to create a proper set of unit tests.
Pete: Yes, to be honest the code is a bit sloppy and would be hard to maintain and extend as it is. We simply did not have enough time to do it properly if we planned to be able to demo the functionality.
Mark: That is not uncommon, especially in the early iterations. While
the agile community might blast me for this, I am going to suggest that we give you credit for the 10 points for completing this work item, but we need to add a new work item to refactor this functionality so that the code is of good quality. Failure to do so would build some “technical debt” that we would have to pay back in the future when we would be forced to rewrite the code when it becomes too brittle and unmaintainable. The refactor work item needs to be high priority; otherwise, it might never be done.
Louise: What’s the big deal? If it ain’t broke, why fix it?
Mark: Well, if we don’t fix it, poorly written code will lead to an unmaintainable system. Allowing bad code and designs to accumulate in the code base is known as accruing “technical debt.” Like interest debt, it compounds over time. It’s pay me now or pay
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
me later. If later, it will cost much more to fix. In fact it can often require a substantial redesign and rewrite of the code base.
Louise: Okay, it doesn’t provide me immediate benefit, but I can see
that investing some time in refactoring now will benefit me in the longer term.
Dean: Well, despite not getting as much work done as we had hoped, it is comforting to see some of the solution working at such an early stage in the project.
Mark: Agreed. So to summarize, we completed 25 points of functionality in this iteration, and we plan to deliver at least the same, but hopefully more in the next iteration of the Construction phase (C2). With 11 iterations remaining, it would indicate that we could complete another 275 points. The usual pattern is that the team’s productivity increases as the project proceeds so hopefully we can deliver most of the expected functionality. I do expect some additional work items to surface and be added to the WIL, but my hope is that it can be balanced with some increase to the team’s velocity as the team gels.
This ends the iteration review, and those in attendance from outside
the team are dismissed.
Iteration Retrospective
Since the iteration review meeting ended 15 minutes early, the team saves some time by moving straight into the retrospective.
Mark continues to facilitate this meeting. He brings up a spreadsheet where he tracks retrospectives, and he has already logged an item that was surfaced earlier in the iteration by Ashok during a daily stand-up:
The team should not plan to complete a full day of ideal hours the first day of the iteration, since almost one-half of the day is used for the iteration planning workshop.
Mark: It is a good thing that we captured this in this spreadsheet so that it was not forgotten!
Mark asks each team member to consider these things:
• What things went well in the iteration that if we don’t discuss we might forget?
• What did we learn?
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
• What things could we improve on?
• Are there things that still puzzle us?
Going around the room, each team member takes turns giving feedback on how things went:
Katherine: First of all, I would like to say that I am really enjoying the
agile approach to building our solution. It is gratifying to be able to see working software so early in the project. It is also good that we don’t have to sift through piles of documentation. Having Louise and
Ann available to answer our questions immediately really helps and saves time on emails. Regarding what could be improved, to be honest, sometimes the team is a bit rowdy. It is nice that the team is
enjoying themselves and getting along well, but sometimes it is difficult to concentrate.
Mark: Thanks for being honest about that Katherine. This is common
when we have a number of people working in the same area. I am sure that the team will be more sensitive to this in the future. I’ll make a note of it in our retrospective log, so that we can review this at our next retrospective and see whether the situation has improved. Brian, your thoughts on the iteration?
Brian: I am happy with the way things are going. I had a thought about the need for a user manual for the PoS. When should we start writing it?
Mark: Well, an Agile Modeling practice is “continuous documentation.” You bring up a good point, so let’s start documenting the manual as we go. Louise, can we add a work item to the work item list for this?
Louise: Sure, I can do that right now. But it will happen every iteration; should it be a work item?
Mark: Good point. It probably makes more sense to create a task to update the user manual as part of each new story. Let’s do that. I will mention this in the retrospective log so that we don’t forget it in our iteration planning.
The retrospective continues in this manner so that each team member has an opportunity to provide his or her perspective on the effectiveness of the team’s process and make suggestions for improvements.
When the retrospective wraps up, Mark invites the team to leave an hour early on this Friday to celebrate the team’s achievements over
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
a drink. On Monday morning, they will meet to plan the next iteration in the same manner as they did for this one.
Lessons from the Trenches—Digital Versus Manual Taskboards
In this case study we used RTC as an example tool for planning the release, managing the work item list, and the task board. Do you need to have your agile planning managed in a tool? Like anything, it depends. Mark prefers to use manual taskboards for small, collocated teams. A manual taskboard prominently displayed
in the work room with a variety of colored sticky notes gives immediate and live status to everyone in the room on what is going
on. Having to find the dashboard in a tool isn’t quite the same. Having said that, for larger teams, or organizations where those outside the team are interested in the team’s dashboard (such as a
PMO), a virtual dashboard is necessary. Another example is in situations where some team members are geographically dispersed and cannot personally attend the daily coordination meeting. In this case, using a manual taskboard becomes awkward. In situations like this, Mark has resorted to taking pictures of the taskboard and sending them to off-site team members, and the team members in return send him daily updates on their tasks by email with which he then updates the board. Clumsy! Clearly, a tool would have saved time in this situation.
SUBSEQUENT CONSTRUCTION ITERATIONS
Space limits us from describing what happens in each of the subsequent 11 iterations, but the following section discusses some of the more interesting issues that surfaced in subsequent iterations
of the Construction phase.
The Second Construction Iteration
As the second iteration of Construction starts, Mark produces a release ranged burndown chart to track progress of developing the release on an iteration by iteration basis. He posts this chart (see Figure 17.4
) on the wall. The total estimated points to develop the solution (from the planning poker estimating session) were 314. If everything were to go according to plan, the points remaining would
burn down to zero by the end of the 12 iterations. However, in the first iteration only 25 points of functionality were delivered
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
compared to an expected 30. The hope is that the team picks up its velocity over the next few iterations as they learn to work better together and to streamline/optimize their processes. Eight points of work items were added into the work item list as unplanned scope, which is indicated on top of the iteration bar in the chart. The 25 points delivered, less the additional 8 added to the work item list, brought the total remaining work down to 297, which was plotted on
the bar chart.
Figure 17.4. Release burndown chart showing progress for
the release against plan
At one of the coordination meetings, Dick asks a question about this new chart:
Dick: Mark, what do the dashed lines mean?
Mark: Well, we have already fallen a bit behind, and some new scope was added to the list of work items. If the trend continues, it is difficult to say for sure that we can indeed deliver everything you need in 12 weeks. If we were draconian about it, we could rigorously
reduce scope to hit the 12 iteration schedule, but in that case you may not have sufficient functionality to actually go live. A more practical approach is to consider the possibility that we may
have to extend the schedule. The dashed lines represent a “ranged estimate.” It says that with only this one data point for the iteration just completed, we have a predicted range of 10 to 18 iterations
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
needed to complete the application. This is a variation of an estimation model referred to as the “cone of uncertainty.” It suggests that our estimating fidelity is poor early in the project, but will become more accurate with a lower range of estimates as we get more information about our progress.
Dick: But you told me that you added some contingency to the schedule, allowing us to add extra points of functionality to our work
item list.
Mark: Yes, I did, and I hope that it is enough to allow for unplanned work that is added. However, based on one iteration, there is still too much that we don’t know about what your true requirements are, about our delivery velocity, and other unknowns that are a part of every project. So we feel that showing you this range of schedule estimates is prudent. As I said, as uncertainty is reduced as we move through our iterations, the planned schedule variance will reduce dramatically. This is common on IT projects, with a wide estimation range at the start of the project reflecting the uncertainty
of the stakeholders’ understanding of their needs. As the stakeholders’ understanding of their requirements improves, and the
most effective way to do that is to iteratively show them a working solution, the estimate range will narrow.
The Third Construction Iteration
During the third iteration of Construction, Dean, the VP, pulls Louise aside and says that they must add another new feature to the system. Competitors are adding automatic ordering of stock from vendors when inventory for an item falls below a certain level. Orders are sent to suppliers without the need to create a manual order. Dean asks Louise to insert the work item as a high level priority. Louise figures that on a relative basis, this new feature would add at least 100 points to the estimate. Louise discusses the new feature with Mark.
Louise: I am the product owner, and you said that I own the priorities and scope of the project, so I am adding this to the work item list.
Mark: Yes, you can make that call. However, can I remind you that this is why we created a Vision document in the Inception phase? Does this new functionality solve the problem of reducing the lineups in stores, or reducing the maintenance costs for the system?
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
Louise: Well, I guess it doesn’t relate to those problems.
Mark: Then can I suggest that we discuss this with Dean and remind him that he asked us to solve those business problems with this release. Perhaps we can address his inventory management problems in the next release.
Louise: Okay, I will review the Vision with him and ask him to put this off for now.
Mark: I think that would be best. Let’s do our best to meet our existing commitment rather than introducing such a fundamental change in scope.
The Fourth Construction Iteration
An additional chart that Mark posts in the work area shows the team’s velocity in terms of number of points of functionality that they are delivering in each iteration. The bar chart in Figure 17.5 shows the trend of the productivity of the team. It shows that while the trend is not straight up, the team is succeeding in increasing their productivity as the project progresses through the iterations. This is typical as teams learn to work more effectively.
Figure 17.5. Velocity by Construction iteration
The Fifth Construction Iteration
During this iteration, Janice has a discussion with Mark.
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
Janice: Mark, I had lunch with Sandy, the data center manager working in our operations group. She has heard about our project and says that she really needs to learn about the expectations we have for her to run the system in production. Sandy says that she wants to work with our DAD teams to help facilitate a more frequent and automated deployment to our customers.
Mark: Sandy is definitely a stakeholder. We need to add her to our list of stakeholders in the Vision statement. I’ll set up a meeting with
Louise, Sandy, and myself to bring her up to speed with our plans. We need to start doing some look-ahead planning for the Transition phase, when we deploy the solution to the stores and in the data center. We may need to order some production servers and perform other related deployment activities.
It is also great to hear that she wants to work with us to streamline our deployment. In DAD, we call the practice of frequent deployment
“continuous deployment.” We will be deploying our application in a controlled fashion in the Transition phase. However, because we have already automated the deployment into our systems integration environment we deliver deployment artifacts into that environment frequently. It is relatively straightforward to extend these scripts for deployment into the Staging and high-availability clustered Production environments.
Mark continues: Another stakeholder we should engage with is the Customer Support group. When we have problems in the stores, they will call our help desk and they need to know who the contacts are to address any issues.
The Sixth Construction Iteration
During this iteration, the team brings up a new issue to Mark.
Ashok: Mark, we are getting really frustrated with Gary, our DBA. It takes forever to get a database change “approved.” He insists that database design must be done up front before any code is written, and must be properly thought through to consider future usage of the data.
Mark: Have you suggested that if there is a problem, the database can be changed to support the new requirements that arise, and then refactored if necessary to support a longer term solution?
Ashok: I have indeed, but he says that is ridiculous. He says that refactoring is for code, not databases.
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
Mark: I would respectfully disagree. I will talk to him about this. Did he give you an example of why databases need to be designed up front?
Ashok: Yes, he did. He said that if we pick a column name without thinking about it properly, and then he needs to change it, it will break our system all over the place and we will be faced with a lot of
code changes.
Mark: Well, it needn’t be that way. If he needed to change the column name, he could use a refactoring pattern whereby the new column is created with the new name. A simple script could populate
the new column’s data with the old column’s values. Then a trigger could be used to populate the new column every time our system updates the old column. When we have time, we could refactor our code to use the new column, and then the old column could be removed. This is just one example of a pattern for refactoring databases.
For more information on these agile database patterns, there is a phenomenal book called Agile Database Techniques
by Scott Ambler. I will buy him a copy.
The Ninth Construction Iteration
When the Construction phase started, Mark created a work item for contingency in the amount of 46 points (360 expected points less 314 estimated initially). As the iterations proceeded, sure enough, additional work items were identified as required scope. As the stakeholder priorities changed, some items were actually removed
from the work item list since they were no longer priorities. The estimates for net added items were taken from the contingency work item, totaling the 46 points of contingency available. Some of the contingency points were used for new work items; other points were consumed when it was realized that some user stories were larger than thought during the initial estimating session. Also, some technical refactoring (“do-overs”) was required, using up some points. Once the contingency points were used up, Louise had agreed that any additional work items would need to be deferred to future releases. This proved to be an effective scope management technique.
However, this scope management technique didn’t save the team from the fact that they were delivering fewer points of functionality per iteration than they had expected. In fact, after nine iterations,
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
they were delivering an average of 25 points compared to their initial expectation of 30 points. During the iteration review for the ninth iteration, Mark leads the discussion of what to do in their situation, referring to the ranged release burndown of Figure 17.6 for
the purposes of this discussion.
Figure 17.6. Ranged release burndown after nine
Construction iterations
Mark: Drawing trend lines from the bar chart out to the X axis, we can see clearly from our ranged release burndown chart that it is unlikely that we can finish all of the functionality by the end of the twelfth construction iteration. We can, however, see that the range of schedule variance is much smaller than our view after the first iteration of the project (refer to Figure 17.4
). This is because our stakeholders now have a much better understanding of what they want based on what they’ve seen the team produce. We now believe that if we keep up this net velocity we will finish construction
sometime between week 14 and week 17.
Dean: Not good. What are our alternatives?
Mark: Well, there is no magic here. The good news is that we expect to deliver the functionality that is most valuable to you. Since Louise
has agreed to defer some functionality, we still plan to complete the Construction phase in 12 iterations, which was the original schedule.
The remaining user stories that we will not complete are lower in
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
priority than what we have already delivered. They pertain to setting
up sales promotions in advance to automatically adjust a basket of items’ prices for the sales period. Louise, would you agree that this functionality is not critical to our first release of the solution?
Louise: Well, I am not pleased, but I understand that we couldn’t really understand what was possible to deliver in advance. I know that the team has worked very hard, and that we have cut out a lot of the normal bureaucracy that we’ve seen on our past traditional projects. We have definitely more functionality than in the past, and what we are getting is exactly what we need. There have been no surprises on this
project! And that’s a good thing; I don’t like surprises. So I suppose we can live without the remaining functionality. It is good that we can go live with the system on the timeline that we expected, and having spent exactly what we had budgeted.
Iteration #12—The Last Iteration of the Construction Phase
The team cleans up the remaining functionality as per the adjusted agreed upon scope and prepares to move into the Transition phase to deploy the solution to the stores.
Construction Milestone Review
On Friday of the last iteration, Mark and Louise (the product owner) meet with Dean (the VP), Terry (the enterprise architect), Dick (the internal audidtor), and Sue (the store manager representative) to go
through a comprehensive demonstration of the solution. They want to assess the product’s readiness to proceed into the Transition phase to deploy the solution into the stores.
Louise: Well, Dean, I am happy to say that although we were not able to complete all the functionality that we had in mind at the beginning of the project, we at least have sufficient functionality to deploy what we have completed, on time, and on budget!
Dean: Well, two out of three ain’t bad <smiles>. And, Louise, since you were there the whole time the system was built, there are no surprises at this point about what we are getting. Terry, are we confident that the system will scale properly when we eventually deploy to all of our 250 stores?
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
Terry: Yes, we ran testing under simulated load early in the project to
ensure that our architecture as designed can support this load. We found a few issues, but fortunately it was early enough to make the required changes before we had invested too much coding around a flawed architecture.
Dean: Dick, from an internal audit perspective, do you have any concerns?
Dick: No, I have been involved regularly during the process, attending many of your daily coordination meetings, as well as attending each of the 12 iteration reviews and voicing any concerns I had at the time. However, before we approve the system to go into
production, we want to spend one week of final independent verification testing across all the functionality. This will be done by Paula and three additional testers from outside the development team so that we can do a complete regression. This will begin in week two of Transition, that is, the week after next.
Terry: Yes, our operations folks set up a separate environment for this.
Dean: Louise, how is the quality over all? What is the status of the testing and known defects?
Louise: Well, in our initial Vision that we created in the Inception phase, we determined that all high priority defects, that is, priority one and two, must be fixed before we can go “live.” We have no high priority defects remaining. However, we have 45 lower priority defects, and one simple enhancement that we need to carry over into our Transition phase.
Dean: Mark, how will we deal with these?
Mark: In week two of our eight-week Transition phase, we will be piloting the system in two stores. Next week the team will fix the lower priority defects, as well as implement this small story that was
introduced into the work item list at the last minute. The defect fixes, as well as the new story, will be merged into the code base at the end of the week, so that it will be ready for the independent testing and the pilot in week two. The final build will be done at the end of week two for deployment to the production systems starting in week three of Transition.
Dean: Sounds good. So what else happens in Transition; is there a plan?
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
Louise: I have a work item list for the activities related to Transition. We will be reviewing them with the Transition team on Monday morning.
Dean: Excellent. I would like to continue our weekly reviews to be kept abreast of the progress and issues during Transition.
OTHER CONSTRUCTION PHASE ACTIVITIES
In the Construction phase, we needed to do some “look-ahead” planning for the Transition phase when we will roll out the system to the stores. We added and completed some work items to the work item list. These activities included
• Procurement of production hardware and software licenses for the 60 stores.
• Defining user ids for the store managers for access to the back office system and connectivity to the head office systems.
• Work with operations and independent testing to ensure high-
availability requirements will be met.
• Populating the database tables with data such as grocery items and their prices.
• Sue selected 10 people to become trainers for the rollout of the new system to the stores.
• Store manuals were produced in both electronic and hard copy format.
• The Communications department was engaged to create a rollout campaign to generate excitement among store employees.
• Creation of a high-level rollout plan detailing which stores will be installed in what order.
• Travel arrangements for the trainers were made.
• Determine on-call schedule.
• Establish incident reporting process with call center.
CONCLUDING THE CONSTRUCTION PHASE ITERATIONS
In the last Construction iterations, more thought starts to be given to deployment. Some look-ahead planning occurs to prepare for the
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
Transition phase. This includes activities such as ordering the new Production servers for the back office for each of the stores.
CONCLUDING THOUGHTS
In our case study, the team was relatively successful in its first iteration of Construction, producing an increment of the working solution in the first week. However, in our experience, this is not typical of teams trying agile for the first time. In reality, it is difficult producing consumable software after just one week. It normally takes some time and a few iterations for the team to learn how to effectively work together. Examples of reasons for teams failing to deliver software in the first week include misunderstood requirements, unwillingness to adopt lightweight approach to creating work products, poor team cohesion, lack of commitment to iteration goals, overly optimistic productivity expectations, environments not ready (such as developer environments, build machines, database availability), and misunderstandings about what
constitutes “done” for implemented stories. There are many more reasons why you may not get the results you expect in your early iterations. We find that teams that successfully produce consumable
increments of their solution in early iterations have usually worked together on previous agile projects. They typically understand agile practices, how to most effectively work with each other with minimum bureaucracy in a self-organizing manner with little direction, and are dedicated to helping each other meet their teams’
commitments to their stakeholders. So if you are new to agile development, approach it with reasonable expectations, expecting to improve your performance as you progress through your iterations. We of course believe that your success can be accelerated with some coaching by experienced agile mentors in your early iterations.
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