This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: The New Practice Didn't Help
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog.
The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
Obligatory legalese: The Following text is Copyright 2005 The Pragmatic Programmers LLC. All rights reserved.
The New Practice Didn't Help
We've talked all through this book about "standing on the shoulders of
giants." The best way to do that is to learn the practices that the giants
are using and use them yourself. There's always room for improvement
in any software shop, so always be on the lookout for better practices
that will provide that improvement.
When Not to Introduce a Practice
It seems strange to start here, doesn't it? But many shops add new
practices and process when they're not necessary or at a bad time
when they'll be disruptive to critical work. They end up causing more
problems than they solve. The first question you should ask yourself
whenever you're thinking about adding any practice should be, "Is now
a good time to do it?"
Don't try to introduce a new practice or process if there isn't a problem
that needs fixing. Never introduce a change because it's "the right thing
to do." Instead, identify the actual problems in your shop, and then
figure out how to fix them. Before you know it, you'll have a smoothly
running shop because you've fixed only what's broken.
TIP: Only fix what needs fixing
Be creative when thinking about problems and fixes. "There's more
than one way to do it" (The Perl mantra, noted at the bottom of the Perl man page) applies to more than just Perl programs! There
are lots of ways to successfully run a software shop. No set of practices
and no process will always work for every team on every project.
You also need to think about what else is going on in your shop before
you introduce a new practice. Three days before a major release is
probably not a good time to change your current process. Your team
will probably not take kindly to any distractions when they're frantically
trying to get the product out the door. A much better time would
be a week or so after the product ships, so the team can "catch their
breath" before considering the change. So choose a time to introduce
the practice that will minimize disruptions to critical activities.
TIP: Disruptive "best practices" aren't
And of course, make sure the practice or process you're considering
will actually improve things. If it won't make things run faster and
more efficiently, your team won't (and shouldn't!) adopt it. As far as
they're concerned, "If it lets me go home at 5 p.m., I'll do it."
How to Introduce a New Practice
Once you've decided to add a new practice to your repertoire, how do
you go about doing it effectively? There are two main things you've got
to do: demonstrate and persuade. Accomplish these two goals, and
you'll have a group of raving fans in no time.
You've got to get buy-in from several groups of people. First and foremost
are the people who will actually be practicing the new practice,
namely, your team. If they aren't excited about it, it won't matter if
anyone else is. How many stories have you heard about companies
that have mandated from the top down new ways of doing things? And
how many of these mandates have produced lasting change for the better?
(Answer: not many. Think Total Quality Management, ISO-9000,
and the like.)
Conversely, how many times have you heard about technologies and
practices that have been brought in at the grassroots level, which then
sweep through a group, company, or even industry like wildfire? (Think
UNIX vs. mainframes, PCs vs. UNIX, agile development vs. the Waterfall
software development model.)
TIP: Innovate from the bottom up
So how do get your team excited about this new idea? Remember we
talked earlier about demonstrating? Show them the process or tool;
don't just tell them about it. In particular, show them how well it works,
especially in comparison with the old way of doing things.
If you know a "raving fan" who has actually used this practice to good
effect, bring them in and have them show the group how well it has
worked for them. Even better, use it yourself. Build up evidence about
how much more productive and efficient you are, and then tell your
team about it. You probably won't have to do much talking because the
team has probably already noticed how much better you're doing! The
key is to prove that this new-fangled idea is everything you say it is.
TIP: Show, don't just tell
Persuading your team to use this new practice is critical. That's not to
say that you can completely ignore your management, however. Getting
buy-in from your manager makes introducing a practice easier. Your
manager can persuade those team members on the fence about the idea
to give it a try and can act as a shield from the rest of the company.
Such shielding can give your group time to figure out the best way to
implement the practice. And obviously, it's easier to work out a change
in your group when you don't have to hide what you're doing.
If you can't get management buy-in, don't let that dissuade you from
adopting a practice, especially if the team is excited about it. Treat
it like a "stealth practice," and use it quietly but fully. Practices like
code reviews don't require management buy-in to be effective. You can
use them without anyone outside your team being aware that you are
having code reviews. You can set up a CI system on your own box and
share the results with your team. After you've gotten some experience
with the practice, show the practice, along with the associated benefits,
to management.
Previous Topic
