February 2017 Archives

Product learning in Sprint review

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 "bad" case completely miss the point of sprint review.
  • Sprint review is about acceptance. The deep mindset involved is still contract and blame, rather than collaboration and learning.

In my view, the proper focus of Sprint review is product learning.

Levels of product learning

We learn about product from what and why. For what, there are various levels. We learn about story details on acceptance criteria; we learn about release progress on release turndown; we learn about meaningful product slices on story map. For why, we learn about product goal on impact map. Let me explain.

  • what/story, on acceptance criteria

We learn if the team has delivered the right stories. The main learning here is whether we had the shared understanding for those stories. If PO and team collaborate well during the sprint, chances are, PO has already checked this with team. Then, it becomes mainly checking with stakeholders to see if they have the same shared understanding. The results lead to the acceptance or decline, and possibly some improvement ideas on story level, which may become new or updated stories.

  • what/release, on release burndown

We learn if the release is on the right track. This is more about project view than product review. Traditional release burndown helps us understand if the release deviates from the plan, and then we adapt by varying scope, schedule or cost. In an environment where right stories are more known, it makes sense that the learning about delivery progress becomes the focus. Otherwise, we shall go deep into further product learning.

  • what/product, on story map

The learning on story level may be limited, particularly when we split stories for delivery purpose but break the natural size of uses. During initial backlog creation and backlog refinement, you may have done some story mapping and mapped separate stories into user scenarios. Sprint review is the time to revisit your story map. The granularity of discussion is around user scenarios. This reflects better about the progress, as those are more meaningful things for users, rather than separate stories. This supports better in discussing about what's still missing and what's next. This connects better with users as they are more engaging with meaning product slices, which ofter leads to more insights and product ideas.

  • why/product, on impact map

The next level of learning is how much progress we made in achieving why. During initial backlog creation and backlog refinement, you may have done some impact mapping and mapped stories to the goal and measures. Sprint review is the time to revisit your impact map and assumptions. We collect data for the released stories in the past sprints. We evaluate the real impact and come up with next stories to learn or build.

Ways of product learning

Product learning happens with the right people. Besides PO and team, stakeholders such as users and marketing are invited.

I learned the below 4 quadrants of product learning based on what users say vs. do and qualitative vs. quantitative from a former Alibaba product manager Su Jie. 

Blog - product learning in sprint review.png

He puts one example method in each quadrant.

  • Interview, qualitative learning, based on what users say
  • Survey, quantitative learning, based on what users say
  • Usability testing, qualitative learning, based on what users do
  • Data analysis, quantitative learning, based on what users do

Inspired by this, we could organize product learning in sprint review with various ways.

  • demo stories and user scenarios
  • interview with prepared questions
  • survey with prepared questions
  • observe uses of stories and scenarios by users
  • data analysis to understand impact
  • ...

Conclusion

The number of emergent requirements from Sprint review is a reflection of the amount of product learning in Sprint review. My colleague Terry came up with Agility Index that beautifully illustrates this point.

Turn your Sprint review into a product learning session and let your valuable requirements emerge.

User role modeling

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 Larry Constantine's work and his book "Software for Use", chances are it is from there. Do let me know if you happen to know.

Anyway, from my recent experience in helping team charter a new project, we encountered an example that illustrated this nicely.

It is a data application for internal use. Some common uses are as below.

  • Sales looks at product information and price information while creating quotation for customers.
  • Sales updates price information.
  • Marketing looks at product information and price information while building marketing campaign.
  • Marketing uploads product photo.
  • Product engineer adds new product information.
  • Product engineer restricts the access to certain product information.
  • Pricing group uploads price information.
  • Pricing group validates price information.
  • ...

It is tempting to define the following user roles.

  • Sales
  • Marketing
  • Product engineer
  • Pricing group
  • ...

Those roles come directly from work, thus, easy to access. However, those do not describe the relationship to the particular system - the data application. Why does it matter? Same roles have different intents onto the system, while different roles have similar intents onto the system. This makes it difficult to understand the system from those user roles. It makes it a lot easier to understand the system when you define user roles in terms of their relationships to the system.

For this data application, in terms of relationship, we define initial user roles as Producer and Consumer.

Considering two major data types in this application - product data and price data, we may refine the initial roles further like this:

Producer

  • of product data
  • of price data

Consumer

  • of product data
  • of price data

Product data contains text data and photo.

Considering different ways of producing and consuming data, we may refine the initial roles further like this:

Producer

  • creator
  • updater
  • controller

Consumer

  • viewer
  • validator

When we consolidate the user roles with those mixed, we end up with the following list.

Producer

  • Product text data producer (by product engineering)
  • Product photo producer (by marketing)
  • Pricing creator (by pricing group)
  • Pricing updater (by sales)
  • Pricing controller (by pricing group)

Consumer

  • Viewer (of both product and price data, by marketing and sales)
  • Product validator (by product engineer)
  • Pricing validator (by pricing group)

Mike Cohn in his book defines user role as "a collection of defining attributes that characterize a population of users and their intended interactions with the system." To me, this is the verbose version of "relationship to the system".

Paradox in coaching self-organizing team

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 one of two groups, everything was the same for the two groups except for the fact that researchers made one additional statement to the teacher in one group, "remember, it is your responsibility as a teacher to make sure your students perform up to high standards". The researchers then tape-recorded the teaching session and did the analysis. The result was astonishing. The teachers to whom researchers had mentioned the additional statement spent 2x as much time talking during the teaching session as the other teachers. They also made 3x as many directives and 3x as many controlling statements such as "should" or "must".

In order to achieve good results in the students, many people in real life such as school administrators or parents pressure teachers to produce. The paradox is the more they do that, the more controlling the teachers become, which undermines intrinsic motivation and performance in the students. The harder the teachers are pushed to get results, the less likely it is that the important results will be forthcoming.

One essential element in coaching self-organizing team is to support team's autonomy. This experiment provides much food for thought on it.

1. Dedicated coach role

When introducing ScrumMaster role, one question arises - how does it differ from traditional team leader role? For ScrumMaster, a well-working team is her product. In the regard, traditional team leader shares the same responsibility. One could say that traditional team leader does more command and control, while ScrumMaster does more facilitation and coaching. What about team leader with facilitative and coaching style? Does it differ any more from ScrumMaster in that case?

Well, team leader is still responsible for the team performance, instead of team itself. This reflects the organizational hierarchy. Does it matter? Even though I have seen autonomy-supportive team leaders, as well as controlling ScrumMasters, taking the delivery responsibility away from coach role still makes a difference.

This reminds me of Michael James's keynote "Human Beings and Scrum" in Shanghai Scrum Gathering 2013. He stated, "Scrum is the only approach that dedicates a role to create environments for learning, innovative teams - without giving contradictory responsibilities." Delivery is one contradictory responsibility, as the associated pressure creates obstacle for promoting autonomy.

This can be confirmed by my own experience as development area manager in NSN time. Even though I had a deep belief on self-organization and autonomy, I unconsciously (only realized in retrospect) became more controlling when facing great pressure to release the product.

Therefore, there is a reason to believe that having dedicated coach role such as ScrumMaster helps coaching self-organizing team.

2. Coach's performance

As coach does not have the direct responsibility for delivery, how do we know if they are doing a good job? We could see it from the improvement of team performance. Furthermore, when considering self-organizing team, one essential aspect to see is whether team becomes more autonomous.

Coaches face the same paradox as those teachers in the experiment. When they feel more pressured in doing a good job, it is less likely that they will do. I draw the following CLD to illustrate.

paradox in coaching.pngThe B-loop is the reason why they become controlling. The R-loop illustrates the long-term effect. When they become more controlling, intrinsic motivation is undermined, then team performance is degraded in the long run. Notice that the R-loop also works from the other direction - when they feel less pressured in doing a good job, it is more likely that they will do.

I remember that a few years ago, I had a conversation with a friend about this. She commented that it would be very hard for junior ScrumMasters not to feel pressured in doing a good job. This is natural as they need to demonstrate their ability for building confidence and trust. This is the same for ScrumMaster, internal coach, as well as external coach. ScrumMaster and internal coach get pressure from management, while external coach gets pressure from clients. How can they feel less pressured, thus more likely to keep autonomy supportive? Here are a couple of ideas.

Management or client believes in coach's intrinsic motivation of doing a good job, thus, gives space and time to coach. Performance evaluation works more like performance feedback session focusing on improvement rather than evaluation.
Coach makes their own effort not to hook onto the result. The proper state of mind is that they care, but not attached to the result. They care for the sake of caring. When they feel less attached, they feel less pressured, regardless of the expectation from outside. To me, this state of mind is similar to the one in those parents who are effective in helping child develop true self.

3. Parent's state of mind

Parents play an important role in helping child develop true self. They can be autonomy supportive or controlling, which nurtures or undermines intrinsic motivation accordingly. Parents face the same paradox. When they feel pressured to be "good" parents, they become controlling, which undermines child's intrinsic motivation. Eventually child would fail to develop true self.

As no "management" or "client" gives parents pressure to produce result, where do parents get pressure? They are certainly influenced by the society, such as other parents around them, teachers at school, etc. It is hard to change the social environment, same as it is often hard to change management or client's expectation towards coach. As parent or as coach, we both need to learn how to keep own autonomy in that environment.

I have a daughter. I surely care about her. However, she has her own true self to develop, and my self worth is not defined by her either. I view our relationship as enriching each other's life. With that view, I feel less pressured in producing certain result, thus, tend to be more autonomy supportive, which I hope will help her develop true self. I hold the similar state of mind when coaching self-organizing teams for clients.

Conclusion

Promoting autonomy is essential in coaching self-organizing team, while one obstacle is the pressure of producing result. The book "Why we do what we do" gives much more insights, and I would like to recommend it to any parents or teachers who have the interest in helping children develop their true self, as well as any ScrumMasters or coaches who have the interest in helping self-organizing teams develop their autonomy.

About this Archive

This page is an archive of entries from February 2017 listed from newest to oldest.

January 2017 is the previous archive.

March 2017 is the next archive.

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