A presentation of a guy who implemented Scrum in his team in highly formalized environment in Motorola.
A series of Scrum trainings in a company which wanted to be oh so agile which ended up in virtually no change toward agile.
A person I’ve met on some event who told how much their customer was engaged in development process and how happy they were with results.
Implementation of new better agile process which ended up as a playground for a couple of people and brought nothing valuable for the rest of the team.
An environment where agile methods would bring only additional effort with not much, if any, gain.
A team which basically adopted Kanban in few hours.
Which one is real? Which picture shows agile at its true nature? Well, all of them. There’s no such thing as the only proper agile way. This is a lock-pick-word. Under the banner of agile we do good things but we also do bad things and ugly ones too.
When I think about agile as a phenomenon I consider all above as a part of it. If you try to divide good and reasonable implementations of agile from those done wrong or without understanding why it emerged around you reject to accept reality. OK, the part of reality.
If heavy-weight project management methods were done right all the time there wouldn’t be such strong drivers to change something in the area of software development and project management. But heavy-weight processes are bad because people use them bad. So the tool is wrong because people misuse it. OK, fine for me.
How misusing agile is different?
Agile became a buzzword for all good and bad which comes in a package. It’s adopted more and more, which is generally good, but at the same time a part of it is totally counterproductive and done just for the sake of being trendy.
The former is agile and the latter is agile. Even when the latter is agile-in-the-name-only it is still done under banner of agile.