I’ve had a Dilbert strip pinned to my wall for a few years that always brings a smile to my face. In it, the pointy-haired boss is talking to his “team” and says agile programming is, “… no more planning and no more documentation – just start writing code and complaining.” It’s funny because it’s true.
Don’t get me wrong, agile development is fantastic. For most organizations and for most projects, moving away from formal waterfall project methodology is a welcome relief. Companies no longer have the appetite nor patience for multi-year projects and project team members want to work on smaller deliverables to have a sense of accomplishment and to expand their experience with multiple technologies. However, agile has a dirty secret that is overlooked or ignored: it requires commitment and development best practices for success.
In a recent InfoWorld article titled, “What’s wrong with agile development“, culture and people topped the list of reasons for why agile initiatives fail. I agree with the results, however I would suggest that there is a broader misunderstanding of exactly what agile is that needs to be accounted for.
It has been my experience that agile methodologies produce smaller, but faster components and that teams who use agile methods are more nimble than those that do not. Being more nimble means they can more quickly shift focus to keep aligned with ever-changing business priorities.
Agile development does not mean little to no requirements and little to no testing. Somewhere along the line those who haven’t experienced agile for themselves have bought into they myth that agile essentially means a hallway conversation today results in a deliverable tomorrow. That is simply not the case. In addition to culture and people, agile requires well documented requirements, typically in the form of user stories, and good testing practices before production release.
I love PHB’s recommendation to “just start writing code” but without some rigor around the development process the result will look increasingly less like agile development and more like anarchy development.
What have been your experiences? Where have you tried agile and seen it succeed and where has it failed?