The Ideal Agile Marketing Tool

Tools for Agile Marketing seems to be the hot topic in the various Agile Marketing communities. The Marketing Agility Podcast is talking to some tool vendors and people started to discuss it on the  Agile Marketing Facebook Group as well.

Here’s my view on what would be a great tool supporting Agile Marketing:

  • It would talk marketer’s language. Not force marketers to learn the language of development/IT.
  • It would be flexible. Marketers are not following Scrum to the letter. It should enable marketers to follow lean/agile principles without forcing the wrong practices.
  • It would be visual and beautiful because marketers appreciate those things. It wouldn’t bog down people with too many grids and lists and instead use more “Boards”.
  • It would support dynamic teams not just fixed scrum teams. Because that happens in Marketing. (also in Development btw)
  • It would support a combination of Scrum, Kanban without forcing you to choose one ore the other.
  • It would allow different teams in the organization easily adapt their area in the tool to support their own process.
  • It would TEACH marketers how to think about lean/agile flow/behavior. As a complement to frontal training, the tool should pro-actively support changing marketing culture to support agility.
  • Marketers spend even more of their time doing “Keep the lights on” activities such as cleaning up leads, monitoring campaigns, running webinars etc. A great tool would find an effective way not just to take that into account but also to help them manage those activities more effectively. Some of the Personal Kanban body of knowledge can help here.
  • Marketing Agility starts with individuals and can scale to hundreds of people. Not all tools need to support scale. But if the organizational agile tool can help the individual marketer become more agile it would help with adoption of the tool and agile marketing in general.
  • Emphasize simplicity, ease of use, streamlined flows. Otherwise it won’t stick. Having a situation where you have special people working the tool because the actual marketers won’t touch it with a stick is unacceptable (true story I heard in a recent meetup). It should take minutes to onboard a new team. It should take seconds for a marketer to add new work or move work along.
  • Integration into the other main tools of the 21st century marketer. Integration into email is one key thing. SalesForce when we start to talk about Account Based Marketing? Marketo/Hubspot/etc.? Integration into collaboration tools such as Slack/Flowdock?
  • It should provide some actionable insights – e.g. these items have been in flight for quite a while, worth looking at them in your next daily-stand-up. These items took a long time to cross the finish line – maybe worth discussing them in a retrospective/five-whys session. These items ping ponged a lot between states – worth looking at. There seems to be a lot queueing up for the designer. mmmm. maybe you should look at that (and suggest some tips along the lines of the theory of constraints five focusing steps). Why is it important to marketers? actually the more of those insights agile tools include the better it would be for everybody not just marketers. But since marketers are new to this agile thing, and many marketers aren’t necessarily process-oriented, this can help them along. (If they don’t have a lean/agile coach close by that is 😉

Consider this take 1. There’s probably more to think about when considering agile marketing tooling. I’ll add more when I think of it or see the need with the teams/organizations I’m working with.

 

 

Yes, SAFe 4.0 includes kanban. But does it include the beauty of Kanban?

One of the things I like in SAFe (Scaled Agile Framework™) 4.0 is the fact that is includes kanban visualization and flow management so explicitly as part of its recommended practices/building blocks at all levels ranging from the Portfolio (which was part of earlier SAFe versions) through the Value Stream and Program all the way to the Team levels.

Together with the explicit and up-front discussion of Lean-Flow principles and Reinertsen’s work that is indeed great news for kanban fans.

A recent comment from one of Yaki Koren my colleague at AgileSparks that “He’s reminded of the beauty of Kanban” (Reading Mike Burrow’s “Kanban from the Inside” while spending most of his days knee-deep in SAFe/Scrum engagements) sparked a realization that has been bubbling up for me though. SAFe 4.0 might include kanban but it doesn’t necessarily include Kanban.

What do I even mean by that? Capital-K Kanban refers to the change method not just the visualization/flow management technique. That method that “Starts with what you have”, “Respects the current way of doing things” and uses flow visualization/management, WIP limitation, and making your current policies explicit together with evolutionary experimentation and feedback loops to help you improve your fitness for your purpose.

Regardless of whether you want to follow the Kanban Method as a change management approach in your context, I think it is important to REMEMBER what it is about, and discern what sort of kanban/Kanban you’re using and what’s the purpose when you use it as part of SAFe (or Scrum or Agile Marketing or whatever). Too many people out there including some Agile Coaches and probably most SAFe Program Consultants probably can’t tell the difference.

If we don’t do anything about it, I’m afraid over time the Kanban definition that is part of SAFe 4.0 will join the Kanban as defined by Scrum practitioners (both miss more or less the same points) to be the canonical definition of Kanban that Lean/Agile practitioners are aware of and the Kanban Method will become a secret/lost technique. You know what, there’s a good chance that’s already the state of affairs.

And it’s a shame. Because even as part of a SAFe implementation it might be very useful to leverage the Kanban Method and use the Kanbans you have at every level as an engine for that “Inspect & Adapt” you’re seeking.

Even with SAFe Start with what you do now; Agree to pursue incremental, evolutionary change & Respect the current process, roles, responsibilities & titles can all make sense. SAFe takes a slightly different approach about it but it actually respects the “project manager” role for example and fits them into the “Release Train Engineer” role. It can live with component teams even though it prefers Feature teams. Many extreme agilists call it “safe” and closer to waterfall with its approach to periodical planning. That can be seen as a form of “start with what you do now” or “Respect the current process and needs of your surrounding stakeholders/clients”.

And because SAFe starts safe, we need SAFe practitioners to “Agree to pursue incremental, evolutionary change” from their starting point. We want them to ascend beyond the “Essential SAFe” in an effective focused way. We want them to use flow-focused experiments to evolve towards a better fit-for-purpose. We want them to understand and harness the power of WIP limits to drive not just collaboration but also uncovering your impediments/bottlenecks and dealing with them systematically.

We want SAFe practitioners/consultants to consider how Kanban can help them deal with SAFe theater – with those organizations that follow just the “easy” parts of SAFe, for which PI Planning is just a meeting of managers/stakeholders, where planning is push-based rather than pull-based (Where “No we cannot fit it into this PI”), where dependencies abound because they stayed with the “easy” siloed component teams or even component trains that actually make life really tough when you try to create flow.

Let’s see how this message resonates. If it does, I have some ideas what to do next about it…

 

 

Are your Product-Owners cross-functional enough?

Improving teams/organizational flexibility/versatility is a topic that comes up often in my engagements. This includes discussion of T-shaped people/teams, Collective Ownership, Code Stewardship, Full-stack-developers and the like. I typically refer to Henrik’s classic (and recently my “scaled” version ).
So let’s assume you improve the agile team flexibility which means you can “swarm” a couple of teams to areas in high demand. How do you deal with their product ownership/management in those cases?
1544063

Continue reading “Are your Product-Owners cross-functional enough?”

My Agile 2016 Talk – How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push/Mandate

Here are the final slides (including live session polling data) from my Agile 2016 talk last week. If you want to read deeper into this I suggest you look at my blog series from earlier this year.

PS Sadly enough the session wasn’t recorded. If you’re interested in to see this talk leave me a comment here. If there’s enough interest I might do a webinar/periscope/whatever at some point.

Develop on Cadence – Deliver on Demand – The Agile Marketing Version

Recently I participated in a steering discussion for one of the large-scale agile marketing implementations I’m consulting. We’re using a marketing variant of the Scaled Agile Framework (SAFe) there – including planning and executing on a quarterly cadence using Program Increments (PIs).

A key struggle that surfaced was: “Planning the quarter just a week or two before it starts is way too late for us since we have so many long-lead-time activities that support us – things like media buys & field event logistics. Can we plan the quarter earlier in the quarter? Should we consider planning the quarter a quarter in advance? “

My take on this is that when we plan the Program Increment we plan whatever work we need to do in that time period. Some of that work will be delivered throughout the quarter & some would be delivered in the next quarter or even later (e.g. when working on the huge annual customer event). The key question to ask is from a Cost of Delay perspective when will we reach the last reponsible moment to start developing the campaign/program and if that moment is in the upcoming quarter it needs to be considered as part of the planning.

Another way to look at some of these activities is as Enablers (Another SAFe concept) – we do them now to enable us to deliver later. At each point in time some of our capacity would be dedicated to the “Runway” which is work that enables later delivery. (This is called Architectural Runway in canonical SAFe but that name is not very appropriate to the Marketing world I guess…).

NOTE – If we find too much of our capacity is dedicated to “Runway” activities it is an indication that our time to market is probably quite long since most deliveries require multiple quarters to mature. We should look at the main reasons we need to use the “Runway” and start to think about ways to minimize the lead time/overheads associated with them.

An example – Purchasing Media for the whole year due to “Economies of Scale”. Does that mean we need to plan media usage for all campaigns almost a year in advance? Or is there an effective way to purchase the media and figure out the most effective use once we actually start to plan out the details for each campaign/activity throughout the year?

This is just one example of the “Lost In Translation” effect when applying Agile in Marketing. What I find helps is remembering the principles/models (That’s part of my role here – making sure people understand lean/agile deeper – beyond the superficial Scrum Master/Sprint/Agile Team level).

Any thoughts?