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.

Featured

  • IT Modernization
    Eisenhower Executive Office Building (Image: Wikimedia Commons)

    OMB's user guide to the MGT Act

    The Office of Management and Budget is working on a rules-of-the-road document to cover how agencies can seek and use funds under the MGT Act.

  • global network (Pushish Images/Shutterstock.com)

    As others see us -- a few surprises

    A recent dinner with civil servants from Asia delivered some interesting insights, Steve Kelman writes.

  • FCW Perspectives
    cloud (Singkham/Shutterstock.com)

    A smarter approach to cloud

    Advances in cloud technology are shifting the focus toward choosing the right tool for the job and crafting solutions that truly modernize systems.

Stay Connected

FCW Update

Sign up for our newsletter.

I agree to this site's Privacy Policy.