Introducing Agile - how to best get the stakeholders opinion
Hi,
we are introducing a few methodologies into organizations that are not familiar with them yet. Specifically, trying either XP Planning Game or Scrum Spring and Release Planning, first with a couple of teams.
Would be happy to hear suggestions on how to best get the stakeholders open feedback on the new suggested planning, and how to test ourselves if we are indeed doing the right thing.
Our initial thinking is about a short survey, with max 10 questions, that people can opt to fill after a period of experimenting.
Any suggestions on good questions and success criteria to test ourselves would be much appreciated!
Will be happy to get idea, suggestion and feedback!
Thanks!
Are you planning on doing these activities within the Scrum framework? If so, the Scrum Guide (https://scrumguides.org/index.html) provides some insights into how the Scrum Team would work with stakeholders.
If not, what has led you to feel these techniques are needed and the problem that you are trying to solve? Where the stakeholders involved in the decision to undertake this effort? Those questions should help you understand what you expect to happen by introducing these.
I will point out that you mentioned only 1 item that is part of Scrum. Scrum does have an event called a Sprint. The Scrum Guide explains the event and all supporting events/activities that are associated to a Scrum Sprint. Given that you mentioned the other 2 items, I would suggest that you are considering implementing a time-boxed iterative development practice and not Scrum Sprints.
The Scrum event stakeholders are invited to and expected to attend is the Sprint Review, held at the end of each Sprint, which is a collaborative working session. The plan is your Product Backlog, which emerges based on new learnings and the latest information.
At the Sprint Review, this is a chance for the Scrum Team to collaborate with stakeholders to get their feedback on the latest product Increment created during the Sprint, to inspect progress towards the Product Goal, and to adapt and adjust the Product Backlog for future Sprints. The Scrum Team will talk about what was done and not done, and mention any challenges they might have encountered. The Product Owner may also share release progress and forecasts.
By actually showing Done, working product that might be or has been shipped, that is a great way to build up trust.
The Sprint Review isn't the only time the Scrum Team speaks with stakeholders, but it is the event they attend. I would suggest a Product Owner would also be having plenty of conversations with the stakeholders, and the Scrum Master might even be doing some teaching to help everyone understand Scrum.
As the Scrum Guide tells us:
The Scrum Master serves the organization in several ways, including:
Leading, training, and coaching the organization in its Scrum adoption;
Planning and advising Scrum implementations within the organization;
Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
Removing barriers between stakeholders and Scrum Teams.
Hi folks, thanks for the answers and feedback.
I should probably clarify more about the background.
The SW development organization into which we introduce Agile are not methodical, things tend "just to happen" and even tend to be chaotic.
Our goal is to introduce a single practice, not a full blown framework, and evaluate the response and perception of developers and surrounding stakeholders.
The Agile process\framework we chose for the experiment is XP Planning Game in which we will measure and track the Exploration and Commitment phases.
This link for example, looks very relevant to what we would need to measure and evaluate: https://www.mountaingoatsoftware.com/articles/introducing-an-agile-proc…
Things we care about:
- reaction of different stakeholders
- what did we actually improve compared to the previous state
- what did not improve or perhaps even did not work in the experiment
- did they feel a positive change and willing to pursue a bigger transition
Thanks again for your response!
Our goal is to introduce a single practice, not a full blown framework,
My advice is to start with a single team. Get the agile outcomes you are looking for with that one team first. That's the best way to limit your work in progress change-wise.
I don't think there's a silver bullet in the form of a "single practice". You'll be able to measure something from its introduction of course, but you'll be measuring something else, and not an agile outcome. Bear in mind that Scrum is not a pick-and-choose framework.
Scrum needs to be adopted in its entirety, if any of scrum event is dropped then Scrum is not followed and may not provide desired result.
For adopting XP , XP roots for onsite customer, there is good research paper -
https://core.ac.uk/download/pdf/41336233.pdf
https://zenodo.org/record/4662322#.Yic-quhBw2w