Using Agile Marketing How We Turned Business as Usual into Value Delivery

a group of business people in front of an agile marketing board

There are few sentences more toxic to a workplace than, “That’s the way we’ve always done it.”  A marketing team is often tasked with ongoing maintenance work that must be done. Updating a webpage, a piece of collateral, or a social feed can often feel like everyday, run-of-the-mill work that rarely gets seen or appreciated. It just sort of runs in the background and quietly eats away at the work day. As a result, this unappreciated, untracked work usually gets thrown into an ever-expanding pile of just-get-it-done tasks that mandate no thought and no context. Before you know it, someone’s asking why we do it at all, and that toxic answer resurfaces: “That’s the way we’ve always done it.”

To me, this answer is a symptom of the larger problem. Born out of years of repetitive tasks that never see the organizational light of day. We always do it that way because we’ve never had the time to closely examine our process. Or, it’s been so long that literally no one can remember why those decisions were made in the first place.

Agile marketing provides multiple tools to marketing leaders to help focus their teams’ efforts. Our goal is to never just eliminate business as usual (BAU) work; just make sure it’s the right one. This was the challenge I faced when I recently took over an agile marketing team. How could I leverage the Scaled Agile Framework® (SAFe®) to make sure we’re doing the right work to keep the ART on track, rather than just busywork? Luckily, agile marketing gave me a few tools I never had before in previous marketing leadership roles. I have visibility into and clarity around the work that had never existed before, and my team has reaped the benefits.

Data: It’s not just for open rates anymore

Agile preaches that all work should be visible. But as previously stated, BAU work rarely is. Being an agile team that leverages a Kanban board to visualize the flow of work getting done, we made a small tweak. We tagged every user story that fit the description of BAU. Voilà! I could now pull clean reports on exactly what type of BAU we were working on, what percent of our time we were dedicating to it, and who on the team it affected the most.

We found that we were spending a staggering 31 percent of our time on BAU! And as we examined more closely, we found many people had no idea why we were working on these things at all. It was just the way we had always done it.

Most importantly, the ART and the team had no idea just how much time all this work was taking. No one had ever calculated it. By taking a data-driven approach to the issue of BAU, we did something crazy: We timeboxed it.

Capacity allocations

There are only so many hours in a day and any good leader wants to make sure their team is getting the top-priority things across the line. Our goal is not to eliminate BAU work, but to ensure it’s the right work. By following agile marketing practices we can calculate exactly how much we can accomplish in a two-week iteration. Leveraging ‘capacity allocation’ helps marketing leaders limit BAU’s ability to derail the priorities.

And that’s exactly what we did. Our team allocates 20 percent of our available time to deal with BAU work like website maintenance, monthly newsletters, and updates to graphics. This creates a forcing function in evaluating BAU. Is this BAU user story more important than another one? To answer that question, team members have to fully understand the work and the product owner (PO) has to understand the customer’s needs. If no one understands why they’re working on something, they shouldn’t be working on it.

To marketing professionals lookin at campaign performance charts for their latest campaign

Hypothesis-driven development

Marketers love a good A/B test. It’s short and simple. But harder, more in-depth questions like “Does this webpage provide value to the reader?” take more effort and thought. When evaluating BAU, we found we needed to develop some muscle memory around answering these harder questions. And we wanted something more defensible than our personal opinions.

To do this, we’ve introduced an agile marketing concept called hypothesis-driven design. Essentially, it means you develop a testable hypothesis and the experiment to validate or falsify it. In other words, you leverage the scientific method to evaluate your work. 

After the team took the Agile Marketing with SAFe® course, we began to apply hypothesis-driven design to our website and our underperforming monthly newsletters. This won’t come as much of a surprise to marketing professionals, but we found we’re pretty good at designing tests; not so great at writing hypotheses that can be tested. Introducing hypothesis-driven design was a meaningful step toward building more intention into our BAU work.

So what happened?

Since adopting these practices, our team has seen a 42 percent decrease in capacity spent on BAU. This work is being turned into productive, value-delivering efforts that support the ART’s overall go-to-market strategy.

By leveraging agile marketing we’re no longer just busy: We’re busy delivering value.

About Hannah Bink

Hannah Bink -Agile Marketing

Hannah Bink heads the Marketing Success team at Scaled Agile. She has nearly 15 years of B2B marketing experience and studied business at Pennsylvania State University. Prior to Scaled Agile, Hannah spent the majority of her career in telecommunications and healthcare sectors, running global marketing divisions. She is also author of the “Musings of a Marketeer” blog, and lives in Denver, Colorado.

View all posts by Hannah Bink

Share:

Back to: All Blog Posts

Next: What is SAFe? Eight Facts About the Scaled Agile Framework That You Should Know.

8 Facts about Scaled Agile Framework Training

If you’ve spent much time working in enterprise environments, you might have heard about the Scaled Agile Framework® (SAFe®). And if that’s the case, there’s also a good chance that you’ve heard many opinions about what SAFe is and what it’s not.

Maybe you’ve found yourself in a ‘SAFe-adjacent’ space, are curious about how SAFe concepts can help you, or are new to the space entirely. Regardless, here are eight facts about SAFe that you should know. 

 1: SAFe is based on nearly 100 years of lessons learned

The concepts within SAFe are nothing new. In fact, one key aspect of the Framework—flow—was first documented by Shigeo Shingo and Taiichi Ohno in the 1930s as the Toyota Production System (translated to Lean manufacturing).

2: Enterprises of all sizes are using SAFe to solve the digital transformation equation

For organizations such as MetLife, Lockheed Martin, and PepsiCo, SAFe has proven to be a significant factor in helping them figure out what it means to be a digital organization and how to remain competitive in a post-digital economy. What have we learned? That is in 2020, every company is a digital company that may serve a specific customer or market. Mastering customer-centricity and technology are not optional.

3: Enterprises use SAFe to successfully run their entire business

Though SAFe has helped many large organizations address the challenges of large and complex solutions, the Framework is not effective only in those circumstances. In fact, many smaller organizations (such as Mattis & Company and Scaled Agile itself) have found success running their entire business using Portfolio SAFe. It doesn’t matter if technology is your entire business or only part of it, the concepts of organizing around value, Lean startup, and business agility transcend the type of work being done. 

4: Enterprises use SAFe to successfully build complicated cyber-physical solutions
SAFe has helped organizations, such as FitBit, solve the complexity of delivering cyber-physical solutions (the art of marrying software and hardware) within a tight market rhythm to achieve quality and predictability. Organizations like FitBit also appreciate the guidance around Agile Product Management and Lean Portfolio Management to help them achieve strategy agility. 

5: SAFe helps highlight opportunities for improvement

When organizations begin their SAFe journey, many systemic issues become very clear. Issues such as bloated processes, communication bottlenecks, duplicative work, and a lack of understanding around what customers teams serve. While SAFe won’t fix these problems for you, applying the Lean-Agile Mindset, SAFe Lean-Agile Principles, and SAFe Core Values can help you figure out the correct path given your unique context and circumstances.  

6: SAFe is more about what you value than what you do

Many well-intentioned people have relied on the processes within SAFe to address their issues. And more often than not, these people have been quick to learn that SAFe is less about what we do and more about why we do it. Changing mindset, values, and principles is hard to do on your own. Fortunately, there is a plan to help you get started, and plenty of seasoned professionals to guide you along the way. 

7: Enterprises use the tools within SAFe to solve all sorts of problems

You’re in the right headspace if you consider SAFe a giant toolbox—a resource full of proven concepts and patterns that can be used to solve a wide variety of problems, like quality, time-to-market, and employee engagement. But those aren’t the only problems SAFe can help an organization address. At Scaled Agile, we regularly maintain and expand our library of valuable resources, including toolkits, workshops, and videos—all freely available to members of the SAFe Community Platform. Consultants and coaches use these resources daily to help organizations create solutions that are rooted in the Lean-Agile Principles and applied in organizations’ specific contexts.

8: SAFe is constantly evolving

As the global business climate continues to change at an ever-accelerating pace, the Framework is changing along with it. From providing guidance around participatory budgeting, SAFe® for Marketing, and people agility—and in the spirit of relentless improvement—the Scaled Agile team is constantly working to refine these concepts. We’re committed to understanding markets, evolving business guidance, and helping you help others win in the post-digital economy.

Join us at this year’s 2020 Global SAFe Summit to learn more about SAFe from the people practicing it, and explore a wide variety of concepts and topics. I hope to see you there!

About Adam Mattis

Adam Mattis headshot

Adam Mattis is a SAFe Program Consultant Trainer (SPCT) at Scaled Agile with many years of experience overseeing SAFe implementations across a wide range of industries. He’s also an experienced transformation architect, engaging speaker, energetic trainer, and a regular contributor to the broader Lean-Agile and educational communities. Learn more about Adam at adammattis.com.

View all posts by Adam Mattis

Share:

Back to: All Blog Posts

Next: SAFe® Program Dependency Board Retrospective

SAFe® Program Dependency Board Retrospective – PI Planning and Execution

Learning from the program dependency board

SAFe® Program Dependency Board Retrospective

The SAFe program board, or program dependency board, is a key artifact used in PI Planning and execution. The Agile Release Train (ART) teams and stakeholders used it to align, anticipate risks, and adapt the plan accordingly.

This inspection and adaptation of the plan based on insights from the program dependency board is first-loop learning—making changes in the plan based on what we see.

Deeper learning from the program dependency board

What we rarely see, though, is deeper learning from what the program dependency board shows us. It’s like the good old times where you would see a project manager/PMO working their Microsoft Project Gantt Chart, moving things around, but rarely stopping to ask deeper questions around the base structure of their plans and why they’re based on a waterfall model.

Program dependency boards can drive deeper learning about the structure of our ART and its alignment with the kind of mission/vision we’re pursuing, and the backlog of features we’re working on. If we see too much red yarn on our boards, it isn’t something to be proud of. Yes, we can be proud that we identified the dependency and even more that we were able to massage our PI plan to deal with it in a reasonable way. But too much red yarn means too many dependencies. Too many dependencies mean our Value Stream network isn’t configured well. It means we should probably look at ways to reconfigure the network (meaning restructure teams and maybe even the ART).

When to do this deeper learning

I get it. This sort of learning is hard to pursue in the heat of PI Planning. And all too often when PI Planning is done and we have a workable plan in hand, it’s tempting to just move into execution. Resist the temptation. Let the dust settle, but find the time that makes sense to have a deeper retrospective that is based on the patterns you see on the program board. This can be a good discussion in your Scrum of Scrums or with an extended forum that includes the wider ART leadership.

There’s no need to wait for the next inspection and adapt (I&A). It’s fresh now and outcomes from this retrospective might anyhow require a lot of refinement and consideration before they’re actionable. Start the process early in the PI, so hopefully, you’ll be in a position to reconfigure the network going into the next PI as needed.

A typical pattern is when such a retrospective raises the need to rerun a Value Stream identification (VSI) workshop.

SAFe® Program Dependency Board Retrospective

Validating the Value Stream design hypothesis—a key but often skipped step

Speaking of the VSI workshop, one key element in it that many practitioners skip is the validation of your Value Stream design hypothesis. After identifying a development Value Stream, run some water through the pipes—take some work in the form of Features or even higher-level Epics/Themes and explore how they will flow through this Value Stream/ART/Solution ART. If the work flows nicely with a minimal number of dependencies, you found a good setup. If even in this ‘dry run’ you already see you have too many dependencies, time to rework the design!

PI Planning dry run

And yes, what this dry run means is that ideally, even in this early phase, before even launching the ART, you should consider doing a light version of PI Planning with the Value Stream design you have in mind to see that it makes sense. You don’t want to train everybody, spend a serious amount of time on preparing to launch the ART, and then find it’s not a self-sufficient ART or that it’s comprised of teams that aren’t self-sufficient.

Summary

I’ve talked about some recommended SAFe best practices here—some are implicitly mentioned in SAFe, and some complement the formal guidance. The key point I wanted to make is how important is it to aim for the right Value Stream network and to continuously inspect and adapt so that value can easily flow with minimal dependencies and slowdowns. And if your Value Stream network is configured well, everything else becomes much easier.

If you’d like to read more about my SAFe experiences in the trenches, I’ve written an e-book. I’ll also be at the upcoming 2020 Global SAFe Summit on the Agile Marketing panel, at the AgileSparks booth in the Partner Marketplace, and at the SAFe Experts Coaching Station. I look forward to connecting with you.

About Yuval Yeret

Yuval Yeret is the head of AgileSparks (a Scaled Agile Partner)

Yuval Yeret is the head of AgileSparks (a Scaled Agile Partner) in the United States where he leads enterprise-level Agile implementations. He’s also the steward of The AgileSparks Way and the firm’s SAFe, Flow/Kanban, and Agile Marketing. Yuval is a SAFe Program Consultant Trainer (SPCT5), a Professional Scrum.org Trainer (PST), an internationally recognized Kanban Trainer, a thought leader, recipient of the Lean/Kanban Brickell Key Award, and a frequent speaker at industry conferences.

View all posts by Yuval Yeret

Share:

Back to: All Blog Posts

Next: The Power of Informal Learning Networks

Welcome to the Scaled Agile Blog – Enhance SAFe® Knowledge

Scaled Agile Team

Hi, we’re glad you found us. Now that you have, we thought we’d introduce you to what our new Scaled Agile blog is all about and what topics you can look forward to.

If you think you’re seeing double, you’re not. There’s another blog on scaledagileframework.com that’s full of great posts designed to enhance the guidance provided in the SAFe® knowledge base. Many are written by members of the Framework team‚ including SAFe’s creator Dean Leffingwell, and cover the more technical elements of the Framework.

But the world of SAFe has grown too big for just one news source, so we created the Scaled Agile blog to keep you up to date on other topics, including:

  • Success stories from businesses experiencing wins of all sizes
  • SAFe tips and tricks
  • Aha moments from customers, partners, instructors, and students
  • The latest videos from our awesome multimedia team
  • Anecdotes from Scaled Agile employees inside our headquarters and out in the wild
  • How teams are using SAFe outside of software/product development
  • The latest announcements and early bird deals for SAFe events

You’ll get to read blog posts from our partners, folks in the field, scrum masters and product owners, customers, and our instructors, just to name a few. It’s through these voices that we hope to connect with you, inspire you, learn from you, and simply provide some great—and relevant—content on the topics you care about.

Interest piqued? Good! Consider subscribing and be the first to read the latest and greatest posts from Scaled Agile.

Speaking of new posts, check out “What in the World is SAFe?” by Emma Ropski, an editor on our Learning and Certification team.

Happy reading!

About JB Brockman

JB Brockman

JB has been writing great B2B copy for 15+ years and is thrilled to again be working in an Agile marketing environment. In her fun time, JB skis, rides bikes, travels, and eats great food with her friends and family.

View all posts by JB Brockman

Share:

Back to: All Blog Posts

Next: Aligning Global Teams Through Agile Program Management: A Case Study