Agile is a buzzword. These days, everyone is “doing agile”. Or so they say.
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.
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:
- What is fake agile?
- Why fake agile is bad for your teams
- Fake agile vs true agile: How to spot the difference
- Misguided agile leadership
- Understanding true agile
- Questions to ask to help you spot a fake agile team
- The need for agile training
- Tools for agile teams