Can your dev team handle Agile/iterative development?

This post was originally published here.

Too often development teams or organizations push straight into an Agile/iterative process like Scrum without considering the implications of iterative development.  Iterative development forces regular feedback and regular deliveries, but how do we know if the dev team is able to handle feedback and deliver more often?  If any of these criteria match your team, then you are going to have some major challenges adopting an Agile process:

• Testability is not the top design concern
  • Unit tests are optional or non-existent
    • Builds happen less often than once a day
      • Deployments to test environments happen even less often, if at all
        • “Quick and Dirty” is your team’s motto
          • Refactoring is considered taboo and dismissed as “over-engineering”
            • Email is the primary method of communication between team members
              • You don’t see the person giving you requirements for weeks or months at a time
                • You don’t see the testers until just before releasing</ul> Feedback isn’t useful if your team or application can’t act on that feedback.  Without solid engineering practices in place, adopting an iterative process will likely end in disaster, as the application wasn’t built to accept changes and feedback on a regular basis.