• Read the summary for the Agile Project Management Case Study below.

Employees

Sandra: Software engineer/programmer

Brian Greenly: Project manager and now scrum-master

Abbi: Product manager

Sandra had worked for six years as a software engineer (computer programmer) in the IT (information technology) department at Challenger Motor Freight, a large freight moving and trucking company headquartered in Cambridge Ontario. 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. 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. When Sandra went to conferences and talked to other software engineers, she often heard that their projects were late and over-budget - in fact this is common for IT projects.

In the past few years, management has decided to try to turn things around by changing the way Challenger completes IT projects. Instead of the traditional waterfall approach in which all the requirements were defined upfront and the requirements and other analysis work was done prior to the start of programming (called development), the IT department decided to start using Agile project management, and more specifically the Scrum methodology, to complete their projects.

Sandra had just been assigned to a new project named CarbonData project. The goal of the CarbonData project is to develop a system for monitoring Challenger's carbon footprint in order to report this to the government and meet Challenger's environmental obligations. 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 didn't 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 wasn't 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 too long. She also liked having the product manager in the meetings because they were the ultimate decider on features and decided 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 that the finished software needed to provide. There was healthy discussion, and Pun amended the list to include some features that the team felt was necessary. In the afternoon session Pun prioritized 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 first 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 team's 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 other's 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 requested 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 needs 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.

The beginning of the Second Sprint

Brian wanted to capitalize on the momentum that was happening after the first sprint. He went into the first daily scrum of the second sprint feeling energized and enthusiastic about this new way of working.

The team was assembled and looking at the backlog. Brian got right down to business, assigning deliverables to Sandra and asking her and her team-mates how much time it would take them to complete their work. He thought that his enthusiasm was shared by all the team members.

Initially it seemed that it did. In the first day Sandra was a little confused about what just happened in the meeting but she started the work she was assigned. In the second and third day of the sprint she started thinking that maybe she should have clarified more of the expectations with the entire team and not just have taken what Brian assigned right away. She was starting to feel that she wasn't working in the way that she was taught at the two-day training session that she had previously attended (when she learned about Scrum). She wondered if she was the only team member feeling this way or whether others felt the same way. In any case, she was working alone in her cubicle and trying to make the best of it.

QUESTIONS:

1---Sprint and sprint planning description

2---Daily scrum (team meeting) description

3---Sprint review (end of execution) description

4---Sprint Retrospective (in closing) meeting description

5---Sprint backlog