Don Gray explains why software development teams need three common goals: long term, mid term, and short term. These goals focus a team and provide the glue that holds the team together.
"If you don't know where you are going, you probably won’t get there."–Yogi Berra
The pager tones sounded at 2 a.m. "Squad 86, car accident with personal injuries on Highway 268 west of Pilot Mountain." I don’t know how much research went into deciding how loud the tones should be, but when they sound, they can wake anyone from sleep. I quickly calculated that the accident was less than a half-mile from my house. I climbed into my turn-out gear, got into my car, and off I went. I found the first patient sitting on the side of the road. Talking with him revealed another victim, somewhere on a side road. Other squad members arrived. I could hear the ambulance siren headed our way. Their goals were simple: Find the patients, stabilize their injuries, and send them to definitive care.
Similarly, software development teams need three common goals: long term, mid term, and short term. These goals focus a team and provide the glue that holds the team together. They answer the basic question "Why am I here?" Knowing why the team has been brought together provides purpose and identity. These goals are the project goal, sprint goal, and daily goal.
Project Goals
Project goals provide the overall direction and answer the questions "Which part of the corporate mission statement does the project I’m working on support?" and "What business goal does this completed project meet?" Time for these goals ranges from several months to years. Suppose your company has a strategic goal to increase their product offerings. After some research, the managers decide to create an application that uses a camera to track the user’s eyes and automatically move the cursor based on eye movement. The project charter should connect to the "increase product offerings" strategic goal. Using the project goals developers can connect today’s work with the company’s strategic goals. Since long term goals take months to years, we need interim goals to track how we’re doing.
Sprint Goals
Sprint goals act as the checkpoints along the project's path. These checkpoints answer the questions "How are we doing toward meeting the long-term goal?" and "Are we done yet?" Sprint goal time spans should be between two to four weeks. Having sprint goals allows the team to verify progress as they deliver working software. Additionally, these checkpoints allow the team to make corrections if they misunderstood the functionality required for the mid-term goal. An example sprint goal for the eye tracking application might be to find and activate the computer camera. The developers can check their daily activities against this goal. If they can't tie what they’re doing to the sprint goal, they should ask "Why am I doing this?"
Daily Goals
Daily goals focus on the implementation question “Who does what, when, and where?” These tasked oriented goals have a time span of a few hours to a couple of days at most. This enables the developers to make visible progress toward the sprint goal. Problems meeting the short-term goals can bring a team together by providing an opportunity to cooperate by swarming to overcome the problem. Completing task goals indicates if the sprint goal will be met.
Hitting the sprint goal of "finding and activating the computer camera" might include:
- Query the OS for Devices
- Determine which devices are cameras
- Locate drivers for those devices
- Enable the drivers
- Turn on the camera
These tasks may be further sub-divided. Not completing these task goals puts the sprint goal in jeopardy, which in turn impacts the project goal.
How Unaligned Goals Impact Your Bottom Line
"Never attribute to malice or stupidity that which can be explained by moderately rational individuals following incentives in a complex system of interactions." Hubbard’s Corollary to Hanlon’s Razor
I recently visited a team I worked with to see how they were doing. In an effort to get control of feature creep, the IT department directors instituted an "analysis/design" phase just after I left the project. This phase resulted in the creation of a design packet containing all the information the team would need to develop the software. If the team had questions, they could ask the systems analysts for clarification. This decision did remove change requests from the client (another business unit in the company). It also disconnected the team from getting more information about the client's goals.
When the client representatives began user acceptance tests, they refused to accept the software until changes were made. The team worked on the changes and delivered the software six weeks late. While six weeks doesn’t seem terrible, let’s take a look at the costs associated with the schedule slip.
Failure Demand
Software teams' productivity falls in two basic categories: value demand and failure demand. When the team started the project, they spent their time on value demand and created value for the client. As the project got closer to completion, the team delivered completed functionality to the external QAT testers. When the testers sent defects to the team, the team shifted to a combination of value demand (creating new features) and failure demand (correcting defects). In the final six weeks, beyond the original twelve-week schedule, the team spent 100 percent of their time doing failure demand work. I don’t know what the loaded cost for the seven team members was, but it was a cost that could have been avoided if the IT directors had the same goal as the client.
Lost Opportunity
For the six additional weeks the team worked on this project, they could not add the next project to the queue. This meant that the potential revenue and benefits for the next project could not be realized as anticipated. Making matters slightly worse, the six-week shuffle affected delivery of the next project because major deployments to production occurred quarterly and delivery for the new project didn't happen until the next drop window.
Confidence
We can assign a reasonably accurate number to the six weeks of failure demand. Using the calculations that justified the next project, we can anticipate how much the lost opportunity cost. We can't assign a value to the loss in confidence the client organization now has in the ability of the IT department to deliver on its commitments.
From the Top Down
Here’s what to do to make sure your project, sprint, and daily goals align:
Project Goals—Charter And Vision
Check your project charter. In what way does the charter support a major strategic goal for your company? If you can’t find a charter for your project, create one and share with your boss and your boss's boss. Tying your project to a strategic corporate goal, such as "Increasing Market Share" or "Expanding Current Product Lines" provides the long-term goal teams need for framing their activities.
With a project charter that supports a strategic goal, you can then examine the product’s vision statement. The product vision also provides a touchstone for the team to use as they work. If you don't have a product vision, you might consider using Jim Highsmith’s information on product vision to create one. If you create a product vision, be sure to include those who will use the product. The problem I experience most often with charters and visions isn’t that they don’t exist; it’s that they rarely make it to the team level.
Sprint Goals—What We’re Doing
Now that you have a project charter and know the product vision, you can create a Product Backlog to fulfill the vision. The Product Backlog contains the information from the user’s viewpoint showing what the software must do to fulfill the vision. This information often takes the form of a User Story: As a [type of user], I would like [some functionality], so that I may [receive value].
The team selects work for the Sprint Backlog from the Product Backlog. The team and Product Owner (or customer proxy) then define the sprint goal, which is a short description of what the team plans to achieve during the sprint.
Daily Goals—Will We Get There?
The Sprint Project Goals keep the team’s efforts aligned with the company's strategic goals. Daily goals show the progress we’re making towards completing the work.
Tracking daily goals starts with team members answering three questions:
- What I have accomplished since our last meeting?
- What will I accomplish before we meet again?
- What is getting in my way of getting things done?
When a team member has a problem, other team members can help them. If an impediment gets in the team’s way, they can raise awareness about the impediment and get it removed.
Tracking the daily goals also shows progress to other people who might be interested in the project.
All’s Well that Ends Well
We finally located the second patient a mile down a side road. When the ambulances arrived we loaded the patients and helped the paramedics start the necessary intervention based protocols. Our goals allowed us to focus on achieving a positive outcome for the patients.
Having clear connections between the project’s goal, the sprint's goals and the daily goals keeps the team’s efforts focused on helping the business. When the goals get disconnected, problems can creep in, adding time, cost, and extra effort to achieving the original goals. If you’re not sure the project, sprint, and daily goals align, check the project charter/vision, sprint goal, and daily progress.
