Top Five Ways to Transform Your Organization
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
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.