June 2018 Archives

Zoom out and see the big picture of Scrum roles

Zooming out and seeing the big picture is a form of systems thinking, and we see how it helps to understand Scrum roles.

Distributed project management

"Distributed project management" is a very powerful exercise regarding Scrum roles. We start to write down all project management tasks in post-it notes, then, group them based on which Scrum role does it. The below is the typical outcome.

Blog - zoom for Scrum roles - 1.jpg

It shows that project management is distributed among Scrum roles, without the role of project manager. The key points for each role in relation to project management are as following.

  • Product Owner: manage the release, in terms of items, sprints, and teams
  • Team: manage the sprint, in terms of items/tasks, days and team members
  • ScrumMaster: develop the team so that members would work together to deliver the product
  • Others (undefined in Scrum): form the project team, which is done very differently after shifting from project mode to product mode with Scrum

Often, people would draw another couple of conclusions:

  1. ScrumMaster does not have much work to do
  2. Product Owner is the project manager

This is a common manifestation of fast thinking. We started from project management tasks in this exercise. If you reasoned well with slow thinking, you would notice that this only touched the project management work.

The more solid conclusion would respectively be:

  1. ScrumMaster does not have much project management work
  2. Product Owner does some project management work

And we still need to see the bigger picture, beyond the project management work.

Systems thinking

One important aspect of systems thinking is seeing the big picture. The wonderful children book "Zoom" illustrates the approach of zooming out and seeing the ever bigger pictures, with one sample shown in the below.

Blog - zoom for Scrum roles - 2.jpg

Similarly, we zoom out and see the bigger picture of Scrum roles.

Blog - zoom for Scrum roles - 3.jpg

Now, we go beyond the project management work, and the bigger picture shows the below.

  • Product Owner: the main job for PO is product discovery, i.e. find the valuable work, see 80% product discovery and 20% project management
  • Team: the main job for team is product delivery, with self-management, i.e. manage its progress and process
  • ScrumMaster: focus on coaching for self-organization and continuous improvement, rather than short-term delivery.


Click "Zoom out":)

Blog - zoom for Scrum roles - 4.jpg 

My view of LeSS

As part of the LeSS trainer application, I was asked to give a graphical representation of LeSS. Here's the result showing my view of LeSS.

My view of LeSS.jpg

A series of choices

LeSS is a series of choices for the large-scale product development. We could make any choice if we were not clear about the optimizing goal. The choices made by LeSS are optimized for the agility and adaptiveness.

Among others, two choices stand out.

  1. One Product Owner and one Product Backlog, rather than many Product Owners and many Product Backlogs (team PO as anti-pattern; 1 vs. n product owners; 1 vs. n product backlogs)
  2. Feature team, rather than component team and feature group (component team vs. feature team; feature team vs. feature group)

To get the informed consent about adopting LeSS, i.e. making a series of choices, we should explore and see the system dynamics behind those choices. This is why systems thinking is critical in understanding LeSS.

Systems thinking

Systems thinking sounds great, thus, it could be claimed to be relevant anywhere. LeSS applies it concretely to evaluate the choices you make. What is the system optimizing goal? What are your choices? What are causes behind it? What are consequences from it? Is it consistent to your system optimizing goal?

I am often asked to compare LeSS with SAFe and others. I have no answer, but would like to offer doing an exercise of system modeling on the different choices they make. We evaluate those by applying systems thinking.

When team gets big, we split it into two. How? most typically by dividing into components or sub-components. Why do we split this way? What are the consequences? What are the alternatives? Often, we did not think them through. That is the typical manifestation of fast thinking. However, those choices are so important that they deserve slow thinking. System modeling helps us do slow thinking, and critical thinking.

Learning organization

If you practice systems thinking on your choices, you are free to do experiments that may not be consistent with LeSS. Eventually, you "own" what you do, rather than "rent" ideas from others. Less copying, more learning.

Systems thinking is the cornerstone (i.e. the fifth discipline) for a learning organization. LeSS opens up the stairway to a learning organization in the field of product development. By experimenting and practicing the five disciplines, we move toward the learning organization, while LeSS is a starting point in the journey.

This is my view of LeSS.

P.S. I had to ask my daughter for help in doing this graphical representation. I learned a small detail afterwards. There are two paths to the house representing the learning organization. One is through the back door, which is the shorter route; the other is through the front door, which is the longer route. They happen to be a good representation of fast thinking and slow thinking.

[Team Leader = TL; Product Owner = PO; ScrumMaster = SM]

The real Scrum requires significant organizational redesign. I have seen two common settings to pilot Scrum: 1) project group and 2) component team, as those are existing structures thus convenient to just use them. However, without organizational redesign, you could not adopt the real Scrum.

In this article, we focus on the setting of component team, and discuss two alternatives before we are ready for organizational redesign to adopt the real Scrum.

Here is the starting point. 

Blog - TL vs SM and PO for component team 1.jpg

Let me clarify a few terms I use here:

  • Features are requirements on the product, and they are customer centric and associated with business value
  • Component requirements are requirements on the component, and they are actually tasks from the perspective of the product.
  • Component tasks are internal tasks in the component.

Traditionally, TL is responsible for the component team, and held accountable for the delivery of the component work.

The fake Scrum with team PO

This is what usually happens while adopting Scrum for component team.

Blog - TL vs SM and PO for component team 2.jpg

Of course, we introduce the role of SM and PO, right? As there used to be one TL, I have seen a couple of common arrangements.

  • TL becomes the PO, who is a team PO as well as a fake PO, as he is clearly not responsible maximizing value for the product; and find another person to be the SM
  • TL becomes the SM; find another person to be the team PO.

Usually, regardless of TL becoming PO or SM, the accountability is still kept in the TL.

With Scrum roles in place, 1) team PO creates a fake product backlog for the component, which becomes the single source of the work for the component team; 2) SM coaches team to self-organize in completing the component work. 

Those are good progress. However, it misses the most important point behind the real Scrum - maximize the value through inspection and adaptation on the product and features. Therefore, this is the fake Scrum with team PO.

The real "Scrum" with TL

An alternative I would recommend is to keep the TL role but transform the role to 1) do the fake Scrum on the component, 2) shift the focus to the product and features, and 3) advocate for the organizational redesign. 

Blog - TL vs SM and PO for component team 3.jpg

Let me elaborate:

  1. do the fake Scrum on the component
  • consolidate all component work and prioritize (i.e. what the fake PO does)
  • coach team to self-organize in delivering the component (i.e. what the SM does)
  1. shift the focus to the product and features
  • connect component work to the product and features
  • connect component team to the real PO
  • coach team to self-organize with other component teams in delivering the feature
  • coach the real PO to inspect & adapt on the product
  1. advocate for the organizational redesign
  • spread the knowledge and experience on organizational redesign to feature team
  • prepare with cross-learning and technical excellence

This approach better follows big ideas behind Scrum, even though Scrum roles are missing. Therefore, this is the real "Scrum" with TL.

Only after the organizational redesign to feature team, the team would work directly with the real PO, and it would take end-to-end responsibility for feature delivery. Eventually, TL would be replaced by SM - a coaching role not responsible for the delivery. That would be the real Scrum.

End note

In fact, TL working this way is well defined in the book "Leading Self-Directed Work Teams". It describes the TL role as a boundary manager. Please do not introduce team PO for component team, and TL will do.

About this Archive

This page is an archive of entries from June 2018 listed from newest to oldest.

April 2018 is the previous archive.

July 2018 is the next archive.

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