Face-Off: Marketing, Management, and Delivery
(In the Agile Space)
12 September 2013
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
For decades there has been a growing conflict between the marketing end of an organization and the delivery side, especially in the software industry. Projections, Promises, and Profits versus Feasibility, Facts, and Fallacies. The two groups do not see eye to eye on a majority of organizational issues.
"Oh, the marketing folks make baseless and outrageous promises to the customers in order to win their business," says a senior software engineer I work with.
"We win business with great difficulty and the software engineers mess it up by not delivering on time," comments a friend of mine who is a marketing professional in a software consulting firm.
I can't say I blame either for their reactions. This is typical in the majority of organizations. The two groups seem to be anti each other. In my experience of more than 20 years in the software industry, I have yet to see these two groups work in harmony. This friction or animosity, or whatever we might chose to call it, is more apparent and obvious in the Agile world. And there is a new group that enters into the picture -- management. So now we have three groups -- marketing, management, and delivery. These three groups run the organization -- sometimes down to the ground.
Several things come into play in such organizations, power being the prime factor. In the corporate world, power is the key motivator for an individual's aspirations for growth. It always was and continues to be. With power comes responsibility, and that is where most people fall short. In my experience, the above-mentioned three groups are always struggling for power. The concept of working together as a single cohesive team is novel to them -- more so in the Agile space.
Agile is all about self-organized, cross-functional teams at all levels. The roles are very specific and require extensive collaboration between the team members and/or groups. Marketing departments are focused almost entirely on projections for the next quarter and what can be promised to the customer to maximize the profits. For example, "Last quarter we netted 20M dollars. I am expected to show at least 20 percent growth in order to meet my quota. I should target for at least 24M dollars for next quarter. I'll add ten more features to the product and get the customer's business." In the eyes of management and delivery groups, this is the typical mind-set of a sales and marketing professional.
Management tends to follow the top-down approach for managing people and projects. They follow processes and contracts, and they create large plans spanning months or even years. They like to get involved in day-to-day management of people, telling them what and how to do things. Management is given to micromanaging. This group is more used to checking up on people on the teams. Demanding status, checking for progress, trying to find who made the mistake, holding back information with an "on a need to know basis" mind-set are some of the things management does frequently.
What management needs to understand, especially in an Agile environment, is that if they put severe constraints on the delivery team in terms of how the team members solve their challenges, it becomes an impediment to the team's self-organization objective. Management needs to understand the roles within an Agile team and follow the guidelines.
The Agile delivery team is tasked with producing results, sometimes against all odds. The team reserves the right to decide how to get the job done. But in many cases these teams are told how to. In such situations the conflict between all the various groups becomes more obvious and tempers flare. Without proper feasibility checks, the delivery teams will not be able to start their work. The teams expect the other groups to resist throwing impediments in their way, however inadvertent they might be. And comments (from marketing and/or management) such as, "Our contract was not extended. That means you did not do well" do not help. On the contrary, they make matters worse. Delivery teams are pretty good at providing empirical data on deliveries. These facts must be taken into account by the other groups before engaging in contract negotiations and planning projects.
Over eighty percent of organizations claiming to be Agile are only partially Agile. In those organizations, agility is perceived to be the job of the delivery teams only. Marketing and management teams apparently don't feel obligated to follow Agile practices. This results in a mishmash of traditional methods and Agile methods. Vision, ideation, and project kickoff take place using traditional Waterfall, while development and deployment take place using Agile methods. Doing so generates unfavorable results. By the time deployment is done, scope might already have changed. Therefore, even though the delivery team produced results, they are unacceptable. This causes friction between the Agile delivery groups and the remaining non-Agile groups. It is not good for the organization. Teams are demoralized, costs go up, and deliveries turn to waste.
These groups within organizations need to fully understand what it takes to work and deliver in an Agile environment. The company's vision must expertly encapsulate the collaboration that is required from all the different groups within the organization and the specific role each plays in delivering the product. The groups must be able to identify areas of improvement, how to achieve their objectives, how to respond quickly to unforeseen changes, and how to eliminate waste.
In an Agile environment, if any of the groups within an organization decide to act independently of the others, the risk of failure goes up exponentially. As we say, "We all need to sync up and be on the same page."
Easier said than done!
Current rating: 3 (1 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.