Agile Coach Interview Questions and Answers

The Agile Coach is someone who is experienced in implementing agile projects and can share that experience with a project team. An Agile Coach helps to define what is to be done, how, who does it, when, why, how it fits in with the organization, change management, people management and interactions between agile teams and other parts of the organization (like Dev Ops, Hosting, Build teams, Education, UX/UI, etc).

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.

1. How Agile Coach role is different from Scrum Master?

Answer: The biggest differences is the level at which the two are operating, single team vs enterprise. A Scrum Master works with ONE or limited number of team and influence those team with respect to scrum values and principles. An Agile Coach works with multiple IT or business areas , executives including middle management and senior management influencing them with regard to Agile.

A Scrum Master ensures that the team is following the Scrum process, doing the ceremonies and behaving the right way. An Agile Coach helps to define what is to be done, how, who does it, when, why, how it fits in with the organization, change management, people management and interactions between agile teams and other parts of the organization (like Dev Ops, Hosting, Build teams, Education, UX/UI, etc).

2. What does coaching mean to you?

Answer: Coaching to me means being someone who draws the potential out of both individuals and teams. Rather than providing solutions as in a consultancy, a coach tends to draw the solution out of the individual and team rather than providing them with solutions from which they pick.

The coach does this by helping their clients to see new perspectives and possibilities which ultimately in our context lead to better performance as a product team and as individuals.

In order to orchestrate this, the coach will typically engage in activities both at the individual and team level relating to mentoring, teaching, facilitating, problem solving and resolving conflicts.

3. What is the difference between coaching and mentoring?

Answer: Mentoring is a long-term process based on mutual trust and respect. Coaching, on the other hand, is for a short period of time. Mentoring is more focused on creating an informal association between the mentor and mentee, whereas coaching follows a more structured and formal approach.

Coaching helps the team’s performance get better, whereas mentoring is more specific to individuals and the specific problem that a team is trying to solve where you transfer your knowledge and experience that is relevant to that specific problem.

4. How would you establish a highly motivated scrum team?

Answer: I think one of the ways to motivate any team is to empower that team to have control over their own work where they own it and are self-governing. Help the PO to vision cast and empower the team.

The work has to be challenging and create an environment in the team in which they can master a particular skill set. Also, aligning the team with a higher purpose will motivate, so having the team aligned with other teams but remaining strongly decoupled with little hand-offs. Being part of a larger vision, engineering strategy will also motivate.

Give the team opportunities to grow – knowledge sharing sessions, lab-like work where they experiment with different ways of doing things including different technologies. Some key items to consider are

Acknowledgment and Recognition
Team Building Activities
Staying Positive During Setbacks
Ensuring Balanced Workload
Being Open to Criticism and Differing Opinions
Having Fun

5. How do you build trust with a team you’re working with? What approaches you might take?

Answer: Work with team over time. Trust isn’t something established quickly, it can be quickly lost but not so easily gained.

Start with those already in trusted positions e.g. PO/SM and then work from there to influence the rest of the team.
Work with the team. Spend time with people listening and observing.
Default by trusting people up front and I often find they return it.
Be transparent and visible, be vulnerable.
Take the heat for other’s mistakes and protect team.

6. If a leader came to you and explained they were budget constrained and wanted to combine the PO and SM role, what would you advise?

Answer: If they want to use Scrum, then there are three very well-defined roles. Combining SM and PO will not be effective because PO role needs to focus on product decisions. SM activities would distract the PO from that. Likewise for the SM role. Both the roles have different sets of activities and combining both will create conflict of interest.

If the SM and PO were the same person, it’s likely the PO role would dominate. The PO represents the interests of the customer whereby the SM represents the team. The separation offers a pragmatic argument between client expectation vs technical feasibility.

7. What are the most common challenges that you encounter as an Agile coach?

Answer: In many cases, it’s the management that is suspicious of the agile approach. In agile we propagate self-organized teams and for some managers, this sounds like: we do what we want. But that’s not true at all. There is always a product owner who says what to do and an agile coach that helps to ensure that the work is carried out efficiently.

But there is somehow a lack of control. The partial results are no longer checked. You no longer measure whether an employee did this or that, but only focus on the added value at the end of a sprint. That’s what makes many managers suspicious and some have a problem finding their own role in it. What is the role of a manager when the teams work independently? In the sense of an agile leader, management is more than just servant leadership. Instead of directing and controlling work, they must clearly communicate expectations and goals and then support the teams in achieving them.

It must be acceptable to make mistakes, because only then can the teams learn and further progress. You should try something out and then we have to make sure that the mistakes can be quickly fixed so that no disaster is triggered. Everybody learns from small mistakes and that’s why I cannot come and punish people. Instead, I have to say, “Making one mistake is no problem, but do not make them twice”. We always have to learn from the mistake made. When the lived culture becomes part of the company, everything is actually fulfilled. The big challenge is to make everyone believe in this and to take everyone along the way, not just the team, but also the management and top management.

8. As an Agile coach how do you manage to take management in Agile Journey?

Answer: First of all, I have to make clear that working agile is not something we’ve just come up with. It’s something that the most successful companies in the world practice and because of that they are successful. To prove the people that the agile way works, I need a small leap of faith. For this, you have to work hard with a trustworthy presence and by delivering again and again.

9. As an Agile coach how would you approach an Agile-resistant environment?

Answer: This is a crucial question for candidates who are applying for a position in a company that is only starting to implement Agile into its organization. The answer may seem like an invitation to list a number of actions required to approach an environment that is not that welcoming to Agile, but this is not the case.

The answer employers will be looking for is an elaboration on how complicated this can be and the need to tailor one’s approach to a specific situation with an organization. There are innumerable ways in which organizations reject and only half-accept Agile and the candidates should display their understanding of this and share their past experiences on how they dealt with this.

One of the worst approaches to answering this question is to start to contemplate on the ways in which Agile can be implemented as a modification of the existing (usually waterfall) model of doing things. While it may show some resourcefulness on part of the candidate, all experienced and knowledgeable Agile practitioners know that these Agile-like abominations help no one.

10. How do you deal with employees who have worked with the waterfall approach for ages and now all of a sudden have to adapt to the agile way of working?

Answer: It is important for everyone to understand the reason why we work agile and what it means for the further development of the team. It’s not about organizing a short standup meeting every day or splitting the work into 2-week stages. But instead, I always start by explaining the core values of the agile world: Respect, Openness, Focus, Commitment, and Courage. Then I specify with the team whether everyone stands behind them and finally how exactly we want to implement them in the team.

The team should only consist of people who want to live the values and I support anyone who wants to learn this. Depending on the task of the team, I introduce appropriate procedures such as Scrum and Kanban and together with the team I decide how to start. Sometimes there happen to be people that simply don’t want to learn the agile way of working. In this case, I’m powerless and the only possibility is that this person goes out of the agile team and does something else or works in another company.

11. What do you mean by Fail Fast in context of Agile?

Answer: Agile values rapid development, adaptability, and continuous improvement.Fail Fast principle is also applied at the software bug lifecycle. As we know, the longer it takes for a bug to appear on the surface, the longer it takes to fix and the greater it costs.

Fail-fast makes bugs and failures appear sooner, thus:

Bugs are earlier to detect, easier to reproduce and faster to fix.
It’s faster to stabilize software.
Fewer bugs and defects will go into production, thus leading to higher-quality and more production-ready software.
The cost of failures and bugs are reduced.

There are four key components of Fail-fast theory.

Fail Early: Learning from failure is critical for success so the sooner the failure occurs, the sooner the learning begins. By failing early, you can create something useful and deliver it to the consumer as soon as possible. This will allow you to get real and fast feedback about what works and what does not; which you can then adjust before moving forward.
Fail Fast: Fail quickly so that we can begin the learning process as fast as possible and there are many ways to achieve this during software development. One of the possibilities is Test Driven Development – which we can use to write a failing test before we produce code. The test will fail immediately presenting the shortest feedback loop available. When the test works, any time the code is worked on tests can be run again, giving instant feedback.
Fail Often: Once failing and learning loop has been established, we can see that the more things we try, the more failures we will have and therefore the more chances we have to both learn and steer our project in the right direction. In addition, this will remove the need to waste time by working on incorrect avenues.
Fail Better: With early and frequent failures all that is needed is to maximize the learning opportunities. One possibility is to be with the real user while they test the project, and another is to code up what we understand as quickly as possible with the aim of helping us speedily discover the right path.

12. What kind of work would you do as an agile coach? And what is not your responsibility?

Answer: I would do almost every kind of work but still prioritize where my help will be most useful. For example, if someone would come and say to me, “I have a great idea! We have to change the framework somehow, but the other people in the team do not want that.” Then, of course, I would first ask, “Did you talk to the other people?” or “Why do they not want to do it? or “Did you get any feedback from the rest of the team?” – and then I would advise solving the problem themselves. If this is being rejected by the others in the team then maybe there is a reason for it.

But when it comes to the fact that you generally cannot develop within the team, then I can be helpful by taking a closer look at the dynamics of the team to see if everyone also has a voice to be heard. That’s why I always listen in order for me to be able to address the problem in the best way possible. I always ask critically to find the reason for why the team needs my help and of course, I also evaluate who I think is the right person for a given task.

13. What does a day at work as an agile coach look like?

Answer: At least the day looks like I have no clue what will happen throughout the day. First, I go to the teams and ask them how everything is going. I offer them to take my help if they need it and then people come to me and say, “This just happened here. How should I proceed? Do you have an idea? or “Can you take the lead here?” Basically, I offer my service. You can see it as Management as a Service or Leadership as a Service.

Sometimes very trivial topics also arise like, “Can you organize a meeting for this and that – and can you moderate it?”. Or more demanding topics like, “I have a problem with this other team. They never do what we ask them to do. Can you talk to them?” Then I’ll assign the task to myself and do it.

14. As an Agile Coach what do you do to meet the changing requirements during the phase of development?

Answer: Change requirement is the very aspect of the agile method. So it is necessary for the team to maintain a check over the requirements of the customer. These changes must be made regularly in the upcoming sprints and until changes are not done completely, the team should not move to the next process. Change requirement in agile is an advantage to ensure satisfaction of the owner.

15. During the phase of software development, what were your responsibilities for meeting the changing requirements?

Answer: A team needs to be very aware of the requirements of a customer. Therefore, a change in requirement should be kept at check properly. In every upcoming sprint, these changes should be updated on a regular basis. A team working on this change should not move to other processes unless that specific change is done completely.

Hence, the answer to this question should be those specific responsibilities that a coach did to manage these changes and how these changes ensured customer satisfaction with their requirements.

16. As an Agile Coach in what way do you manage overlapping iterations?

Answer: Iteration overlaps can be managed by having a multifunctional team. Multifunctional teams consist members that are enthusiastic about all the agile requirements. They will be skilled in areas of design, testing and coding. These members are capable of participating in all the processes equally.

There are many views of how iterative/incremental projects should run under Agile. Overlapping iterations is certainly one strategy. The danger is to pay attention to the candidate if they say that “iterations should never overlap.” This may tell you that the candidate is used to having what is called “multidisciplinary teams.” This type of team consists of a set of generic team members who all have the skills and enthusiasm for requirements, design, coding and testing and who each participate in those activities almost equally. If your company has defined roles (business analyst, test analyst, etc.) and career paths then this candidate may have a tough time fitting into your structure. They will want BAs to code and testers to do design. Is that okay? It is your decision. Again, nothing wrong with multidisciplinary teams, but your organization must be able to handle the change if you decide to go that way.

17. Did you use automated test tools on your projects? Explain how that worked.

Answer: Agile project team members should have experience (or at the very least, the desire) to use automated testing tools for regression and performance testing of each iteration. At the end of each iteration you want to have something that your customer/client can “see.” Automated testing allows quick identification and isolation of development defects as well as the ability to test development work completed in previous iterations. Expect the candidate to talk about automated regression testing, continuous integration and testing and even performance testing techniques and tools. Also expect them to discuss the need for manual testing as well as automated testing, due to the ever-changing nature of the code base in Agile.

18. Have you done continuous integration on a project before? Describe.

Answer: Here you want to get a pretty detailed explanation of how the candidate has used continuous integration on previous projects. Continuous integration is a set of automated build, integration and test steps that executes against the code base in a configuration management repository. For instance, if you were using Java and CVS, the CVS repository would have a set of triggers that automatically built, integrated and unit tested the code often, perhaps each night, perhaps a few times a week, or even every time someone checked in new code. Each of these is a valid continuous integration story.

19. How did you manage traceability of the requirements to testing?

Answer: The point here is to make sure testing goes all the way back to requirements for validation. Not only is it important to test that the functionality a developer has created during an iteration actually functions, it is also important to determine if it functions the way the business wanted it to function. Does it meet the requirements defined in the story card / use case? Your team members should understand the importance of this concept and if they understand and accept traceability, you should be able to count on this person to help you meet project goals.

20. As an Agile coach how comfortable are you with ever-changing requirements?

Answer: Many development methodologies specify that requirements are locked down at the beginning of a project. Although that is not the case in Agile, it does not mean that requirements are loosey-goosey! The advantage of Agile and its short iterations is that it is easy to quickly recognize that work is not progressing as desired what the customer asked for. If it is not what they wanted then the requirements must be changed. Team members should be able to handle such changes on an Agile project. It shouldn’t be so tied to code, a story card or any other component of work that prevents providing a solution which meets the customer’s needs. The general idea is that requirements can change a lot at the beginning of the release, and very little at the end.

Agile Coach Interview Questions and Answers – II: 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/.