Marketing/IT Collaboration: Merging the Two Cultures

Especially in the current resource-constrained environment (but also in the long-term uncertainty- and change-filled future), managers can not afford the distractions, lost Productiv Ity, and CultUre damage that comes with the Market Ing and IT teams regarding each other with suspicion and disdain.

Key Questions

• How can I keep the teams from pointing fingers at each other?

• Who's "in charge" of the overall product development process?

• How do I staff various positions that provide an interface between the teams?

• How should the overall portfolio of projects be managed? How centralized/formal does the process need to be?

• What are the implications of/for outsourcing?

Key Finding

Traditional "rigorous" software development methodologies often use formal processes as a way of ignoring human conflict rather than resolving it. Agile methodologies, such as Extreme Programming, push constant informal communication and implementation feedback cycles to improve both parties' satisfaction with both the work product and the working environment.

Key Takeaways

• Certain changes in development practices make a steady flow of working code more likely.

• When constant communication with Marketing is added, monthly delivery of business-valuable working code becomes possible.

• Faster delivery cycles allow for fewer interim deliverables (e.g. large design documents).

• This doesn't eliminate the need for a process to bring consensus to the ordering of separate projects.

Many organizations experience conflicts between Marketing and IT. Marketing perceives IT as often being a barrier to getting anything done ("they make everything sound hard"), and as taking too long to get anything done. IT often perceives Marketing as "having no respect for actually doing something", and being unable to either think through its needs systematically or make up its mind (esp. in terms of prioritizing).

Make Communication More Frequent and Less Formal

Organizations often react to internal tensions by "setting ground rules" for communication: legalistic written communication and formal political committee meetings. At best this "papers over" the tensions, but it can neither avoid nor resolve them. In many cases it makes things worse by creating more drag on both teams, resulting in more resentment.

Newly publicized Agile Software Development methodologies such as Extreme Programming ([XP]) and Scrum, using practices such as Short ReLease-s and Onsite Customer, make communication sufficiently intense in both directions that formality is greatly reduced in favor of clarity and mutual understanding. A single integrated team operates. Here I focus mainly on the specific vocabulary (capitalized below) and practices of [XP], but you may want to research the alternatives.

Marketing assigns a product designer (called simply the Customer/Onsite Customer in [XP]), who invests significant time. There are no other "business analysts" to filter the communciation. The Customer writes brief requirements in the form of User Stories, clarifies them with developers in person, rates their relative business value, then prioritizes them for scheduling after developers have provided cost estimates for each. They stay highly available (e.g. On-Site) to resolve ambiguities and conflicts within hours.

In return they get Frequent Iterations: working, integrated, and bug-free implementations of the scheduled User Stories. Typically an Iteration is completed roughly every month. This allows true operational progress to be demonstrated, and triggers a new Planning Game session where User Stories can be added and changed, then a new batch scheduled for the following Iteration. Not every Iteration is necessarily Released to the users, but the constant testing and integration makes that possible. And since User Stories are generally prioritized in order of business value/[ROI], stopping development on a project can happen as soon as the Customer (or senior management) feels he's gotten enough value from the process: there's never a sense of a large "sunk cost" requiring additional development to generate returns.

This Requires Changes in Development Practices

This kind of development often requires some significant changes to the development practices. Test-Driven Development requires that the Unit Test suite be fully automated, written before the code, and passed completely before any code integration takes place. Pair Programming (a) eliminates separate Designer/Architect roles (note this is not true in all agile approaches), (b) provides continuous peer review as a replacement for separate review activities, and (c) provides a mentoring process to improve the skills of your more junior developers. Not every developer welcomes these practices at first, but many find that the payoffs convince them.

Multi-Project, Multi-Customer Situations Require a Macro Process

Most of the literature about agile processes focus on a single team working on a single stand-along project at a time. When there is a single Customer but with multiple projects, there is some potential for the same developer to work on individual User Stories from multiple projects during the same Iteration. But that is not probably ideal - better results are likely to come from having a single Iteration focus on a single project (though the IT group could be split into separate sub-teams to work on separate projects simultaneously). Alistair Cockburn's Crystal Orange Web process explores practices for having multiple projects running simultaneously which must being globally integrated into a deployed code base.

When there are multiple Customer factions things become even more complex: forming a coherent Customer Team isn't easy. One approach is to have a Customer Committee, which runs a periodic (per-Release?) macro Planning Game using coarse-grained User Stories and estimates to come to consensus on Prioritizing Projects. Another approach is to dedicate a separate IT sub-team to each Customer (possibly re-balancing resources on a periodic basis).

Outsourc Ing Becomes Messier

This kind of process is more difficult to follow when developers are external (outsourced/offsite, not as much of an issue with contractors working on-site with your in-house team). Integrating the Customer into the development process is more complicated in such situations. And dynamic environments do not mix well with Fixed Price And Scope Contract-s, regardless of the methodology. Extreme Programming notes that tracking costs at each Iteration gives the Customer a strong sense of cost vs. benefit for the work performed so far: if the relationship is not going to work out, (a) he discovers it faster (putting less money at issue) and (b) he's received the most valuable chunks of functionality first (assuming at least 1 Iteration's worth of working/maintainable code has been delivered). This reduces the need for fixed-pricing as a method of reducing risk.

Solve People Problems with People

Collaboration problems are People problems. They are often best solved by increasing the communication bandwidth between people. Agile methods aggressively pursue personal communication to bring issues to the surface where there is some hope of their resolution, resulting in increased trust and respect.

User Options Recent Changes Help Page