10 Signs That You're Not Agile

December 24, 2007 by Jeremy Weiskotten

Since most readers of this blog are likely to be practicing or budding Agilists, replace "you" with "your coworkers" or "your manager" as appropriate.

1. You haven't seen or spoken to a coworker about work for at least a day.

Even remote team members should be in contact on a daily basis for Scrum/stand-up meetings and throughout the day over the phone/Skype/IM/email. On-site, co-located teams really have no excuse to work in isolation.

2. You email a status report to your manager, attend weekly 1-2 hour status meetings, and you and your coworkers still have no idea what each other is doing.

Often a consequence of #1. Scrum is a good way to report status efficiently, facilitate face-to-face communication, and make commitments to each other rather than management.

3. You can't remember when the last build passed without manual intervention.

This happens if you're not doing continuous integration on a clean (not a developer's) machine at a minimum of once a day, but preferably whenever someone checks code in to source control. You are using source control, right?

4. You write a 30-page specification (which the customer signs off on) and still don't build the right thing.

Good old Waterfall, Big Design Up Front, and Cover Your A**. Instead, favor open, continuous communication with the customer or her representative, including continuous release/demonstration and feedback. This allows you to adapt to changing, or simply miscommunicated, requirements.

5. You think unit testing is QA's job.

It's really amazing how many developers, including (especially?) senior-level developers, haven't grokked the benefits of unit testing. Somehow any practice with the word "testing" in its name is up to QA to figure out, if you're lucky enough to have a good QA department and process. Unit testing is a "white-box" (or glass-box if you prefer) test — leverage your knowledge of the implementation to fully exercise the code under test. QA typically operates at the black-box level, without understanding the fine-grained implementation details, like a user.

6. You think quality is QA's responsibility.

Sounds like #5, but a bit different. Everyone is responsible for quality, especially developers. The sooner a bug is found, the cheaper it is to fix.

7. Your project schedule contains 18 months worth of fine-grained tasks, but no one knows who estimated the work. (Or the person who made the estimates isn't doing the work.)

No one knows for sure how long it will take to design, implement, and integrate a software component. But the person who is designing, implementing, and integrating it should be able to make the best guess and will have more incentive to produce accurate estimates.

8. Your architect doesn't write code very often, and that's probably a good thing. Have you seen his code?!

A lot of architects are great. I've worked with a few that were hands-on and knew their stuff. They knew the environment, languages, libraries, and legacy code as well or better than most of the developers. But architects who don't get their hands dirty can be dangerous, especially if they opt not to consult with their lead developers on important design considerations.

9. Every time you make a relatively small change, it takes days or even weeks to integrate and regression test.

Without continuous integration, a good test suite, and solid design, touching even the seemingly most innocuous line of code is a risk to distant, often unknown, relatives than depend on the behavior of that code.

10. You're not allowed to refactor. We're shipping in 3 months and refactoring is too risky!

Definitely related to #9, but that word "refactor" is especially scary to some, especially if you don't have a good test suite for a safety net. It's also scary if your team doesn't understand what refactoring is, and uses it to describe massive redesign — management is once-bitten-twice-shy when it comes to that sort of thing.

Permalink