Agile Zone is brought to you in partnership with:

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

Top Five Ways to Transform Your Organization

03.11.2011
| 1066 views |
  • submit to reddit
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.
References
Published at DZone with permission of its author, Jared Richardson. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Milos Solujic replied on Mon, 2011/03/14 - 9:22am

Jared,

you picked really bold headline for CI+DDT+TDD+Sprint+Communication. 

Altough I like wery much your last point, because Communication was really key for success on most of projects I've participated so far.

Also, I would like to recommend Hudson + Sonar for CI/code quallity.

Jared Richardson replied on Tue, 2011/03/15 - 11:10am in response to: Milos Solujic

Hi Milos,

It was a bold title, but chosen on purpose. I believe few companies understand how much these technologies can change the way they do business.

And I agree. Hudson and Sonar make a great combination. A little Cobertura (http://cobertura.sourceforge.net/) never hurt anyone either. ;)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.