Scrum. Burndown charts. Daily standups. Retrospectives. The Phoenix Project. Chances are, if you’re working in software development you’ve at least heard these terms along with the context of “Agile Programming” or “Agile Development.” The problem is that very few, if any, companies do Agile “right”, and that leads developers, product owners, and the business to conclude that “Agile sucks.”
The Agile Premise
The two biggest reasons that Agile sucks are right there at the top of the Agile Manifesto:
[We…] Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
This leads to User Stories, which Wikipedia defines as:
Here there be dragons. Large software projects used to be written with gigantic requirements documents that often took months or years to produce. These requirements routinely laid out in excruciating detail everything from color schemes to pixel spacing between elements on the screen to interactions between various parts of the system. They also had the pesky problems of becoming out of date almost as soon as development actually began, and planned delivery schedules of months or years. Enter the User Story.
The problem with user stories is that they’re supposed to be written by users and, except in rare circumstances, users are not technical people. If an end user needs to be able to find information easily on a website, the user story will usually read: “Web site must be searchable.” To make matters worse, developers can be pretty arrogant at times and will happily take that poor excuse for a story and run with it thinking: “Web search! No problem. I know exactly what they need.” After all, we want more time to hit our sprint targets and the user story is certainly expressed in informal, natural language. Continue Reading