The company that I’m currently coaching went (in the last 10 months) through a major transformation from traditional waterfall to a more Agile way of working.
Although the teams are continuously improving their way of working and best practices, I can see major improvements compared to their old way of working. Management are quite happy with the result so far.
This year the emphasis was on Agility within the Development, Operations and the Product Management departments. For 2014 I want to focus more on ‘Business Agility’, most importantly marketing…
How it works now is a follow:
Marketing comes up with a ‘Marketing plan 2014’ and ask Development for an initial estimation. From experience I know that these ‘initial estimations’ will lead to hard deadlines so I usual “protect” the team by explaining why upfront planning isn't gonna work.
However, from a Marketing perspective, I can imagine that they want to have a ‘rough idea’ of when things will be done so that they can communicate it back to customers, create marketing campaigns, promoting the new features at conference etc.
In my opinion, departments like Marketing/ sales etc. are the root cause of upfront planning which leads to “coding against a fixed deadline and scope”.
Does anyone have experience with dealing with departments like marketing from an Agile perspective?
Kind regards, Chee-Hong
It sounds as though you have created a "Scrum Studio", where technical engineering teams have adopted an agile way of working but other parts of the organization have not, e.g. Marketing. The studio model is a reasonable intermediate goal for an agile transformation.
Let's check one thing though. It seems that Development, Operations, and Product Management have gained reasonable traction in the agile roll-out. However, are these teams actually driven by the work put on their backlogs and by common release goals? That's the way a good studio would work. If they are separately accountable to project managers, and are servicing different release strategies, then there are still things to be done in with those teams *before* you start to look at Marketing.
Creating a truly agile marketing function is hard, because it means tackling emergence and adopting a just-in-time approach. Marketing would have to be comfortable with the validated learning cycle, and interpreting the results of split tests with customers so that a minimum usable product can be created and targeted appropriately. That's a tall order. It means enormous cultural change, and it's part of the reason why predictive frameworks like SAFe have gained market share. Creating an Agile Release Train that Marketing can refer to is essentially non-agile, but it is assimilable and can be turned into a rolling strategy that handles emergence better.
I’ve never heard of the phrase “Scrum Studio” but I like it
To give you a bit more context, the organisation which I’m coaching can be seen as a “software house”. We provide customers with a web-based tool so that they can manage their (for sake of arguments) “things”. So basically all the things that we build can be seen as a feature for the existing tool.
Our Product Owner comes from the Product management department. They work with the Scrum teams according to prioritised Backlog. Operational bugs and findings discovered on the live products goes via Operations to our Kan Ban team.
Furthermore I’ve introduced a so-called Agile Roadmap within the company where we prioritised all the projects that eventually needs to be done. Once a month we (Management, me, Product owner) comes together, update the roadmap and re-prioritised the roadmap if needed.
Depending on which project is on top, (internal) a knowledge transfer session will be initiated by the seniors because our development teams consists of junior developers. Once the knowledge transfer session has taken place the grooming session follows up. During this session the team helps the PO in creating items etc. After that we start Scrumming. The great thing is that the roadmap doesn’t consist any planning. It’s purely based on importance… This way we never talk about “when is it done”. Product Management has accepted that the Development team has a steady pace (velocity) and the only way for them to influence the planning is either updating the items on the backlog or re-prioritising it.
We don’t have traditional project manager within the company, only Scrum masters, PO and the teams.
I’m actually working on an idea to tackle this “problem”. For me it’s a bit strange that a department like Marketing sets up a certain deadline and then it’s basically Developments problem… Today I investigated the Marketing process of my company and found out that our Marketing department needs at least 1 month in advance to do their Marketing magic. According to stats, even the easiest projects takes at least 1 month (2 Sprints) When the velocity of the teams gets stable, the Product Owner will be able to “forecast” a certain initial planning upfront… I’m not sure yet so to be continue…
I’m also working on other theory but that one REALLY don’t go in-line with the Scrum rules, but it can be an answer to this problem…
> our Marketing department needs at least 1 month in advance to do their Marketing magic
In my experience it is usual for marketing timeframes to run 3 to 6 months in advance of delivery. I don't know your product or the size and nature of your market, but I'd check that 1 month figure again. A one month ramp-up period for marketing is something many agile organizations would envy.
In any event, marketing's "magic" should be included in the release strategy. It isn't up to them to set deadlines, even if they are as short as a month. What they need is sight of the roadmap, and to indicate which assets they need from developers in order to release their marketing campaign. In short, marketing have to be first-class citizens in release planning. Their information should be valued by Product Owner(s) who must prioritize based on this as well as other concerns.
I like the sound of this transformation.
A little off-topic, but for those interested, the "Scrum Studio" term is described well in "Software in 30 Days" by Schwaber and Sutherland. Chapter 7.
Chee-Hong, I couldn't tell whether the Marketing Team is looking to churn out a new product with an existing team, having known historical velocity? If this is the case when deadline is a driver, I usually let the stakeholders know how much functionality to expect. Perhaps I'm oversimplifying this...?
(It also seems that some form of Release Planning has taken place.)
If we can let them know what to expect by a certain date, it will usually force them to order items accordingly with the PO. At the end of the Sprints, the PO can re-visit the roadmap as well as adjust forecasts for future potential releases. Are the people uncomfortable with this approach?
I've seen projects driven by Sales and Marketing eventually spinning out of control. It takes a very mature Sales and Marketing division to work well with Engineering folks and this is a rarity nowadays when every penny counts.
I wouldn't recommend the Scrum Studio approach because it doesn't seem like its applicable in your case nor does it seem like you are implementing it. As already mentioned you can read all about it in Ken and Jeff's book if you are interested in it. Its a bit utopian if I may be allowed to say so.
First things first your Product Owner has to be empowered by senior management to have a direct line of communication with customers and should also be given the necessary strategic information so that he can optimize the value of the product.
This would mean that the Product Owner and not Marketing or even Senior Management is the ultimate authority on what the customer needs.
Senior Management can set a direction for your company but when it comes to customer needs the PO should be the authority. This will keep Marketing in line