Currently, at Avocode we are ready to start the second dev cycle on Monday. I personally held retrospective meetings during the cool-down with all teams and I have some feedback which in some cases I don’t know how to deal with.
One of the pain points during the first cycle was Marketing
How does the feature fit into our marketing strategy - this should be probably the responsibility of the lead shaper to discuss this with the marketing department right?
Who should be responsible for making the marketing happen during the dev cycle - should the lead dev contact marketing team, “Hey we are about to release those features, are you ready with the communication etc.” or should it be the lead shaper (who is shaping different product)?
The second pain point was Onboarding
Who is responsible for contacting support team (whoever does that in the company) during the dev cycle to make onboarding for the developed feature. Should it be initiative of the team itself or responsibility of lead dev/lead shaper?
There are few similar topics but the main question is Are those responsibilities of the lead dev/lead shaper or the departments? How do you deal with those issues in your companies? Because what we have ended up with right now is a checklist for the Lead shaper, what they have to do during the dev cycle and for me, it’s starting to smell like a manager above the lead dev who is responsible for all of that stuff (contacting marketing if their campaign is ready, discussing onboarding etc. and shaping other project).
The way we handle these cases is: the dev team generates an internal (written) message explaining the feature. He usually adds some images/screen shots.
Tech support and marketing take it from there.
TS uses the QA environment to practice using the feature. Marketing starts generating the public message with our “public voice/tone” and sales also studies the topic in order to add it to their pitch.
All this happens around 2 days before releasing to production.
If needed, we can postpone a little bit before sending the features to production. For the web app, we would leave the branch ready to be merged to master. For the mobile apps, we would leave them in the Beta Channel on Play Store, ready to start partial rollouts (25% each day).
Writing the message is extra useful because it’s there for future devs and persons from other teams to see and understand the process.
For most projects we aren’t strict about the timing of help documentation, marketing updates, or announcements to customers and don’t expect those to happen within the cycle. Those are thin-tailed from a risk perspective (they never take 5x as long as we think they will) and are mostly handled by other teams. We’ll often take care of those updates and publish an announcement about the new feature during cool-down after the cycle.
Our marketing and support teams will be aware of the work from the Pitch announcements and can work on getting ready, sending out whatever comms they see fit - definitely not part of the shape or build team responsibilities. They can get early visibility with internal builds if they want. Deployment to prod is separate to releasing the feature, in that it’s behind a feature toggle.