Agile Coach is a catalyst, change agent and servant leader who help train corporate teams on the agile methodology and oversee the development of agile teams to ensure effective outcomes for the organization. They provides professional coaching, facilitation, teaching and mentoring to help organizations realize their agenda and achieve full potential of the organization. There are broadly three levels for Agile coaching:

• Agile team facilitator: The starter level, working with existing teams
• Agile coach: The advanced level with a specific domain focus, working with teams that are currently forming
• Enterprise Agile coach: The expert level, working on leadership and strategic level with the organization 

Please read Agile Interview Questions and Answer for interview questions related to Agile Fundamentals. Scrum Interview Questions and Answer for interview questions related to Scrum Fundamentals.

Agile Coach Interview Questions and Answers

1. What factors would you consider while recommending the sprint length for a team?

Answer: Below are the few factors helps in deciding sprint length.

Risk Appetite and Market viability: When competition is cut throat business might not have an appetite to take a risk and would like to deliver products frequently. So the sprint length will be shorter duration.

Overall length of the release: Product with shorter release duration will have shorter sprint length so that shorter feedback loop can be help inspect and adapt.

Uncertainty: The level of uncertainty over the new and potentially risky technology while developing the work product is a critical factor for sprint length. Sprint length of shorter duration is recommended so that the team would get opportunities to get more frequent feedbacks from the stakeholders as well as will get more opportunities to inspect and adapt accordingly.

Uncertainty can impact sprint length as it can come in a variety of forms: 

• Requirements are not well defined; 
• technology is new and potentially risky; 
• an algorithm or interface may be difficult to implement. 

Disengaged Stakeholder: The risk of being disengaged from the stakeholders during the execution of the work product is a critical factor in deciding sprint length.

2. What are the benefits of recommending fixed sprint length?

Answer: Below are the benefits of fixed sprint length.

Regular Rhythm: It helps to establish a consistent pattern of delivery.

Easier Sprint Planning: The team members know how much work they are supposed to deliver in the forthcoming sprint.

Easier Velocity Tracking: It helps the team to objectively measure progress. It provides a consistent means of measuring team velocity.

Faster Corrections: Fixed-length sprints minimize that gap by bringing the product manager and engineers together at a fixed interval. The findings at each sprint guide the Scrum team to incorporate the required changes before the particular task is done, tested & documented. 

Customer Satisfaction: Fixed-length sprints improve the responsiveness to customer requests.

3. What are Burn-up and Burn-down charts?

Answer: Both the charts help to keep the track of the sprint progress. Burn-up charts indicates the amount of work completed in the sprint and the Burn-down chart indicates the amount of work remaining in the sprint.

In the Burn-Down chart, the vertical axis shows the remaining amount of work and the horizontal axis shows the amount of time passed from the beginning of the project.

In the Burn-Up chart the vertical axis represents the amount of work and is measured in units or story points, and the horizontal axis represents time, usually measured in days.

4. What are the typical Agile Team’s Struggle while transforming into a highly productive team?

Answer: The typical challenges while transforming into a highly productive team are

Lack of Common Objectives and Goals alignment: When teamdoesn’t have shared belief and lack of understanding of each team member’s role it impacts team’s velocity. Roles that are still aligned with traditional functional roles are often impacts the whole team.

Lack of adopting New Tools and Practices: New tools and practices are necessary for efficiency. Lack of Application lifecycle management (ALM) tools such as JIRA and Rally, continuous integration (CI) tools such as Jenkins and Bamboo, distributed software configuration management (CM) tools such as Git and GitHub, and lightweight test automation tools such as Selenium and JUnit impact team’s performance.

New practices such as test-driven development (TDD), behavior-driven development (BDD), and DevOps also critical for high performing teams. A lack of formal training and hands-on experience with these agile tools and practices will often result in a team that struggles to meet its commitments and to reach its full potential.

Incorporating Agile Testing and Automation: Teams often struggle with how to build and test software in concert, as they are used to following traditional testing practices that often start testing after code is frozen and automation is only done as an afterthought. But following these traditional practices results in delayed feedback to the developers about the quality of their code, as testing gets deferred to subsequent iterations. It can also lead to delays in deploying tested features into downstream test environments.

Decomposing Epics into User Stories and Considering Acceptance Criteria: Properly decomposing epics into user stories and estimating their size is critical for success of the team. Teams often lack the focus and ability to scrutinize requirements from a user-centric perspective, resulting in ambiguous user stories that are difficult to properly implement and test within the time the team planned for.

Dealing with Cultural Transformation: While teams are doing their best to transform to agile, there are organizational and cultural aspects that impact their performance, such as resolving dependencies with other teams in the same program or portfolio, new release management processes that must be followed, coordination with multiple stakeholders on priorities and feedback, and learning new communication and interaction channels. Not addressing these cultural challenges often results in pseudo-agile behavior where agile principles are followed in name only.

Being Operationally Disciplined: Being operationally disciplined means adhering to a set of well-defined, proven, and well-thought-out processes and consistently performing them correctly. In agile, this means conducting agile ceremonies diligently, such as having periodic meetings and discussions with stakeholders for planning, user acceptance and sprint reviews, sprint retrospectives, team brainstorming sessions, and daily Scrum meetings. These collaborative activities demand a lot of commitment and discipline from the team members in order for them to be productive. 

Understanding the Business Purpose: It is very important for every member of the team to understand the business purpose of what they are working on and what impact new features will have on the users of their software. Often, the tendency of a new agile team is to focus only on their individual software component or feature, the technical details in developing it, or the immediate delivery need, while ignoring the bigger picture of the project. This results in teams that veer off track, away from customer value and needs. 

Having an Encouraging Atmosphere: Agile is not only about following certain practices and ceremonies or using automated tools and technologies to speed software releases. It also demands that teams have no fear of failure, can deal with lots of unknowns, and can manage and embrace conflicts. It is also about the ability to try out innovative ideas, experiment frequently, and fail fast if failure is going to happen. Lack of having a safe environment will lead to demotivated individuals who are afraid to try new practices and processes and will not produce innovative solutions.

5. Describe the typical journey of a team towards their goal of being a high performing team?

Answer: It’s the team’s responsibility to embrace agile principles and sustain the efficiency in their activities and effectiveness in their outcome.

Aligning with Leadership Regularly: Agile teams should have regular interactions with the program sponsors or leadership and have a common understanding of project goals. Teams should understand their role in addressing the business objectives, and the entire team should speak with a “one-voice” approach when communicating with stakeholders.

Sharing Knowledge and Experiences: Sharing new knowledge and experiences across all teams is critical to getting your entire organization up to speed as fast as possible. By actively participating in team product demonstrations, showcases, and established agile communities of practice, organizational knowledge grows much quicker than if each team attempts to learn everything on its own. Sharing experiences frequently also builds relationships among teams and increases the likelihood of effective collaboration.

Adopting Test-Driven Development and Behavior-Driven Development: TDD is a development practice in which low-level unit tests are used to drive successful software implementation. BDD and ATDD (acceptance test-driven development) are similar practices for specifying expected software behavior for stories and use cases using tests. All allow the business, testers, and developers to collaborate on understanding the requirements and properly building and testing the right functionality. Embedding these practices into day-to-day activities of the team not only fortifies the quality of deliverables, but helps the team reduce rework and communicate what needs to be done more clearly.

Defining User Stories and Requirements: The effective decomposition of epics into appropriate user stories is one of the most important activities for agile development. This not only helps provide clarity to the agile team on the requirements, but also aids them in estimating their work properly.

A proven practice for effectively breaking down epics is to use a Three Amigos approach, where representatives from the business, development, and testing have collective conversations on deriving the behavioral aspects and acceptance criteria for every user story. Your entire team should also participate in backlog grooming sessions to share their ideas and define the guidelines for a definition of “done” to determine when a user story is ready to be picked up for development. 

Participating in Organizational Change Management: When an organization is undergoing transformational change, it is not only the responsibility of the management, but also the individual teams, to contribute positively to the process. Teams should consistently demonstrate their commitment toward achieving business goals through continuous collaboration with business stakeholders while helping to instill a high-performing agile culture in their team and overall organization. A key aspect of this commitment is delivery of promised functionality during each sprint.

Practicing Good Collaboration and Communication: Achieving high performance within the team and software delivery process without strong communication and collaboration will be very difficult. Team must exhibit the behavioral aspects of discipline, close collaboration, and commitment with stakeholders during iteration planning, and be open to feedback during review and retrospective meetings. Availability of high-end infrastructure, such as video conferencing, messaging systems, and other collaboration tools, at the team’s workplace will help distributed teams effectively collaborate and communicate.

Having Systems Thinking and Mindfulness: It’s very important that each team has a complete picture of the project and program within which they are working. To achieve this, teams should develop a deep understanding of business domain, business rules, enterprise architecture, and applications of client organization and align this knowledge with the software modules they are working on. As much as possible, teams should not focus on optimizing their specific aspects of a larger program, but help the entire program optimize its efficiency.

Generating a Positive and Energizing Work Culture within the Team: If team members are not open with each other and with their stakeholders, there will be very little trust. Team members that trust others, are open-minded to feedback and suggestions, are cheerful, and encourage others will make it easier for all to express and articulate new ideas. These attributes can be spread among team members through activities such as discussions without agendas (e.g., lean coffee), celebrating small achievements, and constant inspiration from leadership.

6. How should you recommend team to handle scope changes during sprint? Explain few strategies which worked for you?

Answer: Few questions which helps me to decide the recommendation are 

1. Does it serve the Sprint Goal?
2. What is the business value of this change?
3. Will the customer use the result of the scope change on release?
4. What is the urgency?
5. Exceptions are allowed
6. If I add new scope to the sprint backlog, what I remove?

Recommended strategies 

Absorb: A bug for which fix is not complex reported for a recently released feature which is critical for the customer.

Break Up and Carry Over:The story which is delivered misses an important functionality, which is critical to release. In this scenario complete the original user story as agreed on the planning. Separate all the additional requirements off to a new user story and plan it for the upcoming sprints.

Replace: A high priority bug for which fix is complex reported. It will invalidate the product. In this scenario add the new user story or bug to the sprint. Then decide what other story or stories of the same size can be sacrificed and remove them from the sprint. 

Plan a Buffer: Every release there are bugs being reported and planned stories are being replaced to fix the bugs. In this scenario during sprint plannings reserve some buffer in a sprint backlog. 

Improve Prioritization: Some stakeholder has asked to implement a story urgently int he middle of the sprint.In this scenario help the product owner  to say “No”. 

Improve Quality: Every release there are critical bugs being reported which is impacting increment. In this scenario analyze the causes for low quality, it may be due to crunch timeline, unclear product backlog, infrastructural issue etc. 

Remove Dependency: Another team is dependent on your team and this is impacting the delivery. In this scenario ask the dependent team to own their piece of work as much as possible.Provide them all necessary permissions and access to the shared code base etc.

Adapt the Process: Constant interruptions, sprint backlogs get completely revamped, unplanned work. In this scenario try out something different like smaller sprint length, use a different framework like Kanban etc.

7. What is the benefit of estimating work in story points rather than hours/days? What is the relationship between story point and hours/days?

Answer: Story points give more predictable & make estimation easier, reduces planning time, accurately predict release dates, and help teams to improve performance. In Story point estimation instead of looking at a product backlog item and estimating it in hours, teams consider only how much effort a product backlog item will require, relative to other product backlog items. In other words relative sizing instead of relative effort. This prevents the need for frequent re-estimation and works like a size-based estimate.

Effort varies from person to person. If you use hours or days then a senior member hour is not the same as junior member hour on the same task. So it introduce large amounts of waste into the system, unpredictability in release planning, and confuse the team. 

Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

There are no relationship between story points and hours/days.

8. Management wants to evaluate individual performance on an ongoing basis so it helps them during annual review process. They are thinking about tracking story points completed by each developer in a Sprint. What are your thoughts?

Answer: Story points are relative so someone that sizes high would have a natural advantage over someone who sizes conservative. So to evaluate individual performance below are the recommendation. 

1. Give all of the members of an Agile team the same performance goals.
2. Assign individual goals for individual development.
3. Make sure individual goals are aligned with team goals.
4. Frequent 360 degree performance feedback is better than many alternatives.
5. Value highly the personal traits, characteristics, and behaviors of good team members.

9. For a distributed team spread across multiple locations – what key practices would you recommend them to adopt?

Answer: 

• Adopt a hybrid approach with local and remote team members
• Adhere to engineering best practices and development standards.
• Respect time zone and ensure that teamwork and collaboration are working well by removing cultural and process limitations.
• Use of online tools for agile artifacts. clear objectives and well written requirements.
• Cultivate commitment to product and delivery quality. Create ‘rich’ communication channels to reduce the impact of low levels of ‘face-to-face’. Try to arrange face-to-face interaction.
• Create frequent deliveries of deliverables to establish control. Frequent demos and retrospectives.

10. What are some of the approaches to deal with team conflicts? How would you approach a conflict between developers and testers where developers feel testers are raising unnecessary bugs and testers feel developers give them completed stories too late in the Sprint?

Answer: Key is to identify, be neutral and have focus on solution.

Recognize Conflicts vs Disputes: Is the disagreement on outcome or approach? Is there any parties personally invested in the outcome of the conflict? Is there any personal judgment? Is there any mismatch between goals at the root of the conflict?

Establish a Neutral Coaching Stance: Acknowledge both parties & engage in personal coaching

Solution-focused conversations: A solution-focused conversation helps the parties move away from confrontation and into a collaborative space where they can build a solution together. Increase understanding, team cohesion, self-knowledge reduces conflicts.

11. What resistance and opposition do we face in our daily work as agile coaches?

Answer: Resistance comes in many forms e.g.

Understaffing in Scrum Team : Key roles like ScrumMaster and Product Owner are not staffed adequately which leads to significant delays, trust issues and misunderstandings with in the team.

Inadequate budget & advance tools:  It impacts the velocity and Performance of scrum team.

Not considering big picture or enterprise view: Department thinking and local optimizations instead of a holistic view and applying systems thinking.

Missing management buy-in: It creates fear and resistance that needs professional guidance.

Fear of decision making: There are multiple factors like disengaged stakeholders, not adequately empowered team, lack of coaching etc.

12. What skills are required to succeed as an agile coach?

Answer: Agile coaches must have many of the following skills:

1. Communication
2. Problem-solving
3. Industry knowledge
4. Critical thinking
5. Conflict resolution
6. Leadership

13. When you start new application what are the typical stages it goes through? How do you begin transforming a group?

Answer: Most transformations goes through a mix of executive and low level team buy in. So usually an Agile Coach should look for “train executive leaders first” and then at some point it needs to get down to the team level. Some key factors to maintain transparency are 

1. Build the Right Teams
2. Have Good Metrics From Day One
3. Focus on Products Not Projects
4. Choose the right Product Owners 
5. Choose the Right Scrum Masters
6. Differentiate between Mentorship vs. Management

14. Explain some common metrics for Agile?

Answer: You may definitely come across agile scrum interview questions regarding agile metrics. The question may be related to a particular agile matrix or explaining all the metrics. So, the detailed description of some common metrics for Agile is as follows:

Velocity – Velocity is the average number of points from last 3-4 sprints. It is measured by the summation of the all approved estimates of the stories. It gives an idea of the capacity, progress etc.

Cumulative Flow Diagram – With the help of a cumulative flow diagram, an inspection is done over the uniform workflow. In this diagram/graph, the x-axis represents time whereas the y-axis represents the number of efforts.

Work Category Allocation – Work category allocation is an important factor that gives a quick information of the time investment i.e. where the time is being invested and which task should be given priority as a factor of time.

Time Coverage – It is the time that is given to a code during testing. It is calculated in percentage as a factor of the number of lines of code called by the test suite and the total number of relative lines of code.

Business Value Delivered – It is a term which denotes the working efficiency of the team. The business objectives are assigned numerical values 1,2,3.. and so on, as per the level of priority, complexity, and ROI.

Defect Removal Awareness – It is the factor that helps the team to deliver a quality product. The identification of an active number of defects, their awareness, and removal plays an important role in delivering a high-quality product.

Defect Resolution Time – It is a procedure through which the team members detect the defects (bugs) and set a priority for the defect resolution. The procedure of fixing errors/bugs or defect resolution comprises of multiple processes such as clearing the picture of defect, schedule defect fixation, completing defect fixation, generation, and handling of resolution report.

Sprint Burn Down Matric – The sprint burndown chart is a graph to represent the number of non-implemented or implemented sprints during a Scrum cycle. This matric helps to track the work completed with the sprint.

15. What are the desirable qualities of the vision?

Answer: The vision forms the foundation of any product, it is something which encourages and inspires people to stay on the right path, hence it should be clear and firm; extensive and appealing. Vison should be Imaginable, Desirable/Compelling, Achievable/Feasible, Challenging, Aligned/Focused, Flexible & Communicable. To list out few desired qualities of the vision, let’s look at the following points:

Clear and firm – A good product vision should be easy to grasp, interpret and creates a common purpose for the teams while avoiding confusion and misinterpretation. Visions may change with changing factors. Small adjustments are allowed provided the value proposition of the item is retained. But big adjustments may cause confusion, project failure and demotivation.

Extensive and appealing – It should provide a very high-level view of where we want to go, and also provides the development team with space to come up with ideas, to collaborative, to find solutions, to inspire to achieve more. It should encourage the team for better delivery in line with customer expectations.

Brief and concise –It should contain only information critical to the realization of the product. It is not a list of requirements, hence, it should not cover the minute details. In simple terms, it should be short and sweet.

16. What is the relationship between vision and product roadmap?

Answer: Vision is a sort of a goal you see for your organization and for the product. You do not own the vision, but you should have a clear sense of what it is as you help carry it out. Thus, there are three elements which constitute a vision on a broader level, the purpose, the picture, and the values. For any product, it’s really important to understand why we are building it, what purpose will it serve to the customer or the client.

Next comes the picture where we see how the end result should look like and lastly what value will it deliver. The vision statement can be just a few lines and it is not going to be very elaborative or prescriptive.

To achieve this vision, a roadmap is created, it is a powerful means to define how a product is likely to grow, to align the stakeholders, and to procure a budget for developing the product and it is also a visual summary that maps out the vision and direction of the product offering over time. It outlines goals, milestones, and deliverables for a product in development.

e.g. Let’s say a Space travel company has a vision that “affordable and repeatable space travel”. The product strategy is to build vehicles capable of going to space multiple times, along with the supporting infrastructure to make that possible. The product roadmap is (for each spaceship) the high-level steps required to build a spaceship that meets the requirements of the product strategy, which in turn is fulfilling the company vision.

17. What is a product roadmap? How will you create or help in creating a Product roadmap?

Answer: The product roadmap provides a strategy and plan for product development. It’s driven by short and long-term company goals and communicates how and when the product will help achieve those goals. It reduces uncertainty about the future and keeps product teams focused on the highest priority product initiatives.

In addition, the roadmap helps product leaders communicate the product vision and strategy to senior executives, sales and marketing teams, and customers, and manage expectations about when significant product milestones will be completed. When stakeholders don’t feel heard or are uncertain about where the product is going, they may begin to doubt the strategy, which can lead to a toxic work environment. The product roadmap aligns the key stakeholders on product goals, strategy, and development timelines.

The product roadmap typically illustrates the following key elements:

• Product strategy and goals
• What products and features will be built
• When those product features will be built
• Who is responsible for building those products and features
• “Themes” or high-level priorities

For a small organization the PO might be directly involved in creating the roadmap however in large organization, he would be someone whose input would be required.

18. How do you work together with the Scrum Master/Product Owner?

Answer: Good collaboration between a Scrum Master and a Product Owner is essential for a good Scrum Team and regardless of the position an organization is hiring, the candidates need to understand this.

Both Scrum Master and Product Owner candidates should be able to provide insights into exactly how they would support the other role and, just as importantly, when they would ask for assistance from the other person.

Just as an example, both Scrum Master and Product Owner candidates should understand how they should collaboratively present the product, the Product Backlog and the work to be done to the Scrum Team. By working together closely, the SM and the PO can also ensure 100% open lines of communication which call for easier problem solving and a more efficient process.

The important thing is that the candidate understands how these two roles have a common goal and how they can support one another.

19. How do you integrate into an existing teams as an Agile Coach when you first start a new engagement in an organization?

Answer: Set expectations about what my approach: with managers, leadership, and also the team (they are different discussions). “Expect that I will ask a lot of questions.”

Observe (from an outsider’s POV) what they are already doing, for at most one sprint.

Search & fine pain points,  look for adherence. Then use the insights to draw up some suggestions, and discuss this with the team and leadership to choose what it makes to mitigate these.

20. How do you promote Agile mindset across the organization?

Answer: – Agile Coach is a catalyst, change agent and servant leader who help train corporate teams on the agile methodology and oversee the development of agile teams to ensure effective outcomes for the organization. Few strategies to promote agile mindset are

• Engage people in this discussion by various means. Not necessarily in meetings can be in during Lunch time, coffee time etc.
• Arrange for different types of workshops to train them.
• Call them for the sprint planning, review, and retrospection.
• Discuss the velocity, lead time change from idea to product launch and level of customer satisfaction during this process.
• Arrange for small pilot projects for their domain to give them more insights into this process.
• Product and engineering teams can demonstrate that scrum mitigates risk (i.e. the prediction of when new features could be made available), thus contributing to other departments’ successes in planning and execution.

Agile Coach Interview Questions and Answers – I: Click Here

Disclaimer: All the content related to Scrum Guide is taken from scrumguides.org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.