Been reading Steve Yegge’s famous Agile rant again. I agree with pretty much everything in it as I’ve had a few painful experiences with bad agile. Many of the agile methodologies are highly loose guidelines that come with the disclaimer “use your common sense here”. Well here’s the thing, when agile pushes a manager into doing something that isn’t common sense then why try to be agile? Isn’t it just a name ?… Just an evolution of thought process which suggests that a team’s performance can be improved if they accept their development will occur in iterations rather than in one monolithic flush 😛 of the “waterfall”. The problem here is that I know (very) few engineers who ever did waterfall as badly as portrayed by the agil-evangelists. I know very few real “cowboy programmers”. They just weren’t that dumb. So from the kernel of a good idea comes dogma about how to stop evil developers doing the evil things that developers do when they’re left alone without a watchdog methodology. The following are required to control those pesky developers.
- immature tracking tools
- imposed rules about team and group programming.
- odd notions about starting development without necessary background research
- time driven iterations which don’t allow for normal human biorhythms
- dismissive attitudes to the 80% of the time required to get the tricky 20% done
- dismissive attitudes to detailed analysis regardless of the problem
- religious fervour & absolute conviction
All of these things are bad agile but it’s possible to follow the books and fall into the bad agile trap. Good agile requires affinity with the problem domain and knowledge gaps are often underestimated by managers and hidden by wary engineers. Equally, many engineers cannot work in a 9-5 clock-in & clock-out way.
Now I know that Kent Beck et al. don’t intend managers to fall into these traps. It’s just that the marketing industry surrounding agile leads them to believe they’re getting something for nothing. It’s the same kind of thinking that leads to misnomers like Simple Object Access Protocol.
All I know is that in the “accurate tracking” of “agile iterations” I find myself thinking that intuitive understanding of complexity management, delegation, abstraction, team motivation & a whole bunch of things that apply across many industries are what leads a project to success. These skills generally aren’t covered in agile courses or books. Indeed it’s a wonder that nobody has really improved on Fred Brooks. These qualities exist in the manager and the team members. A truly agile process is whatever works for them & with them.
I also don’t think it’s just about “hiring smart people” either. This oft trotted-out phrase relates to the practice of hiring the apparently best and brightest grads and appears to the be the mantra of HR in many tech companies including Google & Microsoft. The problem is that it depends on the task at hand. One can have an a priori belief in the mantra and ignore empirical and anecdotal evidence to the contrary. Sustainable success is about “hiring the right people” which are not necessarily those with the highest IQ but those that can work best in a team for the realisation of a common goal.
At any given time someone has to lead, someone has to follow and both have to feel comfortable that the relationship isn’t exploitative. The guy leading has to recognise the transience of leadership and the guy following needs to at least have professional empathy for the leader and their shared goal.