RSS Feed
Productivity and Pitching Agile to Senior Management
If you have an interest in agile development, take a look at this article: Pitching Agile to Senior Management. If you don’t care about agile development, have a look at it anyway – it brings up a few interesting points. To sum things up very briefly, the article goes something along these lines:
- Junior managers and up-and-coming engineers want to try agile development methods to increase productivity.
- However, they don’t understand the criteria upon which upper management decisions are made.
- This article explains that senior managers don’t have the same goals as engineers or juniors, and teaches the latter a few economic buzzwords to throw around.
- The end.
Despite appearances and my cynical summary, this is actually interesting! For example, the second page discusses the difference between introducing technological improvements and introducing economically beneficial improvements; this might be pretty obvious but it never hurts to get a nice summary of the different perspectives. Also, the third page has a very very important tip: you don’t always have to get permissions for everything. I seriously don’t know how I’d get anything done if I didn’t have both the initiative to make my own decisions, and the (grudging) acceptance from managers that it’s okay to do things my way. It’s an old cliche that you can’t get denied permission for something that you don’t ask permission for – but it’s also very true. As long as the results are good, no one will hang you for your slightly questionable methods.
Unless you work in bad companies, of course.
I’m a big fan of Dilbert, but I would never accuse my bosses of being pointy-haired. I often critizise their decisions, but I don’t think that they’re incompetent. Rather, as the article suggests, I think that they’re smart people who are making the best decisions they can based on the information they have…and the goals they want to achieve. Sometimes, when I read horror stories on the ‘net, I get the impression that other people either have completely moronic bosses or a complete lack of understanding for why decisions are made. I try not to be one of the latter people, and I’d never be able to work for the former. I don’t want to end up in…oh, the horror of this flawed and unhumorous pun…bad company.
And speaking of bad companies: time to bring up a bad thing about the article above. Take a look at this quote:
A few months ago I was educating a client about agile development and they told me that they weren’t interested in pair programming because of what they felt to be obvious loss of productivity in having two people do the work of one. I pointed out that with pair programming, when you’re doing it right, both pairs are exhausted after five to six hours.
This seems to be a prime example of bad management.
“Lesse, people who produce get tired. Thus, if a person is very exhausted he must be very productive. Let’s aim for exhausted people!”
Can you spot the errors in that line of thought? At a recent meeting I noted that my company doesn’t use the term productivity. The reason was that many people assumed that increased productivity was the same as more effort, so they exchanged produtivity for a different, more positive, term. At the time I was irritated at this obviously ridiculous attempt at giving productivity a more humane name in order to disguise it…but after reading this article I suspect that there really might have been good cause for it.
Finally, if you’re anything like me you might have wondered what Moore’s technology adaptation chasm that was mentioned on the first page of the article is. Wonder no more: I looked it up for you! To sum things up briefly, Moore divided people into Innovators, Early Adopters, Pragmatists and Traditionalists, and noted that there’s a chasm between Early Adopters and Pragmatists; a new technology must cross this chasm before it can become common practice.
Now, wasn’t that fascinating?