How do you Convince an Agile Skeptic?
Daniel Markham, a hands-on technologist, and agile coach wrote a post last week trying to answer the question why some people are seriously pissed off at Agile? He regularly receives negative emails rebuffing Agile claims. After well over a decade of Agile practice and a wide adoption across the industry, it might be a good time to pause for a second and ask some questions like Amr Elssamadisy did earlier this year. There is often one small step between success or failure, not to mention that it is often difficult to measure success.
Here are the problems he sees and hear about:
- Fake success stories
- Trainers who can't do the work
- Inflexibility on the part of adherents
- "Feel good" agile
- Magic Bullet Syndrome
- Reversal of team dominance
- Cargo Cult Agile
- Non-answers to questions
- Conflicting Advice
- It's the same, only different
- Little Gold Star Syndrome
This set of remarks reflect a fairly general pattern in our industry and the same things could possibly said just by replacing Agile by the buzzword du jour. As it is often the root cause of skepticism, Daniel explains:
Agile has no definition. There's no standards board, there's no test, there's no approved workbook, there's no checklist. Agile is nothing like Scrum. Personally, I think that's a good thing. Agile is a set of best practices around running iterative and incremental development teams. [Agile itself is just] a marketing term.
Yet, there is ample evidence that Agile teams are generally happier an have a higher productivity. As the debate on the ingredients of success is still active, for Daniel, the keys towards becoming a successful Agile team is about doing, reflecting and adapting:
It IS an art, not a science. You don't just read a book or take a class and suddenly you are agile. You don't learn to play the piano by watching a film of somebody else playing, reading a book about it, or going to a conference.
Not surprisingly, lots of comments followed:
[Techneilogy] One thing that makes things with some good (like agile programming) go so bad, is the "secret formula" mindset endemic in middle management.
[Alan Franzoni] Agile should be agile in adoption as well - it's very hard to start from scratch and adopt each and every "agile technique" at once, and it should be a developer's demand beyond the manager's will - if something works well, there may be no reason to change its.
[Rui Curado] Pragmatic model-driven development (hence not UML/MDA) coupled with code generation is one step forward to a better development future. It does require some mindset shift but pragmatic approaches are within reach of the mere developer mortal.
[Ben] I can relate to the people who don't like the nerf ball, the haikus or whatever other "far-out" ideas the "Agile people" can come up with, and I can tell why I don't like it either with one simple sentence: what the hell does that have to do with software development?! I think that the Agile community would gain a lot by realizing that what me and a lot of people like me need are not "anecdotes", "coaches" and "stories" but techniques, clear structures and measurements.
[Anonymous] We've recently switched over to scrum at my company, and for the second time in my career I've been stuck doing this. It's so tiring on developers, all these iterations. Two week cycles, over and over, on mini tasks, makes you feel more like a code monkey than an actual developer. [To which Daniel responded] So if I were you (or your team) and I found this agile stuff just grinding the hell out of me? I'd be bringing that up every stand-up. It's an obstacle, an impediment to team performance. It needs to be fixed.
If you think that Agile is here to stay, how would convince a skeptic? Is it mature enough? or is it still going through the troth of disillusionment? Is it still suited for a world dominated by mobile applications and Cloud Computing? Or does our industry need to look beyond its processes to find new productivity gains?
Agile has no definition
I think the problem with adopting agile is that there is no defined process, step and rules. In the other hand these factors are most notable feature of agile. There is no definition; you should learn how to play and improve your process in continuous manner.
time and materials
It is double profitable because it is easy to portray ‘activity’ as real progress;
Focus on short term deliverables easily leads to hacks and lack of thoughtfulness causing a lot of rework. That can to be mitigated when there is somebody why really understand what needs to be done, but often is not because reward for ‘not understanding’ is quite substantial.
Re: Agile has no definition
I'm still not sure that the agile development copes well with processes where a good look ahead is essential.
In some respects agile strikes me as driving a high speed in foggy conditions and no map.
Why try to convince a skeptic?
agile fall from grace
abraham lincoln once asked "how many legs would a dog have if you called his tail a leg?"
the correct answer is 4, because calling the tail a leg doesn't make it a leg
calling a dysfunctional scheduling obsession 'agile' by having daily stand-up meetings does not an agile process make
a candle on a raft in the ocean
They often don't realize how difficult change is and expect Agile is a function of engineering/IT and has no effect on the rest of the organization. There are many factors contributing to the perception that Agile is broken.
There are tons of posts of "I've been using Scrum successfully for years..." all over linked in and google groups, there are people that just don't get it, there are coaches who aren't considering the culture and pace the organization transforming can support and the list goes on and on.
What Agile is all about is taking data that is made visible and giving the business an opportunity to make better decisions. That's it. Whether Scrum/XP/Kanban/Scrum-but/Butt-ban/<fancy method name here> fit the bill, that's fine. Pick what works to help you solve your organizational problems and more often than not I find that management simply ignores this data because they don't like what they hear.
To the point Daniel made, getting burned out using Scrum shows there is a problem of too much work being pushed through the team. This is common. It's expected that 'agile' is for the team and the business does not change their bad habits. With that attitude and ignorance to analyzing the whole system, any methodology isn't going to work.</fancy>
Not enough good guys