Read an Excerpt
Professional Scrum with Team Foundation Server 2010
By Steve Resnick Aaron Bjork Michael de la Maza
John Wiley & SonsCopyright © 2011 John Wiley & Sons, Ltd
All right reserved.
Chapter OneShipping Software
WHAT'S IN THIS CHAPTER?
* Understanding what you need to ship software: vision, insight, resources, planning, and product features.
* Understanding three approaches to management methodologies: Scrum, MSF, and Waterfall.
* Comparing the three project management methodologies.
This chapter covers the high-level process of shipping software. You'll learn how to start with a compelling vision and the resources you need to build a product. You'll also learn about the relationship among competing constraints. You'll read about three popular software project management techniques: Scrum, Microsoft Solutions Framework (MSF), and Waterfall. By the end of this chapter, you'll be able to use what you know about the MSF and Waterfall methods to gain insight into Scrum.
This book is about using a specific tool, Visual Studio Team Foundation Server (TFS), to support the Scrum process for shipping great software. The fundamental concept is to put customer value at the center of everything you do. While maximizing customer value, you also maximize your team's productivity and predictability with each release, creating a sustainable team environment for shipping great software. In this book, you'll learn how to use the tools in TFS to manage a software development project using Scrum.
WHAT DO YOU NEED TO SHIP SOFTWARE?
Before you can ship great software, you need to build it. Before you can build it, you need to envision how it might work and look. Before you can envision it, you need to know why and how someone would use it. And before that, you need insight into the problem you're trying to solve. So, shipping great software really begins with vision and insight into how something works, how it can be improved, and why people care.
This section discusses the following requirements for shipping software:
* Product features
Great software starts with a great vision. It starts with a simple description of what you're setting out to build, for whom, and why. If you can't define this before starting the project, you should think about it some more. Creating software requires a surprising amount of resources, and you need to have a compelling vision in order to attract and allocate the resources you'll need.
The vision should be a meaningful description of the product goals and an inspiring outcome. It doesn't need to be melodramatic — helping the world's neediest people or creating the world's newest billionaire — but it must resonate with all stakeholders. The vision should describe the needs and benefits in terms that the user cares about. It should describe the problem being solved and the opportunity in solving it. The vision should pique the interest of customers, sponsors, and the project team.
The product vision should be relatively short; a few paragraphs generally suffice. It should include a description of the problem and opportunity as well as the solution and the benefit. Everyone on the project team will read it. They will talk to their colleagues, friends, and families about it. It should be clear yet comprehensive enough to resonate with these audiences.
The product vision is typically accompanied by a definition of scope. The scope clearly sets the path for the vision, from problem to solution. It should include high-level features, time lines, and constraints. You can define the scope of a prototype, a beta, and the first few releases. Earlier milestones should have greater granularity; later milestones can be more vague. The scope should clearly define what is being proposed and what is not being proposed.
Often, the vision and scope are combined into a single document, cleverly called a vision/scope. This document is the first opportunity to define a series of releases. Thinking and communicating in terms of successive releases is critical with Scrum. You can define the rough features that will be in each release, so everyone learns to expect incremental progress as the team iterates toward the solution.
For example, say you enjoy fantasy football, a game in which you create virtual football teams that compete based on the statistics of the individual players. The fantasy football sites have great features for building teams and leagues, but they don't combine that with great search capabilities. Using Google or Bing for searching just doesn't give you the data you want. In a moment of inspiration, you decide to fix the problem by building a search engine for this purpose. You could create the following vision for this product:
Create a search engine for fantasy sports enthusiasts.
Based on your vision, the reader will conjure up ideas about what the product may do. It's a good start, but this vision, as stated, is much broader than your intent. Your idea involved fantasy football, and the vision you've created could be interpreted much more broadly. Therefore, you might rewrite the vision as follows:
Many websites are available for fantasy football leagues. They have great features but lack powerful search capabilities. We will create a fantasy football search engine so that fans have access to more data and can create the best teams.
This is better, as it constrains the problem to what you initially had in mind — fantasy football. It also adds a purpose: creating the best teams. Now you need to scope the problem. You want to solve the problem for fantasy football, but you also realize that the solution would work just as well with other sports. So you can broaden the vision and then constrain it with the scope:
Many websites are available for fantasy sports leagues. They have great features but lack powerful search capabilities. We will create a fantasy sports search engine so that fans have access to more data and can create the best teams.
The immediate market for fantasy sports is 50 dedicated websites, reaching over 3 million users. The indirect market, including news and sports sites, is approximately 500 sites that reach over 20 million people.
The first release will target American football and provide an interface for existing websites. It will contain data for all NFL teams and will support parametric searches on player characteristics. Subsequent releases will add more sports leagues; will support features for managing teams, players, standings, and trading; and will have an interface for mobile apps.
From this vision/scope, the reader will have an idea of the problem being solved, the benefit of the solution, and the iterative path for expanding the product over time. After this, you can define a business case, technical solution concept, and critical assumptions.
There are many examples of vision/scope documents online. They commonly have sections for vision, requirements, solution, assumptions, limitations, and risks. While Scrum doesn't prescribe a vision/scope document prior to initiating a project, it's a best practice to create one in software project management as it forces you to articulate the big picture.
It's one thing to have a great vision; it's quite another to turn that vision into a great product. This is true of engineering in general and software engineering in particular. Product management has a broad role in engineering and design. It involves translating the needs and desires of the user or market into instructions for engineering. (We use the term instructions very loosely here, as it may take the form of requirements, storyboards, user stories, mockups, visual comps, or other design artifacts.)
As you'll read in Chapter 2, product management is an essential element of Scrum. Say that you're working with a highly skilled, cohesive, experienced engineering team. And say that the working environment allows the team to flourish. This is a great start, but it's insufficient to build a successful product. In this case, the success of the product depends on product management. Specifically, it depends on product management to determine what's needed, by whom, why, and at what cost.
The product owner, who fills the product management role in Scrum, is embedded in the Scrum team and is counted on to know the user intimately. This person must know the user's likes and dislikes, tolerances, and aspirations. The product owner must know what the users love, what they don't like, and what they don't care about. Essentially, the product owner must have insight into how the user will value the product.
As you'll read further in this chapter and Chapters 2 and 3, Scrum is an Agile process for developing software. It prescribes planning and design up front, and it involves more planning and design as you iteratively build the solution. It's far from random and far from chaotic, but it does move fast and allows for unexpected results. Because of this, the product owner's insight into user needs is essential.
Several factors drive the need for insight in the product owner role in Scrum:
* Decision making — One person, rather than a group, makes product management decisions. Decisions are made faster than in traditional software creation, but if the product owner lacks sufficient insight into the problem, he or she will make wrong decisions or lack confidence to make any decisions at all.
* Minimal prototyping — There is minimal prototyping before the project starts because it's done in early sprints of the project. This means the product owner's insight will quickly be reflected in the product.
* Iterative nature — The product features are defined iteratively and frequently. They come in and out of scope based on product owner decisions, which directly impact the value of the product.
* Customer feedback — Customer feedback comes early and often. Good insight is necessary to sift out valuable data from extraneous data.
Building a software product is a very resource-intensive activity. It requires people from many different disciplines working together toward a common goal. These people include visual designers, domain experts, software developers, and product managers. Depending on the domain, building software may also require business analysts, security experts, information architects, and marketing specialists.
It's easy to underestimate the true cost of building production-quality software. When you wrote your first computer program, it was pretty easy: You were the designer, developer, tester, and possibly customer. Indeed, it was a lot of fun, and that's how many of us got hooked on creating software.
Building a commercial product is much more difficult than creating software for yourself. You need to clearly understand what the customer wants before you can start building. You need to know how much the customer is willing to spend before you begin to buy technology or hire the team for the job. Whether you're building something for just one customer or thousands, the work requires significantly more resources than building something for your own use.
As you'll see later in this chapter when we compare different strategies for software project management, Scrum optimizes resources by iterating toward a solution. This enables you to adjust your plans along the way, based on the realities you encounter with technology, the team, and customers.
Time and Money
You need many resources to build and ship a great software product. At the highest level, you need time and money. To be sure, these are not interchangeable, no matter how much you have of either.
The saying "Timing is everything" holds quite true in software development. A perfect product released at the wrong time is generally not very useful. It may be interesting or thought provoking, and it may even be amusing, but if the timing is wrong, the product won't be useful. Similarly, the wrong product at the right time isn't very useful either. It may garner a lot of attention because of its potential, but if the product is lacking some critical element, it won't be very successful. On the other hand, the right product at the right time is very valuable: Even if it has flaws, if you release the right product at the right time, you'll have a success on your hands.
People and Technology
Unlike time, money can easily be converted to other resources you might need. Two obvious resources you need for software development are people and equipment.
For people, you'll likely want a mix of generalists and specialists. You'll need product managers to define the feature set that exactly meets your client's needs. You'll need software architects to stay with the project from beginning to end and to define the technical architecture and design patterns for the product. You may need user interface specialists, database specialists, security experts, and performance-tuning engineers. The bulk of the technical work will likely be done by generalists: engineers skilled in coding and testing.
If your project needs a high percentage of specialists rather than generalists, you might want to increase your time and cost estimates. Finding and replacing specialists can be a more time-consuming and costly activity than swapping generalists.
You can convert money into people by hiring a team. Some team members will be employees — people you want to retain for the duration of the project and beyond. Others will be contractors — people with specialized skills that you need during certain phases of the project.
You'll also need to convert money into technology. You can buy it, lease it, or rent it for remote access. This is true for both hardware and software. You can allocate technology to problems as they arise and then shift resources (such as money) as circumstances change. For instance, you may need significant hardware capacity during a performance-testing phase of a project. In this case, you can acquire the technology on a temporary basis and then shift it elsewhere when you're done.
Planning is an essential ingredient in shipping great software. Planning takes a great deal of time before a project begins and even more time once a project is under way. This is true whether you're using Scrum or another project management methodology. Depending on which methodology you use, the specific planning activities will vary dramatically.
For instance, planning a project using a traditional software development methodology involves allocating time for requirements definition, design, development, testing, user acceptance, release management, and support. Software development occurs solely during the development phase. Planning a project using Scrum involves allocating time to build features in fixed-duration "sprints." During each sprint, the team conducts the same activities as in the Waterfall method, but it does so in a small set of features. Figure 1-1 shows a high-level view of Waterfall and Scrum planning.
The Waterfall method of project management is the method most commonly used to run software projects. When using the Waterfall method, you schedule tasks sequentially, completing one phase of activity before beginning the next. Later in the chapter, in the "Approaches to Project Management" section, we'll look more closely at the Waterfall method and compare it with Scrum.
One place where Scrum is different from traditional software project management methodologies (such as the Waterfall method) is with respect to predictability. Waterfall assumes that you can predict how long tasks will take. You allocate people and time to tasks and then schedule them accordingly. Scrum assumes the opposite. You cannot accurately predict how long something will take unless you've done it with the same resources (technology and people) before.
If you cannot predict how long a single task will take, how can you predict how long a whole series of tasks will take? Using Scrum, you accept the fact that you can't. Rather than predict the product schedule, you predict smaller units of work that can be completed within a sprint. At the end of each sprint, features are complete and can be included in a potentially shippable product. This way, you predict features by time rather than predicting time by features, which is essentially a time-box approach.
A sprint is the smallest cycle time within Scrum. Chapter 9 focuses on running sprints. Sprints can be as long as a month or two and as short as a day or two. The ScrumMaster decides the duration before the sprint begins. Each sprint starts with a sprint planning meeting, during which the team looks at the product backlog and decides which features to build during the sprint. The team members use their experience in the previous sprint(s) to predict how much they can accomplish in the next sprint. This is significantly different from the Waterfall method, which involves predicting the release and features up front and allocating time and people to the tasks.
Excerpted from Professional Scrum with Team Foundation Server 2010 by Steve Resnick Aaron Bjork Michael de la Maza Copyright © 2011 by John Wiley & Sons, Ltd. Excerpted by permission of John Wiley & Sons. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.