“If you don’t know where you are going, you probably won’t get there.“ Yogi Berra
The pager tones sounded at 2 AM. It blared “Squad 86, car accident with personal injuries on Highway 268 west of Pilot Mountain.” I don’t know how much research went into the tones, but when they sound, they can wake anyone from sleep. I quickly calculated that was less than a half mile from my house. I climbed into my turn-out gear and into my car. Off I went! I found the first patient sitting on the road side. Talking with him revealed another victim, somewhere on a side road. Other squad members started arriving. I could hear the ambulance siren headed our way. The goals were simple. Find the patients, stabilize their injuries, and send them to definitive care.
Software development teams need common goals. These goals create focus and form the glue that holds teams together. They answer the basic question, “Why am I here?” Knowing why the team has been brought together provides purpose and identity. Teams need three common goals; long term, mid term, and short term.
Long Ago, Right Now and in the Near Future
Long term 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 in long term goals ranges from several months to years. The long term goals provide direction to keep the team oriented during the mid term goals.
Mid term goals are check points along the project’s path. These check points answer the questions “How are we doing towards meeting the long term goal?” and “Are we done yet?” Mid term goal time spans should be between 2 – 4 weeks. Having mid term goals allows the team to verify progress as they deliver working software, not a report estimating completion. Additionally these checkpoints allow the team to make corrections if they misunderstood the functionality required for the mid-term goal. They also form the framework for the short term goals.
Short term goals focus the implementation questions: “Who does what, when and where?” Short term goals have a time span of a few hours to a couple of days at most. This keeps the development team making visible progress toward the mid term 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 short term goals provides an indication if the mid term goal will be met.
Some teams lose sight of the goals. One team I worked with had a clear business goal which had substantial profit for the company, but they were making glacial progress towards the goal. The details swamped their planning capacity. We created a burn up chart listing the major portions that needed to be completed then sub-divided those into short term tasks. The team met semi- weekly reviewing what had been completed, and what they were going to work on next. This permitted us to show progress to management and balanced the long/mid/short term focus.
If your team isn’t producing like you feel it should, check to see the members understand the business objective. A simple technique is to ask the question, “Why are we doing this project?” Ask each team member and compare the answers. If the answers don’t agree, there’s confusion about the business objective. Help the team understand how the project provides the value to your company. The same process can be used to clarify the mid-term goals if the team agrees on the business objective.
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 had 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 as I left the project. This phase resulted in a design packet that contained all the information the team would need. 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) … until the client representatives began their user acceptance tests. At that point the client organization refused to accept the software until changes were made. The team started working 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 – creating value for the client. As the project got close to completion, the team started delivering to the external QAT testers. When the testers sent defects to the team they shifted to a combination of value demand (creating new features) and failure demand (correcting defects). The final six weeks (beyond the 12 week original schedule) the team spent 100% of their time doing failure demand work. I don’t know what the loaded cost for the 7 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 this project, it could not start the next project queued. This means the potential revenue and benefits for the next project could not be realized as anticipated. Making matters slightly worse, the six week shuffle rippled into delivering the next project since 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 6 weeks of failure demand. Using the calculations that justified the next project, we can anticipate how much the lost opportunity cost. What we can’t assign a value to is the loss in confidence the client organization now has in the ability of the IT department to deliver on its commitments. But as I wander through and around clients, I hear cynicism and distrust abound when they discuss IT.
From the Top Down
So what steps can we take to make sure we have common goals, and what can we do if the goals don’t align?
Charter
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 provides the long term goal teams need for framing their activities.
Vision
With a project charter that supports a strategic goal, next look at the product’s vision statement. Teams with a compelling goal do better work. [1] 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 the information here http://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html to create one. Be sure to include those who will use the product if you find yourself creating a product vision.
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.
Backlog
Now that you have a project charter and know the product vision, you can create a product back- log to fulfill the vision.
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.
By keeping your organization, department and project goals aligned you can achieve success.
[1] Katzenbach & Smith The Wisdom of Teams and J. Richard Hackman Collaborative Intelligence
This article was published on techwell.com