Lv Yi

I worked with an organization that adopted Scrum for months. Their traditional release milestone for "content frozen" still kept, and I found that they had assigned all features to teams in sprints on that milestone. I asked, "wouldn't it be change on requirements while you are doing the release?" They answered, "we don't have emergent requirements."

One important characteristic for good product backlog is being emergent. While different markets have different rate of changes, I doubt that some market is so static that there is no emergent requirement at all.

Scrum provides a framework to inspect and adapt. Even though that doing inspection and adaptation inside R&D already helps, lack of emergent requirements prevents us from reaping its full benefit. I'd like to explore this problem and possible leverages from two areas.

1. Disconnection between business and R&D

This disconnection is still one major source for the problem.

• Product Owner from R&D

Product Owner should be business oriented, while we see that R&D oriented Product Owners are still prevalent. Their connection with real customers and markets is weak, accordingly, they lacked the insights and abilities to come up with emergent requirements to increase customer value. The synergy by having business people and R&D people work together is missing.

Product Owner role responds to the need to bring business and R&D together, since that's essential to develop great products. If Product Owner has more R&D background than business background, it may not be a show stopper, but it certainly means that this Product Owner needs to spend significant efforts towards business and customer side.

• Contract game continues

In some organizations, they are able to get Product Owner from business side, e.g. the product managers. While they are made as Product Owner, the mindset of predictive planning and the practice of contract game continues. The most obvious sign is the very existence of milestone for "content frozen" and release commitment. Traditionally, we treat changes as evil, thus, do strict change control. Same mindset continues even though we have adopted Scrum, which provides the mechanism for us to inspect and adapt on sprint basis. Release commitment enforced from business to R&D is a sure sign of low trust and lack of collaboration. All of those hinder the business and R&D to work together and capture emergent requirements.

It is best to stop doing those milestones any more, though you may first work on the possibility of committing later and committing in parts at different time.

• Sprint review

Most of sprint review I see is focused too much on the acceptance by the Product Owner, rather than focusing on how to get valuable feedback from customers and stakeholders so that requirements emerge.

We shall first consider whom to invite to attend the sprint review, besides Scrum team (Product Owner, Scrum Master and team). General principle is to invite the people who would be able to give valuable feedback and help make effective inspection and adaptation. It is great if we can invite real customers into sprint review, if not, consider those who are working closely with customers thus have more insights about what to build. It is unlikely that those people are in R&D, unless we are developing products for R&D people. Think of product managers, marketing and sales people, technical support, etc.

Having the right people helps new requirements emerge, and so does the collaboration process. Having the demo from R&D perspective only makes customers and business people bored. Without good facilitation on the conversation, the valuable comments may just be overlooked.

2. R&D's ability to change

I see interesting dynamic between ability to change and the need for change. They are interdependent.

When you have good technical ability to change with low cost, you are more open to the need for change. That openness creates more need for change, in turn, you have more motivation to improve your technical ability. That's a virtuous cycle.

On the other hand, when you don't have good technical ability, you explicitly or implicitly discourage the need for change. Then, without strong need, you lack the motivation to improve your technical capability to change with low cost. That's a vicious cycle.

It's not rare to hear comments such as "but, our customers don't need release that often, why do we need the ability to have short releases?" Sounds similar to "but, we don't have emergent requirements, why do we need to inspect and adapt?"?

If you are able to find other motivations (e.g. quality, predictability) to improve your technical ability to change, after your ability improves, you will likely see more emergent requirements.

End note

Fred Brooks said, "The hardest part of software development is figuring out what to build." It's suspicious that we don't have emergent requirements. Try to look at the above areas, your emergent requirements may emerge:-)

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:-)

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.

There 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.

• 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.

Product Owner is responsible for the product success. Product Owner is the single interface about team's work. In a single-team environment, PO works with that team constantly. It's all very clear.

However, in a multiple-team environment, it gets more complicated. It gets problematic to have one PO work with all teams in the product, when the number of teams goes too big. It leads to multiple POs working with different teams. There is still one PO at product level, who creates PO team with multiple POs. One PO will normally work with more than one team, but not all teams. Since one (big) feature may be developed by multiple teams together, two modes of relating PO and team come up.

• PO on team: Fix the relation between PO and teams. For each PO, they constantly work with a few teams. Naturally, they manage the part of product backlog that relates to his teams' work.

• PO on feature: Not fix the relation between PO and teams, but change it depending on the feature that the teams are working on. In this case, PO is responsible for features in the product. Which teams work on those features, PO works with which teams.

I have been suggesting PO on team all along, and I don't feel right about PO on feature. This post tries to clarify why, not only for you, but also for my own.

Why PO on feature?

Let's first understand the benefits that PO on feature tries to get. There are mainly two.

1. PO can specialize on part of the product and some features. For any team to be able to work on any part of the product, though ideal, it may not be feasible to beginning with. The same applies to PO. PO on feature makes it possible for them to specialize on part of the product.
2. The overall feature can be managed by one PO, so that it reduces the coordination efforts among related teams.

Problems with PO on feature

The most obvious problem with PO on feature is, what if one team need to work on multiple features at the same time? If you would allow multiple POs to interface with same team, it would've brought back all traditional problems such as conflicting priority, partial allocation, etc.

But PO on feature does not have to be so. It can still be clear who is the PO for the team at any time. If team works on two features, the PO responsible for the more significant feature (in terms of value, size, etc.) will be the PO for that team in relevant sprints. Other POs need to work with that PO in order to get their stuff done in those sprints. Then, there will be PO switch, as team works on different features. Two POs may work together for transitional period, though only one of them is PO towards team at any time.

Is this variant ok? I do not think so. There are two deeper problems with PO on feature.

1. PO on feature creates strong focus on current feature, and does harm to the flow and long-term sustainability. If we'd like to get team high performance in the sprint, we shall make the feature ready before putting it into sprint. That requires progressively grooming the backlog and future features. If we'd like to get our release more predictable, we'd like to proactively address risks and uncertainties. That requires investing earlier by having spikes. If we'd like to sustain in delivering good quality product release, we shall lower the cost of change. That requires gradually paying off the technical debts from legacy. However, PO on feature tends to short-term project thinking.
2. PO on feature breaks the feedback loop, which is critical for learning and continuous improvement. It is less likely for PO on feature to learn from mistakes such as wishful commitment, sacrifice done, ineffective collaboration on requirements, etc., together with former teams.

In short, PO on feature often leads to imbalance between short-term and long-term thinking and focus, while for the role of Product Owner, it is not enough to be able to maximize ROI for one sprint or one feature, but do that sustainably for the life of product.

PO on both team and feature

What can we do to gain the same benefits into the mode of PO on team? Working in product areas is the key.

• Since features often spread into many teams, area should be big enough to fit most of features. Then, the overall feature is managed by one area to ease the coordination.
• Big enough area is still smaller than the whole product, thus, PO still possibly specializes in the area with relatively small step.

Regarding the number of teams one PO can work with, some say no more than 2, others say up to 10, my sweet spot is around 5. The size of 5 teams per PO is good for both having some specialization and reducing the feature coordination.

Project management is done differently in Scrum

Project management work still exists when adopting Scrum. Traditionally, project manager plays key role for project management work, and it is done in a centralized manner. While in Scrum, project management work is done in a distributed manner, split among Scrum roles - PO, team and Scrum Master. What if project manager role still remains in the same context, in the meantime of introducing Scrum roles? Conflict and confusion ensue. When project manager wants to do his/her job, it impedes Scrum roles from functioning. Surprisingly, it's not uncommon to see that project manager (probably in a different name) and Scrum roles co-exist in the same organizational context. That must be addressed, in order for a successful Scrum implementation.

"Distributed project management" exercise is an effective way to help understand Scrum roles and see the problems. To do this, you will gather all relevant people together. The exercise works roughly as below. First, people come up with the project management tasks, assuming that all of them will still be needed after adopting Scrum. Second, people need to learn carefully about Scrum roles, e.g. from Scrum books, articles or any Scrum training material. Then, we look at each task to see whose responsibility it is in Scrum. When different parts of the task go to different roles, we split the task into parts, so that each task is taken by only one role. In the end, we discover that project management is well distributed among Scrum roles, without the role of project manager. The problem by having both Scrum roles and project manager in the same context becomes obvious.

Introduce adaptor

Now that the problem becomes visible, the next question is, how shall we transform? Suppose that you are working in a big organization with multiple teams, it's likely that you are not able to transform the whole organization at once. The situation you face is that the part, probably the big part, of the organization runs in old mode based on program and project structure. Program manager interfaces with project manager. Project manager sets up the project team (often a working group with only project manager being accountable for the overall project results). If we introduce one Scrum team with PO, Scrum Master and Team, how does it interface with the rest of the organization?

From Wikipedia, Adaptor is defined as a person that adapts attributes of one system to those of an otherwise incompatible system. Applying it onto this situation, we can implement an adaptor towards the rest of the organization, without causing any incompatibility in interface.

Who can be the adaptor?

• Product Owner

• Scrum Master

One of Scrum Master's responsibilities is to ensure the supportive environment for Scrum implementation. If we see the purpose of adaptor as creating room for Scrum team within the large context to succeed, it fits Scrum Master's job well. I was the Scrum Master while implementing Scrum in the pilot project within my former company, and kind of played the adaptor to interface different parties in the rest of the organization. The advantage was for me to have the opportunity of influencing them and moving the change forward. Remember, Scrum Master is supposed to be a change agent. However, the rest of the organization often expected me to report status and make decision as other project managers. Anyway, that's what adaptor means. This creates a couple of major problems. For release management, since PO is not visible to the rest of the organization, while he/she is the person having the knowledge and authority to inspect and adapt, having the adaptor different than PO slows down information flow and decision making. It also creates the big misunderstanding about Scrum Master role close to project manager.

The variant is to transform the existing project manager to SM role. Believe it or not, among the three Scrum roles, Scrum Master gets the least part of project management responsibility. I like the comment given by a project manager who attended my CSM course, "only atypical project manager may transform into SM".

• One team member

How about having one team member as adaptor? Team is responsible for committing and delivering potentially shippable product increment every sprint. Being adaptor is certainly a distraction. Furthermore, the role division between PO and team gets confused. The information flow between PO and team gets awkward. One argument for this is that great team shall be able to define itself in the organizational context. I would say that this goes beyond what's expected for team in Scrum framework towards more self-designing team [1]. Regardless, for a newly formed team, the clarity in roles is very important, thus, at least the timing is bad.

• One person outside Scrum context

The former project manager acting as adaptor, without taking any Scrum role, is another option. However, for any capable project manager, he/she would either try to have the same influence as early, which creates conflict and dysfunction, or step away from this soon after he/she realizes that adaptor role does not add much real value. It could also be that other body being adaptor. This will not be a rewarding role anyway, unless people seek the title of "project manager". It ends with a waste of human resource. Program manager is a good choice. It is actually closer to no adaptor that i'm going to describe as following.

How about no adaptor?

No adaptor means to expose Scrum roles for the rest of the organization. Here are a few steps I suggest to do.

1. list all parties, with which project manager has interface
2. list tasks each party is concerned
3. bind Scrum role and the tasks to create new interface
4. discuss and agree with each party about new interface

The last step is most critical, since it creates both understanding and action. There will be change for the counterparts, in terms of the number of interfaces, the content, etc. If they are not familiar with Scrum, a brief introduction should be included into the discussion. Though it takes more time to define, agree and get started, this has a few advantages. It doesn't introduce overhead. It creates solid understanding for new roles and prepares better for the further change. It's closer to our ultimate goal of transforming the whole organization. Scrum Master should lead the efforts to define and agree on the interface change with all relevant parties, since it fits the change agent role well.

This is actually my preference. Try no adaptor, before considering to introduce adaptor.

Adaptor towards which part of the organization?

So far, we have explored about using (or not using) adaptor to make Scrum team compatible within traditional organization. In fact, another chance of using adaptor is to make traditional team structure compatible within Scrum organization. In our vision, big product development organization will be organized into requirement areas, each of which has Area Product Owner being responsible, meanwhile, Area Product Owner is the member of the whole product PO team [2]. Since organizational transformation does not happen overnight, chances are, some part of the organization runs in Scrum mode, while the other part remains in traditional mode. In this case, an adaptor in the name of Area Product Owner is useful technique to keep the whole organization operating in Scrum mode. In fact, the adaptor goes beyond the person and includes sprint and backlog interfaces. Later, we gradually refactor to our vision.

Reference:

1. Richard Hackman, Leading teams: setting the stage for great performance
2. Craig Larman, Bas Vodde, Scaling lean & agile development: thinking and organizational tools for large-scale Scrum

Definition of Done is the agreement between Product Owner and team. As ultimate goal, team is delivering potentially shippable product increment every sprint, thus, your Definition of Done shall be equal to what's required to make your product increment potentially shippable. However, your current Done may be only part of what's needed to get potentially shippable, constrained by your current technical capability. When we defined our Definition of Done several years ago, I found that we also added some criteria that are not really part of what's required for being potentially shippable. For example, we may make our product potentially shippable without automating the tests, though we added automated tests into our definition of Done. Why did we add them? Because we'd like to make sure that our development is sustainable. If we rely on manual tests, we shall soon find that regression efforts go up exponentially. We can not really afford, thus, we may not do regression in full all the time. Then, every now and then, we break existing functionality without knowing it. What's in Done and potentially shippable is actually no broken old functionality, while test automation is a practical mean towards that. I realized that there are two kinds of criteria in Definition of Done. One is customer/product and result oriented, which are all required to become potentially shippable; the other is process oriented, which defines the way of working. Over time, i also noticed that when team got mature, they tended to have less process oriented criteria in their definition of Done.

During a recent co-training with my colleague Emerson, I learnt from him that he always included those process-oriented criteria into working agreement. That is interesting, and it makes me wonder why we took different approaches and what differences they actually have. Here's my thoughts. Although it seems trivial since team will do according to both Done and working agreement anyway, there are profound differences. Scrum team is self-managing under certain boundaries. The most important ones are timebox in sprint, and Definition of Done. Organization and Product Owner executes the control through setting the boundary, while team self-manages within the boundary. Working agreement is completely up to team, thus, it's not part of the boundary set by the organization and Product Owner. In my environment, while we adopted Scrum, the concerns about self-managing still prevailed and the feeling of uncertainty from management was still strong. Thus, we kept more control by setting strict boundary through adding more process oriented criteria into Done. On the contrary, Emerson's environment seemed putting more trust on team, thus, they left those to the working agreement, which is created and owned completely by team. Either consciously or unconsciously, we chose the different approaches based on different assumptions and level of trust, and control.

Have you noticed the difference and what's the assumption behind your approach?