Two years ago, I wrote a blog article called "Revisit feature team". I felt not quite complete, thus, the thought went on, until I discovered what was missing recently. Collective ownership Let me recap the scenario here. There is one so-called feature team, in which small groups work
In part 1, we looked at the case of platform as product. Now, we are going to look at the case of product area as product. Those products all have customer views, but there is possibility to define a broad product, then the products become product areas in the broad
What is the product? This is a critical question in organization design. You define the product narrowly or broadly, and the scope of the product is a continuum. We are going to see the factors and dynamics behind different choices in two parts. In part 1, we shall look at
One important leverage in coaching Agile teams is to increase the focus on requirement, rather than task. This article describes the dynamic behind it. Traditional project tracks the progress at two levels. One level is the milestone, which is often associated with stages such as requirement analyzed, ready for integration,
It is natural that people specialize in various things, but when it is too much, it becomes over-specialization. Over-specialization wastes our potential. We shall understand why it happens and how the adoption of LeSS avoids it. Eroding goals "Eroding goals" as a system archetype consists of two balancing
Creating projects is still common in product organization, but it is really not optimized for product development. In this article, we give an analysis from one viewpoint. 1. The conflict between static skill and dynamic work If you prioritize the work from customer point of view, you will inevitably find
Project manager does not exist in Scrum context. Project management in Scrum is distributed mainly between PO and team, for release and sprint respectively. This clarifies one of the most common understandings about SM as project manager, but raises another misunderstanding, which regards PO as project manager. To clarify this,
I started to work with a new organization and its teams recently. During the first sprint retrospective, developers and testers in teams discussed about how to collaborate more effectively. The same discussion has happened in other organizations of the same company, isn't it too slow to go through
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