Every organization, company, department, and team has its own culture. In brief, the culture describes “how we do things around here.” A healthy software culture is characterized by a set of common values and technical practices that drive the behaviors and decisions of people in the organization (Wiegers, 1996; McMenamin et al., 2021). A healthy culture includes commitments at the individual, project team, and organizational levels to build high-quality products through the sensible application of appropriate processes and practices. If all goes well, the team members have a good time along the way, too.
My first book, published in 1996, was titled Creating a Software Engineering Culture. It itemized fourteen shared values—cultural principles—that my software development group had adopted. Looking back at that list, I believe they’re still relevant to successful software development. Indeed, several of them appear as lessons in this book:
• Lesson #44: High quality naturally leads to higher productivity.
• Lesson #47: Never let your boss or your customer talk you into doing a bad job.
• Lesson #48: Strive to have a peer, rather than a customer, find a defect.
• Lesson #60: You can’t change everything at once.
An organization’s culture grows organically unless leaders actively steer it in a particular direction. A random collection of behaviors aggregated from everyone’s past experiences is unlikely to jell spontaneously into a healthy culture. Young companies for which software is the principal product often establish powerful cultural imperatives that best serve their teams and the work they perform (Pronschinske, 2017). Conversely, an IT department within a nontechnology corporation inherits the company’s general cultural characteristics. Steering the IT culture to one more suitable for contemporary knowledge work can be an upstream swim. IT people’s work differs from some other types of corporate work, so it makes sense that their culture should evolve in a different—preferably complementary—direction.
As an illustration, I used to work in a large consumer-products company with a glacially slow decision-making process. It seemed that no one could make a decision unless everyone who was affected in any way by any part of the decision was 100 percent okay with the entire decision. Everyone involved in making a decision seemed to hold a veto. Unanimity is great, but business must move forward—you can’t make decisions that way on a fast-moving software project. Certain aspects of the corporate culture clashed with the demands of today’s nimble and responsive IT work.
Managers influence an organization’s culture through their vision, words, and behaviors. By taking various culture-building actions, managers foster collaborative teamwork and consistent alignment with positive cultural values. But culture is a fragile thing. Culture-killing actions can easily undermine the quality-oriented foundations the group has gradually built up (Wiegers, 1996; McMenamin et al., 2021).
The best sign that an organization has firmly established an improved culture is that the new attitudes, practices, and behaviors persist when key leaders depart. A small software group that I managed for several years made substantial improvements in how we worked together, and we saw the benefits in the systems we delivered. In three years, we grew from a group of five up to eighteen. As new people joined the team, they absorbed our cultural values and helped us sustain the behaviors and practices we believed were important. Eventually, we hired a new manager to replace me, as I didn’t enjoy being a manager. Several other new people joined the group at the same time.
Disappointingly, the new manager didn’t fully share our commitment to continuously enhancing our software development process, nor my improvement philosophy of “gentle pressure, relentlessly applied” (see Lesson #54). Unless leaders sustain their steering toward continuous improvement, some team members might backslide into their comfort zone of familiar practices. Sure enough, some of the process changes we had made gradually decayed. Others, however, were still practiced by those team members who had internalized them as the best way to work.
Congruence is a crucial element of a healthy culture. Congruence means that the managers and team members behave in the ways the organization claims to value, not according to unspoken rules that might conflict with the official value statements (McMenamin et al., 2021). Incongruent actions infect the culture, undermining the declared focus on high quality standards and ethical behaviors. Questions like the following can reveal whether the culture is congruent or not:
• Do managers practice what they preach, or do they fold under outside pressure, such as delivering products that haven’t yet satisfied their release criteria?
• Do technical practitioners follow established processes, or do they cut quality corners and do what’s expedient in the face of looming deadlines?
• Do team members make and keep realistically achievable commitments, or do they make overly ambitious promises that go unfulfilled?
If your organization has a different set of values than this list implies, you might select different questions to test the culture for congruent behaviors. Regardless of what principles the team values, people should act in ways that are consistent with them.
The behaviors that an organization’s managers reward provide a clear sign of their true values. One company conducted two major legacy-system replacement projects concurrently (see Lesson #44, “High quality naturally leads to higher productivity,” for more about this case.) Team A skimped on design and concentrated on coding; their system failed or misbehaved daily. The “commando squad” that Team A formed to get their system up and running again after each failure received a public award for outstanding customer service. In contrast, Team B built their system according to solid software engineering principles; it worked well, despite coming in a few months late. That team received no award or recognition.
Management clearly favored the Team A heroes who put out the fires over the Team B practitioners who quietly prevented fires by following high-quality development practices. Morale on Team B initially suffered when management treated them as losers for being late while lauding the first team’s heroic efforts. But when Team A’s system collapsed, Team B’s morale improved as they took pride in their solid achievements. Which group would you prefer to work with? I’ll take Team B.
An organization’s culture is usually intangible, an unspoken understanding of how people work together and what’s important to them. Some companies codify significant elements of their culture in employee handbooks (Pronschinske, 2017). Public communication like that keeps the cultural values visible and facilitates sharing them with new team members.
In his book Software Teamwork, Jim Brosseau (2008) recommends that teams adopt a team contract, an agreement that identifies common values, rules of engagement, and norms of behavior they can all live by. Each team should craft its own contract, rather than accepting one imposed by management, inherited from another team, or discovered online. The team contract should reflect each team’s specific nature, but it also needs to mesh with other teams and the company as a whole. The team contract should be a working, living document to which people refer periodically and update as needed. It might contain statements such as these (Resologics, 2021):
• We use a respectful debate system for consensus decision-making.
• We arrive on time for meetings and other scheduled activities and respect the agenda.
• Team members are expected to complete all tasks to which they have committed by their due dates.
• We can disagree among ourselves, but we present a unified position outside the team.
• We welcome multiple perspectives and contrary opinions to maximize our collective creativity.
Making cultural factors explicit helps all team members buy into shared values, which leads to improved collaboration. Writing an explicit team contract lets team members refine and sustain it over time. The contract helps new team members fit in and understand how they can contribute to the existing culture. Teams are most productive and team members happiest when their essential needs are satisfied (Hilliard, 2018):
• A safe and comfortable physical environment
• A collaborative environment of integrity and openness
• Team emotional cohesion and mutual support
• Challenging and purposeful—but feasible—work
• The right tools
• Self-determination and autonomy in the work they perform
• Opportunities to contribute technically and to grow professionally
IT is an unusual technical discipline in that it attracts—and benefits from the presence of—people with a broad range of backgrounds, characteristics, and perspectives. Beyond the obvious value of ethnic, racial, gender, age, and ability diversities, people having experience in mathematics, engineering, science, creative design, psychology, business, and other fields all bring something to the project and the culture (Mathieson, 2019). A development group full of hardcore technology experts will be enriched by the presence of people with strong soft skills and application domain knowledge.
Effective teamwork requires alignment toward common goals and the mechanisms to achieve those goals. New team members bring their own cultural baggage, both positive and negative. As you interview candidates to join the group, try to judge how well they would merge with your culture.
I once interviewed a developer named Danielle, who was technically solid but balked at our longstanding practice of recording daily metrics on how we spent our time on projects. I explained that we used the data only to understand our project work and help us plan better. Danielle said she simply wouldn’t do that; she wouldn’t explain why. Maybe she’d had a previous bad experience with a manager who misused metrics data to reward or punish individuals. I appreciated her honesty, but Danielle didn’t get an offer. I wasn’t willing to take the risk of hiring someone who I knew right away would have a cultural clash with the group. I hired three other developers at that time who fit in quickly and contributed constructively to our continued cultural evolution.
It’s worth understanding why a person objects to certain aspects of your current culture or the direction it’s heading. They might have a valid point that you’re too close to notice. Perhaps they’ve seen a better approach used elsewhere, or maybe they’ve encountered some long-term downsides of a particular practice or value that you haven’t hit yet. That perspective alone can help enhance the team’s culture.
You can quickly tell whether some people will mesh well with the rest of the team. Shortly after a developer named Gautam joined my group, we held a group lunch. Another team member, Angie, was always careful about her diet. She would never order a dessert at our occasional lunches, but she enjoyed sampling a bite of other people’s desserts. When Gautam’s dessert arrived, he handed his plate to Angie without a word. I knew then that Gautam would fit in just fine, and he did.
A few years later, I transferred to a different corporate division where Gautam had grown into a skillful manager. He understood how to lead teams effectively, and I was perfectly comfortable reporting to him. In this chapter, I describe seven lessons that I—and Gautam—learned about culture and teamwork.
I suggest you spend a few minutes on the following activities before reading the lessons related to culture and teamwork in this chapter. As you read the lessons, contemplate to what extent each of them applies to your organization or project team.
1. Would you say your organization has a healthy software engineering culture? Why or why not?
2. Can you identify behaviors and actions that managers or team members take that reinforce a focus on a quality-oriented culture?
3. Have you observed any culture-killing behaviors that negatively influence team members’ attitudes, morale, or behaviors? Reversing recurrent culture killers is an obvious place to start improving your work environment.
4. How well do you understand your company’s culture? Does your software team’s culture fit into the company’s culture appropriately? If not, what can you do to adjust the fit?
5. Identify any problems—points of pain—that you can attribute to shortcomings in your culture and how people interact both within and across teams. Identify root causes and impacts. What are the tangible and intangible costs of those shortcomings?
6. State the impacts that each problem has on your ability to complete projects successfully. How do the problems impede achieving business success for both the development organization and its customers? Cultural deficiencies can lead to people who won’t exchange information with others, don’t accept or fulfill commitments, or bypass established processes. Morale problems and staff turnover indicate that the culture has some problems.
7. For each problem from Step #5, identify the root causes that trigger the problem or make it worse. Problems, impacts, and root causes can blur together, so try to tease them apart and see their connections. You might find multiple root causes that contribute to the same problem, as well as several problems that arise from a single root cause.
8. As you read this chapter, list any practices that would be useful to your team.
I used to work with a software developer named Stephan. Stephan was territorial about his knowledge. If I asked him a question, I could almost see the wheels turning in his head: “If I give Karl the full answer to his question, he’ll know as much as I do about that topic. That’s not acceptable, so I’ll give him half of the answer and see if he goes away.” If I came back later seeking a complete response, I might get half of the remaining answer. In this way, I asymptotically approached getting the complete answer to my question.
Extracting information bit by bit from Stephan was annoying. The information I sought was never confidential. We both worked at the same company, so we should have been aligned toward our joint success. Stephan apparently didn’t agree with me that freely sharing knowledge with your colleagues is a characteristic of a healthy software culture.
Knowledge isn’t like other commodities. If I have three dollars and give you one of them, now I have only two dollars. Money is zero-sum in the sense that I must lose some of it for you to gain something in this transaction. In contrast, if I give you some of my knowledge, I still possess all the knowledge myself. I can share it with other people, as can you. Everyone touched by this expanding circle of knowledge benefits.
Some people hoard information out of insecurity. They fear that if they share some of their precious hard-won knowledge with others, those other people become more competitive with them. It’s flattering for someone to ask for your help. The requester is acknowledging your superior experience and insights. Rarely, someone might ask you for information because they’re lazy and don’t want to figure it out themselves. You don’t have to do someone else’s work for them, but you should remember that you and your teammates are all working toward the same ends.
Other people carefully protect their knowledge as a form of job security. If no one else knows what they know, the company can’t possibly fire them because too much institutional knowledge would go out the door. Maybe they think they should get a raise because they’re the sole holder of so much important information. People who conceal organizational knowledge pose too much risk. They create an informational bottleneck that can impede other people’s work. My colleague Jim Brosseau aptly refers to knowledge hoarding as technical ransom (Brosseau, 2008). Information hiding is an excellent practice for software design; for software teams, not so much.
A healthy organization fosters a culture of free knowledge exchange and continuous learning. Sharing knowledge enhances everyone’s performance, so management rewards people who freely pass along what they know, not those who keep it to themselves. In a learning organization, team members feel that it’s psychologically safe to ask questions (Winters, Manshreck, and Wright, 2020). We’re all ignorant about most of the knowledge in the universe, so let’s learn from our colleagues when the opportunity arises.
Experienced members of an organization can share their expertise in many ways. The most obvious method is simply to answer questions. But more than just answering questions, experts should invite the questions. They should appear approachable to fellow employees, particularly novices, and be thoughtful and patient when someone picks their brains. Beyond simply transferring information, experts can convey insights about how to apply the knowledge to specific situations.
Some organizations use formal mentoring programs to get new team members up to speed quickly (Winters, Manshreck, and Wright, 2020). Pairing new employees with experienced colleagues greatly accelerates learning. When I began my professional career as a research chemist, I was the first guinea pig for a new mentoring program. My mentor, Seth, was a scientist in the same group I had joined, but he wasn’t in my reporting chain. I felt comfortable asking Seth questions that otherwise might have awkwardly revealed my ignorance to my manager. Seth helped me get rolling in an unfamiliar technology area. A mentoring or “buddy” program reduces the learning curve for new team members and starts building relationships with them immediately.
One-on-one communications are effective, but they don’t scale well. Experienced, talented people are much in demand, both for their project work and for the expertise they can share. To cultivate a knowledge-sharing culture, consider techniques to leverage information more efficiently than one-on-one time spent together. Here are several possibilities.
My software development team once decided to work through the many excellent programming examples in Steve McConnell’s classic book Code Complete (McConnell, 2004). We took turns studying a particular section and then describing it to the group in a lunch-and-learn session. These informal group learning experiences efficiently disseminated good programming practices across the group. They facilitated a shared understanding of techniques and a common vocabulary.
Formal technical presentations and training courses are good ways to communicate institutional knowledge across an organization. I developed several training courses when I worked at Kodak and delivered them many times. If you set up an internal training program, line up enough qualified instructors so one individual doesn’t have to teach the same courses all the time.
Written knowledge spans the spectrum from specific project or application documentation to broadly applicable technical guides, tutorials, FAQs, Wikis, and tip sheets. Someone must write this documentation, which means they aren’t spending that time creating other project deliverables. Written documentation is a highly leverageable organizational asset, provided that team members turn to it as a useful resource.
I’ve known people who preferred to rediscover knowledge on their own rather than seeking it from existing documentation. Those people didn’t heed Lesson #7, “The cost of recording knowledge is small compared to the cost of acquiring knowledge.” Once someone has invested the time to create relevant and useful documentation, it’s a lot quicker to read it than to reconstruct the same knowledge. All organization members should be able to update such documents to keep them valuable as current sources of pooled experience.
When I worked in a large product-development organization, our process improvement group built an extensive online catalog containing high-quality templates and examples of many project deliverables (Wiegers, 1998b). We scoured company software departments for good requirements specifications, design documents, project plans, process descriptions, and other items. This “good practices” collection provided a valuable jump-start whenever any software practitioner in the company needed to create some new project artifact.
Peer reviews of software work products serve as an informal mechanism for exchanging technical knowledge. They’re a great way to look over other people’s shoulders and to let them peek over yours. I’ve learned something from every review I’ve participated in, whether as a reviewer or as the author of the item being reviewed. The technique of pair programming, in which two people write code together, provides a form of instantaneous peer review, as well as exchanging knowledge between the programmers. See Lesson #48, “Strive to have a peer, rather than a customer, find a defect,” for more about reviews.
Rather than trying to locate exactly the right person when you have a question, you might post it to a discussion group or group chat tool within your company. Exposing your lack of knowledge to a large community can be awkward. That’s why it’s valuable to grow a culture that invites questioning and rewards those who assist. Ignorance is not a tragedy, but an unwillingness to solicit help is.
Discussion participants can offer multiple perspectives on your question quickly. The posted responses are available to everyone in the discussion, which further disseminates the knowledge. You probably weren’t the only person who didn’t know the answer to that specific question, so good for you for asking. I have a friend who’s the most curious person I know. He’s willing to ask anyone he encounters in daily life about things he sees them do that are unfamiliar to him. He’s learned a lot that way, and the people he asks are always happy to share what they know.
Everyone has something to teach—and to learn. When I managed a software development group, I hired a graduate student in computer science as a temporary summer employee. I confess that at first I was skeptical about his understanding of practical software engineering. Similarly, he had some disdain for the process-driven approach our group advocated. After just a few weeks, though, I gained respect for his contemporary programming knowledge, which far exceeded mine. And he acquired an appreciation for how sensible processes can help teams be more effective. We both grew by being open to what each other had to exchange.
You don’t need to be the world’s expert on some topic to be helpful. You just need some useful block of knowledge and the willingness to share it. In the world of technology, if you’re one week ahead of the next person in some area, you’re a wizard. Someone else will doubtless be ahead of you in other areas, so take advantage of that. People in a healthy learning culture share what they know and also acknowledge that someone else might know a better way.
In the mid-1990s, I led a formal software process improvement initiative in a product-development division of 450 engineers that made digital imaging products full of embedded software. Like many big organizations back then, we used the Capability Maturity Model for Software (CMM) to guide our process improvement efforts (Paulk et al., 1995). The CMM was a five-level framework to help organizations systematically improve their software engineering and management practices. My manager and I had a meeting with the division director, Martin, to discuss our status and goals.
Martin balked at my proposed timeline. By carefully assessing our organization’s current status and the gaps we needed to close to achieve the goal, our team had concluded that eighteen months was a realistically achievable target. Martin, who I fear didn’t fully understand the challenges, demanded six months. He wanted to be the first director among his peers to achieve the next process milestone. I explained why we believed that was unrealistic. Like the aggressive manager he was, Martin replied, “Don’t tell me you can’t do it. Tell me what I must do to enable you to do it.” That sounds like a nicely supportive posture, but it wouldn’t magically solve the problem. Martin reluctantly offered twelve months, but I was positive that goal still was not achievable under any conditions.
As he continued to pressure me to promise results that I knew I couldn’t deliver, I finally said, “I’m sorry, Martin, but I can’t commit to that.” He stared at me.
“You can’t commit,” Martin said flatly. “Hmmm.” It was as though no one had ever resisted his pressures before, and he wasn’t sure how to respond. Martin reluctantly accepted our proposed target goal after I assured him that we would work as hard as we could to get there as quickly as possible and would enlist his assistance whenever he could help. Later, back at the office, I heard that my manager—who was a good guy—was telling people, “Karl told Martin he wouldn’t commit!” But my manager trusted my judgment.
My pulse rate had shot up as Martin leaned on me. However, it would have been unethical and unprofessional to make a commitment I knew I could not fulfill. It also would have been wrong for me to make a promise that put excessive pressure on my teammates by overriding our thoughtful analysis.
People rarely take commitments they make under duress seriously. Nor do they take seriously commitments that someone else makes on their behalf without consultation and negotiation. Imposing an impossible commitment increases the victim’s stress level, but it rarely achieves a miracle. People might even relax their effort if they know they can’t make the unachievable goal. Why kill yourself if you’re doomed to fail regardless?
A commitment is a promise that someone makes to perform an action or deliver some body of work in a certain quality state at a specific time. Commitment management is a component of project management, as I described in the introduction to Chapter 4. The concept of not making commitments that you know you can’t keep is a personal ethic. It also reflects sound project and people management.
Commitments accumulate in dependency chains, like the one shown in Figure 5.1. Each commitment recipient depends on those who made the commitments to deliver. If everyone negotiates achievable commitments in good faith, they can rely on each other with confidence (Wiegers, 2019d). Otherwise, the commitment chain is a house of cards. Any unfulfilled lower-level commitments will topple the deck.
As a consultant and author, my practice is to undercommit and overdeliver; I did the same when I was a corporate software developer. Maybe that makes me look overly cautious at times, but it also makes me reliable. One way I stay on schedule is to build contingency buffers into my commitments to account for estimation uncertainties, changing requirements, and other surprises. These buffers provide a safety net in case things don’t go as I had planned. I set myself personal targets that are more aggressive than the commitments I make to others. Then, I work diligently toward the internal goal, knowing that if I don’t quite make that target, I’ll still be on track for the external commitment. More often than not, I deliver early. Everyone likes that outcome.
People make commitments with the best of intentions. Then life happens, and sometimes things change. A new assignment or opportunity might arise that diverts time, or the work could be larger than anticipated. Maybe the individual just loses interest in the original commitment and lets it fall by the wayside, hoping no one will notice. But they do notice.
If you discover that you can’t fulfill a commitment as intended, for whatever reason, tell those affected as soon as possible so they can adjust their plans accordingly. When someone makes a promise to me, I count on them to deliver. If my original expectation isn’t realistic, let’s talk. Maybe we can reach a mutually acceptable and achievable agreement. But I also recognize that the other person might not come through for various reasons.
I encounter a broken-commitment situation with every book I write. I always line up several volunteer manuscript reviewers to help improve my writing. I need my reviewers’ input on specific chapters by particular dates. No reviewer has ever protested that my dates are unrealistic, and yet with every book, some people provide zero feedback. On my last book, nine of the twenty-six reviewers provided no input or explanation (volunteers, remember). It’s as though they took a vow of silence right after we got started.
If I say I’m going to do something, either I do it, or I explain that I cannot do it after all, with apologies. We all know that situations and priorities can change. If a manuscript reviewer can’t contribute to the project, I just wish they’d let me know as soon as they can so I can make adjustments. It’s a simple courtesy.
I also never received a cover blurb for one of my software books from another author who volunteered to contribute one. Since the book was published twenty-five years ago, it looks pretty doubtful that I’ll see that blurb. But he never told me he wouldn’t do it after he committed. That’s all I ask.
Several of my consulting clients complained to me that their management told them to do more with less, to be more productive with fewer people. When I asked, “What’s being done to enable you to do more with less?” I always got the same answer: “Nothing.”
Those demands don’t seem reasonable to me. The senior managers appeared to think the software people had idle time on their hands. Were they working at less than full speed with some reserve capacity to exploit if only they were pressed? I doubt that’s the case. Cracking the whip and demanding that the horse run faster doesn’t work if the horse is already going as fast as it can. At the risk of overstretching the metaphor, you need to understand why the horse isn’t running as fast as you want and then find the acceleration opportunities.
Teams can be motivated (or pressured) into working extra hard for a short-term goal, but not indefinitely. Tired people make more mistakes—which leads to time-sapping rework—and they get burned out. If the pressure goes on for too long, people will leave or revert to a normal pace despite management’s rantings. Heroic efforts are not a sustainable productivity strategy.
“Doing more with less” means delivering more functionality sooner with a smaller team. If you can’t have as many people as you believe you need to achieve compressed schedules, what variables can you manipulate? The options include better processes, better practices, better tools, and better people. Hiring a few top performers is better than staffing a larger team with average performers (Davis, 1995). However, you can’t just swap out your team for a new set of more capable people. You need to make the people you have more productive.
If you need greater productivity, the first question to ask is, “Why isn’t our productivity already as high as we’d like?” Answering this question requires reflection and analysis. Begin any solution hunt by identifying the problem’s origins. (See Lesson #51, “Watch out for ‘Management by Businessweek,’” for a discussion of root cause analysis.) Look back at previous projects to see where there might have been opportunities to work more efficiently and effectively. Once you understand the root causes of insufficient productivity, you can search for solutions. Questions to consider include these:
• What are your teams doing that they don’t need to do?
• What are people currently doing that adds value and could perhaps be leveraged further?
• What are your teams not doing that would accelerate their work if they did?
• What else slows us down?
• How can individuals become more productive?
One way to improve productivity is to stop doing work that doesn’t add proportionate value to the project, the product, or the customer. Is there any unnecessary process overhead? Be careful, though: process steps that don’t provide immediate value often pay off later, so consider the risks before dropping some activity. Do pointless, overly long, or overcrowded meetings waste time? I have a friend who worked for a meeting-crazy technology company. Some meetings simply prepared reports to feed into the next meeting with another group of people just one hour later. She had a hard time getting any work done in that environment.
A second productivity-boosting strategy is to improve the quality of the team’s products. That could mean incorporating additional quality-related practices. Unplanned, excessive rework kills productivity. Instead of moving on to build the next component, team members must redo completed work to repair defects. (See Lesson #44, “High quality naturally leads to higher productivity.”) Adding proven practices like static code analysis and peer reviews consume time, but they more than pay for themselves by reducing downstream rework. Emphasizing design over refactoring reduces technical debt that the team must repay later. It’s a matter of going slow to go fast, a lesson that every craftsman quickly learns. A related saying that applies to many disciplines is, “Slow is smooth, smooth is fast.”
Third, removing barriers to productivity means understanding where time gets wasted. Must people often wait on others before they can proceed with their next step? You can improve throughput by accelerating activities that lie on the critical path to completing a piece of work. Are some team members losing productivity through excessive multitasking? Revisit Lesson #23, “Work plans must account for friction,” to see if any of the sources of project friction described there are impeding progress.
Your fourth productivity improvement lever is to enhance individual team members’ capabilities. I always assume that people do the best job they can, given what they know at the time and the environment in which they work. Both the physical and cultural working environments affect a software developer’s productivity and quality performance (Glass, 2003; DeMarco and Lister, 2013). Selecting appropriate new processes and technical practices can yield significant quality improvements, further boosting productivity. Growing a healthy software engineering culture that motivates and rewards preferred behaviors contributes to efficient work from a happy team.
A manager who wants higher productivity will provide team members with office space that permits their best work, with sufficient square footage, facilities, privacy, and freedom from distractions. When I was at a consulting client’s site once, I was appalled at my main contact’s workspace. His desk sat inches from his neighbor’s. There was barely room around his desk to bring in a chair for me. He had to twist awkwardly to lay out some papers for me to look at on a corner of his desk. No one could work efficiently in that cramped, no-privacy environment. Unfortunately, a software manager informed me recently that, “A manager generally can’t affect office space nowadays, and a huge number of cube farms are indeed that bad.” That’s a discouraging commentary.
The right tools can enhance productivity. The software tool industry has a long history of touting impressive, even order-of-magnitude improvements in productivity if you’ll only buy their latest version. In reality, the productivity gain from a single new tool rarely exceeds 35 percent (Glass, 2003). Software developer productivity has increased impressively over the years through the accumulated benefits of multiple tools, new languages and development practices, reuse of open-source software and common libraries, and other factors, but there’s no single silver-bullet tool. Remember to account for the learning curve as people figure out how to make the new tool work effectively for them. Look for tools that can automate—and document—repetitive tasks like testing.
Training is a powerful performance enhancement lever, provided that the people who get trained apply what they learn back on the job. Overwhelmed managers trying to do more with less might hesitate to pull team members away from their keyboards for training, and training courses are expensive. When I managed a small software group, I routinely overran my training budget, with solid upper-management support. I had friends in another department that had no budget for books. That struck me as ridiculous. Suppose you spend forty dollars on a technical book and read it mostly on your own time. If you save even one hour on your work—any time during the rest of your life—from something you learned in the book, you more than paid for it. The investment in learning pays for itself every time you apply a new practice that yields better, faster results.
Everyone likes to think that their team has top-flight talent; they want to hire only the best developers. However, the fact is that half of all software developers lie below the median of the performance distribution. Those people all work somewhere, and not everyone can hire from the pool’s top echelon. It’s not easy to quantify software developer performance, but who does the work significantly affects a team’s productivity and quality.
Numerous software literature reports have indicated a ten-fold or greater range between the top and bottom performers among software developers (Construx, 2010; McConnell, 2010). And it’s not just developers. People in other project roles—business analyst, tester, product owner—also can vary widely in their performance. However, a recent report by Bill Nichols of the Software Engineering Institute (2020) avers that the 10X ratio of programmer performance is a myth. Nichols’s data indicates that an individual’s own day-to-day variation accounts for about half of the observed performance difference between developers.
My personal experience suggests that the 10X ratio is not implausible. I used to work with a developer who did high-quality, creative work. But he did it less than half as fast as I could do the same job. I also worked with a senior developer who was at least three times as productive as me. His dual master’s degrees in computer science and computer engineering gave him the skills to efficiently tackle complex problems I simply couldn’t handle. Also, he had accumulated an extensive library of reusable components over his career that saved him a lot of time. The three of us thus spanned at least a six-fold performance range.
There’s no question that skilled and talented individuals and teams are more productive than others. Not surprisingly, The Standish Group (2015) reported that projects staffed with “gifted” agile project teams were substantially more successful than those with unskilled teams. As an interesting corollary, small projects had a higher success rate than larger projects, perhaps partly because it’s easier to staff a small team with highly capable individuals. Not everyone gets to be, work with, or hire the top technical staff. As Nichols (2020) points out, “Finding a consistently superior programmer is hard, finding a capable programmer is not.”
If you can’t assemble an all-star team (avoiding arrogant prima donnas in the process), focus on creating a productive environment to get the best results from the people you have. Enhance everyone’s talent by sharing local best practices. Observe what makes your most outstanding performers—everyone knows who they are—so good and let everyone learn from them (Bakker, 2020). Technical skills are important, but so are communication, collaboration, mentoring, lack of territoriality, and an attitude of shared product ownership. The best developers I’ve known had a strong focus on quality. They were nondogmatic and intellectually curious with a breadth of experience, a focus on continuous learning, and a willingness to share.
If you must do more with less, you’re not going to get there by decreeing it, putting more pressure on your team, or hiring only at the ninetieth percentile of talent. The path to increased productivity inevitably involves training, better practices, and improved processes.
Life brings us many freedoms, along with corresponding obligations. You have the right to own a car, but you also must register and insure it. Along with the right to buy real estate comes a requirement to pay property taxes. As a citizen, you have the right to vote, but you also have a responsibility to make your voice heard at the ballot box.
The combination of rights and responsibilities defines how people fit into society. The United States has a Bill of Rights, the first ten amendments to the United States Constitution. However, there’s no corresponding Bill of Responsibilities. Citizens’ responsibilities are embodied in thousands of statutes and regulations in countless jurisdictions. We also have social responsibilities to our fellow residents of Planet Earth, just because we’re all here together.
People on software projects also have rights and responsibilities. We can organize these two sides of the coin by considering the people we interact with, the rights we expect from them, and our responsibilities to them. Individuals have these rights-responsibilities connections with their fellow team members, customers, managers, suppliers, and the general public. As we work with our collaborators, we should hold conversations along these lines: “Here’s what I need from you for us jointly to be successful on this project. What do you need from me?”
Beyond the specific responsibilities of individual commitments we make to others, all software practitioners are responsible for conforming to professional ethics. The two major computing organizations, the Association for Computing Machinery and the IEEE Computer Society, jointly established The Software Engineering Code of Ethics and Professional Practice (ACM, 1999). This code addresses a practitioner’s responsibilities to act in ways consistent with the public interests, maintain confidentiality, respect intellectual property ownership, strive for high quality, and so forth. All software professionals should become familiar with this guide and adopt a personal code of ethics for responsible software development (Löwe, 2015).
There’s a symmetry between software professionals’ rights and responsibilities. Suppose the people in group A have a right to some service or behavior from people in group B. Members of group A, in turn, have some responsibilities to those in group B. You can imagine crafting a bill of responsibilities to accompany each bill of rights for these pairwise relationships. Alternatively, you could devise complementary bills of rights for both parties involved in a relationship, with the corresponding mutual responsibilities implied.
Below are a few examples of rights and responsibilities for some groups involved in software development, drawn from several sources; there are many other suggestions about these topics out there (Atwood, 2006; StackExchange, n.d.). Consider reading the full source of each example for more ideas about professional rights and responsibilities that apply in your context. You might find it helpful to itemize your personal views of rights and responsibilities to help your project stakeholders collaborate more smoothly. If you’re uncomfortable with the formalism of writing down rights and responsibilities, consider phrasing these ideas in the form: “It’s generally reasonable for me to expect X from you, and it’s reasonable for you to expect Y from me.”
As a customer, you have a right to expect a business analyst (BA) to learn about your business and your objectives. You have a responsibility to educate BAs and developers about your business (Wiegers and Beatty, 2013).
As a customer, you have a right to receive a system that meets your functional needs and quality expectations. You have a responsibility to dedicate the time it takes to provide and clarify requirements.
As a customer, you have a right to change your requirements. You have a responsibility to communicate requirement changes to the development team promptly.
As a developer, you have a right to have your intellectual property acknowledged and respected by others. You have a responsibility to respect others’ intellectual property rights by reusing their work only with permission (St Augustine’s College, n.d.).
As a developer, you have a right to know the priority of every requirement. You have a responsibility to inform the customer of the schedule impact of new and reprioritized requirements.
As a developer, you have a right to make and update estimates for your work. You have a responsibility to make your estimates as accurate as possible and to adjust schedules to reflect reality as quickly as possible (Wikic2, 2006; Wikic2, 2008).
As a project manager or sponsor, you have a right to expect developers to produce high-quality software. You have a responsibility to provide the environment, resources, and time to enable developers to produce high-quality software.
As a project manager or sponsor, you have a right to set project goals and establish schedules. You have a responsibility to respect developers’ estimates and to avoid pressuring developers to accomplish work in unrealistic time frames.
As a member of a self-managing, autonomous Scrum team, you have a right to manage your capacity, control how you execute a sprint, and establish when a piece of work is done. You have a responsibility to determine a sprint goal, create a sprint backlog, assess daily progress toward the sprint goal, and participate in a retrospective to assess how the sprint went and create an improvement plan (Ageling, 2020).
You might think you’re entitled to a certain right from some other community, but maybe they’re not able or willing to meet your expectation. Whenever you encounter a mismatch like that, the parties must learn how to work together constructively and without rancor. It’s worth the time for collaborators to discuss their mutual rights and responsibilities, perhaps recording them to avoid misunderstandings. This dialog is a form of expectation management, which was explained in the introduction to Chapter 4.
I’ve long had a philosophy in my close personal relationships to deal with a concern before it becomes a crisis. That’s a good practice with our professional interactions as well. Most people mean well, even if sometimes it isn’t obvious at first glance. Reaching shared understandings regarding rights and responsibilities helps avoid unpleasant interpersonal crises.
Our greatest responsibility is to treat all of our professional counterparts fairly and with respect. We should all be able to do that.
In Lesson #12, “Requirements elicitation must bring the customer’s voice close to the developer’s ear,” I described my experience of writing software for a scientist named Sean, who sat close to me. I was highly productive because of the quick feedback I could get from him when necessary. In the middle of our project, Sean moved to an office on the other side of the building. My productivity promptly took a hit. Now I couldn’t catch Sean’s attention at a moment’s notice to answer a question, decide on a user interface option, or refresh my memory. The separation increased the cycle time on resolving even simple issues. The realization that such a modest distance could impair my development productivity was a powerful insight.
Out-of-sight separation makes it harder for people to interact informally. As Figure 5.2 shows, when I was working on Sean’s project, I could glance up from my desk and see if he was in his office. If he wasn’t there, I’d work on something for which I didn’t need his input. That visibility let me optimize my productive time without having to wait for an answer to proceed.
After he moved, I had to try to reach Sean by phone, send an email, wait for our regularly scheduled meeting, or walk to his new office and see if he was in. The separation problem gets far worse when collaborators are strewn across multiple time zones. The same issue affects daily life too. I have a friend who frequently calls me after he’s eaten supper, but since he lives one time zone to the east of me, I’m always sitting down to eat right about then. His calls come at a time that’s convenient for him but inconvenient for me. Asynchronous communication works across time and space, but it’s slower than talking to someone in real time.
The more time zones that are involved, the bigger the connection problem is, and the less overlap time you have during regular work hours. One project had people in several countries that spanned twelve time zones—halfway around the world. Any time they chose for their videoconferences would be awkward for some of the team members. They rotated their meeting times to inconvenience everyone about equally. This courtesy conveyed an important cultural signal: it demonstrated respect for everyone’s time and indicated that the people in all locations were equally significant to the project. No one location should feel subordinate to another.
Designing office spaces to promote collaboration while retaining privacy for focused work is a delicate balance. Ideally, the manager can accommodate each team member’s preferences while still providing good interaction opportunities. As we saw in Lesson #23, “Work plans must account for friction,” knowledge workers are most productive when they enter a state of flow, deeply immersed in a task. Flow requires freedom from distractions and interruptions. So while people should be close enough to interact readily, they also need private space for concentrated focus.
Having a customer nearby is excellent for the development team because they can get questions answered quickly. But think about it from the customer’s perspective. Sean wasn’t just a chatbot patiently awaiting my next inquiry. He was a research scientist trying to get his own work done. Every question I posed, every request to review a display screen or report, interrupted Sean’s state of flow. Proximity is valuable, but we must also be sensitive to everyone’s need to get their work done with minimal interruption.
More and more software professionals work remotely, either by choice or because of the COVID-19 pandemic, thereby possibly rendering moot the debates over how best to design shared office spaces. Virtual teams pose their own massive set of cultural and collaborative challenges, though. It’s hard to get to know and understand coworkers you’ve never met in person, let alone to build—or integrate into—a shared culture of values and practices. My friend Holly, a BA, described her recent experience:
Until I had to do it myself, I didn’t fully comprehend the challenges involved in creating strong virtual teams. I recently took a new position that is 100 percent remote. The activities I’m performing aren’t new to me, but they’re different now. The expected startup aspects—meeting my new teammates, learning my new organization’s language and communication styles, locating relevant documentation, identifying the technology critical to supporting my role—are all familiar and yet vastly new. Meeting culture has taken on new levels of agony in this new remote world, too. People don’t walk to meetings any longer; we click out of one meeting and into the next one. Where have our bio breaks gone??
A web search for “challenges of virtual software teams” yields numerous articles that address the many issues involved. If you’re in a remote-working environment, it’s worth the time to understand the major challenges and consider how best to succeed in the world of virtual teamwork.
A closed door is a communication barrier. It can be either a benefit or a nuisance, depending on which side of the door you’re on. I’ve worked in private offices with and without doors, in shared offices, and in landscaped areas with a vast sea of cubicles. The office cluster shown in Figure 5.2 had a door to the corridor, but our three individual offices lacked doors. A visitor coming to see any one of us in the cluster distracted the others.
Fellow employees dropped by my office frequently with computer questions. Eventually, I posted a sign outside my doorway that said “The Virtual Door Is Open” on one side and “The Virtual Door Is Closed” on the other. I hoped that people would recognize when I didn’t want to be disturbed. Boy, was I naïve. Most visitors would read the sign and then say, “‘The Virtual Door Is Closed,’ that’s pretty funny. Hey, I’ve got a question.” So that strategy failed. I’ve heard of people who used an orange traffic safety cone or a velvet rope like those seen in movie theaters as a signal to indicate that they were working intently and would prefer not to be interrupted.
I did eventually get an office with a real door, which let me get more work done. Frequently-consulted experts in some companies set up office hours, during which they invite colleagues to come by for discussions (Winters, Manshreck, and Wright, 2020). Maybe it’s not as timely for the person with the question, but it does reduce the expert’s interruption frequency.
Several years later, I moved to a different building with a completely different culture and environment. I was in cubicle land to an extreme degree. We all had five-foot partitions around our desks, except for the managers, who had private offices (of course). My cube was one of the noisiest spaces in this entire quarter-mile-long building. I sat adjacent to the main corridor running down the building’s length, by the top of the escalator, near the bathrooms, and near the meeting and training rooms. Four feet from my desk was the coffee machine, where students would congregate and chat during breaks in training classes. The one good thing about my location was that leftover cake from celebrations was dropped off on the coffee machine’s table. I don’t drink coffee, but I do enjoy cake.
I’m easily distracted by irritating noises that many other people don’t even notice. It took at least two months for me to tune out the distractions in that open space and concentrate on my work. While the open areas facilitated interaction with the people around me, it was highly stressful until I finally adapted to the noisy environment.
There’s no perfect solution to designing workspaces to satisfy the needs of privacy, freedom from distraction, proximity to colleagues for quick interactions, and shared space for project meetings. Geographical separation is problem enough; overlaying cultural differences greatly increases the challenges for effective collaboration. Collaboration tools help geographically separated people work together, but they’re not a complete substitute for real-time, face-to-face interactions. To the extent possible, managers should let the team members design their workspaces to best balance these conflicting goals (DeMarco and Lister, 2013). If that doesn’t work, I recommend headphones or earplugs.
Bill Gates and Paul Allen, Steve Jobs and Steve Wozniak, Bill Hewlett and David Packard—I’m guessing that none of them had written specifications or procedure books for their early projects. A mind meld between pairs of super-talented wizards who work side-by-side obviates the need for most documentation. But it’s hard to scale a mind meld across time, space, and hundreds of brains thinking in different languages and immersed in different cultures.
Figure 5.3 shows a qualitative scale of project complexity. Projects span the extremes between a couple of geniuses working in a garage and a cast of thousands building the International Space Station (the largest project I could think of). As organizations grow, they take on larger and more complex projects. The two geniuses hire some other people, move out of the garage, and tackle projects with a dozen or two technical people in one location. If you build a product with software embedded in a hardware device, your team will include mechanical and electrical engineers. At some point, you might acquire another company in a different city or otherwise partner with people over the horizon in a distributed development project. Companies that build huge, complex products (think airplanes) can have software engineers, hardware engineers, and many other specialists working on dozens of subprojects in multiple countries. Big challenges demand appropriate approaches.
As teams, projects, and organizations grow, the need to beef up their processes sneaks up on them. They might recognize the need only after they encounter a problem. Maybe two teams overwrote each other’s work, or a task was overlooked because everyone thought someone else was going to do it. Those issues call for better planning, coordination, and communication between team members and groups. Sources of friction and delays creep in as more people are involved, particularly when they’re in different locations.
Larger projects call for writing down more information, so others know what’s going on and what lies ahead. A persistent group memory of requirements, decisions, business rules, estimates, and metrics begins to look useful. The farther apart team members are, the more process structure they need, and the more they must rely on remote collaboration tools.
For compatibility and facile information exchange, teams in multiple locations need common tools for task management, modeling, testing, continuous integration, and particularly code management (Senycia, 2020). Open-source software is an extreme example of distributed software development. Contributors to an open-source project can live anywhere in the world. A mass of people who participate in ever-evolving projects need to follow some consistent processes to ensure all the pieces will fit together. As Andrew Leonard (2020) pointed out, “No single innovation was more critical to the facilitation of successful remote collaborative software development than the all-important job of version control.”
I started out in software writing programs for college classes, for my personal use, and for amusement. Then I began writing programs for other people to use and some small commercial apps. Later, I joined forces with other software developers to take on larger projects. While working on a project by myself, I wore all the project role hats in turn. Depending on what I was doing at any particular moment, I might be functioning as a BA, designer, programmer, tester, documentation writer, project manager, or maintainer.
It’s not realistic to expect every team member to be fully proficient in all of those technical domains. As projects and teams get larger, some skills specialization is both natural and beneficial. At some point, even Bill Gates and Paul Allen decided they needed to hire people with skills besides programming to keep their fledgling company growing: technical writer, mathematician, project manager, and so on (Weinberger, 2019). I hear it worked out for them.
As we saw in Lesson #14, the number of communication links grows exponentially with the development team’s size. Project participants need mechanisms for exchanging information quickly and accurately. Communication preferences vary also. People instinctively communicate with others in the ways that are most comfortable for themselves, but that’s not always what the other parties prefer.
I once facilitated a retrospective for a project that involved a web development team and a creative design group. During the retrospective, a member of the creative group said that she felt she wasn’t included in project status communications and didn’t always know what was going on. A surprised member of the software team protested, “I copied you in on all of our emails.” We discovered that the two groups had very different communication preferences and wanted to receive status updates differently.
In this case, the teams were not geographically far apart, but they definitely had some stylewise separation. As you move to projects involving multiple groups of people, it’s important to lay the foundation early on to communicate in ways that work for everyone. Similarly, the groups might make decisions differently. To avoid hard feelings and speed up decision-making, they should discuss how the teams will jointly make decisions—before they confront their first big one.
Successful organizations grow and take on ever-greater challenges. They shouldn’t expect the techniques that worked for a few people in a garage to scale up and span large distances. They can dodge some growth pains by anticipating the processes and tools they’ll need to integrate the various team efforts. It’s less disruptive to build as much infrastructure as possible in advance rather than introducing it to projects in the heat of battle. Having project participants get to know and understand their remote counterparts early in the process can avoid culture clashes. The time spent laying these foundations can prevent a lot of grief down the road.
In Lesson #36, “No matter how much pressure others exert, never make a commitment you know you can’t fulfill.” I mentioned that I once led a process improvement program in a large corporate division. The senior manager of that division—four steps above me on the organization chart—enthusiastically supported the effort. But Martin didn’t fully appreciate everything involved with moving several hundred software and systems engineers into a new paradigm.
Martin seemed to think we could simply write new software development procedures, and everyone would get on board. He rubber-stamped the management policies that we wrote as part of the change framework we were following, but that was it. He didn’t announce or explain the policies, set expectations for how they should be applied, define a migration path to the new ways of working, nor hold anyone accountable for following the policies. Hence, the policies were broadly ignored, and the new procedures had limited impact initially.
This experience revealed that installing a new process is easier than instilling a new culture. A successful change initiative requires both. You can’t just send anybody off to a training class and give them a big honkin’ binder of new procedures (or a thin guide, whichever represents the direction you’re going) and expect everyone to start working effectively in new ways right away. That approach just perplexes and stresses people. It damages management credibility, even in strong cultures.
As I described earlier, a software engineering culture encompasses shared values, behaviors, and technical practices. Engaging team members in the change process increases their buy-in—crafty leaders can make people believe ideas were their own. Members of an organization undergoing a change initiative need to know a lot more than the new practices they’re expected to follow. The change leaders will need to explain
• Why change is necessary.
• What problems it will address.
• What outcomes the organization hopes to achieve as a result.
• The impact on the organizational chart.
• Any new roles, job titles, or responsibilities.
• The expectations of team members as individuals.
• The implementation timeline.
• Accountability for constructively contributing to the change initiative.
For successful culture change, the change leaders must persuade everyone affected of the merits of both the goal and the approach. Persuasion is easier when everyone is well aware of the pain points. A colleague once told me she had never worked on a successful software project. That frustration strongly motivated her to lead process improvement activities to enhance project outcomes and the company’s business success.
Change is hard. Not everyone wants to get on board, and you can’t evolve a culture if people are kicking and screaming, reluctant to leave their comfort zone. However, those individuals who are most uneasy about the change must not hold back the entire initiative. Strive for a sensible balance point between imposing a new way of life by fiat at one extreme and trying to make everyone happy at the other.
Martin said he supported the change initiative in his division, but I’m not sure he was truly committed to it. To me, support is a vague and ambiguous word. When someone says, “I support that,” often what they mean is, “It’s okay with me if that happens” or, “That sounds like a good idea.” The notion of support as tolerance or approval is very different from a commitment. Committed leaders take action and lead by example. They set concrete goals, provide resources, and demonstrate behaviors that are aligned with the intended outcome. They put something of themselves at risk and are accountable for their organizations’ results. Managers who are committed to lasting change know to frame the change in a way that stirs emotions and stimulates actions (Walker and Soule, 2017). Platitudes, mandates, and directives don’t cut it.
Effective change leaders know that it takes persuasion and time to steer team members towards new values and behaviors. People in the organization have three options: they can help lead the initiative, follow along with the program and do their part, or get out of the way. If the magnitude or nature of the change makes some people too uncomfortable, they’ll probably leave; it’s better for everyone concerned if they do. I’ve seen too many cases where people who were unhappy with their organization’s new direction took a passive-aggressive approach. They paid lip service to the evolution but ignored or undermined it whenever they could.
Changing to agile is a major shift in how a software organization operates. I used to say that you can’t buy a culture in shrink wrap and install it like you can a new tool or technical practice, but that’s not entirely true with agile. Migrating to, say, Scrum does involve absorbing a prepackaged culture with a set of values, behaviors, and technical practices. Many aspects of the culture must change when transitioning to agile, including these (Hatch, 2019):
• Organizational structure and team composition
• Values and principles
• New roles, such as Scrum Master and product owner
• Scheduling and planning practices
• The nature of collaboration and communication
• How progress is measured
• Accountability for results
That’s a lot of disruption to absorb all at once. Traditional software process improvement strategies are incremental: new procedures and practices are incorporated into project activities in digestible bites. Switching to agile involves a more abrupt shift of thinking and practice. Simply training everyone isn’t sufficient to gain commitment to the new values, change individual behaviors, and adopt new practices. It takes time for practitioners to unlearn what they’ve done before and to become comfortable and proficient with new ways of working.
I know of two companies that carried out large-scale agile training for hundreds of their software developers. One company promptly dove into a massive strategic project involving more than 150 people in multiple locations, mandated by senior management to be done using agile. After an investment of several years and a huge amount of money, the project was suspended without delivering anything usable.
The second company adopted an enterprise-level agile framework and decreed it for all projects, regardless of how well it fit the project situation. As a friend at that company explained it:
This was a huge transformation. As it affected all of our development practices, procedures, and audit requirements, the aggressive conversion schedule caused problems in areas where insufficient time or training was provided for smooth transitions. The conversion to agile was presented as a finalized decision. Upper management didn’t frame it in terms of solving specific problems within the company, and they didn’t try to talk us into wanting it. There were varying amounts of pushback across the organization. A lot of developers were very unhappy because they were hired as waterfall developers, not agile ones.
In an ideal world, everybody responds to profound change by thinking, “What’s in it for us?” but most people actually think, “Why are you making me do this?” Some people got over this response; some didn’t.
Had management paid more attention to the substantial cultural impacts of these radical, all-at-once transformations, the changes might have been more readily accepted and the results more satisfactory. Time will tell how well these kinds of large-scale transformation attempts succeed.
To achieve the desired business outcomes, a process-oriented and cultural change initiative has two objectives. One is institutionalization. Institutionalization means that new practices, behaviors, and values have been established across the organization and are now part of the routine ways that projects operate. The second objective is internalization. Internalization means that new ways of working have become ingrained in how individual team members think and function.
When team members have internalized new methods and behaviors, they don’t perform them because the manager, procedures book, or agile coach told them to. They work that way simply because it’s the best way they know to get the job done. Internalization is more difficult and takes longer than institutionalization, but it’s also a stronger indication of a successful culture change.
Making fundamental transitions from established ways of working to something very different requires many flavors of change: organizational, managerial, project leadership, rewards, technical practice, individual habits, and team behaviors. It’s not something that you can buy or mandate. Senior management must be committed to the change and make a compelling case for it with all those who are affected (Agile Alliance, Eckstein, and Buck, 2021). The cultural transition poses a greater challenge than installing a set of new practices and methods, but you’re likely to fail without it.
From time to time, you might encounter someone at work who strikes you as being unreasonable. It could be a fellow team member, manager, customer, or some other collaborator. We’ve met several such people in previous lessons, including:
• A team leader who expected a team member to handle five eight-hour activities per week on different projects (Lesson #23).
• A customer who insisted that she could provide requirements on behalf of a user class to which she didn’t belong (Lesson #33).
• A coworker who hoarded knowledge instead of sharing it with his colleagues (Lesson #35).
• A senior manager who hoped to alter the culture in a large organization by decreeing a set of new processes (Lesson #41).
When you encounter someone who doesn’t seem to be reasonable, that’s not a technical problem—it’s a people problem. There are several ways you can respond. One is to defend your position in the form of a debate. Another is to succumb to pressure from the unreasonable person and do whatever they say, even if you don’t think it’s the right approach. A third option is to pretend to comply but take no action.
A better strategy is to understand what makes such a person appear unreasonable to you and then consider how to respond. They might be defending an entrenched position rather than protecting their legitimate interests. Often, people who seem unreasonable are simply uninformed. Unfamiliar practices, jargon, and cocky software developers can intimidate customers who have little experience collaborating with a software team and lack technical knowledge. People who were disappointed by an earlier project experience could be wary of getting involved again.
When I was the lead BA on one project, I worked with a customer who’d been burned twice on previous projects that failed. He was wary of working with yet another software team. When I learned about his history, I could understand why he didn’t trust me—someone he had just met—from the outset. We worked through it, though, with a little patience and explanation, and the project was a solid success.
If the unreasonable reaction is due to a lack of knowledge, try educating the person. They need to understand the terminology you use, the practices you perform, why those practices contribute to project success, and what happens if you don’t do them. The people you work with must understand what input and actions you need from them and what they can expect from you. If a BA begins a conversation with a new customer with, “Let’s talk about your user stories,” that’s intimidating and invites a negative response. The customer has no idea what a user story is or what their role is in the process. Sometimes all it takes is transmitting a little information to resolve what came across as an unreasonable reaction.
I ran into this lack-of-knowledge scenario shortly after becoming the manager of a software group that supported the research laboratories in a large company. I described my group’s work at an annual meeting of the senior research management and technical staff. I stated that, from now on, our group would write no software without written specifications. A senior manager named Scott protested, “Wait a minute—I’m not sure your definition of specifications is the same as mine.” My first response was, “Then let’s use mine.” Lest that appear too flippant (which, of course, it was), I then explained what I meant by specifications. Once he understood that I wasn’t asking for anything outrageous, Scott agreed that this was a fair expectation.
My conversation with Scott illustrated an important point: make sure you aren’t the one who’s being unreasonable. Business analysts, project managers, or developers might seem to be difficult if they don’t agree to do everything that someone asks of them. A BA who asks that a user or manager spend time working with the software team could appear unreasonable to someone who didn’t expect to invest much effort in the project.
Sometimes people think they have more knowledge than they actually do and exert pressure to take an unsound approach. My friend Andrea, a highly experienced developer and database designer, contracted to a company for which she had previously built several successful systems. A senior developer at the client insisted that their new system’s database use a data model that he had developed. Andrea pointed out the serious flaws in the data model, but the client developer threatened, “Use my data model, or I’m canceling the project.” Andrea reluctantly agreed. Sure enough, the product suffered many problems, which took great effort to resolve. When Andrea correctly noted that those problems derived from the flawed data model, the client developer accused her of messing up the implementation of his great data model. That client’s behavior was unreasonable by any measure; everyone suffered the consequences.
Being dogmatic is another way to appear unreasonable. When I worked in a group leading a software process improvement program based on the Capability Maturity Model for Software, I once got pulled into a debate with a less-experienced colleague. Silvia maintained, “The CMM is a model. We’re supposed to do what it says!” That struck me as an overly constraining misinterpretation. My response was, “The CMM is a model. We’re supposed to adapt it to our situation!” I thought Silvia was dogmatic and inflexible; she thought I was violating the intent of the CMM by not applying it prescriptively. Through the ensuing discussion, our group reached a shared understanding about how to use the CMM in our environment. Still, I was struck by the big difference in how Sylvia and I interpreted what a “model” is for.
To make sure that no one comes across as unreasonable, let’s try to understand each other’s goals, priorities, pressures, drivers, fears, and constraints. Let’s find out which behaviors and outcomes generate rewards in both of our worlds and which ones generate retribution. Let’s craft agreements so that we all know what others expect from us and what we can expect from them. We’ll all get along better if we appreciate—and respect—each other’s point of view.
1. Identify which of the lessons described in this chapter are relevant to your experiences with organizational culture and teamwork.
2. Can you think of any other lessons related to culture and teamwork from your own experience that are worth sharing with your colleagues?
3. Identify any practices described in this chapter that might be solutions to the culture- and teamwork-related problems you identified in the First Steps at the beginning of the chapter. How could each practice improve how your project team members work together? How might you rectify any culture-killing actions and reinforce culture-building actions?
4. How could you tell if each practice from Step #3 was yielding the desired results? What would those results be worth to you?
5. Identify any barriers that might make it difficult to apply the practices from Step #3. How could you break down those barriers or enlist allies to help you implement the practices effectively?
6. Think of ways to take the best aspects of how your teams collaborate and spread that wisdom to other project teams. How can you instill cultural practices and attitudes that will persist over time to help future teams succeed?