How does an Agile coach manage changing requirements in the middle of product development?
As part of our interview questions series, we identified a number of questions asked of Agile coaches during interviews and client engagements, and this one is somewhat annoying.
Managing changing requirements in the middle of product development is not an Agile coach’s role.
It has nothing to do with them whatsoever.
That said, let me answer the question to the best of my ability and hopefully that helps you should you find yourself being asked this question in an interview.
First, let’s define what we mean by managing changing requirements in the middle of product development.
As an agile coach, we don’t get into the detail and assign work to people, nor do we prioritise what needs doing and instruct the team to get on with that. That’s what a project manager does.
What a great Agile coach would do is call attention to the fact that a lot of requirements are changing, and doing so frequently, and encourage the team to have the conversation about what is happening in the environment and why it is happening.
You would want to facilitate a review or retrospective that allows the team to talk about what the problems are, why stakeholders and customers are requesting so many changes, and how best to deal with the problem.
You would want to invest extra time with the product owner to understand why there are so many changes, how to get customers and product stakeholders to commit to a prioritised backlog and shield the team from shifting requirements as best you can.
One of the Agile values is to welcome changing requirements, even late in development, but you also need to understand that it can’t be a never-ending series of changing requirements that prevent the team from delivering anything of value.
A great Agile coach will look to work directly with customers and product stakeholders to help them understand the cost involved with constantly changing requirements and offer them insights into best practice for process and value stream identification.
Actively work with them to create better backlog items and understand which elements are the most valuable, the most compelling, and the highest priority so that the scrum team can focus on delivery whilst the customer and product owner focus on identifying the most valuable work or the most compelling problem that needs to be solved.
In terms of the developers, an agile coach would not be telling them what to do nor would they be telling them what they are doing wrong. They would focus on raising visibility of a potential problem and facilitate conversations that help the team make important decisions.
Decisions about what needs to be addressed, why it needs to be addressed, and help them identify how best to solve the problem. The developers are bright, creative and committed people and given the right facilitation, they are more than capable of coming up with great answers.
They are more than capable of identifying threats and working with the product owner, customer and products stakeholders to identify what is most important, why it is the most important item, and how to address the most critical items first.
Remember, Agile is built on the idea of pushing decision-making down to the people who are the experts in that field and are the most competent at evaluating what needs doing and how to go about doing that. Make sure you are pushing decision-making to the experts.
As an agile coach, you would be helping the team identify what is within their realm of control and what lives outside of their sphere of influence and capability.
The items that lie outside of their influence and capability will require people outside of the scrum team to address those impediments and so great, you can work with the scrum master and product stakeholders to facilitate conversations with people who can help resolve these issues and set about overcoming the impediments to progress.
You might need to take that up to executive level for resolution so work with powerful product stakeholders and sponsors to make a compelling case for the executive or leadership team to solve the problem.
In closing, I would remind you that your job is not to tell people what to do or how to do it. It is to bring the relevant people together to identify the problems and design/develop processes and systems that prevent those problems from repeating in the environment.
You are also there to help identify what needs to be escalated outside of the scrum team and into the organization for resolution. It isn’t your job to ensure that it is resolved but the team would be super appreciative if you did choose to get involved and help create a compelling story or argument for the resolution of the problem or impediment.
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster