The psychology of software
Organizational development—or OD for those who insist on acronyms—is
a branch of psychology that studies how individuals interact within an organization
and how to improve the organization's performance. Software development
depends on individuals working effectively within an organization. Whether
it's a small team or a large government information technology shop, the
way individuals interact has a lot to do with whether the organization succeeds
in its mission.
I first encountered OD many years ago, when the consulting shop I worked
for conducted surveys of employee attitudes and job satisfaction. These
studies often revealed why organizations seemed to be dysfunctional in certain
ways and helped workers better understand one another's styles and work
more effectively as a team.
I've recently been asked by a medium-sized organization to help implement
a software development process. The effort will be based in large part on
QuickStep, a software development methodology that I developed during the
past 10 years. It seems to be a good fit, both with this organization's
current practices and with its philosophy of software development.
But even when these circumstances exist, there's no guarantee that a
new process grafted on from the outside will take root and flourish. A good
process can fail if the organizational culture doesn't allow key practices
to be performed.
For example, most development methodologies require various kinds of
reviews. In a design review, a lot of emphasis may be placed on the materials
that must be prepared for the participants, the process by which participants
are selected and the manner in which the results are recorded.
Yet, the problem of how to actually get people to participate is often
overlooked. If your staff is afraid to speak up, how can you have a meaningful
review? Despite lip service that "frank input is encouraged," too often
differing views are oppressed and a culture of enforcement reigns. How many
times have you seen programmers trudging along, implementing a flawed design
because they know it isn't safe to say the Emperor of Design has no clothes?
If you can't get authorization for an actual OD intervention, consider
sponsoring interventions of your own. Ask a programmer to lunch, and see
if he or she wants to talk about unacknowledged problems. Stay late to help
with testing, and see what you can pick up about the health of the project.
Finally, ask yourself: "Who's complaining?" If the poor performers are
complaining, perhaps they're being given tough performance standards—and
that might not be a bad thing. On the other hand, if your star performers
are grousing or even resigning, that should probably tell you something.
Bragg is an independent consultant and systems architect with extensive
experience in the federal market. He welcomes your questions and topic suggestions
at tbragg@acm.org.