Yuval Yeret

I'm encountering more and more people that are trying to solve different kind of problems with Scrum..

I'm hearing from more and more companies that are using the Entrepreneurial Operating System® (EOS®) and are also looking at or practicing Agile e.g. using Scrum. In discussions with these companies two key questions surface time after time: My teams want to use Agile/Scrum - is that aligned with the fact that we’re using EOS® in the organization? My teams use Agile/Scrum, can we use EOS®? The short answer is that Agile and specifically Scrum and EOS®are mostly complementary. EOS®, as well as Agile approaches, emphasize focus, alignment, a disciplined approach with structured events, artifacts, and policies that attempt to limit the amount of work in process (WIP) in a systematic way, and create better flow with cadence. So what’s one big thing that’s different about Agile/Scrum in comparison to EOS®? Transparency and Empiricism Transparency is emphasized in both but is used differently. Both approaches make the work transparent. Agile frameworks like Scrum are designed to deal with VUCA (Volatility, Uncertainty, Complexity, Ambiguity) through empiricism - an aspect which EOS®isn’t explicitly solving for. And in this environment Transparency goes much further - it is not just awareness of what the team and individuals on the team are working on - it is the transparency of whether the product of the team’s work (whether the team is building a product or leading a company) is working and effective. Scrum can help teams: align towards the Vision - making the Vision or a specific sub-aspect of it their “Product Goal” (even if they’re not a Product team - it’s the overarching goal for the product of their work - be it winning deals, operating the company, growing, etc. ) plan and deliver on their Rocks and achieve Traction®- by using Product Backlogs, Sprints, and potentially concepts like “Program Increments” from SAFe which align very well with the EOS®Quarter. EOS® Big Rocks can map almost 1:1 to PI Objectives. For teams, We recommend having them at the team level and not an individual contributor in order to drive collaborative collective ownership towards results. When scaling across the organization each team/function does have its own list of PI Objectives/Big Rocks like in EOS, as well as an organization-wide list of Big Rocks / PI Objectives. SAFe PI Planning or other types of Big Room Planning could complement EOS®Quarterly planning by involving the actual Teams and not just the function leads in the planning and accountability cycle. Issues are very similar to Risks and how they’re managed in SAFe via ongoing ROAMing (Resolving, Owning, Accepting, Mitigating) Scrum Sprints map to the Weekly Level 10 cycle. Sprint Review/Retrospective/Planning is an opportunity to inspect and adapt where we are within the quarter, which is especially important in VUCA We’re not just executing a quarterly plan. We’re intentionally learning what works/doesn’t and adjusting course accordingly. Another opportunity is to use Scrum at the leadership level - as a way to apply more empiricism to complement EOS®discipline. All of the above could be used by the leadership team itself. The “Product Backlog” is focused on the “product” of the leadership team’s work - which is leading the company - solving issues, growing, implementing strategies/tactics, etc. Changes in Process, People, Dealing with Issues, Advancing Rocks. The Increment of each Sprint is not just a “Done / Not Done” answer to to-do items - it’s an actual “working change” in how the company operates. (For example - list of candidates for a VP position, draft scorecard, analysis of desired profitability range, etc. ) This Increment is ready for the leadership team to inspect, review, with the goal of adapting their plans (Product Backlog) accordingly each and every Sprint/Week. A leadership team could also decide to run longer Sprints e.g. Monthly and use a weekly cycle similar to Scrum’s “Daily Scrum” to inspect and adapt progress within the Sprint. The Sprint length should match the level of VUCA the leadership team/company is facing. Leadership Team acts as the “Developers” of the “Product” The PO/SM Scrum roles could map several ways - Option 1 Visionary - Product Owner Integrator - Scrum Master Option 2 Visionary and Integrator™- Sharing the Product Owner role Dedicated coach/Scrum expert as the Scrum Master Similar to how EOS®starts at the top, Organizations NOT using Scrum yet could use Scrum to complement EOS® at the top level and then expand from there into the various teams. This would follow the guidelines/mapping described above. In this scenario, a solid Scrum Training/Coaching would be provided to the leadership team in advance of the whole organization and they would become Scrum Practitioners better able to understand as well as drive what’s going on when Scrum/EOS®gets implemented throughout the organization. For teams in an organization using EOS®… If you’re starting to use Scrum in an organization using EOS®or if you’re using Scrum and your organization is in the process of implementing EOS®the list of mappings above will help you create some common language and reduce the conflict/confusion that might arise due to running both EOS®and Scrum at the same time. Real/Imaginary conflicts between Scrum and EOS® Is EOS®Waterfall? The main aspect of EOS®that looks waterfallish is the fact that it runs a quarterly cycle with planning the Rocks for the quarter in advance. I don’t consider that waterfall. And if care is given to making sure that Rocks focus on WHAT rather than HOW and leave enough space to account for variability/learning, I don’t see a problem. It’s very similar to SAFe’s PI-level planning, which is again properly done with an eye towards emerging learning and adjusting course as needed while staying focused on the high-level objectives for the quarter. How about individual accountability in EOS®- isn’t that in conflict with Scrum’s “Collective Ownership” approach? Isn’t EOS®in the way of Teamwork? Indeed this is a potential area of conflict. But even EOS®makes several mentions of the fact that in order to succeed team members need to prioritize the team’s rocks over their individual ones and support each other. When implementing EOS®there should be an emphasis on accountability towards team rocks rather than individual rocks, even at the leadership team level. Isn’t EOS® Micro-management under a thin veil? The way to look at this is that EOS®allows teams to micro-manage their work - with the understanding that in a VUCA environment there’ll be lots of surprises and emerging realities that are better addressed quickly. The Integrator role, like the Scrum Master, should lead the team through this discipline of tight-loop inspection and adaptation, rather than feel a need to micromanage work or output. Learning the proper “Leaders who Serve” Scrum Master mindset would be very useful to any EOS leader if he wants to avoid EOS becoming a checklist-based micro-management tool. Conclusion As you can see above, as long as you understand the purpose and practices of EOS®, Agile, and Scrum, and are thinking about how they can complement each other, you can definitely use them in tandem. If you want some help in thinking through what this would mean in your context, we'll be happy to discuss it further. Credits to Erez Tatcher, AgileSparks CEO who participated in the thinking and writing of this article.

I've been asked several times now about Nexus and SAFe - what are the similarities, differences, etc. If you’re not familiar with either Nexus or SAFe I recommend taking a look at the Nexus Guide and the SAFe whitepaper first.

So you have a couple of Scrum Teams that are working in adjacent areas and you're starting to face some challenges in delivering value in a coordinated integrative way.

I've been using a visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from "The Little Prince". (I'm sure there is a good connection to elephant carpaccio somewhere in here ...). In this article I'll explore this model and connect it to the stances of the Scrum Product Owner. 

The COVID19 pandemic gives us plenty of opportunities to think about uncertainty, complexity, and how to deal with those using Empiricism.

The Kanban Guide for Scrum Teams aims to help Scrum Teams leverage the ideas and practices of Flow and Kanban in a way that is coherent with Scrum as defined by the Scrum Guide.

Defining Agile/Scrum for Marketing Scrum.org joined the discussion around Agile Marketing recently. This is an area close to my heart. I've been helping Marketing organizations leverage Scrum, Kanban and Lean Startup concepts to improve their agility since around 2016 or so and I find it a fascinating space for the application of flow and empiricism - a world that is in dire need of a more agile operating system. In this article, I will provide my definition of "Agile Marketing" - The application of ideas from the world of "Lean/Agile Software Development" to the world of marketing with the aim of achieving marketing agility. Then in a follow up article I'll share some thoughts and experiences about using Scrum for Agile Marketing contexts. The audience for this blog is both Scrum practitioners getting some questions about using Scrum in a marketing context as well as marketers interested in Agile Marketing and Scrum. Agile Marketing - What it ISN'T First, a couple of clarifications and myth-busting. Agile Marketing isn't reactive marketing. Agile Marketing isn't about how you react in a Marketing/PR crisis (ask United about those) or real-time opportunity (you can ask Oreo about those). I don't mean that you can not/shouldn't deal with those when you're doing Agile Marketing, but it isn't what Agile Marketing is about. Agile Marketing also isn't "We just get things done without any real process". You could say your marketing department is agile in how it deals with emerging needs and very responsive and it might be working great for you. But it's still not necessarily capital-A Agile Marketing! Agile Marketing isn't also Scrum. Agile Marketing isn't Daily Scrums/Standups, Sprints, Scrum Masters. Agile Marketing also isn't using a Kanban board to manage marketing. Agile Marketing isn't a methodology or even a framework. So, What IS Agile Marketing? Based on the same thinking and mindset behind Agile Development, Agile Marketing is an approach/philosophy that helps marketing professionals optimize deliver better results in a context of uncertainty and complexity through iterating, anticipating, and adaptation. In an earlier post, I described several challenges marketing organizations are facing. If you look at them more closely you will see that many of them arise from a significant growth in uncertainty that these organizations face. around both WHAT marketing would work as well as HOW to build these marketing deliverables in an effective way. Dealing with uncertainty around WHAT marketing experience to deliver In the diagram above, called the Stacey Matrix (see a description by Sam Laing back in 2013 or on my personal blog), WHAT relates to questions around what our customer journey experience should look like. well understood and agreed on means that we have very high certainty around what experience would drive our customers through their journey in the fastest most streamlined way. vague or not understood means we might think we know but we're not sure, or even worse we're oblivious to our gap of knowledge. In the age of the "Digital" experience, the explosion of channels, as well as the pace industries are being disrupted and forced to change, figuring out what constitutes an effective experience is becoming harder and harder challenge. Dealing with uncertainty around HOW to deliver the marketing experience HOW relates to questions around implementation. Here, a big part of the challenge is the growth of the marketing technology stack. As Molly Walsh asks, How the heck did we get here? Most marketing organizations are struggling to implement their marketing plays. The more technologies in your stack the more moving parts, the more uncertainty around how to fit the pieces together. As you can see, once you have both WHAT and HOW uncertainty, you're well into the complex space. In the complex space planning up front wields limited results as you can't predict what would work in advance. You can plan your objectives/goals/investments but even that would change as the landscape changes. Agile Marketing - Anticipating Complexity/Uncertainty and Dealing with it using Iteration/Adaptation Agile Marketing is about anticipating this complexity/uncertainty and dealing with it in a disciplined pragmatic sustainable manner. We plan to work in an iterative way. We plan based on some hypothesis. We build in small increments, validating both the technology/implementation as well as the experience as often as possible by demonstrating it and testing it both internally as well as in the real world. We also realize that when faced with this level of uncertainty and complexity it is hard to carve out marketing work into small self-contained pieces that can be planned and built-in isolation. It is better to create customer-focused teams where everyone working to optimize a certain marketing aspect is on the same team and can collaborate effectively. While several practitioners used Agile in the context of Marketing more than 10 years ago, Agile Marketing was officially born in 2012 with the creation of the Agile Marketing Manifesto during the SprintZero event. The Agile Marketing Manifesto emphasizes/values some new approaches to marketing that are replacing some well-entrenched marketing conventions. This is actually aligned with what Marketing leaders such as Sergio Zyman have been advocating for. If you read Sergio's "The End of Marketing As We Know It" from back in 2000 you will find hints of Agile Marketing! Validated Learning, Customer Discovery With Many Small Experiments, Leading to Adaptive and Iterative Campaigns The Agile Marketing Manifesto introduces concepts such as validated learning (which is brought over from the Lean Startup approach) - replacing decisions made just based on opinions and conventions with a process of looking at each marketing play, identifying risks/assumptions, then for the risky plays going into a Build-Measure-Learn experimentation iterative loop where marketers try to validate as quickly as possible whether their thinking and assumptions are correct. Upon validation, the play can be completed and scaled. In case of invalidation, the play can be tweaked/changed in what is called a "Pivot" to continue to look for a winning play. This is called "Fire bullets (and only) then fire cannonballs" in Jim Collins's Great By Choice. When there's less risk, it still makes sense to deliver incrementally - you want to minimize the cost of delays between the time you decide to execute a marketing play/campaign and the time you're able to go to the market. If you can deliver some minimal play/campaign that can already start to have an impact on your customer journey/brand, you want to do that. In Scrum theory we call this Empiricism. So interestingly enough you can argue that the Agile Marketing manifesto is more explicit on Empiricism - Transparency, Inspection and Adaptation via real experiments. Agile Marketing Isn't Easy To Digest This seemingly goes against marketing conventions like "nailing the perfect campaign and only then launching it with a big bang" and "protecting our brand by only releasing high-quality marketing content". Why seemingly? because in spirit the agile marketing approach actually is more aligned with the rationale behind these conventions. Using adaptive iterative campaigns leverage small experiments to make sure "we nailed it" and only then "launching with a big bang" still looks like a "big bang" to most of the market. In addition, you get the advantage of having a higher chance of success since it was validated in the real world, thereby actually protecting the brand by reducing the chance of spectacular failure upon the big bang launch. (e.g. Pepsi's controversial ad or New Coke - both smartly pulled from the market pretty quickly after considerable sunk costs). We HAVE to be able to adapt. It might feel uncomfortable but we must find a way to do it. The key to doing it well is to slice experiences in a way that you're still delivering a great experience but only for a small slice of the market or some part of their needs but in a way that is representative of the wider audience / experience so that you can learn and improve your plans/designs based on it. (e.g. just in one city, just for one type of users of your product, just as an experiment in one airport, whatever). Being able to craft meaningful high-quality experiences that are still smaller than the "full thing" is one of the non-trivial yet important skills of the agile marketer. There's a lot of applicable learning in this domain from what startups and enterprises are seeing trying to adopt "Lean Startup" "Minimum Viable Product" thinking but it comes down to innovative creative thinking by marketers to come up with the right tactics that can help them test their strategies without risking the brand or diminishing the overall impact of the overall marketing campaign. Customer Focused Collaboration Agile Marketing brings together marketers and other players to collaborate on improving customer experiences. If you were ever a sole marketer for a company or part of a marketing team for a small startup/company you know how this looks like. You can move much faster when everybody you need to deliver the overall marketing impact is on your team (or in your head). Most marketing organizations lose this advantage when they grow beyond a single team and start specializing. I cringe when I hear terms like Shared Services crossing over from IT and abused to optimize utilization at the expense of value delivery. (Sometimes this concept masquerades as the "Internal Agency" concept ) Customer-focused collaboration can be implemented by creating a Scrum cross-functional team with the relevant roles all part of the "Development Team" - collaborating to deliver a marketing impact on the customer's journey. Agile Marketing requires Lean/Agile Leadership Agile Marketing tries to bring back this effectiveness, speed, fun and focus of the small startup regardless of your organization size. We create autonomous agile marketing teams that are empowered to make local decisions aligned with achieving their goals while doing what's right for the overall brand. This only works if we: build the right competence by hiring the right people and encouraging them to master their domain and giving them the space to learn and improve create high clarity by sharing the business context, our vision, constraints. This autonomy and new structure don't mean there's no need for marketing managers/directors of course. It does mean changes in their focus e.g. on things like hiring and nurturing great marketers and providing clear and meaningful mission/purpose. Customer-focus teams can take many shapes Those customer-focused teams own aspects such as: The whole customer journey for a certain brand/product/market (e.g. SMB) Content Creation, Publication, Measurement A key marketing challenge/opportunity such as a stuck Middle of the Funnel (MOFU), ineffective Sales Enablement. Account Based Everything (ABX) Planning and delivering the company's Customer event or presence at a key industry event Exploration of a new marketing approach such as "Social Selling", "Video" A key marketing KPI that is not performing well or is identified as a key objective for growth. While we call it Agile Marketing, in many cases these teams include and involve participants from other adjacent functions such as Inside Sales, Product Management, Customer Success. From tasks to Customer-focused stories Once the marketing organization work structure is oriented towards a customer-focus - Agile Marketers start managing their work in a customer-focused way as well. They use work items that reflect marketing value such as "User Stories" or "Job Stories" rather than "to do lists" or "tasks". Thinking of work in this way and including the goal/impact expected of each work item as part of the "Story" helps marketers maintain a laser-focus on the customer impact they're aiming for day in and day out. This also makes it easier to communicate with business stakeholders about what marketing is focusing on and get their early feedback and guidance - which helps avoid the common situation where marketers talk in language that business/sales don't care about and after delivering something there are still major gaps between what the business/sales expected and the marketing that was delivered. Agile Marketers also use more disciplined and more customer-focused prioritization mechanisms that take into account considerations such as Cost of Delay, Time Criticality, Opportunities as well as Risks addressed to consider what to focus on next and whether to interrupt ongoing work for an emerging opportunity. Continuous Planning While some marketers understand agile marketing to mean "no planning" this is not the intent. The Agile Marketing Manifesto talks about "Responding To Change" over "Following The Plan". Another way to look at it as "Flexible" or "Continuous" Planning vs "Rigid Static Planning". Planning in Agile Marketing happens at two levels. One is planning what to work on and what we can commit to delivering for a certain timebox - be it a day, week, quarter or year. Let's call this cadence-driven planning. The other is focused on a certain marketing campaign/play - planning the strategy, vision, tactics, rollout plan for that campaign/play. Let's call this content-focused planning. Sometimes most content-focused planning happens during cadence-driven planning but that's not a must. It might make more sense to do the content-focused planning just in time as we start a campaign/play and not at the beginning of the quarter. Agile Marketers use a combination of Kanban, Scrum and sometimes a higher-level framework such as SAFe (Scaled Agile Framework) as their main techniques for dealing with these different planning and execution management levels. Scrum for Marketing - Same Same but Different So as you can see Agile Marketing applies the same principles used in Agile Software Development, together with a stronger more explicit focus on some ideas coming from the Lean Startup world. When it comes to using the Scrum framework - the values and the theory apply very directly. Marketers do struggle with the Roles, Events and Artifacts as defined in the Scrum Guide though... I'll elaborate more about these challenges in a future blog post... This blog post is based on an article published on the AgileSparks Blog

We've all seen it. The Scrum Team that goes through the motions, implements all the mechanics of Scrum, and still when we look at what's going on it doesn't feel right.

The comparison between Kanban and Scrum obviously comes up often when we're talking to teams, especially in the context of Professional Scrum with Kanban. While they are more similar than many practitioners realize, one key difference is the perspective on Teams.