PROJECT MANAGEMENT

Reference to Agile project management: https://www.youtube.com/watch?v=m5u0P1WPfvs Case Sandra had worked for six years as a software engineer in the IT department at Challenger Motor Freight, a large freight moving and trucking company. While she did some maintenance work on existing IT systems, she mostly worked full-time on new projects. Her work covered a wide range of IT projects including existing system upgrades, inventory control, GPS tracking for the trucks, billing systems, and customer relationship management systems and their databases. These projects were typically able to meet project requirements but were consistently late compared to their original planned completion date/time. Within the IT department it was common practice for a betting pool to be created regarding completion dates. The rule of thumb was to take the original scheduled completion date, double it, and then start guessing from there. Management decided to try to turn things around by changing the way Challenger completed IT projects. Instead of the traditional waterfall approach in which all the requirements were defined upfront and the business analysis work was done prior to the start of development, the IT department decided to start using Agile project management, and more specifically Scrum, to complete their projects. Sandra had just been assigned to the CarbonData project. The goal of the CarbonData project was to develop a system for monitoring Challengers carbon footprint in order to report this to the government. To prepare for this project, Sandra and her entire team of software engineers would attend a two-day Scrum training workshop. Everyone was given a book on Scrum to prepare themselves for the workshop. At first Sandra was overwhelmed by terminologyScrum master, sprints, product manager, sprint logs, etc. She questioned the rugby metaphor, and why was the project manager called a master? She didnt like the term. She had heard it claimed that Scrum gave programmers more freedom to do their work, and work at a faster pace, so she approached the two-day workshop with an open mind. The workshop was facilitated by a trainer who was well versed in the world of software development. Participants included her other five team members as well as Brian Greenly, a veteran project manager who would now assume the role of Scrum master, and Pun Abbi, who would act as the product manager representing the interests of customers. At first everyone gave Brian a hard time, by bowing to him, pleading master, master, master . . . The facilitator quickly corrected them by saying he was not their master but rather master of the Scrum process. The facilitator went on to emphasize that they would work as a self-organizing team. Sandra wasnt exactly sure what that meant, but she felt it had something to do with the team managing itself, not Brian managing the team. The workshop covered all the basic Scrum tools, concepts, and roles. Sandra liked the idea of the standing Scrum meeting, since most of her meetings at Challenger took way too long. She also liked having the product manager who was the ultimate decider on features and when work was completed. Everyone laughed at the only one neck to wring analogy that the facilitator used to describe this role. Overall she thought the process had promise and she was excited about trying it out on the CarbonData project. The CarbonData project was estimated to be completed after five sprints with each sprint lasting four weeks. The first sprint The first sprint planning meeting went pretty much by the book. Pun had done his homework and came to the meeting with a comprehensive list of features the software needed to provide. There was healthy discussion, and Pun amended the list to include some features that the team felt was necessary. The afternoon session featured Pun, the product owner, prioritizing the features in the product backlog with feedback from the team. The final segment was devoted to the team deciding among themselves which high priority features they would commit to build within the four-week sprint. Brian did a good job of reminding the team that they were expected to build a fully functional feature. This tempered the teams enthusiasm, and in the end a challenging but doable set of features was assigned to the sprint backlog for the first sprint. The first couple of daily Scrum meetings were a bit awkward as members were careful not to step on each others toes. One of the first impediments identified was not having a shared understanding of how a self-organizing team worked. Brian kept emphasizing that it was up to the team to decide who does what and when. Then one morning it just suddenly clicked and members came forward claiming work they felt needed to be done. After that the daily scrums took on a life of their own. The pace of work picked up, and there was a shared enthusiasm as tasks and ultimately functional features were completed in rapid fashion. Sandra worked side by side with the other software engineers to solve problems and share what they had learned. Occasionally Pun would be called into the project room to answer questions about specific features and be shown work in progress. By the time of the first sprint review meeting, the team was able to demonstrate all but one of the designated features to Pun and even three more that were not on the initial hit list. The team got some useful feedback not only from Pun but also from a couple of the end users he brought with him. Eighty percent of the features were proclaimed done by Pun while the others needed only slight modifications. Everyone agreed that the next Sprint review would even be more successful. The sprint retrospective meeting was refreshing as members spoke candidly about both the good and the bad. Everyone agreed that the team needed to do a better job at documentation. Issues regarding fairness and spreading both the fun work and the tough work among the entire team were brought to the surface. Sandra was impressed by how everyone focused on what was best for the project not just themselves.

Questions

1. Explain in your own words what the following Scrum terms mean and how they are used in the scrum methodology (7.5 marks)

a. Sprint and sprint planning

b. Daily scrum

c. Scrum review

d. Sprint Retrospective meeting

e. Sprint backlog

2. Given what you are learning about Agile and Scrum, what do you believe are the issues confronting the CarbonData project? (3.5 marks)

3. Assume you are Sandra. What would you want to say at the retrospective? How would you say it? What improvements or changes could be made (in your opinion) (3 marks)

4. List 2 problems that exist with traditional project management that agile project management is attempting to solve. (2 marks)

5. User stories are a way for stakeholders to communicate requirements to the development team.

5.1: Examine the following information and write a user story as shown in class (1 Point) Residents in ward five are concerned about the safety of their children while they play and would like to see clean and maintained parks in their local neighborhoods

User story:

5.2: Construct a user story of your own based on a set of information that you have come up with. Make sure to include all parts of a user story. (make one up) (1 Point)

User story:

6. List the Tuckman Model of Team Development and explain each stage. (5 marks)