We don't have emergent requirements

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