Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile
The really hard part of changing an organization is
changing the people, and that's not something I can tell you how to do
in a blog post. However, I can tell you about five great practices that
will boost your team's productivity, increase quality, and improve
First, use continuous integration.
It's a very simple tool with an enormous impact. A CI tool compiles
source code after every check in, then runs every available automated
test. This means that a developer who checks in code knows as soon as
possible whether they've missed a file (oops!), or whether they've
broken a test in another area. This type of rapid feedback means that
your developers fix their own bugs, and learn from them, instead of
having some poor dupe fix all the problems once a week. (See Jenkins for a good CI server.)
Second, require Defect Driven Testing
(DDT). How often do you find bugs? Fairly often if your shop is
typical. How often do you write automated tests? Infrequently, if your
shop is typical. :) Instead you put in a large number of prints, or you
step through the debugger for hours. And next week, when you find anther
bug in the same area, you'll do it again. Instead, write a JUnit or
Nunit test. It's simple, it's easy, and when the bug comes back, your CI
system will flag it in seconds, saving you hours of debugging.
Thirdly, stop allowing groups to ask for features using Word docs.
English (or any other written language) is very bad way to say something
precisely. That's why lawyers make so much money trying to make it
precise, then other lawyers always seem to manage to find loopholes.
Instead, write simple tests. The automated tests we mentioned before
aren't always unit tests. (In fact, they usually aren't!) If you ask for
a new API, write a test showing how it'll be used. Need a new feature
on the database API? Add a test. When the test passes, it's done. This
is called executable documentation and it's an incredible communication
tool. Use it between teams that are co-located, but especially when
they're not. (Cucumber is a great tool for readable executable docs.)
Fourthly, use time-boxed iterations. Work for a month, or a week, and
then stop. When you time box your work, it forces you to break down your
work into more manageable amounts. We developers tend to be optimists
and quite often (okay, ~always~) take on more work than we can complete
on time. A time box lets us say "Done" or "Not done" in a very short
amount of time. We get trained on breaking down our work, and our
managers (or customers) gets to re-evaluate the work every so often and
say "I wanted that feature when it was going to cost two iterations, but
now that it's costing me 12, I don't want it this bad! Drop it out."
Finally, get developers talking with your customers. The perspective
this interaction brings changes the way your team writes features, and
it changes the way your customer sees your development shop. Both sides
stop seeing stereotypes and start seeing real people.
There's a lot more you can do to change a shop, but these five tips will start you moving in the right direction.