When I wrote about the 10 mistakes people make when transitioning to Agile (http://www.drdobbs.com/dept/architect/193402902) many people wrote back to me with examples from their experiences. The fact remains that we are still in
the process of fully understanding Agile and that's like to continue for some time.
Gone are the days of the "computer operators". Nowadays, few of us programmers will accept such a non-fancy job title. I see big-time labels on the doors these days - Developer, Architect, Senior Systems Architect, Scientist and even Evangelist?
Hmm? Not long ago it was a real profession, maybe the parent of our modern ?developer? jobs. People use to do that work and they did it with joy and excitement. These fine humans used to spend hours of typing long lines of obscure machine language code into punch cards and then wait patiently, sometimes for hours, for the processor to debouch the fruits of their collective labor. Many of my colleagues, especially the ones old enough to remember those days are filled with memories of joy and happiness. Then, suddenly they are wrapped with a peculiar sadness. They miss those days. They miss the feeling of it.
What could one possibly miss about them dark ages of computing? After all, computers were slow - compared to today?s laptops they were simply arcane. The programming languages were...well, waiting to be written. As far as their physical size, well? they were generously commodious.
And yet, people miss them. So, what exactly do they miss? Is it the feeling of single-minded devotion to computing? Is it the white gowns with the pretentious look as if mumbling "Look I am a scientist. I can "operate" this equipment."? Or is it just a primal feeling of retrophilia, the one being displayed to old records today? I think they miss the feeling of being "the specialist" in charge of things. Things that he, and only he can do onto this new and exciting invention. However callow the technology, being part of the core cadre made people develop amity among themselves and their computers and filled them with a Promethean feeling of creating history.
Fast forward today. We are now called programmers. Our distinguishable features include living in cubicles, social apathy and general drowsiness. We wear uninspiring khakis and $14.99-Kmart shirts. Oh, and we wear our JavaONE shirts, which we purchase every year in our once-in-a-year training activity in San Francisco. We are armed with coffee mugs and our best food is pizza, especially when the company orders it for an all-nighter. We never forget our badges and filling our timesheets is now second nature. But most importantly we crank code ? as fast as we can!
Since our lives are a string of broken builds, we do not have time to develop taste for things of beauty that usually make other people?s life interesting - like dressing well, thinking of things outside our tunnel-vision and seeking ways to improve our technical solutions by infusing from other engineering disciplines, as well as sciences and arts. We feel incapacitated in our never-ending cycles of new feature requests, defect queries and ever changing market conditions.
We have ceased to understand ourselves as creators of software for humans. Ineluctably, we fail to understand what makes software interesting to humans who use it (aka users) and what actually makes it useful and usable. We were late for that lecture on creativity in software engineering. It was teaching among other things that creativity is fostered by intellectual diversity and that the foundations of most scientific inventions are actually based on good old generalist interdisciplinary science.
So what does all this have to do with the Agile methods? Umm? a lot.
Agile is many things to many people, but to me it is especially about people and communications. I'd like to underscore the people part ? it?s the plural form of human. Not be confused with a computer, drone, slave drive or even a code monkey!
The Eleventh Mistake: Treat your people like a commodity and that?s what you?ll get in your software
So you really like Waterfall and would love to see that new Agile initiative torpedoed. What a better way to do it than treating your people like Walmart walkie-talkies with their RFIDs attached to their necks? In other words make no distinction in your team and spend no efforts for get to know each person as a human being. In addition, never recognize individuals for their contributions. Even when you do, make sure you stay within budget (read: go for the cheap[est]).
I can almost hear you professing "Duh, isn't it obvious?? Or "This is so trivial that it applies to all software teams, if not all projects period, no matter what development methodology you pick. So what's the point??
Well, here is the point.
The fact that's obvious does not necessarily mean it is being practiced. Until I see it applied, I'll keep writing about it. Secondly, other less-Agile methodologies have developed stop gaps to compensate for the lack of communications developed as a result of corporate policies and methodology prescriptions. Ossified by process doctrines and whipped by methodology puritans, teams have increasingly dehydrated from their creative juices, vital to their success. Add to that an inherent poor leadership and general lack of understanding of the software creation process and you end up with team policies sounding more like a dictum, than a helpful recommendation. The effect has been the transfiguring of independently thinking and acting human beings into policy-governed ?team players?. The whole thing is very process-heavy and usually includes multiple steps and is guarded by various gatekeepers within the organization. They call the whole thing Project Management, or something of that sort? The goal of each of these mostly heavy-weight processes is to try to guess what can go wrong and develop a "system" that can think in place of a human and prevent it from happening. In effect, such systems have been shown to reduce the teams to the very least common denominator and that's been a major factor for the exodus of creative heads from such teams.
Another point has to do with the feeling of being a craftsman. We are all artisans of our callings. Agile teams promote the idea of one team of virtuosos working collectively to find solutions to common problems. Anyone on the team is assumed to be skilled in their art and expected to contribute to the collective olla podrida called software. This is different than normal teams in which roles and hierarchies take precedence over the creativity and individual contribution of its members.
The days of punch cards may be gone, but the spirit of appreciation will live forever. We programmers are first and foremost human beings and as such we need the primal feeing of appreciation. I am not talking about the petite $25 Amazon.com gift cards dumped on our desks for a ?successful? 70-hour week. Or hanging our pictures on those cheesy picture boards reminding Burger King?s Employee of the Month circus. I am more interested in a genuine human-based approach to team management in which people are recognized for their personal contributions, teams achieve things collectively (?and screw-up collectively) and individual differences are celebrated. Such environments are likely to last long and provide a fertile soil for any Agile initiative.
Previous Topic
