Yuval Yeret

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. Nexus and SAFe - Similar Concepts Let’s start with similarities - There are quite a few of them as you can see: Nexus - ART The Nexus group of teams is very similar to the Agile Release Train (ART) construct. In both SAFe/Scrum it is a self-managing team of self-managed teams with a couple of key roles at the team of teams level. Following the principles of Empiricism, Self-management within constraints, organization around value, and flow. Scrum theory emphasizes Empiricism and Self-management, coupled with Flow in recent years. SAFe’s theoretical base is more verbose but essentially similar. Lean/Agile Leadership Both SAFe and Scrum/Nexus emphasize the need for a different style of leadership - leaders who serve, have a growth mindset, lead by example, live and breath Lean/Agile principles and practices, and strive for relentless improvement. Sprint - Iteration SAFe chooses the term Iteration which is more reminiscent of Extreme Programming (XP) but looking at the details Sprints and Iterations are quite interchangeable. PS Some people feel the term Sprint isn’t the best choice if we want to emphasize “sustainable pace”. One Product Backlog - Program Backlog Nexus emphasizes that for one Product there should be one single backlog - the Product Backlog. While SAFe has multiple Team Backlogs for teams working together on a product, it does have the concept of the Program Backlog which serves a similar purpose to the Product Backlog. Nexus Integration Team (NIT) - System Team Both of these have a similar goal - enabling an Integrated Increment at the end of each Iteration/Sprint across the teams. When it comes to how these teams operate Nexus emphasizes the coaching/enablement role while SAFe has a bit more of an emphasis on the actual Integration work. The NIT approach should be a very interesting practice to consider on a SAFe ART / System Team. Scrum Master in the NIT - RTE The Scrum Master in the NIT has a role similar to the Release Train Engineer - orchestrating and facilitating the effective use of Scrum/SAFe across the Nexus/ART with the purpose of enabling a tight Inspection and Adaptation cycle leveraging working product increments. Empiricism via working integrated increments every Sprint - System Demo & Nexus Sprint Review meeting a common Definition of “Done” Both SAFe and Scrum make it very clear that frequent inspection and adaptation of working integrated increments are key to managing the uncertainty/variability inherent to product development in the complex space. The Nexus Sprint Review and the System Demo are similar events happening on a similar cadence - every several weeks (Sprint/Iteration) Nexus Sprint Goal - Program PI Objectives - just at different cadence/frequency Program PI Objectives serve a similar purpose to the Nexus Sprint Goal - a steady North Star goal for the Sprint or set of Iterations to focus on while the details might shift around. You cannot scale crap - Scaling requires technical excellence Both Nexus and SAFe emphasize building quality in and the importance of XP-inspired technical practices in order to effectively scale. Without the technical excellence, both SAFe and Nexus would drown in technical debt. Important Differences Nexus - ART Didn’t I just say The Nexus is similar to the ART? Well, God is in the details… A Nexus is approximately 3-9 Scrum Teams working together. An ART is approximately 5-12 teams working together. This seemingly minor change provides some insight into some of the design choices of the two frameworks. A smaller Nexus can be easier to provide Product Ownership for, making the “Single Product Owner” a more viable choice. Nexus-level events are easier to facilitate/orchestrate than whole-ART events, provide some insight into why SAFe only brings the whole ART together every PI, not every Sprint. For larger teams of teams working on a single product, there’s Nexus+. Nexus+ is comprised of several Nexus. The “Organize around Value” challenge both for Nexus+ as well as the SAFe ART is to figure out what set of teams need to closely coordinate and collaborate. One Product Owner vs Product Ownership/Management Team - PM/POs SAFe’s approach to product ownership is that scale is achieved by splitting the product ownership role between Product Management, which is more like the classic Scrum Product Owner, and the Product Owner, which is indeed more like a proxy or technical product owner working more closely with teams. One of the main reasons SAFe takes this path is that it’s hard for one Product Owner to deal with too many teams while balancing both outbound and inbound activities. Nexus has Product Owner for the entire product. In real life, these Product Owners are typically accountable for the value delivered by these multiple teams and rely upon a lot of assistance from the Development Teams in order to deal with the challenge of scale. As we emphasize in Scrum.org Product Ownership training, Benefits from Scrum are quite limited if your Product Owners are Scribes or Proxies. It might be easier to coordinate meetings and get time with the Product Owner but its harder to maximize value. Benefits grow when the Product Owners are real business representatives, sponsors, or ideally entrepreneurs for their Product. What I’ve seen in the trenches ranges from SAFe Product Owners that really own a product within the bigger solution, own a set of features or even a specific feature that is currently being developed, all the way to technical product owners that aren’t real product owners. Striving towards real product ownership and what it looks like within a SAFe ART is a key topic when I’m helping an ART “Organize around Value”. Similarly to the Feature/Component team discussion, there isn’t a single best-practice here. You need to apply Systems Thinking and look at the different options, and relentlessly improve. Cadence/Frequency of bringing the whole Nexus/ART together for Planning and Retrospection The Nexus reviews, retrospects, plans, and refines together every Sprint. That doesn’t mean the WHOLE Nexus gets together every Sprint though. Typically, Sprint Review has quite a wide attendance including Nexus stakeholders. Refinement, Planning and Retrospective is attended by the appropriate representatives of the Scrum Teams. What’s appropriate is a matter of context of course. In SAFe, the only ART-level Iteration event is System Demo (which as we discussed is very similar to the Sprint Review). There’s no formal place for the ART to Plan/Refine/Retrospect across teams on a Sprint by Sprint basis. Having said that, The ART Sync provides an opportunity to inspect and adapt throughout the ART that many organizations use to Plan/Refine/Retrospect. The formal cross-team Retrospection/Planning cadence in SAFe is the Program Increment which is explicitly a whole-ART event. No team-level Sprint Review Nexus only has one cross-team Sprint Review. On paper, SAFe has both the Iteration Reviews at the team level as well as the System Demo at the ART level. In reality, many ARTs skip the Iteration Reviews and get enough inspection and adaptation from the System Demo. Scope - Team of Teams vs organizational-level Nexus focuses on just the team of teams - what is considered the “Essential” configuration in SAFe. SAFe also covers other competencies needed for Business Agility - Lean Portfolio Management, Large Solutions. Some organizations using Nexus end up looking at SAFe’s Portfolio-level competencies or Portfolio Kanbans to complement Nexus. Integrated Nexus Sprint Backlog vs various team iteration backlogs A Nexus Sprint Backlog is the composite of the Nexus Sprint Goal and Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. This doesn’t explicitly exist in SAFe and should be considered by ARTs that want to highlight dependencies and the flow of work during the Sprint across the ART. It can be seen as a Sprint-level version of the “Program Board” Program Kanban SAFe includes one of the most powerful techniques to help improve flow and collaboration across a team of teams - a Kanban Board that takes a cross-team perspective. I started using this technique back in 2009 and it’s one I “don’t leave home without”. Nexus doesn’t include a Nexus-level Kanban board but it's a very nice complementary practice to consider. Read more here Other potentially useful elements of SAFe that aren’t covered in Nexus As Nexus is designed to be a lightweight framework, with a more limited scope than SAFe, its not surprising that there are a lot more elements in SAFe that Nexus doesn’t say anything about. Some of these can be useful in your context, some not necessarily. Think Architectural Runway, Innovation and Planning iteration, Team-level Kanbans, DevOps, Continuous Delivery pipeline, System Architect, Business Owner, Features/Enablers, Epics. Some ideas for Improving SAFe inspired by Nexus I hinted at some of these above: Retrospect and Plan together across the ART every Sprint/Iteration Don’t just review together every Sprint. Also retrospect and plan together. It doesn’t mean bringing the whole ART together necessarily. It just means creating some alignment across the ART before splitting off and doing Iteration Planning at each team and then coming back together. Sort of like the pattern Solution Trains use when they do PI Planning. Use an ART-level Sprint Backlog Similar to a Program Board for the PI, use an Integrated Nexus Sprint Backlog to look at dependencies at a more granular Sprint/Iteration level. This is an artifact that can support ART-level Iteration Planning Some ideas for adding to Nexus inspired by SAFe Use “Big Room Planning” every 8-12 weeks Follow the SAFe PI Planning format for higher-level alignment/refinement once in a while across the Nexus. Adjust Cadences and level of participation Figure out what level of "big room" whole Nexus together makes sense every Sprint and what can fit a less frequent cadence (e.g. a PI) - Look at how you run the Nexus Sprint Planning, Retrospective specifically. Get inspiration from the SAFe Lean/Agile Principles and Competencies Looking at the SAFe Principles and complementary Lean/Agile competencies like Lean Portfolio as a way to support the Nexus within the traditional ecosystem in the organization. One specific technique you can use is to look at the “Measure & Grow” Business Agility assessments that are included in SAFe. Each category or item could be something you’re already doing (great!), something that you aren’t doing yet but makes sense to consider (also great!), something that doesn’t make sense in your context (fair enough), or something that you disagree with vehemently (totally acceptable as long as you’re looking at each principle/technique at its merits…). This exercise could create an improvement backlog/roadmap. Conclusion - Options are good, Tunnel vision is bad As professional agile practitioners we should be curious and open to new ideas. It helps to get exposed to different scaling frameworks - it gives us a better understanding of the one we're proficient in and using, as well as provides some more ideas we can consider experimenting with. In our work with clients we try to steer them away from dogma and tunnel vision. Yes, learning multiple scaling "languages" can be confusing. (You know what I mean if you have a toddler in the house learning to speak when there are multiple languages spoken around them...) but I think it's totally worth it. As SAFe principle #3 says "Assume Variability, Preserve Options". Get in touch with me if you're interested in figuring out how Nexus can complement your SAFe implementation or vice versa.

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. 

The Professional Scrum with Kanban (PSK) class was launched a year ago - Feb 26 to be precise. We've done some inspection and adaptation throughout the year but this anniversary is a nice opportunity to reflect on where we are and where we're going. So what did we have in this inaugural year of Professional Scrum with Kanban at Scrum.org? In this first year what Scrum.org and the class stewards (Daniel Vacanti and myself) have been focused on is introducing the Scrum with Kanban class to the market and creating a supporting ecosystem for it. We did this at conferences, meetups, Scrum.org Trainer F2F events, podcasts. We wrote blog posts and articles and even did a video or two for the Scrum.org Video Blog. We worked on establishing a worldwide network of trainers that could deliver a Professional Scrum with Kanban curriculum. We ran multiple train-the-trainer events and worked with Scrum.org PSTs to help bring them into the world of Kanban and flow. We were delighted to see how many of the PSTs have already been using Kanban and were anxious to start teaching a Scrum+Kanban curriculum from Scrum.org. We now have over 40 Scrum.org PSTs that are licensed to teach the class. We (as in the Scrum.org PSTs) trained more than 400 students all over the world. We created and nurtured an assessment to accompany the curriculum. The PSK1 assessment was launched back in April. We inspected and adapted the assessment based on feedback and actual performance. What we hear about the PSK1 these days is that it is "Tough but fair". We also made sure that the Kanban Guide for Scrum teams was complemented with some supporting materials in the form of blog posts and articles that can support Scrum practitioners in their learning/competency journey. We hear that these materials complement the assessment well. As usual in the Scrum.org world, it isn't mandatory to take a class in order to pass the assessment and we indeed see a constant flow of practitioners taking the assessment on its own. The pass rate is higher for those who take it after a PSK class understandably. We launched an open PSK assessment back in August to give people a taste for the assessment and the class. We've had more than a thousand people take the assessment so far (and many of them say it is pretty tough - we have a 53% pass rate) We took in feedback and ran a couple of iterations of changes on the curriculum. We added/removed/changed exercises, visuals, flow. All in all, we closed 72 GitHub issues containing feedback about the class. (We currently have 42 issues in our Product Backlog. ) What have we learned? The PSK is valuable to all Scrum practitioners. It is especially valuable to Scrum Masters who are looking for ways to help the teams they're working with. We used this insight to hone some of our messaging and positioning over the year to make sure that Scrum Masters indeed see the PSK as a natural step in their learning/competence journey. Scrum trainers and practitioners are very excited about finding alternatives to Story Points, Velocity and Burndown charts. PSK is coming just at the right time with more and more Scrum practitioners realizing these aren't part of core Scrum anyhow, just complementary practices that work in some contexts. And in many contexts, the alternative of Throughput, Monte Carlo, counting small PBIs delivers better results. Learning about Kanban's principles actually reinforces your understanding of Scrum and what makes it tick. Talking about queueing theory, small batches, limiting work in process, continuous flow takes people through a journey of rediscovering some of the core Scrum concepts such as the Sprint Forecast and the Sprint itself. Personally, I just love it when I see people realizing how Scrum limits work in process when you do it right. The format works. Starting with a discussion about the risks of ignoring flow in Scrum, then introducing flow and Kanban, experiencing Kanban and then exploring the impact Kanban would have on the Scrum artifacts, events and roles is overall a good flow for the class. We're still playing with the order of some of the Scrum impact elements and we can definitely improve some of the exploration exercises but the overall story works. It's possible and important to build bridges and be open to other approaches. We've learned that it's possible to transcend the Agile methodology wars and that sometimes we look to the practitioners in the field like a rendition of Monty Python's "People's Front of Judea" skit. And building bridges isn't just about Scrum.org launching the PSK class. It's also about looking at ways to cross-pollinate between the different Scrum competency areas and therefore classes. Creating this organic links between the domains - e.g. by talking about Monte Carlo forecasting when discussing Release Planning and predictability/confidence/professionalism in a Scrum Master or Product Owner class is maybe even a more important bridge to build. What's next with the PSK We will continue to fine tune the curriculum with the aim of optimizing the class experience and the outcomes students are able to achieve after it. We still have lots of work to do around educating Scrum practitioners and especially Scrum Masters about the value of Kanban and especially the value of doing Kanban professionally when trying to improve the professionalism of your Scrum team. We will work with the stewards of other Scrum.org classes on integrating key concepts from PSK into these classes where it makes sense. There are so many cool ideas for what to add to the PSK and how to change it. Many of these make more sense as ideas for a PSK2. We're not yet working on that one but we're seeing more and more demand for it, at least from the trainer community. This could give us the opportunity to dive deeper into topics such as whole value stream flow, DevOps/CD, Scaling, adding Scrum to a Kanban context and more.

When I work with my clients on Scrum in a Marketing context the discussion about the Marketing Backlog and how to move from a big bang marketing campaign to a more iterative approach via smaller slices of stories is naturally a key area we focus on.