December 2020 Archives

Experiments are at the heart of LeSS

less-complete-picture.png

Frameworks as starting point

If you look at the LeSS complete picture, you see that the frameworks - defined by the rules - and the principles are at the heart of LeSS. However, this is not completely true.

In fact, the LeSS frameworks emerged out of the experiments, in response to the need of novice group in large-scale product development domain. In the first two LeSS books, hundreds of concrete experiments are shared. Those experiments are insightful but do not fit for novice group. We may start from the frameworks, then still move towards experiments. Therefore, experiments are really at the heart of LeSS.

Then, what is the essence of experiments? How do they differ from best practices and patterns?

Best practices and patterns

At a glance, experiments look similar to best practices. The below is the description for best practice in Wikipedia.

"A best practice is a method or technique that has been generally accepted as superior to any alternatives, because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things."

With best practices, we focus on adopting and spreading them as they are already proven. Best practices both cater to and nurture copying mindset.

However, using experiments in LeSS is to emphasize that "there are no such things as best practices in product development. there are only practices that are adequate within a certain context". This is meant to encourage a culture of leaning, questioning, engagement and continuous improvement.

Are rules best practices, if experiments are not? Rules and frameworks were created to help novice group get started and form the foundation to support empirical process control for the whole product and organization. Would it encourage following and copying mindset, as these are stated as rules? Probably. To mitigate it, in the CLP (Certified LeSS Practitioner) course, we explore the rules via systems modeling to understand various factors and dynamics behind them.

How about patterns - are experiments patterns? A pattern is a general, reusable solution to a commonly occurring problem within a given context. In a way, patterns are formalized best practices, and they differ in patterns emphasizing the context. With patterns we focus on solving problems within a given context. This helps shift the focus away from the copying. While focusing on problem solving in a context, we are more likely trying to understand how the solution is supposed to solve the problem, and how the context matters. In this sense, experiments and patterns are close, as they both present logic and depend on context. However, they differ in putting which one first - the solution or the reasoning?

Focus on reasoning in experiments

In my view, reasoning is at the heart of experiments. When we learn about experiments, we don't focus on copying the solution, we don't even focus on learning the solution itself, we focus on learning the reasoning about the solution - how this solution is created, what factors and dynamics are involved, etc., so as to reason about our own problem and context then create our own solution.

reasoning.jpg

This view made me think that the current format of experiments - try/avoid - does not promote enough the focus on reasoning. Let me use two different formats for one experiment to illustrate the difference.

  1. Try - one product backlog shared by multiple teams.
  2. Understand - the impact of number of product backlogs on adaptiveness

With the first format, the focus is immediately on the practice or the solution (share one product backlog) itself; while with the second format, the focus is on the problem/goal (adaptiveness) and the potential leverage (number of product backlogs), thus, the reasoning.

I have to admit that it is unappealing to focus on "understanding" for many people. Unfortunately many people often just want to copy something, thus, any attempt to reason about factors and dynamics with them is seen too slow. However, this is exactly what we need in the complex domain such as large-scale product development.

The experiments are evolving, and never-ending because of continuous improvement. The first two LeSS books documented only those experiments collected till that time. Although we can wait for a revision of those two books, considering the nature of experiments, we would benefit from having a more dynamic collection of experiments made by and for the community of LeSS practitioners.

In summary, here is the shift of focus from best practices to pattens further to experiments:

  • with best practices we focus more on copying the solution than understanding the logic
  • with patterns we focus on learning the solution as well as understanding the logic - its problem and context
  • with experiments we focus on learning the logic - factors and dynamics, then creating solution on our own

Shared vision on organization

Shared vision is one of the five disciplines practiced in learning organization. This is the second article on how this discipline relates to product development organization, and it is about organizational vision. You may want to read the first one about product vision as well.

Let's look at organizational vision again in one-team Scrum context and multi-team LeSS context respectively.

One-team Scrum

In this context, organizational vision is actually team vision.

Scrum is based on empirical process control, while empirical process is guided by goals. There are three instances of empirical processes in Scrum.

  1. Daily Scrum is the empirical process applied towards sprint goal
  2. Sprint review is the empirical process applied towards product goal
  3. Sprint retrospective is the empirical process applied towards process goal

While sprint goal and product goal are straightforward, what is process goal? The embedded "process goal" in Scrum is to get potentially shippable at the end of every sprint. This lies at the heart of Scrum. Initially team may not be able to achieve this, and they use sprint retrospective to reflect and improve towards it.

Thumbnail image for shared vision - 4.jpg

Another common source of process goals comes from some assessment frameworks, either created by other people or on our own. The assessment framework is usually associated with questionnaires or checklists. The above diagram is a checklist I created many years ago for my own usage to assess team and organization. Its scope is bigger than one team, but the idea is the same. This kind of framework or checklist implies that team aims to achieve the ideal state indicated by getting full score in all dimensions and questions. If all questions are written as statement and the scores are marked based on the extent that team or organization has realized, the overall statement is essentially a team vision. Team vision describes more than processes, while getting potentially shippable at the end of every sprint is one of those processes.

Similar to product vision, here we set time-bounded team goals based on team vision, and work towards them mainly through sprint retrospective.

Who owns team vision? Though it is clearly defined in Scrum that PO owns product vision, it is less clear about who owns team vision. ScrumMaster certainly plays an important role as change agent, because team vision is closely connected to change vision. On the other hand, as team is self-managing, how much should they own team vision themselves?

Thumbnail image for shared vision - 2.jpg

This relates again to the above diagram from the book "The Fifth Discipline Fieldbook", which shows the degree of shared-ness. Similar to PO sharing product vision, SM could tell/sell/test/consult/co-create team vision with the team. These various ways of engaging team will also achieve different degrees of shared-ness. Let's elaborate on this.

Suppose that we would like to create a team vision that describes what an ideal team would look like. It could happen in the following ways.

  • [Telling] SM creates a full version and simply tells the team that this is what great Scrum team would look like. SM may borrow it from others, create it based on her own experience and aspiration, or mix multiple sources.
  • [Selling] SM creates a full version and explains why to the team in trying to convince them that this is a great team vision.
  • [Testing] SM creates a full version, explains why, and asks feedback from the team about what excites them and what does not. Then, she refines the vision.
  • [Consulting] SM creates a draft version, and asks the team to contribute. However, SM still reserves the role of judge, and she chooses to accept or ignore what the team says.
  • [Co-creating] SM does not create any version at all, and asks the team to co-create. SM may prepare some inputs for the team to reference, if they want. In this case, team fully owns the decision making, and SM only acts as the facilitator.?

The co-creation is often done through a series of team visioning workshops, which leads to shared team vision. Please note that it is not a one-time effort, but an ongoing process. Every quarter or half-a-year, perhaps during normal sprint retrospectives, team shall revisit and evolve its shared vision.

Multi-team LeSS

In this context, organizational vision spans across multiple teams.

In LeSS, there is an additional event called overall retrospective, which is the empirical process applied towards organizational goal. Organizational goals support to achieve organizational vision.

What is organizational vision? There is a LeSS guide called "Organizational Perfection Vision". Even though "a perfection vision is different from a vision. The goal of a vision is to achieve it, whereas the goal of a perfection vision is to channel improvements", the general idea of organizational vision still holds true. The vision describes a future state of organization, e.g. "able to deliver or change direction at any time without additional cost", "special coordination roles are avoided and teams are responsible for coordination", etc.

In the book "The Fifth Discipline", it defines learning organizations as "organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to see the whole together". In fact, this describes a future state of organization, thus, learning organization itself is an organizational vision too.

In the book "Reinventing Organizations", it describes the advance of organizational models, and the emergence of teal organizations. Teal organization operates as a living organism or living system, with three major breakthroughs: self-management, wholeness, and evolutionary purpose. Teal organization is another organizational vision that we may aspire to.

Thumbnail image for shared vision - 3.jpg

In the above diagram from the LeSS guide "The LeSS Organization", we learn that PO provides product vision. Then, who provides organizational vision? Managers and SMs focus on organizational capability improvement, while organizational and team vision guides the improvement. Therefore, manager plays a similar role in organizational vision as SM in team vision. Managers together with SMs may provide organizational vision, by telling all the way to co-creating. Co-creation would lead to the highest degree of shared-ness. Nevertheless, the quality of organizational vision is also dependent on the quality of individual's personal vision. This is why shared vision better starts with personal vision, which is the focus of another discipline "personal mastery".

How do we co-create organizational vision? It could be similar to team visioning process, but with larger group. In those sessions, divergent and convergent steps are planned to facilitate large group. Alternatively, team visioning - what do we want to create as a team - may happen first, then, we organize the sharing sessions for teams to listen to one another, and let the shared vision emerge over time. You may find more from "shared vision" section in the book "The Fifth Discipline Fieldbook".

In product development organization, shared vision is applied to both product and organization. We have explored them in the previous article and this one respectively, and hope that it will help you practice the discipline of "shared vision" in product development organization.

About this Archive

This page is an archive of entries from December 2020 listed from newest to oldest.

November 2020 is the previous archive.

January 2021 is the next archive.

Find recent content on the main index or look in the archives to find all content.