Listen to the Kanban Guide for Scrum Teams in full - Narrated by one of its co-authors (Yuval Yeret - aka me)

What is SAFe’s perspective on the Product Owner role? How does it differ from the Scrum Guide? Why is Product Ownership split to Product Owner and Product Manager in SAFe? SAFe’s approach to Product Ownership draws quite a bit of criticism. As a Professional Scrum Trainer who’s also a SAFe Fellow/SPCT, here’s my perspective…

Agile was born in software development and has been widely adopted in IT and Product organizations to the point that there's little argument that product/technology organizations should operate using agility principles. More recently, other functions, such as Marketing, have adopted these agility principles and practices. These are useful stopgap measures on the journey toward real organizational agility. The next frontier in expanding the scope of agility is tackling the complex challenge of developing the company as the Product people use Scrum to manage.

The story of Capital One laying off hundreds of people in Agile roles is making the rounds. I have no direct connection to Capital One, so I can’t comment about what’s going on there. I'll just say that based on what I hear from people who've been involved, the reality is more complex than it seems on the surface. Check out my thoughts about the future of agile roles and agility in general.

Many organizations struggle with OKRs (Objectives and Key Results). Let's explore how agility principles and practices such as Scrum can help us use OKRs to improve alignment, focus, empowerment, and empiricism in our organization.

Many organizations are trying to improve the alignment between strategy and execution with the OKRs framework (Objectives and Key Results). There’s good intent there, but more often than not, looking under the hood, you notice:  OKRs that look more like tasks than strategic objectives – especially by the time they reach working teams OKRs are used to micro-manage teams and individuals rather than empower and enable them.  Too many OKRs are set without any respect/consideration of the ability to deliver them sustainably while dealing with other work in the organization. Defining OKRs and then forgetting about them until it's time to grade them. (Even worse, some organizations don’t even bother with a serious consideration of how they did on their OKRs…)  These are smells of "OKR Theater" or "OKRs in Name Only."

In this article, I’ll explore the need for and the attributes of an agile business operating system related to Private Equity (PE) portfolio companies. It hopefully helps leaders of such companies and PE professionals focused on the operations side expand their perspective on what “Agile” and "Agility" mean in their world and how they can help them improve returns realized in their investments. 

Are Scrum Masters here set up for success? Are they “leaders who serve”? Which of the Professional Scrum Master choices/stances can they choose from? Are they a core aspect of our organization's approach to leadership/management? Are they an afterthought to get a higher score on an agile maturity assessment or some RFP? Are they respected, and appreciated by the people they serve? Are they in high demand? Implementing the Scrum Master accountability effectively is hard. It ties straight into creating a servant leadership and self-managemement/empowering culture in which business agility thrives. These are some of the questions leaders should be asking and thinking about.

If you are an agile leader - do you know whether your teams are currently operating at a sustainable pace? Do you care? Would you rather not know because you’re afraid of the answer? 

Aligning Scrum Team Topology to Strategy with OKRs and Product Goals

Leaders use the Scrum Artifacts as a window into the work of the Scrum Team. This transparency enables inspection and adaptation at the appropriate level while enabling the team to self-manage. 

It's time to look at the Scrum Events

We started the Scrum Guide for Leaders series with a discussion of what Scrum means for you as a Leader. Next, we discussed the conditions where Scrum's Empiricism, Self-Management, and Continuous Improvement can thrive. We then explored some concrete examples of how adopting the Scrum Values as a Leader can help you create these conditions.

As mentioned earlier, Scrum is founded on empiricism - transparency, inspection, and adaptation. Empiricism is only possible in certain cultures and contexts. Leaders have the role of creating and nurturing the culture and shaping the context.

If you’re leading Scrum Teams or generally are a leader in an organization that’s leveraging Scrum?

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

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.

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.

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. 

In this video, Scrum.org Professional Scrum Trainer and Professional Scrum with Kanban (PSK) course steward Yuval Yeret talks about the PSK course, helping viewers to understand more about the structure of the class and what they will learn when attending. 

The Scaled Agile Framework (SAFe™) is one of the most popular approaches to applying agile at scale out there. SAFe's perspective is that "Nothing beats an Agile Team" and it doesn't try to reinvent the wheel or even innovate too much when it comes to the Team level

One of the key Kanban practices we discuss in the Kanban Guide for Scrum Teams is Limiting Work in Process. 

Over the years I've heard my share of these kinds of statements from various levels of executives...

If you’re a veteran of the software industry, you probably remember those days where we released to production/GA every couple of months. Heck, many of the companies I meet these days still work that way.

One of the new concepts we introduce in the Kanban Guide for Scrum Teams is the Service Level Expectation, defined as: An SLE forecasts how long it should take a given item to flow from start to finish within your workflow.

One of the key Kanban practices is Limiting Work in Progress. If you want to be pedantic, actually what this practice aims for is Reducing and stabilizing Work in Progress. This improves flow, provides predictability, and is actually even more important for creating a pull-based Kanban system than visualizing your workflow using a Kanban board. I worked with several clients that limited their WIP but didn't use Kanban boards. One could argue that maybe this practice deserves to be first in the list of Kanban practices, ahead of Visualization.

In the Kanban Guide for Scrum Teams and the Professional Scrum with Kanban workshop, we introduce 4 key flow metrics that we believe Scrum teams can use to improve their flow.

It’s been so exciting to hear so much positive feedback and interest in the new Scrum.org Kanban Guide for Scrum Teams and the ac

 

Bringing values down to earth Values and principles can often seem lofty and intangible so many agile practitioners prefer to focus on tools and practices. That's understandable but unfortunate.