May 2011 Archives

Insights for PO during Agile transformation

Recently, my former NSN colleague, Huang Hongqiang, and me reflected on the lessons learnt from Product Owner perspective during our Agile transformation. We used to work together for one product area with 100+ people, 10+ teams for more than 3 years. He has been the Area Product Owner, who provides the leadership on product, while i was the Area manager, who focused more on enabling environment, supporting teams and developing people. We were accountable for the success of the product area, and together with other areas, for the success of the product and team.

The main learning is summarized with 4 stages. Each stage provides the different focus. They are not strictly sequential, but the focus does switch over time.

Stage 1, get visibility

When your Agile transformation gets started, it is very likely that every team seems busy, but nobody really knows the overall status particularly regarding the work value and priority. As Product Owner, your single most important focus shall be getting the visibility by creating the product backlog. Evaluate legacy product, are they really working? do they incur technical debts? What is the maintenance load? Consider value, be prepared to have surprises, e.g. some teams may have been doing low value work for years.

Stage 2, improve predictability

Chances are, there is still lack of trust between business and R&D. You want to build the trust by improving the predictability, i.e. delivering commitment and managing the expectation. Challenges include dealing with wishful commitment, not knowing velocity or unstable velocity to begin with. The visibility improves the predictability. Moreover, you want to delay making the commitment, negotiate for flexibility, get teams involved into continuous analysis.

Stage 3, deliver value with quality

Velocity depends on the team's capability, which only improves over time. As Product Owner, you should not expect higher velocity soon. Instead, focus on delivering less but valuable features. You want to achieve this by working closely with business side and customers, collaborating with team on why, and splitting features into small ones to identify what's the most valuable minimum. Under any circumstance, you should not sacrifice Definition of Done and quality.

Stage 4, increase productivity

Finally, you help team on increasing productivity. Understand "slower before faster" by planning only 80% of your team's capacity. Work together with team to invest on improving engineer practices and paying back technical debts. Agree with team on feature, including legacy, responsibility so that teams continuously improve the product. Discuss with team how to extend their area so that it matches business needs while sustaining velocity.

Hongqiang and me will give a presentation on this topic in the coming Shanghai Scrum gathering on June 24-25. If you want to learn more details, please join our session:-)

Accidental adversaries

I recently attended a sprint review. It went on like this. PO checked every acceptance criteria in details, and criticized as much as he could; while team defended and demanded for acceptance, as much as they could. I heard comments as below.


  • From team, "we will only work on what's in acceptance criteria, if you want this, you need to include it in the acceptance criteria. It's your problem if you don't."
  • From PO, "But this should be common sense. Ok, I shall write more details into acceptance criteria, otherwise, you guys will just argue for acceptance."


PO and team are supposed to embody agile value "customer collaboration over contract negotiation". However, it looked as if they were in win-lose situation. How come?


System archetype "Accidental adversaries" well captures the dynamic.


Accidental adversaries.jpgThere are 2 reinforcing loops and 2 balancing loops involved.


  1. It begins with the outer reinforcing loop. PO is responsible for the success of the product, and is capable of defining the right product. While team is responsible for the product delivery, and is capable of building the right product. They benefit a lot from collaboration. When PO invites team into the collaboration on defining the product, team understands why to build, then, what to build deeply. When team delivers the right product to customers, they are more motivated in contributing further on product specification. This in turn helps PO succeed in defining the right product.
  2. At some point, bad cases occurred. For example, product missed some functionality because team thought that it would not be necessary. Customers complained and escalated, and PO got blamed for missing the specification. PO tried to improve by writing detailed acceptance criteria for team, then, strictly checking the written criteria for acceptance. They thought that this practice gave them the control necessary to get the right product. This forms the balancing loop in the upper left.
  3. However, this practice generated the un-intended consequence. When PO declined team's delivery, team's capability was evaluated as poor, and team was hurt. Thus, to fix it, team asked acceptance criteria from PO, blindly followed the written criteria and demanded acceptance based on what's there. This forms the balancing loop in the lower right.
  4. When team succeeds in defending the acceptance, it becomes PO's failure in defining the right product. To deal with this, PO focuses more on the details in acceptance criteria and criticizes the sprint outcome more. This in turn caused team to become more defensive. This forms the reinforcing loop in the middle.


Even though from PO and team's own perspective, what they are doing both make perfect sense, PO and team become accidental adversaries over time. The focus shifts from customer collaboration to contract negotiation, and from improving to blaming.


What are strategies for leverage in this situation?


  • Understand each other's behavior, i.e. their balancing loops, and realize that what they are doing makes sense from their own point of view, and the obstruction to each other's success is unintended. The problem is not caused by people, but by system.
  • Break the middle reinforcing loop by stopping the evaluation for both PO and team based on acceptance criteria and acceptance, i.e. if it is declined, it is team's problem; and if it is accepted but customer is not satisfied, it is PO's problem. Stop the blaming first.
  • Instead, strengthen the outer reinforcing loop by aligning both to the common higher level goal - customer gets the right product. Promote solving the problem and, more importantly, improving together, over blaming each other. When team does not deliver the right product, PO asks team how he can help team understand better; when PO does not define the right product, team asks PO how they can contribute. PO and team are on the same Scrum team and collaborate to achieve the common goal.


I have been implementing, and suggesting others to implement, solid team in Scrum context. I consider this as essential because virtual team structure so often leads to unaligned purpose and goals, since the respective managers still try to enforce their (e.g. functional) goals on the members who now work in Scrum team. Only when team shares same purpose and goals, self-managing is likely to emerge.


Recently, while coaching an organization for Agile adoption, i saw the virtual team again. The team members belong to different reporting lines, but they are supposed to all dedicate on the Scrum team, and the team is supposed to stay in the long run too. Interestingly, they choose to do that on purpose.


Why do they choose so?


  1. From manager perspective, they have no team to command & control, since they don't have one team to control. They are removed from the single point of accountability for the team. This may help transform.
  2. From team perspective, they have no reliance on manager. This may help team learn self-managing and transform too.


This reminds me of one common scenario about self-managing team.


Self-managing is one key aspect in Scrum implementation. When we form Scrum team, we tell our team to be self-managing. However, things don't work as expected, for instance, team may overlook risks in their plan, team may not well manage dependencies with other teams, team may not give sufficient visibility to stakeholders, and etc. As manager, you point those out and ask them to correct. Team fixes those, but you see more problems. Then, you follow up more closely. To your frustration, it seems not improving the situation, and the trend is even getting worse. You start to lose the confidence about the direction of self-managing.


The system archetype "Shifting the burden" captures the dynamic pretty well.


Shifting the burden.jpg


  • The problem symptom is that team does not manage themselves well.
  • It consists of two balancing loops. The upper one is a quick fix - managers use command and control to put out fire; and the lower one is the fundamental solution - increase team's capability to manage themselves.
  • There's one reinforcing loop. When managers execute command and control, it develops the unintended consequence - team steps back, which does harm to the effort on developing capability to self-manage. Then, more failure ensues, which causes managers to execute even more command and control.


The general strategy to leverage this situation includes:


  1. Focus on the fundamental solution
  2. Stop using the quick fix, or use it only to buy time


Applying those into our specific situation, it means:


  1. Agree on the vision of self-managing, managers transform from command & control to coaching and leading, and teams increase their capability and learn how to self-manage
  2. Limit the urgent cases that call for command & control, i.e. use quick fix carefully only to buy time


This promotes the gradual change, as is described in our story.


Another leverage option for a "shifting the burden" situation is to "go cold turkey", i.e. stop using quick fix completely. This is essentially what the organization i worked with would like to achieve by keeping virtual team.


However, there are dangers with this approach too. The withdrawal symptoms may be unbearable. In this case, corresponding to the reasons why they choose to have long-lived virtual team structure,


  1. When there is no direct point of accountability towards one team (there's still one point of accountability at upper level), middle managers neither function in old way, nor transform to new way.
  2. Accordingly, team lacks the support, thus, doesn't survive.


I do not mean that this will fail. Context matters and time will tell. It's a different approach, and I am keen to see how it evolves.


About this Archive

This page is an archive of entries from May 2011 listed from newest to oldest.

April 2011 is the previous archive.

July 2011 is the next archive.

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