How to deal with stakeholders during the sprint?
Hi,
I still get a bit confused on how Scrum deals with the collaboration between the development team and the stakeholders.
Based on my comprehension, I assume that the Development Team can interact with the stakeholders as much as necessary, as soon as possible, whenever it is necessary.
Is that correct? The sprint review in this perspective is an opportunity to frequently inspect and adapt the Product (Backlog) and get feedback on the softwrae increment.
So Developpers in this mode can have a direct access to clients or end users during the development phase, and co-create with them the best possible product increment, considering them as "extended team members".
Still correct?
Thanks,
J.
Hi Jason,
I really like your view on collaboration between the development team and the stakeholders. When there is too much communication going on, the team should address it in the retrospective and some changes should be made.
We have a similar structure and I personally see some big benefits in the setup you described.
Nils
...considering them as "extended team members".
Why blur the team boundary in such a way? Regardless of how collaborative stakeholders should or prove to be, what risks might this present?
Hello,
Thanks for sharing feedback and insights!
Actually what happens in my context is that product is built in constant alignement with our client's expectations. Client is part of the team. In our business, this is a key concern in order to have the shortest feedback loop between a request and it's release. Having the client within the team allows us to continuously focus on the most vauable features and implementation strategies for these features. But I recognize this must be a very specific situation. We develop an SAAS solution and this is quite an ideal environment to share (cocreate) the product guidance with our clients.
J.
Having the client within the team allows us to continuously focus on the most vauable features and implementation strategies for these features.
Would there be any better way to develop high value products? I can hardly think of any. Constant validation of the benefit/value hypothysis are indeed developed correctly is the most accurate and adaptive one.
Customer collaboration>contraction negotiation:)