Page 226 -

programming manager in your organization is on board with the improvements, he can
pitch an improvement as a technical change instead of a more general, far-reaching process
change. Once the programmers start demanding changes, they usually get their way.
There are a lot of project problems that the team is very aware of. When the scope creeps,
the programmers have to tear down code they previously built and replace it with code
that is patched together and not built as well as they would like. The programmers would
much rather fix a bug before a client sees it. Poorly defined requirements lead to changes
and frustration. All of these problems are exactly the ones that you are trying to fix.
Show the team that you are working to help them. For example, using Wideband Delphi
estimation and building a project schedule may seem needlessly “bureaucratic” to them—
until you show them how it will help them avoid working overtime later on in the project.
By showing that there are clear benefits to what you are doing or suggesting, you can
avoid some of the knee-jerk reactions from your team against your changes, and instead
get them on board.

Show that the changes will save time and effort
When someone talks about a change adding too much bureaucracy, what she usually
means is that it takes time and effort that she is not used to spending. This is where an
explicit justification is necessary. That justification is not about showing them charts,
graphs, or numbers; rather, your goal should be to show how you are working to reduce
the overall effort required for the team to build the software.
People do not want to come to meetings unless those meetings are proven to work. You
need to convince them that for every hour they spend in a meeting, they are shaving off at
least an hour at the end of the project. It’s not hard to make an intuitive case for this, as
long as you tailor it to each individual person that you are talking to. Explain the impact of
the problems on each person’s work, and show how the tool will reduce that impact.

For example, if a technical support manager is balking at attending inspection meetings,
point out that you are trying to get more defects out of the software so she’ll have to deal
with fewer support calls about them. Programmers are often concerned with scope creep

because it requires tedious and unnecessary rework; show them how a vision and scope
document or use cases will help to reduce the time spent on rework.

Work around stragglers
There are some people who simply cannot be convinced that a change is worthwhile.
They resent being given any extra work. They may even be against the entire project for
entirely selfish reasons. For example, it’s not unheard of for a programmer who is highly
skilled with a particular platform or technology to sabotage efforts to migrate the software
to an entirely different platform, simply to protect his expertise. Some stragglers don’t
even look like stragglers—they may be “heroes” who are used to waiting until there is an
emergency before jumping in and saving the day. But whatever the reason, if someone is
firmly against your changes, you are not going to be able to bring them on board—at least
not by yourself and not now.
218 CHAPTER NINE