0

ALM Ruminations Part 2: TPS Reports and Writing Myself a New Pair of Fluevogs

by Angela 3. September 2013 17:58

Yes, Fluevogs. What? I don’t need a minivan!  My husband will find it amusing that I managed to get a plug in there for my favorite boots from the Fluevog fall lineup. It’s OK, I’ll stop talking about shoes now, read on...

If you’ve been following along with my ruminations about the process struggles and pop psychology required to survive software development, you may have already seen my first post. This is a follow-up, and I hope to have MANY more assuming I can find time between TFS installs Winking smile  So without further delay:

Favorite “Drive” quote #2: Goals that people [teams] set for themselves and that are devoted to attaining mastery are usually healthy. But goals imposed by others – sales targets, quarterly returns, standardized test scores, and so on – can sometimes have dangerous side effects.

So why do some managers cling to measuring their people by metrics like Lines of Code, # bugs fixed, and other archaic and easily gamed statistics? I can’t say for sure but I have some theories. One that I keep finding is that it’s often what they KNOW how to measure, and it makes them to feel like they have control over things. But sadly the accuracy of those metrics if often unreliable, at best. Add to that, their direct reports may have figured out how to work the system to meet artificially established goals, hiding issues, and masking discontent. Or perhaps software development management folks haven’t yet figured out what behavioral scientists have known for years - that creative work is actually HARMED by the use of extrinsic rewards systems.

Solving the first issue (bad metrics) is tough, how do you make someone see there is little value in many of the metrics that have traditionally been used since the beginning of IT? What SHOULD they be measuring instead? What are they themselves being measured on, and are those metrics effecting how they reward/punish the software team? I’m still working on perfecting how to address this one myself, and I often immediately point to the Dilbert where the software developer “codes himself a new minivan” as a wake-up call. Often times, it does not even occur to them that their cherished status reports might be at the root of the team’s problems.

The second point (hiding issues) is one I see even more often, where software teams themselves train managers that no matter how unreasonable a deadline, no matter how many times they change requirements, that the tem will double-down, work a lot of overtime and get it done. Even worse, most times the overtime goes unreported, and so any normal manager may conclude that any “small request” can be accommodated at the drop of a hat, and so will continue to do so. The team may be seen as a hero, but can also be seen as one that does not plan well, and is often scrambling to meet deadlines.  It is a double-edged sword. The team inevitably burns itself out trying to keep up, quality suffers in favor of getting features out the door quickly, and the manager often doesn’t get everything they wanted anyway. And no one is happy, not you, not the manager, and certainly not the customer. It’s lose-lose-lose situation and it doesn’t HAVE to be that way.

On the last point (squelching creativity), this is possibly the toughest of all to address, because again, most of us “IT folk” are not psychologists. Maybe your boss does not have an IT background, and simply does not understand that writing software is actually quite complex and difficult. You may have crafted hundreds of web pages, but that doesn’t mean that the 101st web page isn’t a totally different animal. God forbid the framework or tooling upon which you rely to build web pages has gone through a major upgrade recently!  I blame this on the inappropriate and overused comparison of software development to building a house. NO, NO, NO it is NOT just like building a house. And if you think the metaphor holds I doubt if you’ve ever actually written any software, or at least you haven’t in the last 10 years or so. Or maybe you want your software to turn out like just another plastic shoebox in a huge soulless fields of cheap Mc Mansions. Sure, in some cases the issue here is that IT management do not personally feel the pains or understand the challenges that the team is going through, or maybe they, in fact, are causing the pain… After all, the first step to recovery is realizing you have a problem in the first place…Seriously, we need an “agile intervention” offering complete with a 12-step program!

So if this sounds like where you work, buy your boss a copy of Drive and an anthology of Dilbert cartoons, and please stop training them to continue to give you unreasonable goals by working overtime and underreporting issues and bugs to make things look rosy. I promise you, that strategy may payoff in the short term, but in the long term nobody wins!

OK, I have a lot more spinning through my head but I think we’ve done enough navel gazing for this post. Stay tuned for more musings in the next week or so.

Tags:

ALM | Application Lifecycle Management | General | Process Methodology | SDLC | Scrum | development

Powered by BlogEngine.NET 2.7.0.0
Original Design by Laptop Geek, Adapted by onesoft