It’s easy to jump on a bandwagon and end up in a ditch. Nowhere is this maxim more evident than in agile development. Plenty of organizations jump into agile in pursuit of its advantages -- ease of embracing change, decreased cycle times, evolutionary architecture, and so on -- only to find their best agile practitioners leaving the company, and the uneasy remainder unable to fix a development process gone wrong.
The problem with most approaches to agile is not a problem with agile; it's a problem with Agile, the Capitalized Methodology. Agile isn't a methodology. Treating it as one confuses process with philosophy and culture, and that’s a one-way ticket back into waterfall -- or worse.
Fortunately, it is not difficult to recognize the signs of an agile approach gone wrong and to take steps to restore harmony. Here we examine 15 signs you’re doing agile wrong. Even one of these can seriously derail your software development efforts.
Doing agile vs. being agile
Agile begins with attitude. If your company emphasizes doing agile rather than being agile, you’re on the wrong foot right from the start. Agile is a paradigm, a mental shift in how you approach software development. The specific techniques and ceremonies come later, and they're the least important part. The point is to be agile; embrace and employ the philosophy outlined in the Agile Manifesto, and you will “do” agile automatically.
Be sure to look carefully at the manifesto; its choice of words is no accident. Think about the implications: shed useless ceremonies, administration, and paperwork; focus on working code and fast feedback cycles; self-organize, self-examine, and self-optimize. This is the revolution. The specific practices of how to go about achieving what the manifesto outlines continue to evolve.
If you’re following a one-size-fits-all agile “process” mandated for all teams, you’re doing it wrong. The notion of a “standard” agile process is contradictory -- agile means adapting and improving, continuously.
To remediate this, remember that the main goal is to deliver working software, not to follow a recipe; there is no recipe that always works for every project and team. Therefore, let each team adopt their own practices and take responsibility for adjusting and improving them.
Treating story points as goals
User stories are a key facet of agile, capturing a software feature requirement from the user’s perspective. Stories are assigned point values to estimate the level of effort necessary to implement the story.
These story points are neither a promise nor a goal. They have no intrinsic meaning or measure. They are an informal agreement among team members reflecting a common understanding of a project’s complexities and the team’s capabilities.
Sign up for CIO Asia eNewsletters.