Sometimes the only way to get a fire under control is to call in the smokejumpers. These specially trained firefighters parachute into a region to take on a blaze and contain it before any more damage is done. Some software development projects have smokejumpers, too. These professionals enter struggling projects midstream, assess the situation, and hopefully lead the team to a successful outcome.
Do you know about smokejumpers? They're brave, self-sufficient firefighters who parachute into remote areas wearing eighty pounds of gear and ready to fight a forest fire. If the jump goes well, they land safely. After extinguishing the fire, they may have a ten-mile hike out. It's not a job for the faint of heart, slow of mind, or weak of back.
Have you considered that you may be a smokejumper? Think about it: Many of you join software projects midstream because sometimes a project needs additional contributors—some add brains, others brawn. Sometimes mentors are needed to improve project performance. Sometimes management needs an outsider's view of the project status.
Have you considered that you may be a smokejumper? Think about it: Many of you join software projects midstream because sometimes a project needs additional contributors—some add brains, others brawn. Sometimes mentors are needed to improve project performance. Sometimes management needs an outsider's view of the project status.
No matter why you join a project after it begins, you will encounter challenges. To be successful you must:
- Determine your role
- Build trust
- Learn the territory
- Gather information
- Do your job
- Declare victory
Determine Your Role
"If you don't know where you are going, you'll probably end up somewhere else." — Laurence J. Peter
Smokejumpers work on well-defined teams. Everyone has a job to do and knows how to do it. Before jumping into a project you should determine your role. Ask:
- What specifically is my sponsor asking me to do?
- How can I demonstrate to my sponsor that I have been successful?
- What will my relationship be with others on the project?
Knowing what my sponsor wants keeps me focused. Difficulties arise when the sponsor has trouble explaining the problem. He knows the project is late and he wants better quality, but he can’t say exactly why the project is late or what’s creating sub-standard quality. Generally, the greater the pain (lateness, poor quality), the less articulate about the problem the sponsor becomes. When this happens, I like to use the SMART acronym Johanna Rothman describes in "Release Criteria: Is This Software Done?" (STQE magazine, March/April, 2002). SMART reminds me to get a problem definition that is: specific, measurable, attainable, relevant, and trackable.
Next, I need to know what “done” means. Knowing how I'm going to demonstrate "done" gives me information on what to track so I can provide my sponsor the information needed to prove the fire is out. A good question to ask is "What will you see, hear, and feel when this problem is solved?"
I often use a simple reporting format when I check in with the people for whom I'm working. I describe what we've done since our last discussion, what we're currently working on, and any barriers to progress we're encountering.
Last, but not least, I need to know who I will be working with and in what capacity. Based on what I'm being asked to do (brawn, brains, mentor, or project review), I'm going to relate to the team in different ways. I may be a coworker, a coach, or an investigator. Knowing which role I'll be in guides me as I work on getting a demonstrable "done."
Currently, I'm working with a client whose staff has been trying to solve a problem for a month. In our kick-off meeting, we established that my job was to get the project "done," and they don't care how. On this project, “done” means all the applications have been switched to the new server and tested and the old server decommissioned. I'm going to function primarily in
| Attachment | Size |
|---|---|
 Skills for Software Smokejumpers | 674.62 KB |
About the author
Don Gray’s goal to answer “What is the earliest indicator for a project’s status?” has led him to focus on such diverse topics as communication, personality types, team styles, systems thinking and human systems dynamics. Don’s varied interests and client experience provides a platform for helping clients introduce and work through change as they transition to agile development practices. His blog can be found at www.donaldegray.com. Don helped create and co-Hosts the AYE Conference.
