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
Introducing coordination roles is a very common choice made by many organizations to deal with coordination complexity. I realized during the recent course that this quick fix is seen by many as the only solution while it is hard for many to even image that there is another fundamental solution.
Feature group is a temporary group of individuals to deliver specific feature. It is very common in traditional matrix organization, and also called feature project. Meanwhile, feature team is a stable team who takes shared responsibility to deliver feature after feature. The below table from feature team primer summarizes the
In a product organization with multiple teams, it raises a choice - whether to have one or many product backlogs. They usually start with one product backlog, either because they start with one pilot team, or because their product starts small from one team. Later, some organizations choose to have
This is one article in a series that tries to see system dynamics behind various choices in organizing work, people and time. Among many choices in organizing people, feature team vs. component team is an important one. The below CLD (Causal Loop Diagram) illustrates the system dynamic around it. The
Feature team gains popularity, but the difference between feature team and cross-functional team is still confusing to many people. Surprisingly, I failed to find good reference to clarify it, thus I decide to write one. 1. Does Scrum require feature team? If you read Scrum Guide, the below defines the
Creating stable teams and having teams work from one priority are two critical ideas in large-scale product development. This means when we discover some work, we put it into the overall backlog with appropriate priority; then, all teams share same priority, and any team may do the work. However, two
Real development team is already rare, let alone real management team. When talking about real team, I mean that the group has common goal and takes shared responsibility. Usually, management team is not a real team, but a working group. This is indicated by every member having clear individual responsibility.
After almost 10 years, I got chance again to work on a LeSS Huge adoption. Facing different challenges and reflecting on my experience 10 years ago, I am proposing an experiment here to decouple line organization from requirement area. NSN experience In 2007, I experienced an organizational transformation in NSN