In large-scale product development, multiple teams work on one product. Team PO is prevalent for various reasons, but they are anti-patterns. In this article, I try to describe those and provide the leverages. In Scrum, PO plays an important role in breaking the traditional contract game and improving the collaboration
I have seen ever-growing development group over and over again, whether it is a component team, a specialized feature team, or a Requirement Area (RA). There is an intriguing dynamic behind. Ever-growing people This is my first time writing a dynamic with Stock & Flow Diagram (SFD) rather than Causal
People ask me how long it takes to adopt LeSS? I say, half a day. I refer to the most visible change in the LeSS adoption - team self-designing workshop, where the restructuring to feature teams happens. In fact, change starts before it starts. A couple of years ago, my
Mental models are underlying assumptions. Many different behaviors and decisions could be traced back to different mental models. However, when we start to argue whose mental model is right or wrong, it usually leads nowhere. Make it explicit In order to be able to talk about different mental models, the
When adopting Scrum, we usually take the team-first approach by looking at which teams to pilot Scrum. However, the problem with this approach is that quite often the existing teams are not properly designed for Scrum. So, the alternative approach is organization-first by looking at which part of the organization
Almost a year ago, I wrote about "Seeing the underlying resource thinking". It was in the context of large-scale product development. In my recent training and coaching, I face more holistic product development including not only software, but also hardware, mechanical, supplier chain, etc. It is a different
I thought that this choice was essentially the same as the choice of 1 vs. n Product Backlog. When I examine more, I find it worthwhile to write it as a separate topic. As the two most popular scaling frameworks - SAFe and LeSS, they made different choices on this.
Regarding time dimension, SAFe introduces another concept called PI (Program Increment) besides Sprint. This is a super Sprint, by default consisting of 4 normal Sprints plus 1 special Sprint called IP (Innovation and Planning). In Scrum and LeSS (LeSS is still Scrum), there is no such concept, and Sprint is
Sprint review is the Scrum element for which I evolved my understanding the most during the past 10+ years. There still exists two prevalent but mistaken views. * Sprint review is about showcase. The demo could be an effective vehicle for product learning, but showing "good" case, and hiding
User role describes the relationship to the system. I read this from somewhere, but could not find its origin any more. In Mike Cohn's classic book "User Story Applied", there is a chapter dedicated on this topic called "user role modeling". It referred to
Recently, I read an interesting experiment from the book "Why we do what we do: understanding self-motivation" by a psychologist called Edward L. Deci. In this experiment, the subjects were teachers. They came into the lab to teach students how to solve problems. They were randomly assigned to
Regarding the time dimension, there are two main options - sprint (aka iteration, timebox) or flow. This choice is often coupled with the choice of implementing Scrum vs. Kanban, respectively. However, in this article, we do not try to compare Scrum vs. Kanban, but only sprint vs. flow. We focus