3

Agile dev team says the cost is already fixed due to a fixed number of developers, so either scope or deadline shall remain flexible.

Marketing team whats to launch a promotion campaign with a specific release date aimed at current customers before the release with details as to what the new to-be-released extra features entail and how adding them is beneficial for the current customers.

So marketing wants to make promises to customers, but the agile team only wants to promise either scope or deadline.

This conflict is an endless forth-and-back and comes up every time that a new version has new major features in them.

Obviously, we also don't want to have a finished version sitting there for three or so weeks just so that marketing can do their promotional campaign before release.

How can management approach this issue so both parties can be satisfied and development and promotion can work in parallel?

  • How is the marketing department determining what can be provided and when, if the development team is telling them something completely different? Do they have another source of information that should be kept in the loop? Someone in management perhaps? – user34587 Feb 15 at 8:08
  • 1
    Not a conflict of interest (which can be confused with the legal concept) but rather a conflict of priorities. – rath Feb 15 at 10:47
  • "Obviously, we also don't want to have a finished version sitting there for three or so weeks just so that marketing can do their promotional campaign before release." Why not? If the campaign is a net positive for the company, what's to be gained by shoving the release out the door early? – Blrfl Feb 15 at 13:28
4

The answer resides in the ability to have a compromise and business and the team working together. Get a list of requirements, of user stories, groom it and get the team to estimate it and business to assess business value (this probably is the most important). With this, you should be able to prioritize these stories to come with a prioritized product backlog. The value-to-effort ratio should help to prioritize. From there, using your past velocity to predict the future, you should be able to get a rough idea of what you could get done by when (having an optimistic and pessimistic planning is probably a good idea), and based on what the MVP must contain you can then have at least a timeframe for delivery.

Then it's all about what you communicate and how. Any early communication can be quite vague about the content but also the date of delivery : "later this year", "in the summer" leave you with several months margin; "some long-awaited features", "an easier way to communicate with us" is just the 1-line pitch of what you'll be delivering. Note that you could also challenge marketing on the utility of an early communication; For example when you go to an apple keynote you don't know what will be discussed there but they also usually don't speak about stuff they'll be delivering in 9 months...

  • Thank you. While not the highest voted, I choose this as the accepted answer, as it has been of most help for me by giving concrete actions that can be taken. The other answers are also very good and provide things to be contemplated, but are a little too abstract to be of direct use. – MPS Feb 18 at 2:06
9

Well, that's a topic as old as the division of tasks between those who sell and those who build.

those who sell need to make their customers dreams in order to achieve sales.

those who make are limited in capacity, usually below the seller's needs.

There is not "good" solution to this question, the role of the management is mainly to play the diplomat's game, helping the sales team to understand the capacity constraints, and helping the building team to focus on producing elements with added value for the sales team.

But be warned : it will always be a game of juggling with contradictory interests. That's (one of the reasons) why management is hard.

1

It’s the job of management to make sure that the dev and marketing teams have a good understanding of each other. Once this happens, there can be a more sustainable approach to delivery.

Marketing need to ensure they are communicating the correct things to customers, based on the highest priority work coming through the dev team. If this work is only being requested directly by the Marketing team themselves then there is a poor time estimate being put on the work and it is not being requested early enough. Also, the specifications should be written collaboratively with representation from both teams, using plain language.

It sounds like there is not enough strategic release planning, which actually can be quite broad and high level stories, with value put against them to help prioritisation. Management should deal with this.

If the communication between dev and marketing is good, and specs are written collaboratively, there will be a sound understanding of the release plan by all.

Development in iterations means that the high level release plan can be made with a common understanding of the features being released for each development cycle. When the correct MVP features are delivered, according to the release plan, then marketing can deliver their communication to customers at the correct moment.

It’s the dev teams job to make the release plan sensible and sustainable based on the work being requested, the complexity of the tasks, and the people power available. It’s the marketing teams job to synchronize their customer comms, based on the agreed release plan. It’s the management job to get that comms working and get a strategic release plan sorted out so that you’re not all developing by the seat of your pants.

1

Did you consider that the agile way of working doesn't fit within your company? The agile way of working is not the holy grail that works for every environment. Especially in your company, with release dates with promised scope, you are not flexible at all.

The release cycle is not something you can change. Marketing has to work with something, and if they don't know what you produce or when, there is nothing they can work to.

I know it is an unpopular opinion,, amd you may not like it, but consider to replace your agile way of working, and replace it with a more waterfall approach. Explain in the company (as there may be other stakeholders) that this comes at the cost of not being able to change requirements for a release.

  • Excellent point. In every Agile shop I’ve worked in, we’ve had to drop, change, or add elements to meet the business needs. And that’s ok. – Thunk Feb 16 at 8:02
-1

Obviously, we also don't want to have a finished version sitting there for three or so weeks just so that marketing can do their promotional campaign before release.

This is your problem. Agile team want to finish product on day zero.
It is "possible" but marketing need to be aware of the fact that the campaign should be planned to soften the blow of subpar products (because that is always the possibility).

Second thing is that "scope should be flexible" is only partially true. There must be some scope that MUST be achieved. If there is none then on what major features Agile is working on that they can just don't make anything? If during testing you see nothing could be implemented then Marketing don't have anything to write about.

Also Marketing should be trained on what Agile is and how the Marketing content should be considered. For example 30% of information should be based on feedback you had and WILL be seen in next release.

Personal Note: There is nothing bad in having 2-3 week of product sitting there. There may be something bad when your launch date is before the deadline.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.