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
How often do you feel the discomfort? If it is everyday, you burn out; if it is seldom, you probably do not grow much. Sitting on the plane to visit a client in US, I felt discomfort, because of different culture, different language, and more. I expected this to come
In the recent email exchanges, one topic came up as whether introducing more coordination meetings and roles actually solves dependency problem or just "shifts the burden". Shifting the burden is one common system archetype, which consists of two balancing loops and one reinforcing loop. For the topic of
I visited a client recently on consulting LeSS. They assured me that they had feature teams in place, "they are stable as line organization unit, and the size varies from 10 to 15 people." The large size smelled. I learned further... It turned out to be like this.
In the context of multiple teams working on one product, I try to figure out where priority is set. I first ask, "do we have one priority at product level and shared by all teams, or do we have priority at team level?" The answer is often, "
In scaling environment, it is common that PSPI is not yet achievable in every sprint. Even though the ultimate goal would be the team producing PSPI at the end of every short (say, 2-week) sprint, we begin with imperfect Done, i.e. there is undone work between current Done and
The essence in PO role is to manage ROI - Return on Investment. While you are doing projects for clients, there is contract in between and ROI involves both sides, which makes who taking PO role more complicated than it is in product organization. We are going to look at
During the recent Advanced ScrumMaster course, two guidelines for performance metrics emerged. Continuous Improvement over Performance Evaluation "Measuring and Managing Performance in Organizations" by Robert D. Austin is a great source for the topic of metrics. He made the distinction in terms of the purpose of using the
You have more work in one area than what the people in that area can do. You also have available people in the organization, but their skill does not match the work. Will this happen? Believe me, it will always happen at some point, either at team level or at
What's appropriate to put into Product backlog? In order to answer this question, we first look at different views on Scrum. Two views of Scrum One is viewing Scrum as planning framework, then, PBI (Product Backlog Item) is the unit for work planning. The other is viewing Scrum
How to split work (from big to small) and how to split people (into multiple teams) are two essential and very related topics in the context of scaling Agile. In these two dimensions (work and people), there are two common splitting strategies, through component or through feature. This leads to
Contract game is the traditional way that Business and R&D work together. At the beginning of the project, Business asks R&D to commit a big batch of work and holds R&D accountable for execution. The mindset behind is "plan then execute". Clearly
Specialization is about being good at something, while responsibility is about having a duty to deal with something. While they are related, it may not be good idea to couple them together. Component specialization and Feature responsibility Conway's law states, "organizations which design systems ... are constrained to
I'd like to revisit the rationale behind moving fixed scope to fixed time in Agile development. By understanding what is essential, we may get back to the thinking of fixed scope. Fixed scope in traditional development In traditional development, we often start by fixing the scope (of the
In my recent CSPO course, I got a question about when we should focus on the whole team (team, PO and SM), and when we should highlight different roles. Some people are somewhat confused because on one hand we define different roles and responsibilities, on the other hand we talk
I realize that LeSS is a natural way to scale. And let me illustrate. LeSS is still Scrum LeSS provides two different large-scale frameworks: LeSS for 2-8 teams and LeSS huge for 8+ teams. We focus on LeSS here. LeSS is trying to reach the same purpose as one-team Scrum