What software developers seem to hate most of all in this industry of delivering digital goods and services seems to be this:
Being told what to do and how to do it.
This isn't always the case and mostly the two are perfectly acceptable when not joined together. For instance, being told what to do is usually acceptable as without knowing what to do (as in go fix the payroll system) we may not have a job. The how can be more shady in acceptance, but it's not a far reach for a developer to know that to fix said payroll system they need to do it a certain way, but if the certain way requires the sharing of too much detail then you're bordering on micro-managing and that's just insulting to someone with enough intellect to make a computer say "Hello world!" in 30 different programming languages.
This is where the pundits behind agile have had the hardest time selling the manifesto. After all, they don't see that what they are evangelizing is process intensive or micro-management-centric. This is because they understand agile development at it's essence, not just it's definition or the definition of the processes behind it. Some have began to grok this and have taken strides to adjust the face of agile development as it is presented to the process-weary IT staffs of the world. [couldn't find the links I wanted to back up this statement so validity here should be questioned]
The logical, linear, cause-and-effect thinking software engineer hasn't had time to consider the essence of this concept. This is buzz, trending toward that of enterprise vendors selling SOA and web services to inept project managers who put more time into earning their PMPs than understanding what really goes into developing solutions in software for people to use. And not only is this buzz, but you're going to tell this intelligent software engineer that they need to do things a certain way. They need to work with a partner (must not be competent or worthy of trust), they need to always write tests and those tests should be written first (can't trust them to code like a big kid) and you're going to make them work in preset increments of time and make them stick to a schedule!
This is madness! How can a person of average to high intellect and moderate sanity even consider working under these conditions? All they see is definitions and those definitions bullet point processes and if all you can do is fence them in with process it must mean you think they can't function as an individual and after all, all they want to do is write code....
I may be rambling, but I think my point is easy to understand. Programmers don't want to have to follow strict guidelines and commit to too many things because what they do isn't hard architecture where things have been defined for years (a bridge of X dimensions will require Y resources and Z time to complete), they work in the realm of virtual architecture where they like to think things are complicated and undefined and there is no way to know when it will be finished until it's finished.
But that isn't the essence of agile development. So how do you sell essence to a group of people that believe in seeing hard facts but delivering virtual goods? That my friends is a job better left to someone more intelligent than myself, after all, I'm one of the guys you should be selling to.
Just saying.
3 comments:
Right on. I have seen this kind of visceral reaction to high dollar consultants who swoop in on a team and start pointing fingers. "Did you write a test before you coded that?" "How come you coded this feature alone?"
I'm glad you highlighted the impression the pundits make on many developers, because it is making it harder for those pundits to actually make a positive difference.
I am definitely convinced of the value of many "agile" techniques and disciplines. Yet I am learning to approach others with patience and respect in order to show them how things I've learned might help them be more effective.
And I always learn something that helps me be more effective along the way.
Agile costs money to implement. There's no doubt about it. I think the hardest thing for management to swallow is the cost. For developers, there's definitely a learning curve involved in the process. There's a cultural change that must happen. That change may or may not be accepted by the entire staff. Pair programming is tedious when a junior developer is so far ahead of an existing senior developer that he/she outclasses said senior. It is equally tedious for the senior developer when terminology is being dropped that he/she doesn't comprehend. This can be brutally apparent when someone is being arrogant. It is equally tedious when a new programmer is pairing with someone with far more experience (and also arrogant). Finding that synergy between developers can be a tough thing to accomplish. Where agile shines, in my humble opinion, is the amount of communication that occurs within the team. Knowledge transfer is critical. In my opinion, that is the most important thing agile brings to the table. Agile opens the lines of communication. As one example, TDD is great, not because you should test your code as a responsible developer, but because it's a communication tool that tells another developer how a certain piece of code should function.
My point from the previous post is that maybe agile pundits should focus more on the communication that agile brings to the table instead of "do it this way because it's the agile way".
Post a Comment