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.
>
No comments:
Post a Comment