Over a million developers have joined DZone.

Top Five Ways to Transform Your Organization

DZone's Guide to

Top Five Ways to Transform Your Organization

· Agile Zone ·
Free Resource

You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang

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 communications.

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.

Download the free agile tools checklist from 321 Gang. This guide will help you choose the right agile tools to position your team for success. 


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}