Business stakeholders believe that certain requirements are too obvious to need to be written in a document. Technology guys complain that the specifications are unclear and they demand for more details on requests. When features are implemented, the business stakeholders has no time to validate delivery. The tech team, on the other hand, when they receive the feedback, says they need to wait for their sprint to finish. To try to solve, it creates more processes and more bureaucracy, as we have already mentioned here on the blog.

Although you focus on discussions about artifacts, you believe it is agile because you call them user stories and write them on post-its. Despite prioritizing sprint closure and the process, you believes you are agile because you estimate using planning poker and attending stand up meetings.

Agile software development is not in the first place about pair programming, TDD, or user stories… But the more you’re imposing them as fixed rules, the more you are constraining the innate rulemaking capabilities of your team members.

Jurgen Appelo – Management 3.0

The apparent lightness of agile methods compared to traditional approaches can lead us to believe that they alone can bring agility to our teams. In this case, a good adaptation of them to our organization would be enough to become us agile. Prescriptive methods is replacing our critical thinking that allows us to analyze, understand, and apply the agile principles in our day to day.

I’m not talking about that the simplicity of these methodologies, which allowed the massification of “agile”, have not brought benefits, but as the cliché slogan of the corporate market says, we need to be results focused. After all, as cool as a methodology may be, we need to understand how our actions generate value for the business. How we can deliver more quality software in less time, with less effort, solving the right problem.