This chapter is from the book
This chapter is from the book
This chapter is from the book
Growing Your Own Culture
You can’t buy a culture in shrink-wrap; you must grow your own. Every software team works in a different context of technologies, application domains, customer expectations, and management pressures. While the trade-offs made in different environments will vary, quality-focused attitudes and the sound engineering processes that lead to quality products are applicable nearly everywhere.
There is no simple recipe or checklist for creating a software engineering culture. There is only a set of technical practices that are known to facilitate the building of quality software products, the individual discipline to apply these practices, and leadership behaviors that nurture the budding quality-focused culture. Cultivating a software engineering culture is a long path with many steps. Each step will contribute constructively to the culture as well as to improving the products created by the people in the organization.
In a group without a shared objective of software excellence, not every member feels the need to change. It is easy to dismiss process improvement efforts as just the latest management blathering. Therein lies the seeds of conflict, as some members of a team embrace new ways of working, while others grumble their resistance. This conflict is not a requirement: If all goes well, a nucleus of improvement enthusiasts will serve as role models for those more skeptical about the need for change and the anticipated benefits. As most of the team forges ahead toward the future world of software engineering, those who don’t embrace the new culture will probably complain for a while, and then leave. Alternatively, the resisters may attempt to drag the group back to their own comfort level, if permitted to do so by their management and peers.
The process of agreeing on principles and values provides many opportunities for improving the work environment and the work results. Aligning the group members toward common improvement activities is best performed through group brainstorming exercises or formal process assessments. Small teams composed of representatives from the group can then work together to identify better ways to perform the group’s software tasks. The software manager cannot simply decree the changes that need to be made and expect anything constructive to happen. His job is to steer the team toward working on the key improvement areas that constitute the next step toward the software engineering culture.
A shared culture is a necessary foundation for progressing through the software process maturity sequence, to the discipline of repeatable and measurable development processes. As an organization systematically and thoughtfully works to improve its procedures and processes, a common culture is a natural by-product. A quality-oriented culture enables all team members to contribute their full capabilities to building excellent products through both individual achievements and effective teamwork. People working in such a culture recognize that employing defined processes for developing software does not inhibit their creativity; instead, it lets them shift their creative energies to other aspects of the development life cycle, such as requirements engineering and software design.
Once the improved processes are under control and have become part of the normal way of doing business, more focus can be placed on the product itself. Companies and development organizations don’t produce processes—they create products intended to delight their customers. When the culture supports process improvement as a matter of course, people will not waste energy resisting beneficial changes; instead, they can concentrate their creativity on building new and better software products, using improved techniques.
Even though aspects of an organization’s culture may be documented in writing, the real culture is revealed through the behaviors of everyone in the group. Writing mission statements, visions, values, and principles are the latest rage. Mission statements can help everyone in the group understand his or her role in the grand scheme of the corporation, and having the team agree on a vision describing long-range objectives that transcend individual projects also provides a focus for sustained achievements. The culture can indeed be shaped through this sort of practical and meaningful documentation of shared philosophies, provided it offers working tools rather than just the output of one-time exercises in group-think.
Too often, though, missions, visions, and the rest simply contain platitudes. “We value honesty, integrity, and respect for others.” “We will be a world-class software supplier.” “We will produce zero-defect products.” Few can disagree with such lofty goals. But are they realistic? Can they be measured? Do they have any impact on the way the people in the group work and act? Do the leaders practice what the slogans on the wall preach?
Sometimes, the official behavioral expectations of a group are documented in a shelf full of software development standards. But are they followed and enforced? Do they add value to the development process and its products, or are they a standing joke among the development staff? The official party line expressed in this kind of written documentation may be at odds with the underlying, unwritten culture of the group. Standards and methodologies may represent what the managers claim they want from people, or what they think they are supposed to want. The unwritten culture, though, is shaped by the degree of trust and mutual respect among all members of the organization. It is reflected in the consistency, or congruence, between what is said and what is done by managers and team members [Weinberg, 1994]. In short, culture is “how things are really done around here.”
The first-line manager or project leader has a tremendous influence on the ability of a software group to evolve constructively. The manager must shape the culture by gentle persuasion, leading by example, providing positive and negative reinforcement, and supplying the resources necessary to make change happen. For example, a manager who declares that 5 percent of each engineer’s time should be devoted to process improvement activities but then does not adjust project responsibilities to make this time available will likely harm the culture, not help it. The manager is sending mixed signals, and the action of always succumbing to project pressures speaks louder than the words “process improvement.”
The path to a software engineering culture involves changing the behaviors of team members so they follow proven practices that lead to superior software. By moving toward an environment in which every team member can effectively apply the best available software engineering methods, the group will enjoy improved quality and productivity. When your developers have truly internalized the concepts of software engineering, those concepts define the way software is built in your group, not a way someone might choose to build software. A developer interested in software engineering practices may use them if it is convenient, but a developer committed to software engineering will stick to a disciplined approach even if it is inconvenient at times.