Agile is a buzzword. These days, everyone is “doing agile”. Or so they say.
Despite over 90% of senior executives stating agile adoption as a top priority, less than 10% actually consider their firm to be performing with a high level of agility.
As much as people love to wear the badge of agile on their sleeve, there is a great deal of confusion swelling in the dark chasm between the aspiration of agile implementation and reality.
So what is agile?
It’s basically a philosophy of software development that prioritizes iterative development of working software and solutions through cross-collaboration and self-organizing teams.
It’s also an umbrella term for a bunch of development frameworks, but agile doesn’t simply mean kanban or scrum.
Some of the confusion arises when teams equate the agile approach to using an “Agile framework” (usually capitalized).
Frameworks like these are attractive because they’re sold as simplified solutions to difficult project and process management problems.
Sure, these frameworks can be an important part of an agile implementation, but they need more. They need a firm foundation to stand upon.
It’s not enough to simply go through the motions and expect an agile approach to “just work”, especially when transitioning from a more rigid and traditional framework like waterfall.
In order to drive agile success, teams need to adopt agile philosophy. They need to change the way they think about work ownership, management, and their relationship and duty to customers.
Without this vital force, frameworks like scrum and kanban fall flat.
In this article I’ll investigate what it is that separates true agile from the “fake” agile that is often the differentiator between success and failure of a development team. Here’s a quick overview:
