PO Interview Questions

PO Interview Questions

What is the purpose of agile?

  • Test hypothesis
  • Rapid feedback
  • Fail early, fail faster
To what extent is the role of product owner that of a product manager?

It all depends on individual companies how the roles are crystallised within the organisational structure. From what I understand, Product Manager role is more market-facing and is strategically focused. 

When was the last time you said NO to a stakeholder and how did you approach the situation?

SF was insisting on what is called a certificate testing. There were nearly 170 scenarios to be tested manually as part of that. However, it was realised our regression suite covered a large part of what was expected of us. I went back to SF and clarified things. Had  a chat with the technical guys. Why did they want certificate testing on SIT, especially since they were going to test it anyway during the SIT as well as UAT phase. It sounded more like a vendor-client relationship than that of a co-creation one. It also made perfect sense that we do a  part of it - those that weren't covered by the regression suite. However, doing the entirety was not a use of time productively. I communicated the same to SF asserting that this was possibly avoidable and suggested another approach that better suited to the needs of the project. 

How do you manage your stakeholders?

You don't manage stakeholders. You create an environment where interacting, communicating and negotiating with the stakeholders is healthy, there is a healthy debate, and you are able to put across your concerns, team constraints positively, without fear or retribution. 

1. Understand your stakeholders. Take time to know them, what drives them, what motivates them, what their preferences are with respect to POs, what kind of interaction they expect, what are their thoughts on key negotiations, etc. and treat them accordingly. 
2. Not all stakeholders are same. Have a plan for each of your stakeholder, how you want to deal with them, etc. 
3. Set expectations. Set expectations about the team, your constraints and team constraints. And communicate with them on these expectations 
4. Communicate upfront: As PO you know what is good for the project and what is bad. Be willing to say NO if something is bad for the project, or doesn't align with the objectives of your team. For the benefit of the project feel free to say NO to the stakeholders. They will appreciate a firm NO than a Yes and then not delivering. 

What are the roles and responsibilities of a product owner?
  • Responsible for product vision. 
  • Manage product backlog
  • Prioritise product backlog
  • Participate in customer journey mapping / story mapping sessions
  • Develop and maintain a product roadmap
  • Participate in release map - which epics go where.
  • Epic prioritisation
  • User story prioritisation
  • Clarifying business priorities, functionality
  • Being available for the development team to answer questions. 
How do you collaborate with Scrum Master or other team members?
  • The best way is to collaborate through Scrum values - commitment, focus, courage, openness, and respect. 
  • Both the PO and SM roles are leadership roles. PO owns the product vision and drives the team towards achieving it. SM supports it thru an actionable sprint backlog. PO is there to support the team in making the goals and vision understand, clarify on the user story functionalities, expectations, etc. 
  • PO teams up with SM for release planning, sprint planning, MVP, etc. 
What is a Product?

Product is a vehicle to deliver value to the customer. It is something physical created thru a process and benefits the customer and market. 

What is a Product Roadmap?

A product roadmap is the visual summary of the development of the product - what features the product will have in the coming months, years. It captures the vision and strategy of the product.  

What is Product Vision?

A product vision is the PURPOSE for product development -- Why the product exists, why it is being created, what it aims for. It is a goal for your product. It should be clear, concise, and appealing. Something that will have a buy in from the team. 

Product vision helps creators stay focused as they experiment with their ideas. 

It is a North Star and stays high enough to remain largely "Unachievable". If the goal is reached reasonably early in the journey, we would consider it too tactical - no longer a vision. 

1983 -- Toyota (Eiji Toyoda)
|
|
|
|
Build the best Luxury Sedan in the world, in the first attempt ! (Vision for car)
|
|
|
|
Engineering specs were, based on the product vision
|
|
|
|
155 mph
22.5 mpg fuel economy
Aerodynamic drag coefficient of < 0.3
|
|
|
|
After 6 years, Toyota came out with LS400. 

> The vision should be aspirational
> The vision should be provocative
> The vision should inspire everyone in the team
> Without prescribing how we go about it

What are the characteristics of a good product backlog?

D - Detailed: It should be appropriately detailed. Those at top of the backlog have more details (these are the stuff that will be completed in the upcoming sprints). And those at the bottom have less details. 
E - Emergent: Product backlog is not static. As more details emerge from product discovery, the form and shape of the backlog will change. User stories will be added, modified, deleted as appropriate. 
E - Estimated: The user stories in a backlog are estimated in story points. 
P - Prioritised: The backlog is prioritised with the top ones in the backlog having higher priority than the bottom ones. 

How are product vision, product strategy and product road map related?

Vision-->Goals-->Strategy-->Roadmap

What is a good user story?

INVEST -- 

A good user story should be
Independent
Negotiable
Value
Estimable
Small
Testable

What is the difference between Product Manager and Product Owner?


What are the techniques for backlog prioritisation?

We have used the MoSCoW (Must Have, Should Have, Could Have, Won't Have). 

What are the characteristics of a good product owner?
  • Good leader
  • Knowledgeable
  • Conflict resolver
  • Good negotiator
  • Researcher
  • Good decision maker
  • Efficient communicator
As a product owner what will be your responsibilities?

> Represent customers and stakeholder needs
> Creating and managing the product backlog
> Coordinating with the development team
> Communicating status to the stakeholders
> Managing team economics and participating in various meetings
> Ensure transparency into upcoming work for the team

What skills do you have to become a PO?

> Good communication skills
> Always reliable and available for team
> Commitment towards team and work
> Knowledgeable

When do you think Scrum is not advisable?

There could be cases where scrum may not be the right methodology / framework or fit. A few cases listed below:

> Environment is not complex.
> Requirements are not emergent. They are kind of static and no product discovery is needed. 
> Stakeholders don't accept changes to backlog.
> Stakeholders don't agree that the things we learned about the product in the sprint is going to affect the backlog.
> There is no way to deliver an increment at the end of a sprint. For example there are some infrastructure projects where the lead time is couple of if not several months. 
> Teams are not empowered or not able to self-organise and self-manage. In such cases, organisations want to have a say in what and how a team does or delivers something.

Q. What experience and qualifications have you got as product owner?

I am a certified scrum product owner (CSPO) from Agile Alliance Org. I have played the roles of PO in a few projects (SM-PO sort of roles where both roles were wrapped into one). My role was to primarily elicit requirements from the business and feeding them back to the team, commit on the timelines with business, team up with development teams for delivery. Run sprint review sessions, and review Done criteria for each US. Run the sessions with stakeholders to give them an update on the latest. 

Q1. What experience do you have in stakeholder management?

Test and Test Management --> Client / customers
Process and Tool consulting --> Sr. management, tool vendors, business (funding departments), governance teams, auditors
Scrum master / PO --> Customers, users, development team, scrum master, UX designers, service designer, six sigma champions, senior management, delivery heads, agile coaches, etc.
Change management --> development teams, infrastructure teams, release management teams
Incident management --> Client, vendor infra teams, other third party.

Q2. How do you deal with a tough client / customer. 

Tough or problem clients are a necessary evil - we can't live with them, we cannot live without them. :-). They fund our initiatives, but sometimes can be hard to deal with. 

Some reasons why we have hard time with them:

1. Price sensitivity. The business stakeholders have a hard time in understanding why we charge how much we charge. They think it is super easy and shouldn't cost so much money. 
2. ROI - they also have a hard time understanding the ROI on what we do. Sometimes. 
3. Endlessly tweak requirements leading to scope creep. While the fact that requirements can be emergent is nice, frequent tweaks or changes, especially in-sprint changes and requests to accommodate can be real pesky. That can cause tremendous amount of work, over-work or revision that hurts the development team. As PO my responsibility will also be to ensure that there is no dev-team burnout. 
4. Design by committee. That is way too many stakeholders deciding the outcome of product development. 
5. Stakeholders are not aligned with each other. 
6. Stakeholders can be controlling. They can try to influence what it is that you are doing. 

So, how do you manage tough clients?

Something that has worked for me in the past is this:

1. First listen to the client. Empathise. Let them speak (Listen more than you speak). Let them tell you what the problem is. While they are telling you, use effective listening skills to make them understand that you are lending a patient ear. 
2. Ask them probing question. Get to the bottom of what their issue is. What are their needs? Try and build up a common connection. When you are able to make a common connection, it is more likely that you are able to come out successfully from the discussion. 
3. Come up with a solution for their problem. Confirm with them if they are happy with the solution. 
4. Touch base a day later to check if they are still happy with the solution. 
5. Look for ways to ensure this is not repeated / improve thru feedback to stop recurrence. 

NEVER GET IRRITATED OR FRUSTRATED WITH THE STAKEHOLDER

Note

also think about 

Co-creation. Your client may want to get involved deeply in what we are doing. Do we have to let them? Clients may think what we do is easy. By co-creation, we let them have a peek into what we do so they are able to better appreciate our work. It improves and increases respect for our skills, and they are part of our process. While giving a sprint demo / review for example touch on the pain areas we have addressed and things that we have surmounted to develop the feature.

Clear decision making criteria. Who are the stakeholders who are making the final decision, and the criteria they will use to make the decision. 

Q3. How do you manage internal team issues?

> Conflict should be resolved ASAP. If we ignore, it will get bigger and would lead to something else serious. 
> First thing to do is to encourage the co-workers to resolve the conflict amongst themselves. They should have the maturity and professionalism to recognise that the organisation has to come first, the needs of team have to come first so they have to sort it among themselves. 
> Sometimes even by mentioning that such and such conflict exists is enough to encourage to sort it out. 
> If it doesn't get resolved, I would then speak to both of them. Will facilitate the conversation and help them resolve. Fair without taking sides. Speak to them consistently. Make them understand the repercussions of this fallout and the effect it has on the team. Remind them of their responsibility. 
>  Get them to work together on some important piece to build the relationship. 

Q4. How do you deal with resource crunch? How are you going to mitigate the risk?

Resource crunch can happen due to various reasons:
- Same resource has multiple skills and picks up multiple tasks in the project. (This can be easily managed)
- Same resource is deployed in multiple projects.
- A resource goes on an emergency leave
- A resource leaves the company.

So, effectively absence can lead to short term or long term availability issues. 

Short term
-------------

Short term is relatively easy to manage. Have a technical discussion with team to see if the team to understand the impact, to know if it can absorb it. If the team cannot, then check with team and stakeholders to understand how we can adjust the sprint goal accordingly.  

> While planning we always ensure we have 15-20% slack / buffer time, that is while planning we plan for only 85% of the team's time. I typically plan for 6 hours per day per resource - 25% slack time [Slack is added for emergent design, refactoring. We can use this slack to absorb urgent needs].

The options therefore are:
-- Squeeze it into the current sprint. 
-- Throw it into the backlog
-- Carry it over to the next sprint
-- One item, in, one item out.

Typically a PROGRAM EPIC is delivered in say 6 sprints. Then the PO has a say on what should happen as only until the 6th sprint is delivered, does the customer see a value delivered. So we may not be able to deliver value in the current sprint but sill certainly aim to deliver in the next sprint.

Long term unavailability
------------------------------

> With long term unavailability, we know the replacement-resource isn't going to be available for quite some time. Speak with another team to understand if they can spare a resource. 

> Adjust the team velocity in the next sprint accordingly. 

> We may not be able to deliver the sprint goal in the current sprint, however we can deliver it in the next sprint. 

Points to ponder when having discussions about unavailability
---------------------------------------------------------------------------

> Analyse and understand the impact of the resource unavailability. What has been affected, how much will that affect the delivery? What is affected, what else will be affected? What impact does it have on other piece of in-flight work? 

> When the team prepares the team charter / ways of working / or working agreement, ensure to have a remedy as to what should happen if one of the team member is unavailable and has to leave all of a sudden. Will there be a handover possible, what other mitigation steps are possible? This addresses one of the scenarios above. 

Q5. What if customer comes in the middle of a sprint and forces you to take up some urgent work?

> Project runs healthy when people are not burnt out, and the customer / stakeholder is also happy. This is the end goal we try to achieve. So, when we have a customer or business that is insistent on pushing more work, we have to understand why it is so. What exactly is prompting the customer to act that way. Mutual empathy should help. Go to the stakeholder / customer and first understand the need. 

> One of the principles of Agile is also customer collaboration over contract negotiations. We co-create stuff. Software delivery is no longer a Pizza-delivery service where someone orders a particular style of pizza, and then in the end the pizza is delivered. There's a lot of co-creation that is needed; active and early feedback is required. 

> Urgency also depends on which phase the project is in -- is it too early into the project, then it can be absorbed. If it is too late into the project, then no matter what it cannot be accommodated.
  
> Have a chat with technical teams. Understand the technical feasibility - Why it CAN be done? Why it CAN'T be done?

> What is the impact if it is picked up?

> If there is a possibility, then I surely will. If there isn't one, then it is a firm NO. 

> Talk to the customer and help them appreciate the team constraints, yet also identifying the need and see what best can be achieved without the team getting burnt. If it is a high priority work, for example the Covid riders we added on the insurance policies recently, then it is something that MUST be done no matter what. That is business criticality which can't push back. Even if it means the team works 15 hours. That is a one off and should be okay.

> Software development is a create process that requires collaboration, so pushing or bargaining doesn't help. Mutual empathy and realisation of needs helps solve things. 

> Difficult to run the show without transparency and trust.   

Q6. Do you have DW experience?

I have experience in Core Java development, VB, Oracle, SQL, Linux, XML, XSLT, XPath etc. 

Q7. Why do you think you fit in SO role than in SM role?

> I have done both SM and PO roles. 
> I have dealt with different kinds of stakeholders (People who have purse string in their hands).
> I am good with negotiations
> I can deal difficult situations. 
> I can deal with people of different mindsets
> I can protect my team in difficult situations without irking the customer

Q8. Where's your PO experience?

> SM/PO roles in Airbus
> Unix-based project, and a vendor management application (Starlings)
> Interact with multiple stakeholders for requirement elicitation. 
> Working sessions with team to get estimates
> Agree on estimates with stakeholders and commit to it
> Risk management

Q9. Do you have banking experience? How are you going to manage if not?

I have experience in the insurance and finance. Worked with Toyota Financial Services and with IAG in the recent past, so I think I have the analytical skills to understand the Banking domain quickly. I am a quick learner and would probably be comfortable within 4-5 weeks.

Q10. What is a Data Warehouse?













Data warehousing is the process of Data Collection (from multiple sources) and Storage from various sources and Managing it to provide valuable business insights

Steps in DW: Extract, Load and Transport [ETL]

1. Extraction of data: 
2. Cleaning of data: 
3. Conversion of data: 
4. Storing of data in a warehouse: 

How do you deal with NFR in product backlog?

NFRs or non-functional requirements such as security, reliability, performance, scalability, usability, etc. There are three ways of capturing the needs:

1. Write them as user stories - The website should be able to upload within 3 seconds.  
2. Write them as acceptance criteria. Given the User enters the username and password, when s/he clicks Enter, the Home page should load within 3 seconds. 
3. Write them as DoD - Home page loads within 3 second. 

How do you deal with Tech Debt in backlog?

We write user stories for Tech Debt, though intent is to capture technical details. We write acceptance criteria as well. Example is Clean up all the XMLs where Vehicle Type is no longer acceptable (results in a claim denial).

How do you deal with Spike in backlog?

Spikes are also written as user stories and all technical details captured within it. Upgrade Java to version 15.0 and investigate which modules of the application are affected. 

What are some of the challenges of a PO role?

> First and foremost is balancing the time between the product manager / business stakeholders and the development team is not easy. 
> Estimation of Epics / Features and committing to a particular date isn't easy, and often there's a slippage. T-Shirt sizing may be easy, but putting an hourly/day-estimate to it won't be accurate. 
> Changing priorities during sprints are always challenging. 
> Over a period of time the product backlog becomes quite bulky. Going thru the backlog, keeping track of the user story / feature / epic and its purpose is difficult. 
> Multiple-stakeholder alignment. Each stakeholder has different priorities and objectives for the product, which may lead to competing visions and directions for the product. 

SM Interview Questions

  • What do you understand by Psychological Safety? 
Psychological safety is where team members feel comfortable taking risks, sharing ideas, and expressing concerns without fear of judgment or reprisal.
    Agile teams need a conflict of a different kind - a healthy conflict. The ability to express their disagreement or differing opinion in a way that leads to a better decision making. 
      • WP, entire teams were summarily dismissed upon faulty or failed production deployment. This became a practice leading to serious job concerns.
      • Never ending restructuring in WP leading to psychological safety & health concerns because of proloned uncertainty. 
      • In AAG, there was this guy, a very senior, who had the expertise, depth of knowledge, and yet a curt, unforgiving, and no-margin-for-error or first-time-right kind of. Business analysts, developers and testers were scared of approaching him. The fact was it never came out in the open during the retrospectives nor at any time in between or thereafter. Not until the final project post-mortem / retrospective. Clearly it was a case of psychological safety where colleagues weren't comfortable sharing their opinion, or view or in a way were muzzled, muffled by fear of judgement. 
    • How do you empower people to speak out?
    > Why don't people want to talk - i could get into a trouble, i don't want to mess up the current team dynamics, i don't want to make a political enemy, i don't care about it, or i am hopeless about it. There could be multiple reasons. Speak to the team and try to understand which of these is it. Hopeless problem or "i don't care" is a much bigger problem. Who's losing it because of this dysfunction. People may think they are not losing it so "who cares". 
    > Start with "why are people not bringing this out in the public?"
    > Next try to understand the impact of it. 
    > Fear --> try to address it, "I don't care" try to see what can bring in the care, show things can work if proper attention is directed and things are willingly addressed.
    > Quantify and make the impact visible (run Retro to expose these issues). 
    > Look for opportunities when these things surface. Pick up one such opportunity and bring in to discuss.
    1. Self organising Scrum Team
      1. Self organisation: A self organising team is one that doesn't have to wait for a manager to allocate work, instead they manage their own work and associated responsibilities and timelines.
      2. For a team to be self organising, they need to be collaborating, responsive, empowered, flexible / change driven, 
        1. In AAG, nobody waited for another to allocate work. The product backlog was prioritised, and the developers picked up from the top once they were through with their in-flight work. Likewise the testers picked up from the ready to test stream.
        2. SM enables team self manages and resolve their own conflict. 
      3. Cross functional
    2. How do you manage Scope creep in Agile?: In the classical ways of working, scope creep was when a team has agreed to build a piece of software for a given price in a given time frame and then the business changes their mind of what they want, and they ask the team to do something outside of initial agreement. Yet business needs change. In agile, it is not scope creep when you are asking before the team has started to think about the details. It is not scope creep if it doesn't create additional work for anyone. 
      1. It will be scope creep if stakeholders want to swap new work for work already done. 
      2. It would be scope creep if stakeholders want to swap something big for something small. 
    3. How do you ensure productivity in Agile?
    Team productivity is a classical project management approach to ensure people are "productive", they are working 100%, are billing 100%. 

    People work better when they know what their goal is and why! Agile ensures transparency due to which people know their sprint goal, product goal, product roadmap and the product strategy behind all of it and how it ties with the product vision. 


    1. Not consistently delivering - velocity
      1. There could be multiple reasons why teams are not delivering consistently, or delivering small - Team composition and skill sets, extent of team collaboration, effectiveness of communication to clear barriers, scope change, technical debt. etc.  
      2. In AAG, for the first few months, the velocity was abysmal. The business complained. Fact of the matter is the application was extremely complex, the code itself was old and complex too, so the dev teams took a while to surmount the learning curve. Over a period of time, what used to be a less than 30 story points, picked up momentum and the team started delivering an average of 60 story points per sprint. 
    2. Common Antipatterns I came across
      1. Line managers are attending daily scrum. This has created performance pressure.  
      2. Project manager attends the daily scrum and gives instructions. 
      3. Account manager (of vendor delivery team) attending scrum, and making space for comments, offering advise, etc. 
      4. Project manager running the estimation session. 
      5. Absent PO, or partially available PO. 
      6. Un-empowered PO
      7. Moving user stories from one sprint to another; not really committing to sprint goals. Flexible sprint goals repeatedly.
    3. Forming, Storming, Norming, performing
      1. Tuckman's stages of team development. 
      2. Forming - little agreement, unclear purpose
      3. Storming - Conflict, increased clarify of purpose, power struggles
      4. Norming - agreement and consensus, clear roles and responsibilities
      5. Performing - clear vision and purpose
      6. Adjourning - task completion
    4. Agile mindset - based on the 4 values and 12 principles. 
      1. Respect
      2. Collaboration
      3. Continuous improvement
      4. Focus on delivering value
    5. 4 values and 12 principles of Agile
      1. 4 values
        1. Individuals and Interactions Over Processes and Tools
        2. Working Software Over Comprehensive Documentation
        3. Customer Collaboration Over Contract Negotiation
        4. Responding to change over following a plan
      2. 12 principles
        1. Customer satisfaction through early and continuous software delivery
        2. Accommodate changing requirements throughout the development process 
        3. Frequent delivery of working software
        4. Collaboration between the business stakeholders and developers throughout the project.
        5. Support, trust, and motivate the people involved
        6. Enable fact to face interactions 
        7. Working software is the primary measure of progress
        8. Agile processes to support a consistent development pace 
        9. Attention to technical detail and design enhances agility
        10. Simplicity
        11. Self-organising teams encourage great architectures, requirements, and designs
        12. Regular reflections on how to become more effective
    6. How big was the team, was it collocated? 
      1. 5 developers, 2 testers, 2 BAs. Distributed.
    7. Any specific rituals?
      1. Project kick off / user story mapping
      2. Daily stand up, sprint review, sprint retrospective.
      3. Backlog refinement (Once a week 2 hours). 
      4. Sprint planning.
      5. User story hand over sessions (BA).
      6. 3 Amigos for specific user stories.  
    8. How do you prepare for sprint planning sessions?
      1. Conduct weekly backlog grooming sessions (Wednesday's). With PO / BAs, team. This ensures the backlog is prioritised, and estimated.
      2. Refer the roadmap and see how the delivery is going, something needs to be included etc.
      3. Calculate sprint capacity based on team availability (leaves, resignations, etc.).
      4. I usually prefer a prepared PPT deck with all the information. 
      5. Refer to Jira and see the progress of in-flight tickets. 
      6. Finalise the sprint user stories, and sprint goal. 
      7. Commit to the sprint.
    9. Some live examples of sprint goals.
      1. When we trigger hailstorm alerts, the SMS alerts are sequenced and sent to customers. 
      2. Referral trigger and referral suppression work as expected. 
    10. What tools have you used for sprint management?
      1. Jira, Confluence, MIRO for user story mapping, Fun retro, Pointingpoker.com for estimation
    11. Walk thru of scrum demo / review session.
      1. Schedule it on the last day of the sprint. 
      2. Attended by PO, Business and important stakeholders as required. 
      3. Have a pre-planning meeting with the team on what will be showcased, who will showcase, and how will they showcase. 
      4. Starting of sprint review a quick overview of what is being demoed, etc. 
      5. Then the sprint demo / review takes place and feedback sought. Feedback is taken and incorporated for planning.
    12. Retrospective formats I have used in the past:
      1. What worked, kinda worked, and did not work
      2. Sad, Mad, Glad
      3. Hot air balloon
      4. Boat - what propelled you, what held you back.
      5. etc.
    13. Retrospective
      1. Go thru the previous action items
      2. Run the retro
      3. Identify and capture action items, person responsible for the action and commit on a date.
    14. High-performing scrum team - AAG
      1. Collective ownership
      2. Cadence / frequent releases.
      3. High velocity
      4. Highly skilled technical, cross functional teams.
      5. Commitment to sprint goals
      6. Trust and mutual respect
      7. Continuous learning
      8. Self organising
      9. Clear understanding of where their work fits within the organisational context
      10. Understanding and acknowledging the release dates
      11. Clearly defined roles and responsibilities
      12. Personal excellence
      13. Healthy conflict (this was missing)
      14. Psychological safety (this was again missing).
    • There is a senior guy who keeps information to himself, is uncooperative; how will you tackle him?
    • Team does not feel motivated. How will you deal with the situation? OR How do you motivate your team?
    > Get to know the team
    > Understand what they are passionate about
    > Understand how they want to be recognised
    > Tap into people's intrinsic motivation.
        > > Give people control over their work
        >> Provide opportunities for challenges and mastery (Hackathons).
        >> Aligning their work with a higher purpose
    > Speak to senior management to see if something can be done. We gave away AUD 100 and AUD 25 during the past one year as a way to keep team motivated.
    • There are a lot of defects coming up. What will you do?
    > Gather data to understand where exactly the defects are coming (Module / specific functional area, part of the code, which environment, etc.). Do a root cause analysis.
    > Speak to PO. 
    > Try to see if automation is there and is effective. 
    > Come up with a strategy to deal with the defects.
    > Implement the solution, track and monitor to see improvement.
    > Get an understanding from PO whether she's okay with it. 
    • How would you handle a new team?
    1. Understand Stakeholders
    2. Deploy / activate process
    3. Understand technical side of things
    4. Understand business side of things
    5. Focus on being agile

    Understand stakeholders
    --------------------------------
    There is a key need for myself to be able to be accepted by the team, secure their trust and goodwill. I will first embed myself into the team and observe the team members. I won't start with anything agile yet. This exercise will tell me a lot about the current team dynamics, their motivation levels, expertise, what will and won't work for them, etc.  

    I will then set up a one to one (recurring) and try to know them, their interests, motivation, expectations, etc. 

    Deploy / activate process

    > Team up with the Agile Coach to understand and implement the organisational framework
    > Set up learning sessions
    > Define the type of agile you want to implement, define the sprint length (for Scrum)
    > Establish and run the key scrum events (Scrum) or other events (Kanban, etc.)
    > Set up a working session and come up with Team Playbook / working agreement. 

    This will consist of 
    -- How the team members will work together. 
    -- What time will the stand up happen?
    -- What will be the modes of communication
    -- How will you let you know your availability thru Teams or another collaboration tool?

    > Set up Jira and other tools
    > Ensure team is "Doing" agile

    Understand technical side of things

    > Understand the technology, tools, etc. 
    > Understand the project from technical side of things

    Understand business side of things
    > Thoroughly understand the business processes and business side of things required for the project

    Focus on the Being part of agile

    - Focus on team developing an agile mindset - team should be able to cultivate the Agile Mindset which is critical to success of agile development
    - The three pillars of Empiricism are - Transparency, Inspection and Adaptation
    • What are some of the common agile metrics you have used?
    > Velocity
    > Sprint burndown
    > Epic and Release burndown
    > How frequently do you release to production?
    > Defects in Dev, SIT and UAT
    • What is your typical daily schedule?
    > I start of early 8am within city, 8:30 north sydney.
    > Catch up with the defects, Jira and dashboard
    > Catch up with all emails, production alerts, failure alerts, etc.
    > Interaction with the team
    > Running the standup
    > PO / BA catch up based on need. But BA catchups are quite frequent.
    > Upstream, downstream, dependency checks with other teams
    > Change, release checks
    > Preparation for scrum of scrums
    > Preparations for ROAM
    > Preparations for community of practice
    > Preparations for weekly dashboard reports
    • How have you mentored and coached the teams?
    Mentor is a trusted guide, a wise counsel. Someone skilled in a specific domain. I am in the Agile ways of working. There have been occasions in the past where a new team was totally new to the story point estimation; they required training as well as some kind of hand-holding / mentoring. 
    • What are the various roles of a scrum master
    > Teacher
    > Mentor
    > Coach
    > Facilitator
    • What are the key challenges you have faced as a srcum master
    > People are unwilling to change. / > Don't get a buy in from the team. Have one-on-one to understand what motivates each. For example in AAG, there were a few highly skilled resources who have been in the org for 15+ years and absolute masters in their field. They needed a way to express their talent and skill. Hackathons provided a good opportunity for them. They contributed, and stayed motivated. 

    > Avoid overly long sessions. Team decided not to have any meetings more than 2 hours at a stretch. Intersperse with fun activities. 

    > Coffee talks and lunch outs / lunch talks. Coffee catch ups were a regular feature; occasionally we encouraged people to join remotely over lunch for unofficial chat. 

    > "Hurt the butt" catch ups on Fridays. CTP team. Intent was to hear from each member what was it that hurt them most (in terms of the project) during the week. What was it that was the most challenging and left them exasperated / fuming. Conversely, one could also discuss what was it that overawed them too.  

    > Sometimes due to lack of transparency, especially during restructuring, there are concerns and apprehensions about jobs / role redundancy. (Give Telstra example)

    > Tech lead doesn't listen, is not supportive, and bosses around. Personally, I don't like to have a hierarchy within my team. However, there may be situations where there is a need to have a tech lead within the team in some companies, just as they would like to have a test lead or an automation lead. So, I had this big-ego guy that sort of derailed every stand-up because of his unavailability. Realised this soon after I joined the team; after a few days, had a personal chat with him to understand his situation. Turns out his spouse was carrying and he therefore had to get the kid readied, drop her off at the school and do a bunch of other chores at home. That meant, he had little time, and if he did, was much constrained for the daily stand ups. We tried if a remote call would help. Soon after we realised that wasn't working. The only option was to again check with the PO to see if we could instead push the standup to 11:30 against the company practice. It was a one-off and we had our fair reasons. The PO heard, empathised and was in all support. 
    • Product Owner / Business is forcing to push more work, or pick up more user stories, or increase the velocity
    > Project runs healthy, people are not burnt out, and the customer / stakeholder is also happy. This is the end goal we try to achieve. So, when we have a customer or business that is insistent on pushing more work, we have to understand why it is so. What exactly is prompting the customer to act that way. Mutual empathy should help. Go to the PO and first understand the need. 
    > Talk to the PO and help them appreciate the team constraints, yet also identifying the need and see what best can be achieved without the team getting burnt. If it is a high priority work, for example the Covid riders we added on the insurance policies recently, then it is something that MUST be done no matter what. That is business criticality which can't push back. Even if it means the team works 15 hours. That is a one off and should be okay.
    > Software development is a create process that requires collaboration, so pushing or bargaining doesn't help. Mutual empathy and realisation of needs helps solve things. 
    > Difficult to run the show without transparency and trust.  
    • Example of Epics and user stories from your recent past
    Epic = Reporting
    US1 = Cover report
    US2 = Referral report

    Epic = New Business, Endorsements, Renewals, Cancellations, Mid-term Alterations
    US1 = Create NB
    US2 = Update NB

    OR

    Epic = July Release
    User stories = a bunch of related user stories that need to go as part of the Jul release (BAU situation).
    • What are the improvements you have done in your agile team?
    > Improvements are always team effort, especially so in Agile. Communication, coordination, balance of team contribution, 
    Increased productivity. Beginning of the project velocity was 30 to 35 story points. After 6 months, production was averaging at 70 story points. 
    TDD / Test first approach / shift left. Team made it mandatory to start with automated testing first approach, as well as a shift left with testers pairing up with developers during story development - coming up with scenarios, writing DROOLS Business Logic, as well as regression scenarios and test cases for the user story such that by the time the user story was ready, the tests were ready as well. 
    >  Increased focus on technical debt. We took a pause to understand reasons for increased build failures, longer set up times, frequent environment failures etc. Then reworked on improving / moving modules, changing configurations, etc. to ensure the application was faster, reduced the number of regression tests / optimised the regression suite, and also stabilise the application set up. 
    Wilful participation in hackathons to ensure the motivated members of our team are able to exercise their skills in organisational innovation. 
    Ensure team learnings / tranings are always captured / recorded and archive them for posterity. And capture technical changes / configuration changes etc. on Confluence for similar reasons. 
    • Project team is consistently failing to achieve sprint goal. How do you manage this situation?
    When answering acknowledge that this is a hypothetical situation as you don't know anything about the team as such. Also there could be several reasons or a bigger problem lurking behind this symptom. 

    > Two possibilities - I am new to the scrum team, and the second situation is I am already a scrum master in the team. 
    > When I am new to the project I wouldn't know the history of the project. Was this already recognised as a problem in the previous sprint retrospectives? If yes, what was the outcome of those retros and what has the action items led the team to? If not, then ensure we have a retrospective where these items are discussed. 
    > Over-commitment could be a possibility. PO pushing and the team agreeing could also be a possibility. 
    > Manage WIP. Pick up moderately with clear stretch goals identified. Don't over commit. 
    > There could even be inter team dependencies that could have led to this situation. 
    > Retros will identify such issues. 
    > Agree with PO on definition of ready - take only those items into the sprint that have their dependencies resolved in the previous sprint. 
    • PO is allocating the work and pushing team to complete work.
    > PO may be unaware of agile ways of working. Have a chat and clarify.
    > PO is not confident as the team has been faulting on delivering the sprint goal for the past few iterations. 
    > PO may want to experiment a particular feature and as a one off wants team to deliver. Again have a chat with PO, understand the priority, intent and how, what and when deliveries need to happen and decide accordingly.
    > PO may be having a push from the business to deliver, we don't know. Again, have a chat with PO to set expectations. 
    • How does your playbook / working agreements look like?

    • How do you tackle conflicts within your team? Especially during pandemic situations. Example team availability, as every person may like to work at different times.
    > Agile is a process of co-creation. You will need to cooperation and collaboration of other team members, their guidance, their availability to complete your part of the task that ties to the larger piece of work. It is therefore imperative to be able to work during similar times / with overlaps. 
    > If work times, next day schedules are becoming unpredictable, then 
    > Revisit working agreements. (as there is no office environment anymore).
    > What happens when someone takes an emergency leave. How do they communicate, handover etc. 
    > How do you communicate on the common channel your availability - when you log in, when you log off, when you are away, etc. etc.
    > When to call, when to WhatsApp, etc. 
    > This way it is more predictable for others as well as they are aware of specific unavailabilities. 
    • One of the team members is lying about estimates. Worked for few hours but estimated for a couple of days. How do you deal with this?
    > Use transparency as a team.
    > Is the work item available to everyone?
    > Use sprint planning / estimate as an effective tool.
    > Create an environment where people challenge one another.
    > If a particular person is always taking more time than others for his piece of work, have a conversation to understand why. Is it lack of understanding, lack of skill, etc. etc.
    > Does developer pairing help? Check and see.
    • How to increase team velocity?
    > Velocity is an observation rather than a target. 
    > If there is a stability, then work is predictable. That there is no variability left. 
    > Find out reasons why.
    > Why is there a consistent velocity.
    > Are some contingencies planned. (team might be adding contingencies in their planning).
    > Complexity, tech debt, or defects could decrease the velocity. Ensure the discussion is able to capture the reasons why and let the team plan for how to.
    • If you are helping move a team from waterfall to scrum, how will you ensure they don't end up continuing to do the same old way of working?
    > Either pickup a hypothetical scenario or can bring in something from experience. 
    > In TFS, there was this project manager who used to manage the same project which has since moved into an agile way of working. Now this person would attend daily stand ups, start dictating terms, and demand answers from the team, tech lead, etc. 
    > Have a conversation.
    > There was also an independent testing team, a third party which was different from the client, and the vendor development team. 
    • How would you handle an old team vs. a new team / If you onboard, what are you going to do - you have two teams - one is new and another is old. (new is totally new to Agile, old has been on it for quite a while and good at it).
    New Team

    > First thing to do is to gain their trust and respect. To be welcomed into their fold before embarking on any improvements. It will take a while though. For this I will have frequent individual catch ups (I prefer individual one-to-one every week and then move to fortnightly until the team is stable), set up coffee catch up sessions, lunch catch ups if the team is willing. Ensuring some Team Building activities - Book or Technology Club, "What Sucks" catch up on fridays, etc. 
    > Observer how things are going.
    Gather information on team skills, competencies and who's on what and how it all fits together
    > Catch up with all stakeholders to understand the expectations from the team - business, product owner, service owner, and any other stakeholder. 
    > Catch up with product owner frequently
    > Catch up with technical lead frequently
    > Start with working agreements. How, when, what etc. etc. This will also set up expectations as to what the team can expect from me, my functioning style -- Meetings, Mode of communications, sprint events, length, participation, how do we let know our availability, leaves and emergency leaves. management expectations from the team, etc., definition of done, definition of ready, etc., any other business.
    > Agree on Scrum / Kanban, length of sprint, etc. 
    > Introduce the organisation framework and the expectations from the agile transformation team. Probably also include the agile coach or let her drive this (maybe).
    User story mapping - May have epics already from the program team OR facilitate customer journeys to flesh out the features and epics. 
    > Set up Jira board.
    > Set up team events - daily stand up, sprint backlog refinement sessions, sprint planning, sprint review and sprint retrospective. Also consider story hand over sessions, 3 Amigos. 
    Get a detailed domain and technical deep dive into the project
    > Run the show

    Existing team

    > Same starting stuff as before. > First thing to do is to gain their trust and respect. To be welcomed into their fold before embarking on any improvements. It will take a while though. For this I will have frequent individual catch ups (I prefer individual one-to-one every week and then move to fortnightly until the team is stable), set up coffee catch up sessions, lunch catch ups if the team is willing. Ensuring some Team Building activities - Book or Technology Club, "What Sucks" catch up on fridays, etc.
    Understand and reflect on the team competencies, skills, number or resources, etc. 
    Frequent stakeholder catch ups - product owner, business, tech lead and other key members.
    Take a look at the recent retrospectives to understand some existing team issues. 
    > Observe, ask, and reflect on what the team is achieving and where it is headed. 
    > Two competing interests would be to apportion time between project work and business as usual work. 20% 80% is okay, or based on the work what percentage on which work will work best for the team. Have a discussion around these and let the team decide. 
    Get a detailed domain and technical deep dive into the project
    Arrange for the scrum events and calendar them up. 
    > Run the show
    • What is the difference between product backlog refinement session and the three amigos?
    > BA writes user stories in conjunction with PO and stakeholders
    > When complete it is put fwd to 3 Amigos
    > BA + QA + Tester discuss and US is fine tuned
    > Then goes to Backlog refinement and sized accordingly after further dicussions.
    > Goes to planning session, picked up for sprint.
    • What motivates you?
    > Learning (new things).
    > Challenges (are like puzzles)
    > Social and intellectual discussions

    Which three words best describe you?

    > Methodical
    > Empathetic
    > Go getter
    • Only when a bunch of your user stories are combined do they deliver value. Each user story doesn't. Is it right to bunch them up so they deliver value?
    Scrum expects that each iteration has an sprint goal. And that iteration probably might have some business value. Nowhere is there an expectation that each user story should deliver business value -- User stories should be DEEP and follow INVEST. Each increment can. Bundling user stories together increases their size, which many not always be possible to deliver in the same sprint. 

    There may be a possibility that your sprint does not have a sprint goal, which defines the business objective of that sprint. 
    • How do you handle absence in scrum?
    > Team playbook will probably give a clue about how to deal with the situation. 
    > When coming up with team playbook / working agreements, consider the scenario of what happens if someone within the team goes on an emergency leave, or quits. How should the team ensure there is business continuity?
    > Discuss first with the team if that user story being worked on by the member can be absorbed as part of current sprint.  
    > Also identify other impacts of the emergency absence. 
    > If the team cannot absorb the work, discuss with PO the subsequent options. Is it okay to push the item to the backlog? If not, should the team pick this one up and accordingly drop a similar size item from the backlog?
    > Each planning should ideally plan for contingency - about 15% of time. (based on the available hours).
    > Some people use focus factor (ratio of story points to actual hours).
    • Team is trained in hours to estimate work. As an SM how will you coach the team to use story points. 
    > Quite common for teams in waterfall and those moving from waterfall to agile to estimate in hours. 
    > Estimating in hours is absolute estimate. It's a known fact that we humans are pretty bad in estimating. We are either over-estimating or under-estimating things. 
    > In agile we focus on relative estimation. It's much easier for us humans to relatively size something with respect to something else. 
    > The central essence of agile is to release a new feature quickly and be able to get a feedback on it. And this goes on indefinitely. Essentially we will end up with a fixed cadence where we are able to consistently deliver with an x amount of work. That x is often the story points. 
    > In agile we also ensure that we prioritise the user stories such that anyone in the team is able to pick up an item and work. 
    > When using hours, each person may take different completion times, therefore what we capture as part of the user story (hours) may not be relevant to all. Consequently, it's easier for team to agree on and work if there is a relative estimate such as story points. A 5 pointer might mean (within the mind of a particular developer) 5 working days, whereas for another it could mean 3 working days; however both agree that it is a 5 pointer. 
    > Absolute estimation works for items that are similar to tasks that have already been worked in the past. For new items, it's much difficult to estimate how long it takes to completion. 
    • There is a request from delivery head to extend the length of the sprint from 2 weeks to six weeks. How will you deal with such a situation?
    > It's clear the delivery head understands the spirit of agile. Or what a cadence means and why it is important. 
    > First go and speak with the delivery head to understand why the request is coming from him to extend the sprint length.
    > Explain cadence and the reasons based on which you had decided that the sprint length should be 2 weeks. 
    > Make him / her understand the organisational cadence / or the cadence of teams in a release train or within a release (if not using SaFe) and why it is important to adhere to a fixed cadence at organisational level.  
    > If the delivery head relents, good. Else, speak with the PO and arrange for a common forum with the delivery head, PO, and the business stakeholders and take it up from there. 
    • As an SM, how will you ensure all your events are running fine? How will you train your team?
    By identifying anti-patterns in the sprint events. These are deviations from the expected. 

    Sprint review
    > Sprint review is not sprint Demo. This is not a demo. The intent is to showcase to get feedback from customer / business (INSPECT) and then take a look at the product backlog to see what has changed / been requested, add / delete / modify (ADAPT) based on the sprint review.
    > Sprint review is not done. 
    > Sprint review is conducted as a reporting session - thees many user stories, these many bug fixes, how much money was spent etc. These should not matter. What should matter is what are the learnings? Are we still on the right track? Do we need to change? 
    > Death by PowerPoint. Avoid a PowerPoint presentation. 

    Daily stand up
    > Team members report
    > Very long stand ups where just about everything is discussed 
    > Problem solving during stand ups.
    > People skip because of time zone difference, or not everyone attends
    > Overly focused on yesterday; no plans for today.

    Sprint planning
    > Team over-estimates its capacity and takes in too many items / tasks.
    > Team ignores to address technical debt
    > Team does not add slack time / contingency time. (Ideally is 60% for new, 20% slack and 20% for bugs and tech debt).
    > Too little or too much of planning
    > Some people skip the planning session

    Sprint retrospective
    > Sprint retrospectives don't happen
    > Action items don't come out of the retro and action items are not tracked - they don't feedback into the planning and thus no effective mechanism in place for ADAPT. 
    > Cancelling sprint retro if more buffer time is needed to achieve sprint goals. 
    > Rushed in retro / quickie 
    • What is included in DoD?
    > Definition of Done is a shared understanding of what Done means and is created by the development team.
    > DoD is at several levels

    - DoD for a User Story ( Is called Acceptance Criteria)
    - DoD for Sprint
    - DoD for Release

    Sample Definition of Done.

    > Code has been reviewed
    > Unit tests have been written and code has passed all UT
    > Design doc has been updated.
    > User stories have been tested
    > Test coverage is satisfactory
    > There are no pending defects
    • What is acceptance criteria, and who sets it?
    Acceptance criteria is the DONE criteria for a User story and is set by the Product Owner / Business Analyst (In consultation with PO). AC tell us the functional and non-functional checks that the user story has to pass thru to be considered done. 

    Example of AC for a user story. Acceptance criteria is usually written in the Given, When, Then format. 

    US = If the Year of the Vehicle make is before 1960, reject the request with a remark "Invalid Year. Request rejected".

    Acceptance criteria - 1
    Given the broker makes a request with year of manufacture of the vehicle as prior to 1960
    When the request is sent to EMBS
    Then EMBS should decline the request with a message "Invalid Year. Request rejected."

    Acceptance criteria - 2
    Given the broker makes a request with year of manufacture of the vehicle as 1960
    When the request is sent to EMBS
    Then EMBS should REFER the request to BPM

    What is a cross-functional team?

    A cross-functional team is a team that is organised around a product, and has all the skills required to deliver the product. The team members may include business analysts, UI/UX designers, Front end and back end developers, quality analysts, and Dev Ops engineers. 

    How do you deal with pressure or stressful situations?

    • Acknowledge that pressure and stressful situations are inherent in IT
    In a recent project involving Fusion GPP, we faced a critical deadline for international payments processing. Fusion GPP serves as the upstream system for our Informatica transformation, which was the primary focus of the project. The end-to-end process included reporting to AUSTRAC, making it imperative to meet our timelines for the international payments flow, as delays would impact several interconnected systems.

    We encountered significant pressure to adhere to these timelines, compounded by frequent challenges such as data unavailability for testing. This created a stressful environment as we had to ensure both the integrity and timeliness of the data flow.

    To manage this I followed the following process:
    • Buy in from team on shorter timelines:
      • Communicate the vision and importance to the team.
      • Involve the team early so they feel valued and provide them ownership.
      • Break tasks to manageable chunks and work allocation accordingly.
      • Open comms
      • Rewards and recognition
      • Lead by example
    • I stay organized and prioritize by tasks as per business needs.
      • I maintain a daily To Do's that include all the tasks expected out of delivery team.
      • All tasks expected from a PM side of things etc. Approvals, removing impediments, etc. 
      • Open up a constant communication channel with the business to relay back the progress as well as communicate any imp things back to team for a pivot/anything else.
      • Example is the inclusion of Monthly Jobs for GCM (Group Customer Master) datasets for the Load Assurance Solution Quantexa. Monthly was never in scope, however business was investigating various scenarios and midway through discussed with the design team both of whom concluded the need to include monthly jobs as well in the scope. 
    • Staying calm and focused.
      • In a multi vendor scenario as well as during critical times, it is common for team members and the larger groups to exchange heated words or disagreements. Now all this has to be within the context of office space and acceptable behaviour, no matter the urgency, need or criticality of work and decisions. By nature i am a calm and focused person with goals clearly visible on the horizon. I set expectations with the team as well as with the larger audience during meetings, anchor, triage and mediate discussions to steer towards the goal. 

    Change and Release Management Interview Questions

    Change management I have implemented at Westpac:
    1. Liaise with the business to align with their release plans - when they want to go for release.
    2. Check the release calendar for any scheduled changes, overlapping changes, blackouts, downtimes, DR activities, etc. 
    3. Liaise with other members / wider teams on the release slots for the specific technology. (Some technologies have only specific windows) 
    4. Check for any EOFY/EOHY - End of financial year, end of half year embargos or any such embargoes. Ensure appropriate approvals are in place. 
    5. Schedule the change. (Ensure all testing is complete and there are no open high priority defects).
    6. Also make an entry in the Release Register / Release Epics to follow up on the release. 
    Normal Change
    ============

    Follows the normal full change cycle. 5 days of lead time. Change should be submitted 5 days in advance with all the testing etc. completed. Include both minor (low to med impact and urgency) and major changes (high impact and urgency). 

    Standard Change
    ============

    Are pre-approved changes. Well known, Low impact and documented. Standard changes require a risk assessment and authorization when first implemented. However for subsequent implementation, they can be done as they have a history of successful implementations without any major risks. They are repeatable. 

    Emergency changes
    ================

    Have high impact and urgency, requiring expedited assessment, approval and implementation to get services up and running as soon as possible. These changes are implemented when critical business operations have failed, therefore causing downtime. 

    6. Review the Implementation plan + L2/L3 walkthrough. 

    7. Ensure there is a proper rollback plan in place if things go wrong. 

    8. Ensure all resources are lined up for deployment. Everyone is available, ROTA has been finalized about who will be available for what, contact numbers, alternative contacts, and escalation points. 

    9. If L2/L3 need to be lined up during weekends, and special permissions need to be taken, then arrange for it. 

    10. Ensure primary and secondary release managers are lined up and they have proper handover / takeover mechanism in place. 

    11. Carry out change.

    12. Open chat window with the all the stakeholders (except business) to follow up on the change deployment. 

    13. Keep sending out comms to all major stakeholders regularly. 

    14. To fix something in production (Configs etc. that does not involve a code change), raise an appropriate Incident in conjunction with the business and support teams).

    15. If a rollback is needed, then consult the Business for Go / No Go and then rollback as appropriate -- + business validation as applicable. 

    16. Follow up on Technical validation and business validation of deployment / rollback.

    17. Communication final status.

    18. Carry out a PIR - Post Implementation Review as applicable. Share results with change / release team and with the business.

    19. Report appropriate metrics as applicable. 





    No comments:

    Post a Comment

    DSPM, Data Security Posture Management, Data Observability

    DATA SECURITY POSTURE MANAGEMENT DSPM, or Data Security Posture Management, is a practice that involves assessing and managing the security ...