Humongous Insurance Scenario: Managing Projects with Microsoft Visual Studio Team System
The following scenario has been adapted from the book Managing Projects with Microsoft Visual Studio Team System by Joel Semeniuk and Martin Danner.
Chase is an experienced software developer who has played almost every role on a software development project from software developer and tester to project manager. Chase was recently hired by a startup venture capital–based organization to lead their latest software development effort. For the first time in his career, Chase has been given complete control and has been made responsible for a team of 25 other people who consist mostly of developers and testers.
Like most software developers, Chase is a very smart person and learns quickly, usually as he goes. Chase has a track record of getting things done; however, over the past five years, Chase’s interest around project management has been growing to the point where he has taken night courses on project management and has been working to reach project management certification from the Project Management Institute. Agile software development methodologies have always been an interest of Chase’s, and he’s looking forward to test driving some of his new knowledge on his new job.
Chase’s team has been assigned to develop a new commercial, shrink-wrapped software application that targets the insurance industry by using the latest Microsoft .NET technology. The organization for which Chase is now working, Humongous Insurance, has given Chase the challenge of having the product ready for release within eight months. Needless to say, Chase is excited and up for the challenge. Chase is starting off with a great team; however, he is very aware that it will take much more than just smart people to succeed.
If there is one thing Chase has learned over the years, it’s that you can’t build great software without great requirements. To emphasize this, Chase calls a meeting with his whole team together with key stakeholders of Humongous Insurance. During this meeting, Chase talks about how requirements form the foundation for everything that follows. Every estimate and every line of code must be derived from good requirements. The team is about to embark upon planning activities, and Chase wants to make sure that requirements, not technology, are their focus because without good requirements, the chance of producing a good plan is remote. Chase tells his team that a good plan involves the whole team and that he expects everyone to contribute to all areas of their plan as they move forward. Chase also emphasizes that planning isn’t a phase of a projects, it’s an activity throughout the project life cycle. He tells the project team that the initial plan will be the focus of the next few weeks; however, this plan will be reviewed and updated at the end of every iteration right until the release of their product. Some team members express concern with this approach—they suggest that it will be a waste of time. But Chase convinces them that estimates are only a best guess and that with each subsequent iteration, the guesses will be more accurate.
Chase has a 45-minute train commute every day and has learned to make the best of the commute by focusing on work. To make it easier to work on his laptop during his train ride, Chase creates a project workbook in Office Excel that will link to all the work item queries in Visual Studio Team System he uses every day. This will enable Chase to take work items with him on the train and provide him with the ability to add new work items and modify existing work items while offline. More important, when Chase returns to the office, he will be able to synchronize all his changes with Visual Studio Team System.
Gathering Requirements and Detailing Scenarios
To begin the planning process, Chase leads his team through a requirements-gathering workshop in which he brings together his team and a group of people who will ultimately be using the product. Together, they use a whiteboard to brainstorm about the scenarios that the software should provide. At the end of the meeting, Chase works to create Scenario work items in Visual Studio Team System that represent the scenarios that were identified. Next he assigns these work items to various team members who will be responsible for gathering more information for each scenario.
During the following week, the team spends time with their target user representatives to detail each of the scenarios and discover additional quality of service requirements needed by users, such as performance, response time, security, and availability. When the team meets again, they review all the work in progress and begin basic estimation and prioritization of the all the requirements. Chase instructs the team on how to prioritize requirements by using priority buckets and how to perform basic rough order of magnitude estimates on all the identified scenarios. He also stresses the importance of performing these activities as a group to make sure that everyone’s expectations and understanding are the same.
While the rest of the team is busy detailing requirements, Chase is hard at work creating an initial iteration schedule that was based on the general constraints Chase was given to work with. He knew that he had six months to release a new product. Chase also knew his budget would ultimately determine the size of his team. From this information, Chase began to decompose his timelines into iterations. Chase began by allowing time at the end of the project for stabilization and release management activities. Chase also allocated the first few weeks of the project to focus on requirements and initial planning activities. This left his team with about four months to build and test software. Chase further divided this four-month period into three-week iterations and selected iterations that would focus on delivering interim releases of the product. Chase would then use this skeleton iteration plan to schedule the work that is required to develop the scenarios his team is working to build.
After the initial iteration plan has been constructed and all scenarios have been identified, prioritized, and given a rough estimate, Chase worked with his team to decompose each of the requirements into tasks. Chase made sure that all kinds of activities related to building each requirement were considered, such as design, coding, testing, build integration, reviews, revisions, and bug fixing. Each of the tasks that were derived from each requirement was stored in Visual Studio Team System as a task work item and was linked to the requirement from which they originated. In addition, each Task work item was given an hourly estimate that was agreed to by the whole team. During this process, many risks were identified that would jeopardize aspects of the project. If teams could not provide an accurate estimate on a task, additional work was scheduled that would allow the team to conduct additional work to better understand the underlying requirement, technology, or method to help increase the accuracy of the estimates. Each of the risks were recorded in Visual Studio Team System so that they can be tracked and integrated into the overall schedule of the project.
After all the tasks and risks had been entered into Visual Studio Team System, Chase worked with his team to schedule all the work into the skeleton iteration plan he created. Chase made sure that his customer representatives participated in this process so that everyone agreed to the ordering and timing of the requirements delivered by the team. During this process, the team discovered that there were too many requirements for the period of time and money assigned to the project. With the help of the customer representatives, Chase and his team were able to remove lower-priority requirements from the scope of the project, reflecting their decisions in the State fields of corresponding work items. Chase and his team used Office Excel to assign work items to each of the iterations; however, his project sponsors wanted to see the Gantt chart and work breakdown structure in Office Project. After his team completed assignments of work to each of the iterations, Chase then used Office Project to import the task work items and make the appropriate adjustments to the start dates and the end dates of each of the tasks based on the start dates and the end dates of the iteration they are in to produce the appropriate report for management. Chase ensured that the Office Excel workbook and Office Project file he used were safely stored in the project portal for his Team Project so that they can be used in future iterations when they revisit the plan and need to make adjustments.
The project, code named “Gimli,” is now underway. To track how the project is progressing, Chase uses several of the default reports provided by Microsoft Solutions Framework (MSF) for Agile Software Development. These reports, such as Actual Quality vs. Planned Velocity, Bug Rates, Remaining Work, and Unplanned Work reports, are reviewed with the team in their weekly team meetings. Chase also includes links to the Team System Web Access location for several of these reports in his weekly status e-mails that Chase's manager reviews.
The first iteration has just wrapped up. Chase asked another project manager, Sue, to facilitate a retrospective meeting for the iteration. Having participated in many retrospective meetings and even led several, she eagerly accepted the invitation because she knows that these meetings are not only worthwhile but they can be fun, too. Sue schedules a two-hour meeting and invites the whole team. She starts the meeting by explaining that the purpose of the retrospective is to constructively evaluate the team’s process and look for ways to improve it. She sets some ground rules to keep the discussion constructive and to make sure everyone has a chance to participate. Next, Sue goes to the whiteboard and draws two columns, one for things that went well and one for things that didn’t go so well. She then asks the team, “If you could do this iteration all over again, what changes would you make?” A lively discussion ensues, and soon both columns are filled. The group takes a few moments to consider this information, and then Sue moves into the next phase of the meeting: brainstorming improvement ideas. She goes around the room and asks for one idea from each person, writing all the ideas on the whiteboard. She continues to solicit ideas until everyone passes. Next she gives everyone five votes that they can use to vote for the ideas they like the best. Before voting starts, though, Sue invites the group to ask questions about any of the ideas listed. Chase is intrigued by an idea listed as Information Radiator, but he’s not sure what it is so he asks for clarification.
Mark, the software developer, contributed the idea. He explained that he read about the concept in a book by Alister Cockburn (Agile Software Development: The Cooperative Game, 2nd Edition, Addison Wesley Professional, 2006). The term comes from the idea that the flow of information is similar to the swirl and flow of convection currents in gas or heat. An Information Radiator is a source of information positioned so that the information flows freely to those who need it. Just as a heat radiator in a building is designed to keep people warm, an Information Radiator is designed to keep people informed. In the case of software projects, an Information Radiator is typically a bulletin board or display set up in a high-traffic area such as a hallway where people notice it as they pass by. The Information Radiator should be set up in such a way that a passerby can see at a glance what is going on; the information flows as a convection current.
Implementing the Information Radiator
The project team finds the idea of an Information Radiator appealing. Sue calls for a vote, and the Information Radiator tops the list. Mark is put in charge of setting it up. The first thing Mark does is consult with Chase on what information should be included in the Information Radiator. They examine the reports available in their Team Project, which was created by using the MSF for Agile Development process template. They then decide to start with two reports: the Work Remaining chart and the Quality Indicators report. Mark decides to start with a low-tech approach for the next iteration, printing the two reports and posting them on the bulletin board in the hallway daily. The Information Radiator is an instant hit. Every time a project team member passes by, he or she looks at the reports to see how things are progressing. But what’s even better is that people outside the project team notice the Information Radiator and stop to look. Some folks are just curious, but others are managers and marketing professionals who have a vested interest in the project. You can spot the latter type because they stop and study the report a bit longer than the average passerby, and they come back regularly.
At the end of the iteration, the team discusses the Information Radiator. The comments are all favorable. The feedback and visibility provided by the Information Radiator has had a positive effect on team performance and morale. The only negative comment came from Mark, who was tired of having to print and post updates to the Information Radiator every day. The team discusses alternatives and decides to allocate some time in the next iteration to go high tech by replacing the bulletin board with a large video display that shows the reports. Mark will program the display to update periodically so that it automatically shows up-to-date information.
Chase and his team finally did it. They released a completely new product line for Humongous Insurance on time and on budget. The management at Humongous Insurance is very impressed and realizes that Chase’s team possessed something very special to have achieved this momentous challenge in such short a period of time. The company approached Chase to see whether he would be interested in taking on yet another challenge; spreading his best practices across the organization so that other teams could benefit from his approach. Chase decides to accept this new challenge.
Chase meets with Humongous Insurance management to determine exactly what the organization expects from the process improvement. He also wants to determine how much money and how many resources the company is willing to invest into the project. After his meeting with management, Chase captures these requirements and constraints in a Vision/Scope document for the process improvement project and asks management for explicit approval to begin the project.
Chase’s next job is to select his project’s primary team members. This group must best represent all the roles and projects in the organization. Chase also contracts a well-known consultant to help facilitate and guide their assessment and planning workshops and calls a kickoff meeting with the whole team. During this meeting, Chase walks the team through the project charter document. He discusses the expectations of the team as they move forward through process improvement and asks each team member to prepare for the upcoming assessment workshop by consulting with their colleagues in all the organization’s development teams to compile lists of the tools, templates, and practices currently used through the company.
During the assessment workshop, the consultant leads the team through exercises designed to capture aspects of their software development processes that worked very well in addition to aspects that need improvement. The assessment results are next distributed to the team for their review as the assessment will be the foundation for the process improvement planning workshop scheduled for the following week.
During the planning workshop, the consultant works with the team to further rank the results of the assessment. With the help of the whole team, the consultant begins to create a process improvement plan broken into twelve one-month iterations in which assigned work will be performed by the team. The process improvement work that is derived from the highest priority areas of the assessment are scheduled first, making sure that everyone agrees on the results that they are trying to achieve in every iteration. The resulting plan is then sent to management for review and approval. As soon as it is approved, the team meets briefly one more time to begin the execution phase of the project.
During the process improvement execution phase, many activities are started by the team in different areas. For example, the entire organization will attend training on Visual Studio Team System. In addition, one group will be setting methods of harvesting and communicating these new processes. This group will be responsible for updating Visual Studio Team System process templates to guarantee that all new processes are reflected and accurately documented. They are also responsible for making sure that any new document template, such as a Microsoft Office Word document template that is used to store the results of a design review meetings, are appropriately integrated into the Visual Studio Team System process template definitions.
During the execution phase of the project, Chase decides to track the project by using Visual Studio Team System. All work specified in the process improvement planning document is represented as work items within Visual Studio Team System. Chase also instructs the team to store all related process improvement documentation and templates in the project portal running under Windows SharePoint Services. The default reports that are included with Visual Studio Team System also provide an easy way to communicate project status with Humongous Insurance management.
At the end of the first execution phase of process improvement at Humongous Insurance, the results of process improvement have begun to become apparent through all aspects of the organization. For the first time, Humongous Insurance now is able to understand their software development processes starting from requirements received from customers and spanning the whole development life cycle reaching into operations and support. They have seen decreases in defect rates, higher-quality budgeting and estimating, and most important, greater customer satisfaction. The staff members, starting with those directly involved with the process improvement project, now seem energized and enthusiastic and ultimately proud of their accomplishments after being empowered to embrace the responsibility of improving their roles in the organization.
At project completion, twelve months after they began, Chase calls a project review meeting with the project team in addition to Humongous Insurance management. During this meeting, the team reflects on the previous twelve months and tries to determine how they could improve the overall process for the future. Chase also asks the management team to discuss the effect of process improvement across the organization and compare the results with what they expected. Chase and management work together to set the focus of the next cycle of process improvement and once again provide confirmation of the constraints that will have to be followed during the next cycle. At the end of the review meeting, Chase schedules the next series of assessment and planning workshops that will guide the next cycle of process improvement.