What Agile isnt

Original on Linkedin

Just copied here the text, as I frames will not occur due to security policy reasons
  • Veröffentlicht am 23. August 2016


Patrick Becka


Patrick Becka


VP of Product Development, MBA, PMP

22 Artikel

On a number of occasions, I’ve been involved in meetings with business professionals and software professionals and observed both parties exhibit a fundamental misunderstanding of what agile means… and doesn’t mean.  So with the framework of the Agile Manifesto in mind, let’s start with what Agile doesn’t say:


Individuals and interactions over processes and tools

What that DOESN’T mean: Processes and tools are irrelevant. Processes are what enable organizations to learn and improve over time, and following procedures leads to reproducible results. Tools can fundamentally change the way that a team sees and responds to problems. As the old saying goes, if the only tool you have is a hammer, every problem looks like a nail.

Working software over comprehensive documentation

What that DOESN’T mean: Documentation is old-fashioned/over-rated.  First, note the qualifier “comprehensive”: Every detail of every line of source code doesn’t have to be commented/documented, and every requirement doesn’t have to spell things out at the micro level.  But without adequate documentation your requirements will be lacking, and that will result in wasted time in meeting clarifying the requirements or worse still, it will may result in even more time-consuming and more expensive revisions to your software.  If you don’t know where you are it’s awfully hard to figure out how to get to where you want to go.  And don’t forget that people get sick, quit, and retire: taking with them the exact kind of product and institutional knowledge that is needed for the rest of the team to continue their work uninterrupted.

Customer collaboration over contract negotiation

What that DOESN’T mean: Contract terms aren’t important.  They are.  But they can be broad enough to recognize that the exact deliverables aren’t specified in advance (because they aren’t fully known when the work starts).  And if both sides are truly collaborating and reasonable then both should be satisfied in the end.  Don’t do business with people who don’t understand the nature of software delivery.

Responding to change over following a plan

What that DOESN’T mean: Planning isn’t needed.  Plans are important, but they usually shouldn't be written in stone.  The plans for a particular period of time need to be documented to know who is working on what, to identify dependencies, etc. but even short-term plans can be changed if the business needs call for them to change.  After all the team’s product isn’t being made for its own sake – it is being built to serve the needs of the business.