I don't think you really understand agile. Why do I think that? Because 90% of people in the industry seem to not know that they don't know what agile is and as a result, think they know what agile is. This results in pervasive misinformation. Just as a pure numbers exercise, it's a good bet -on my part- that you don't, simple.
"...as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones." - Donald Rumsfeld, United States Secretary of Defense
I propose that most agile wells are poisoned. People learn, self-led on the job and are riddled with bias and obstacles which taints their understanding & implementation. These people make and take part in faulty implementations, find the faults they injected, rage then write articles about them.
The major mistake we make when adopting agile is not consulting with experts. Taking in consultants or sending people on courses. Agile is different, it requires a change in attitude more than (certainly before) process and as a result:
we assume agile is largely a process change and not a culture/mentality and extract only the process which makes no sense in most cases without the culture
we dismiss parts as common sense that then don't get attention in implementation.
we don't strive for management buy-in an end up making massive compromises.
We try to phase agile in to avoid disruption and miss the core concept. That agile is about embracing disruption.
The second thing we do is assume that people talking about agile, know about agile...
Everywhere I see articles like this one which base their premise on massively flawed articles such as:
"Agile is the new waterfall…The reality of Agile is that you still have immutable decisions made by business people with no real understanding of technology. Those decisions are then forced on to developers. The end result is the same as Waterfall, only the names have changed.” — ayasin, Architect & Developer
Anyone who knows agile knows this is anything but. "immutable decisions" completely contradicts agile principle 2...so, not agile!
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Then in the same paragraph
Those decisions are then forced on to developers
doesn't seem to match with agile principle 4
Business people and developers must work together daily throughout the project.
And we are given the conclusion that "Agile is the new waterfall". Someone who has managed to be a developer so long they've become an architect seems like someone we can trust, right?
It's very specifically a change in thinking & culture. We strive to embrace uncertainty and cut out wastage so that we can deliver tiny amounts of high quality value quickly and repeatedly based on user feedback. We then turn that attitude inward and cut wastage, make tiny amounts of high quality process changes quickly and repeatedly based on performance in the previous iteration.
Anything that doesn't meet this, isn't agile. All process added and actions performed which decrease quality, time to increment and/or isn't user value focused will corrode all agile implementations.
- Every process that slows development in order to forecast.
- Every time there's a hand-off
- Every user feedback you shun
- Every failure to realise and focus the specific value - added
- Every time you fail to trust each other
- Every single time you say "that's not my job"
Now the question is, am I right? Get a certified consultant! Be ready to commit! Don't assume you know all you need to.