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

Singapore Airlines is one of the worlds most respected airlines. They keep winning airline awards. I happened to live in Singapore and therefore it is most easy for me to fly Singaporeair. And, I have to admit, it is one of the better airlines and I especially notice this when I fly other airlines.

A well respected company. Known for its good service. A national company many Singaporeans are proud of. Yet, last week, they made an unbelievable F*** U*. So bad, that I'm seriously considering of starting to fly other airlines. Even though it doesn't relate to their flights but... their website.

Last week, Singaporeair did a sudden deployment of a totally new site. Absolutely no incremental deployments, but what seems to be perhaps years of work, suddenly deployed all at ones. I have heard that the company doing this for Singaporeair is... Accenture! (couldn't find anything on the web). And it is an absolute disaster. At first, I just thought the UI was bad, but no... the whole site is bad... but that's not all. The last days I have not been able to buy tickets anymore, which I assume is the main purpose of the site. Every time I try to buy a ticket, I get "system error". Everything in this deployment smells like a waterfall project gone very bad. But let me dive a bit deeper.

First, this was an all-at-once deployment, whereas it seems it would have been "easy" to do it incrementally. But lets assume that it is done "all-at-once" because of difficult technology changes. Even then, the old-site of Singaporeair was gone! Why would they run that risk and not, instead, have the old and the new site running together at the same time. Even the ISP I used for years (pair.com), they never swapped out their webmail at once, but kept the new site as a beta next to the old site. With a site where, I guess, a large part of your purchases come from, why would a company like Singapore Air run the risk of loosing that income (which they have now)?

All-at-once deployment aside, I'm not a UI expert, but the new UI sucks enormously. Not only make the choice of colors and fonts it hard to read, also it takes me a longer to buy a ticket (the one time I succeeded) because there are en enormous amount of clicks. Also a lot of technology seems off or used wrongly, which is visible by e.g. 1Password not working anymore for payments. Not only did they change their site, but also their booking confirmation emails (WHY!?). They didn't bother to inform tripit.com about that so that all the frequent travelers using both these services are not able to combine them. UI-wise, these things ought to have been discovered with earlier review cycles (sprint reviews) as they seem so obvious. If they would have bothered to take one frequent user of the site and let them use it, it would have been obvious. Why am I so sure? Well, just google Singaporeair and new site and you'll find complains for example on BusinessTraveler such as "Awful is an understatement" or Australian Frequent Flyer Community such as "Gotta say that I hate the new website." I mean, that is obvious and should have been found way earlier in the development. Not sure how this site was developed, but it smells like a pure waterfall.

All that aside, if I could use it, I would be somewhat happy. But if I try booking a (try it!) from "Singapore" to "Salt Lake City" date of departure "August 5", date of return "August 12", I'll get:


I tried it again and again the whole week. I reported a bug even. But no luck, it seems to not be possible anymore to book a ticket with the new site. This is truly unbelievable, how could a respected company such as Singapore Air allow to deploy a website which is SO BUGGY that even the basic functionality which is the main revenue stream for the company... does not work!

This was reported in the local newspaper: Straights Times in their article "Bumpy start foe SIA's new website". Didn't read the whole article (don't want to subscribe to straights times) but the most amazing part of the preview is the responds from Singaporeair Spokesman Nicholas Ionides:

'As with any major IT project, we do expect teething problems but we expect to be able to iron out these issues in due course. We will closely monitor the website's performance, and make adjustments where necessary.'

So, deploying an all-at-once, unusable, buggy and slow website in 2011 is *still* expected? I do not know where Nicholas has been the last 10 years, but I wouldn't expect it and find it truly shameful.

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.

This post relates to a post written by a friend George Dinwiddie related to the Satir Change Model. In the post he refers to a tweet I made related to the Satir Change Model. I'd like to add some clarification and argue that it is not "just a model" :)

Over the last year, I've started to get a little annoyed with the Satir Change Curve. You can find this in nearly every Agile development book. An example of the curve can be found here. I've used the change curve myself in the past, so why my annoyance?

The diagram expresses an assumption that all change will improve the performance, which we all know, is untrue. If we all know this assumption is untrue, then why would it matter? It matters in the way the change curve is used.

Imagine I'm a consultant promoting reverse-typing-driven-development. It's a wonderful idea where we switch out editor to type from right to left and we start each line of code with the end. As a consultant, I collected all this evidence in brain research showing that right-to-left typing and reverse thinking enables more brain connections and thus making developers more creative, smarter and better. It will improve the performance! So, I go to a team and train them in RTDD. They start off, but it feels a bit uncomfortable in the beginning. I grab out the Satir Change Curve and tell them that that's normal. The earlier way of typing was their status-quo and this change is a foreign element, so their performance will decrease and you will be in chaos! The team accepts my wisdom on change, after all, Satir was a family therapist. Eventually they get used to it, they stop complaining and keep typing in reverse. I declare victory and use them as an example of a successful adoption of RTDD.

The above is exaggerated, but there are a couple of interesting lessons in it. First, the actual measure of performance was missing. This is common and probably a reality of the industry we work in. In product development, especially in software development, there are so much variables that nearly every measure of performance fails. The change in the example was made for productivity and especially productivity in software development is not measurable.

But, I think the most important lesson of the story is that the change model caused the team and the consultant to stop challenging and thinking about the idea. Especially the consultant, he assumed the RTDD working style will improve performance (independently from context) and with that assumption he closed his mind for learning further. This is a very common problem which happens to me also a lot--I know the solution, so no need to think about that anymore, I just need to figure out how to get through the resistance of the people. Very dangerous.

Is the Satir change curve useless? No, probably not, there is definitively some truth in it. This is where the discussion a couple weeks ago became very interesting. I grabbed my Virginia Satir book to look for the curve and... it wasn't there! Now, I'm not a Satir expert, but I couldn't find a direct reference on the Internet either. (If I'm wrong, please, anyone, correct me!). The main reference on the Satir Change Curve seems to come from Gerald Weinberg. So, the curve actually should be called the Weinberg Change Curve and should be separated from the Satir Change Model. Most of this post relates to the Weinberg Change Curve and not the Satir Change Model. Is the Weinberg Change Curve useless? No, neither, but it can be easily misused. (Note: I don't have all of Satir's work and if anyone discovers that this paragraph is nonsense, then please let me know! I'd love to learn more about how the curve and the model relate)

One last thing. George's post was called "It's just a model" and we need to keep that in mind. I agree and yet also disagree with that. I agree it is "just a model" and a simplification. However, models contain assumptions and when models promote wrong/dangerous assumptions, then the model itself becomes dangerous. If that is the case (I'm not saying it is related to the Weinberg Change Curve), then instead of saying "Oh, it's just a model," we ought to say "that model is wrong!"

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.