Home 
CM Journal Articles Dimensions of SCM Challenge #3
CM Journal Articles Dimensions of SCM Challenge #3
|
 Culture & GeographyPart of managing software development is dealing with the challenges that arise. Delivering software requires overcoming the challenges, or at least mitigating the attendant risks during the development activity. Generally, organizations work with a constant level of challenge. When one challenge is overcome, the organization will take on a new challenge. For example, when a project releases software that overcomes a technical challenge, it might then schedule a new release with a challenging timeline, or re-open the technical challenge by choosing a new target platform. The next challenge is not "just like the last one, only more." An organization that successfully implements geographically distributed development does not follow up by adding another development office. The organization may well open another office, but doing so is now a normal operation; in order to maintain the level of challenge, some other "impossible task" must be undertaken. While problems may have unique characteristics, there are a lot of common themes. This series discusses sixteen separate dimensions of challenge. The situation your team faces can be analyzed with respect to the dimensions listed here, and some appropriate conclusions drawn. Each dimension is dissected, and some approaches for dealing with it are provided. Here is the complete list:
Dimension: Culture Let's assume that you have a project with development offices in São Paulo, Brazil; Buenos Aires, Argentina; Monterrey, Mexico; and New York City, USA. Assume further that it's May 3rd, and you realize that the Cinco de Mayo holiday is coming up-probably because you see it mentioned in a TV commercial. Which of your developers are going to need time off, when, and how much?[1] Here's another puzzle: at two different clients, I worked on projects where they had an "offshore" CM repository set up on a dedicated server. Both times, the remote office or outsource vendor was committed to high professional standards. Yet the remote CM servers were chronically infected with spyware, viruses, and trojan horses. Why?[2] At its simplest, culture means shared behavior within a group. Shared behavior creates CM challenges in two ways: when there is a counter-productive (to CM) behavior within a team, or when the differences in culture between two (or more) teams causes problems. Team-internal Culture Challenges The first case is the one you are almost certain to deal with at some point. A common team attitude or behavior that hampers or prevents effective CM. There are the "cowboy coders" who don't do CM: making all their changes on a "blanket" CR, or making changes to a live production server with no record of what was modified. Then there are the "we don't need it" types who feel that anything more than basic version control is a waste. Don't confuse "conflict" with "culture," however. The fact that one CM guy and one software developer get into an email flame-fest does not indicate a culture problem. A culture problem is when all (or nearly all) the developers chime in with the same argument. Dealing with a culture challenge is tough, because CM is an ancillary function-most CM specialists manage by influence, rather than by authority. While management tends to support the CM function (because in most cases the CM function wasn't implemented until some embarrassing CM disaster), the development and test teams are key to the project's day-to-day operation. Not many managers fire a developer for arguing with the CM guy. The key word, though, is "influence." There are a lot of ways to exercise influence without authority. Robert B. Cialdini's book, Influence: The Psychology of Persuasion, is an astonishing introduction to both sides of the influence game. It focuses on sales and marketing, but the lessons are germane to nearly every business environment. A classic example of influence-based management is peer pressure. Using the natural concern that people have for the opinions of their peers is an effective tool for behavior modification. Peer pressure can be positive or negative. The classic example of positive peer pressure comes from Dale Carnegie's How to Win Friends & Influence People: Charles Schwab had a mill manager whose people weren't producing their quota of work. "How is it," Schwab asked him, "that a manager as capable as you can't make this mill turn out what it should?" "I don't know," the manager replied. "I've coaxed the men, I've pushed them, I've sworn and cussed, I've threatened them with damnation and being fired. But nothing works. They just won't produce." This conversation took place at the end of the day, just before the night shift came on. Schwab asked the manager for a piece of chalk, then, turning to the nearest man, asked, "How many heats did your shift make today?" "Six." Without another word, Schwab chalked a big figure six on the floor, and walked away. When the night shift came in, they saw the "6" and asked what it meant. "The big boss was in here today," the day people said. "He asked us how many heats we made, and we told him six. He chalked it down on the floor." The next morning Schwab walked through the mill again. The night shift had rubbed out "6" and replaced it with a big "7." When the day shift reported for work the next morning, they saw a big "7" chalked on the floor. So the night shift thought they were better than the day shift did they? Well, they would show the night shift a thing or two. The crew pitched in with enthusiasm, and when they quit that night, they left behind them an enormous, swaggering "10". Things were stepping up. Shortly this mill, which had been lagging way behind in production, was turning out more work than any other mill in the plant. Positive peer pressure amounts to friendly competition or reputation. This is one of the big motivators in the Open Source community. When you contribute a lot of good stuff, lots of people know who you are and think you're cool. You get a good reputation. When you fix the most bugs on your team, or close the most change requests, your team members think you're some sort of coding wizard. This is the best sort of peer pressure-it leads to better code, higher productivity, and raises. The other form is negative peer pressure. One of Microsoft's development teams reportedly assigned the job of running builds and diagnosing build problems to the last coder that caused the build to break. One of my clients would force anyone responsible for a build or deployment failure downstream of development (in the QA, UAT, or Production areas) to buy coffee and donuts or bagels for the entire team. This is a fairly light-hearted way of saying "we see you messing up," but it provides a social reinforcement of the team rule: don't inconvenience your co-workers. I have implemented more draconian measures when they were needed. In one instance, I began reporting the number of defects per developer on a periodic basis. This led to a "hall of shame" where the chart of the worst offenders was displayed on the way in and out of the development bullpen. Not surprisingly, the charts got torn down a few times. But the number of defects plummeted after about a month to the point where the "biggest loser" chart could be replaced with a system-wide "defects over time" chart, and positive pressure replaced negative pressure. There are other ways to deal with team culture challenges. Many of these are "management problems," and you can find them discussed in books on management, psychology, or team-building. Don't discount this approach-changing a team's culture is hard, and it requires a lot of work and a lot of patience. Failing to realize that you are in a management-by-influence situation, or not knowing how to deal with this situation, can be costly. There is probably at least one post per year on CM Crossroads asking something like "How can I get my boss to force the developers to ... ?" The simple answer is that you can't. If the problem were an obvious and compelling one, the boss would see it on their own. Solutions that involve complaining to the boss, or to someone else's boss, generally involve that other interpersonal technique called Whining and Complaining. While no manager is likely to fire a coder for doing what everyone else on the team does, I have been called in to help a development team eliminate a CM group that favored whining and complaining over supporting the team. A key factor in making cultural changes is justifying them and motivating the team to make them. You need to be able to convince the team that making the change is worthwhile. Part of that is answering the question of why it is important. Metrics are the answer. Because culture is about behavior, most team culture challenges have fairly simple solutions. Usually they take the form of "stop doing that" or "start doing this." If you're right, and everyone else on the team is wrong, you need to be able to show it. That means you need to have metrics. (If you're wrong and everyone else is right, well, hopefully the metrics will show that before you get too embarrassed.) Some metrics are static, and easy to collect: the directory structure of project files, for example. (Useful to show that a developer is checking in changes that impact several different modules, instead of one change per module.) Other metrics must be collected dynamically. There is no single "culture" technique that will solve all possible bad behaviors. Instead, you need to focus on the techniques that address your biggest problems. For all but the simplest metrics, though, automation is going to be your friend. Have a look at Automated Enforcement of Standards, Gated Work Flow, and Fast Feedback on Changes. Cross-team Culture Challenges Pretty much any project that involves more than a single team will have some kind of culture boundaries to cross. The clash between development and testing is an obvious example, but any two groups with a boundary between them-physical or organizational-are going to develop some unique behavioral patterns. Generally, when teams work together over a period of time they will overcome their cultural differences and evolve a kind of "meet in the middle" culture that changes some behaviors while working around or ignoring others. The challenge is to shorten the period of time that it takes to reach that accommodation. Most of these kinds of challenges come down to communications or expectations. If you are working with a team in Massachusetts, do you know when Patriots' Day is? If your QA group is in Bangalore, how much work will they be able to do during Holi? Possibly the worst case is when you are a part of team ‘A', and team ‘B' has some cultural aspect that hinders your efforts at CM. The amount of change you can effect in the other group will depend on your particular skill at management by influence, and the relationship between the two teams. A short contract client/vendor relationship or a temporary project involving two teams will mean that there isn't much you can do. A new partnership between the web development team and a legacy systems group, on the other hand, may be the start of a multi-year relationship. Be wary of tilting at windmills. If you can't bring about any change, you're probably better off fighting a different battle. Most cross-team cultural challenges are caused by poor communications or mismatched expectations. If half your QA team is planning to take a week off for Christmas, the project management team had better be aware of it. ("Use it or lose it" vacation policies can result in some weird project schedules.) In most cases, the solutions to cultural challenges lie in improving the quality of communications, reducing the necessary communications volume, or synchronizing expectations. Societal culture challenges-those that cross national or social boundaries-tend to be more ‘powerful.' A little challenge can cause a disproportionate set of problems. Probably the best long-term approach to this sort of challenge is to create a new, different culture that everyone has to join. Tension between the Little-endian and Big-endian members of your team can be reduced or avoided if they have all gone through some sort of unifying process. Since geographic separation is usually part of these challenges, you probably won't be able to schedule any kind of shared team-building exercise. But other techniques like a common jargon, shared events or activities, and of course shared emergencies, will still work to build a team. One project I was involved with had culture problems within a single office. Since the project was an "enterprise" effort, the project team was drawn from several different groups within the company. Not surprisingly, each group had their own way of doing things, mostly incompatible with all the others. The new project was finally melded into a new team, with a new culture. Part of this was vocabulary: "bones" instead of "change requests," for example. Other parts included a very aggressive development schedule and the adoption of a bunch of new technologies. The result was a group that was basically incomprehensible to the rest of the company. It was easier to be loyal to other members of the new team than to try and reminisce with former team-mates, since that frequently required a translating dictionary. Probably the simplest and easiest way to solve cross-team culture problems is to eliminate the opportunity for them to occur. The decomposition-based construction techniques-Component-based Development, Service-oriented Architecture, and Software Assembly-can partition the project. If your cultural boundaries are aligned with the decomposition (database in Delhi, java in Jakarta), this approach can reduce or eliminate communications, period. And when two people don't need to communicate, they can't have communications problems. The organizational technique Change Control Board can be hard to get working in a widely-distributed project. A CCB can work, but it needs to be aligned correctly. If different members of the CCB represent the different cultures of the project, a lot of the communications burden can be transferred to this small group. This frees up the rest of the cultural groups to focus on internal communications. If the CCB is not aligned with the cultural divisions, this won't work. If the CCB consists of, say, hardware, software, and QA representatives, and there are hardware and software development subteams with both Big- and Little-endian members, then the hardware and software subteams will still face the cultural challenges. Project Baseline is probably the most promising of the work flow techniques. Together with one of the decomposition-based construction techniques, you can encapsulate the project in a set of ‘black box' entities, reducing the communications load between the parts. As with the CCB example, this requires that the decomposition be aligned with the cultural boundaries. Longacre Deployment Management, with its emphasis on transparency and a common vocabulary, will result in increased communications volume but with simplified content. If your cultural boundaries are aligned with your work flow (development in Dallas, testing in Toledo), this is a good approach. The codevelopment techniques-Distributed CM, Independent Development Paths, and Formal Interfaces & Standards-can help when team members from different cultural groups are working on the same components. Providing the developers and/or teams with their own environments, and by setting a consistent, verifiable set of expectations, you can reduce or eliminate a lot of risks. Allowing the teams to self-manage their work schedules can increase the amount of development work done, especially by the young, aggressive, no-family-or-social-life developers so popular with outsourcing vendors. The obvious way to manage expectations and formalize communications is with ceremony. The two techniques Automated Enforcement of Standards and Requirements Management can reduce or resolve problems by setting expectations well in advance, and ensuring that the expectations are universally understood. Compliance with documented, verifiable requirements is simple to check, and is an easy way to reach agreement across cultures. (Notice that many of the outsourcing firms in India are certified at CMM level 5. Setting and meeting defined objectives is a smart way to do business in a client/vendor relationship.) Automated Enforcement of Standards helps overcome culture issues by ensuring that the playing field is seen as level for everyone on the project. Beware, though, of using the automated system to enforce the standards of a single cultural group. Specify the standards, get agreement, and then leave it alone. Dimension: Geography When a project team is spread across more than one location, communications becomes worse and more expensive. The ability to meet in a single room is replaced with tele- or video-conferencing. Hallway chats have to be replaced with instant messages, emails, and phone tag. Geographic distribution challenges are not the same as cultural challenges-geographic challenges can arise when a single development team is spread between two adjacent buildings. When the offices are in different ethnic or corporate cultures, challenges will arise from both geographic and cultural sources. See the Culture and Human Language sections for lists of even more things that can go wrong. Geographic challenges spring from organizational and communications problems. If the organizational boundaries are aligned with the geography then the geography problem is pretty simple. An organization aligned with its geography simply pays a higher price for all communications across organizational boundaries, and so should focus on solving the Organizational Structure challenges by reducing the amount of communications needed, or by improving their clarity. If there is no correlation between location and role-as happens when development teams from different offices need to work together-then you will have Organizational Structure challenges (especially politics) in addition to geographic challenges. Please be sure to read that section when it is published. Currently, it is slated for August. As with Culture challenges, above, the decomposition-based construction techniques can be useful for geographic challenges if the geography is aligned with the project breakdown. In most cases, this will be a no-brainer. If the database team is in Dallas, you are obviously going to assign the database parts to them. But for projects building from scratch, it makes sense to take a hard look at this. Isolating the database functions in a separate module may make sense from a geographic standpoint, but you need to be sure it's the best overall solution. Of the codevelopment techniques, Distributed CM is the obvious answer to Geography challenges. But be wary of over-complex implementations. Implementing a distributed solution does not magically resolve all geographic challenges. You must still ensure that your replication strategy and your repository structure are in harmony with your organizational geography. If developers from several different locations are trying to work on a single module, you will need a fairly complex solution. (Or, you need to kick some of the developers out of that module.) Formal Interfaces & Standards can help separate parts of the project. This reduces and formalizes communications, which is very useful when your teams have a significant time-zone separation. Independent Development Paths is a generally useful capability, but it can introduce problems. Just because it is possible for two developers in two different places to make their own set of changes, that doesn't make it a good idea. Those developers will still have to communicate and coordinate. The organizational technique Change Control Board is probably the best solution for a geographically distributed project. A single System Architect is unlikely to be able to keep up (unless the geographic separation is very small, like separate offices in the same city), but a project that is widely scattered will need a lot of coordination. Even if the CCB is not aligned with the geography, the CCB members still provide a reduced set of communications targets. And while communications within the CCB becomes critical, the CCB is a small subset of the entire project team-it should be easier to optimize their communications than to try to improve everybody's. Both Change Control Board and System Architect reduce the communications load, but there is still an absolute minimum: team members must communicate with a CCB rep or with the architect. For strongly partitioned projects, especially when using Component-based Development or Service-oriented Architecture, it may be possible to get the communications load closer to zero by using Requirements Management or Formal Interfaces & Standards. (Beware of trying to get too close to zero communications. Unless you are on a government project, the system probably has to actually work.) Of the ceremonious techniques, Automated Enforcement of Standards and Requirements Management are the clear choices, for very much the same reason as with Culture challenges: they help reduce or clarify communications. Unlike Culture challenges, sometimes Automated Enforcement of Standards can use changing standards to resolve Geographic challenges. A set of automatically-executed test cases, for example, can be an effective way to communicate updates between widely-separated QA and development teams. (Of course, an email explaining what new test cases were added would be polite.) Of the work flow techniques, Fast Feedback on Changes is absolutely crucial. For a widely-separated team, it makes no sense whatsoever to force developers to wait 24 hours to get test results. If your geography separates development from testing, then some sort of "nearby" testing function is needed to ensure that developers can remember the context of their changes. Longacre Deployment Management offers a broad set of benefits. Because of the abstracted life cycles, and because it tracks changes all the way through to deployment at specific locations, LDM is a good choice for geographically distributed development of complex projects. Looking Ahead I'll try to cover two new dimensions of challenge each month, but there's no fixed order. If you have a particular issue you'd like to see discussed earlier, drop me a line. If you have a challenge that I haven't identified, please, please let me know-I don't claim the list is exhaustive. Austin Hastings has spent more than 20 years in the software industry. He has been a developer, system administrator, CM specialist, manager and consultant. Currently he is principal consultant for Longacre, a software CM and process automation consultancy. Austin lives in the southern part of New Jersey (the garden of the Garden State) but travels the world helping to keep software under control. Contact him at Austin_Hastings@Yahoo.com, or through CM Crossroads. [1]The team from New York will need time to recover from their hangovers on May 6th. The Cinco de Mayo holiday is a Mexican holiday commemorating the battle of Puebla, roughly comparable with Patriots' Day in the United States where residents of Massachusetts, Maine, and Wisconsin celebrate the battles at Lexington and Concorde. But in the U.S., certain beer companies have coopted the date as another "alcoholiday," a la St. Patrick's Day. [2]Both times, the companies had strict, enforced policies about employees using their desktop computers for personal internet surfing-they could lose their jobs. So the developers illicitly used the CM servers, which were not assigned to any single user, to surf porn sites. Of course, viruses, worms, trojan horses, and spyware infected arguably the single most important computer in the building. Resyncing the repositories after the machines were rebuilt cost days of lost productivity for the entire team. The second time I encountered this, I was less shocked than the rest of the project management team. Our solution was to set up a throw-away web surfing box on some old hardware, and let the developers satisfy their baser urges on a system nobody cared about.
Set as favorite
Bookmark
Email this
Hits: 5522 Trackback(0)Comments (0)
|
| Last Updated on Wednesday, 16 April 2008 03:05 |
TrackBack URI for this entry
Subscribe to this comment's feed