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.

need and ability to change.jpg


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

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai