Following are the TOP 10 agile interview questions. There is another list of critical questions while these are expected in most interviews. Moreover these are very basic, and every interviewee is expected to excel in his/her responses for these questions.
What is agile roadmap looks like? Explain agile process start to end? How do you start agile project? What is the difference between product roadmap and Release planning?
If you are a manager and above in agile work environment and you need to go with appraisal, you might have encountered situations where what to expect from your team members compare to traditional model. The focus is on collaboration, pairing, individual ownership for self and team. The “Working for team” culture over work for “self” make it more difficult. One of the recommendation I have for all the managers or individuals responsible for doing appraisals for agile team is to have a certain percentage allocated to team success in everyone’s goal, and further how the team collaborates and how well they work together. The percentage can differ with experience of an agile team member and expectations what you have from your team.
When it comes to individual performance (obviously there is a percentage attached to this as well which is typically little above than team success), I prefer to look at three factors which covers it all.
1. Competence – Demonstrates strong leadership in one or more areas (e.g., technical, project management, process, etc.). Consistently works to leverage skills for team and larger organization success.
Breadth and depth of knowledge and skills
Problem solving ability
Technical, communication, interpersonal, business skills
Leadership and innovation, applied to people, processes, and projects
2. Contribution – Someone who has a lot of initiative, is a leader across the organization, and has outstanding productivity.
Ability to meet commitments
Overall productivity and volume of output
Early communication of problems and contribution to workarounds that meets business goals
Versatility – willingness and ability to adapt to new tasks
Teamwork – willingness and ability to help others
Leadership skills such as architecture, project management, change management, communication, and mentoring
Ability to motivate others, manage self, and demonstrate initiative.
3. Value to business – This is very critical. What kind of value you are adding to business. There could be high competence and contribution to build a product while ROI (Return on investment) should never be ignored.
Knowledge and skills as mapped to needs of the business
Extra points here for unique skills we need
Every agile member should ask three questions to himself/herself frequently
Am I learning?
Am I contributing?
Am I making a difference?
The manager should ask the same questions to himself/herself and same for his team. If the answer is no then appropriate development goals must be planned and discussed.
The biggest goals for a manager should be in while managing agile project should be
In Agile environment, some of the committed stories may not be completed at the end of the iteration. For example, in Scrum, the stories roll to the next sprint. There could be various reasons why some of the stories could not be achieved. Reasons include (not limited to) blockers, inefficiency, improper sync between team members, missing clarity, support from other teams, priority etc. A casual look on this can make someone think this is normal. But sprint success has a huge impact on the long term success of the team and the product.
Following are the some of the reasons why sprint success is important.
Morale : The team members self esteem actually gets higher when they achieve their goal. This breads confidence and help them to get better a their game, which can lead to more success.
Habit: Success breads happiness and more success. At the same time, failure breads failure. Also success/failure on one aspect of life can cause ripple effect on the rest of the life. We should be focused on success on every aspect of life so that it can bread in to itself.
Fig: Habit Loop
Fine reputation: More than any thing else, team will be very proud when they are able to successfully achieve the sprint goals consistently. Their reputation and respect around the company can actually go up and they will have to live up to that standard.
High standards: Team starts to set higher standard for themselves when they have high reputation. This helps them to get better at questioning, coding, testing, deploying and showcasing etc and improves their living standards in a holistic way.
Team bonding: When the team have a standard to live up to, they come together and get the things done, keeping aside the petty things. The goal becomes bigger than individuals and deliver thing as a team. This leads to higher team bonding and it reinforces their standards, reputation, habit and morale.
These are some of the main reasons why sprint success is important. When we focus on success, more positive things happen to the team and to the product that they work on.
Product Owner (PO) – PO is a key stakeholder in an Agile project. He/she is responsible for defining or detailing the vision, understanding organization goals and ensure to align project goals with it. PO has the content authority at a team level.
Defines the features and stories of the product. Responsible for elaborating requirements, clarify doubts, and clearly stating acceptance criteria.
Review and accept/reject the work accomplished by the team.
Responsible for prioritization of the work.
Responsible for release planning.
Owns product backlog and release backlog.
Remove functional impediments and constantly answer product related questions to the team.
Constantly talking to other POs to align product/project changes with business unit/organization goals.
Responsible for the return of investments.
Constantly working with the customer to fulfill their needs and better understand their requirements.
The Scrum master plays a servant leader to the Scrum team.
Facilitate daily standups.
Setting up retrospectives, pre-grooming, showcase, Scrum of the scrum and other meetings.
Remove impediments or obstacles for all kinds (technical, functional, resource, etc.)
Co-ordinate with POs, teams, Manager, and all the project holders.
Ensure team productivity and closely working with them to ensure quality requirements are enforced.
Ensure the team understands the processes and adhere to them.
Protect the team from external interferences and interruptions.
Responsible for actual implementation.
Owns Sprint Backlog while the priority of Sprint backlog should be derived from the product backlog.
The recommended size is between 6 to 10 people. The best practice is to have 7-8 members team.
All the members are expected to be full-time. The exceptions could be DBA or some specialized skill needed on a temporary basis.
Proactively identify ways and opportunities to improve the performance of the team and constantly get better.
Are set of programmers, DBAs, tech writers, technical experts, domain experts, independent testers etc.
Must be self-organizing.
Constantly communicate with the team and ensure to meet sprint goals.
To share all information in daily standups including “work in progress”
To support each other. Most importantly consider sprint goal a priority over individual goals.
Avoid accepting outside or extra work without consent from team.in
Agile software development framework refers to the time-boxed, continuous iteration of development, and testing to build software where the solutions evolve throughout with incremental development via collaboration among self-organizing teams. Agile helps organizations to expertise and respond to continuous change resulting in continuous improvement.
As shown in the above diagram, the vision and feasibility are the most important factors to be considered before starting a project. In this phase,
We identify whether we should consider doing a project or not
What is going to be ROI (Return of investments) for a project?
How do we get funding?
Is it worth taking risks? Staffing?
what is the value the project brings in?
You use this phase to break the idea into individual functionality items called features or user stories. If this looks positive, the next step is to create a product roadmap document.
The product backlog is created by leveraging the product roadmap document. The release planning results in a release backlog. The individual sprints are defined to accomplish upcoming release goals. The Agile Roadmap blog defines the entire project in more detail.
One of the powerful retrospective getting very popular lately is Sad/Mad and Glad. Many organizations don’t even conduct it as they are afraid to talk about employee challenges or too busy to do other things that they don’t have time to focus on employee morale. There are obviously pros and cons but making it work truly helps you to achieve more. In my personal opinion, the number of positives what you have with this retrospective is far higher than challenges hence it’s worth doing it.
Your team and your presence
Sticky notes (Three colors)
Open minded motivated teams
In this retrospective, you ask your team to get into a room. Every colored sticky note represents Sad/Mad or Glad respectively. You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!
You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!
You can start your meeting with a positive note. Ask individuals to participate freely and openly. Once the stage is all set, you can ask every individual to write up the areas what they are happy about it (Glad), don’t like it (Sad) or frustrated with it (Mad) on different color sticky notes. I always recommend individual team members to write their names on each sticky note else there are good chances that it would become a political battle. You should always give an option to do go with anonymous though.
I have seen instances where team members just write some crap either because they did not have good appraisal last time or not in line with others due to personal issues. If you find an item which has something written in sad or mad while an individual who wrote it is not willing to even talk about it then you can very much assume either that’s fake or written with the wrong intention hence discard it. There are some people very shy and not willing to open at all. They should go to their manager or who is driving sad mad/glad to discuss the area of concern. Just to avoid the frustration as manager, anything written as an area of concern and individual is not willing to open up personally or with the team, you can safely scrap it.
Once everyone is done with writing, spend an hour or so reading every item and discuss that with the team. Remember the goal is to share as much as information about the issue and gaining more details around the problem while not fixing the problem there itself. This would be good input to take it forward as employee happiness and moral is very critical to agile success.
Things to remember while doing Sad/Mad & Glad:-
You should be reading every item loud or make it visible to every individual unless there is a derogatory remark which is not acceptable.
Team to think of the success of team and project rather considering this as revenge material.
Everyone must open up. If you don’t have guts to talk about your challenge then don’t even write it. You are just creating a FUSS which is either not true or you don’t know what is this the right forum to talk about it.
Refrain from making comments about an individual if you don’t have supporting material. The world is not perfect. The goal is to identify the improve system over making it worse
Should not be anonymous.
Don’t abuse it. It is conducted to the best interest of an individual and improves as a team. It should never be used as a tool to fulfill your political battle.
Not every problem can be fixed eventually. Somebody writes that I don’t feel like working doesn’t mean you would allow him to sleep in the office.
Don’t try to fix the problems during this retrospective.
Constantly read the issues/concerns raised and strive to fix as much as you can. Provide updates to the team around the issues you committed you would work on.
The benefits I see with this retrospective are:-
Gives lots of motivation to the team when going over “Glad” items.
Give an opportunity to an employee to express their challenges.
Bring in open culture
Reduce attrition as you really know challenges and definitely a lot of which you can work on.
It gives 360 views in terms of how the teams are progressing.
One of the biggest “Glad” item I would say is that your organization is conducting it.
The challenges I see are:-
It may become a political battle if your team is not mature and willing to go for an anonymous survey.
Excessive sad mad and glad would unearth issues which are not really problems while making other team members think it’s a major problem.
Sometimes very happy team morale goes down as well as when you have an opportunity to think about negatives, you feel like writing it and further “law of attraction” does its job.
What I was written must be addressed and fixed “Myth”. You may not like the tile color in the washroom but that cannot be really changed.
You must earn 21 PDUs (Professional Development Units) to be able to appear for this exam. You are expected to earn at least 30 PDU every three years in order to main the status of this certification.
PDU – One PDU can be earned with one hour of activity (training). As per the PMI “The professional development units(PDUs) are the measuring unit used to quantify approved learning and professional service activities.”
Pairprogramming is an agile software development technique in which two programmers work together at one workstation and share the same keyboard. One person (Driver) writes the code while the other person (Navigator) reviews it and at the same time thinks about the big picture. If you want your partner to expand their knowledge in programming, you can even give them one of those gifts for coders.
How to do it right
Understand the requirement well before you start. Spend few minutes and discuss with each other.
Agree on one small goal at a time.
Support each other
If you are a driver, focus on small tasks and quickly complete it avoid bigger issues. Trust navigator to your safety gate.
If you are a navigator, constantly review the code and think of a big picture. You don’t need to dictate the code.
Celebrate victory when the task is completed or you resolve a problem.
Changing roles few times in a day helps (Driver to Navigator and vice versa)
Encourage pairing. Do not worry about slight productivity loss in beginning. This is something I have seen many teams when new teams are formed as they don’t have experience in the pairing.
Start with a trial. Do not force individuals to pair. Let them decide who wants to pair with whom. Changing pairs constantly helps.
Pairing for more than six hours a day is not advisable.
Individuals should switch driver and navigator role when they get bored.
The Large monitors and good leg room are essential along with co-location which is absolutely mandatory.
Trust and support each other. The team culture plays a critical role.
Improves software quality without impacting time to deliver.
The focus and energy involved are much higher hence chances of making mistakes reduces significantly.
The better articulation of complexities and hidden details of coding tasks reduces the human errors.
The requirement elaboration and definition of done usually be better understood.
Build trust and help individuals to be better skilled.
The partners can switch when frustrated or stuck. The work doesn’t get compromised. The change in responsibilities once again adds energy to work.
New recruits come up to speed more rapidly in a pairing environment.
From a developer standpoint, pairing is enjoyable and valuable activity. I have seen developers who resisted pairing the first time, eventually loved it and found it to be much really useful in terms of learning, more engagement, better quality and successful careers.
It’s social skill and it takes a time to do it. The best pairprogrammers exactly know when to say let’s try your idea first. Do not expect the outcome of pairprogramming from day one. It takes some time to do it in right way.
No benefits are expected if both the programmers are not actively engaging themselves. It’s “programming it loud’ methodology” hence it is essential that the driver and navigator constantly communicating. The silence kills the benefits of pairing.
If the two people have personal challenges, the pairing cannot be forced upon. The trust and mutual understanding between the two people is absolutely necessary
Experience mismatch is another bigger challenge. The senior programmers often want to have more control and give a little room to junior programmers.
View pairing as one person watching, the other person doing the actual work. That becomes boring and disengages the person watching, eliminating any real benefit from this practice.
Pairing should be avoided for very simple tasks or tasks which are very clear and can be done in little time.
Pairing needs to be done by two. The moment the third person added to it, it cannot be called pairing anymore.
The co-location is absolutely mandatory. The absence of co-location where the work is shared between two programmers is called sharing over pairing.
Force the pairs or identify them ahead of time which may not be right in many scenarios. The best approach is to let the pairs form and swap by their own.
The pairprogramming is mentoring while it should never be. Programmers often pair with somebody with the goal to learn technology and domain. That is called either mentoring or knowledge transfer. This should be treated as a knowledge transition and expecting less than one person productivity is a fair expectation.
Two people working on the same story but different tasks individually is considered pairing while IT IS NOT! It is sharing the work but not pairing.
I have often seen individuals complete half the task and hand that over to another team member in the evening sitting in a different country and assume that it’s pairing. This is again the sharing of work and comes with an extra cost due to unknowns, handoff, and understanding each other’s work.
Doing agile requires pairprogramming. The reality is Agile manifesto never talks about pairprogramming.
The initial resistance of programmers that pairing is not the right thing to do. Most programmers like it when they try it. Others don’t do it right and start believing it’s a waste.
The pairing would reduce productivity to half. This is one of the most debated topics. I have personally experienced that when it is done in the right way, it improves the overall productivity of more than two people working individually.