Scrum team looking to PO to give them the 'how'

I would say that you are right not to cross that boundary.  When in doubt, always go back to the Scrum Guide: 

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

I believe that it should be the SM that takes action by making the organisation aware of their development experience deficit so that they can help remove that impediment: 

The Scrum Master serves the Scrum Team in several ways, including:

● Coaching the team members in self-management and cross-functionality;

● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;

● Causing the removal of impediments to the Scrum Team’s progress; and,

● Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

The Scrum Master serves the organization in several ways, including:

● Leading, training, and coaching the organization in its Scrum adoption;

● Planning and advising Scrum implementations within the organization;

● Helping employees and stakeholders understand and enact an empirical approach for complex work; and,

● Removing barriers between stakeholders and Scrum Teams.

From a Scrum Master perspective, it does sound like you are being reasonable in not stepping into the "how" aspect. Based on some of my experiences, this can be difficult when you do have the technical expertise needed. However, the team shouldn't rely on you to tell them how to do things. As a Product Owner, you have a lot of other things that you must be responsible for and may not be able to effectively fill two roles.

In a case like this, it may be prudent to increase the amount of slack that the team has each Sprint. Pull in a much smaller amount of Product Backlog Items and make sure that the team has time to learn as they go. They may find it beneficial to pair up to design and implement the solutions. Alternatively, splitting up and creating competing solutions may help the team learn, and then the best solution can be selected. You'll also need this slack if you onboard new developers onto the team, since they won't know everything they need to know on day one.

As a PO I am part of a scrum team which has recently lost senior experienced developers with no replacements yet in place. The team can no longer be described as competent

In what sense do the Developers now lack competence? Was that lost seniority necessary for the product's Definition of Done to be met?

I agree that you are doing the right thing as a Product Owner.  However, you do have an impediment that is preventing the Scrum Team from being able to deliver incremental value to the product. This is the opening statement in the Scrum Guide section that explains the Product Owner role

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The section that describes the Scrum Master role has this as one of the responsibilities to the Scrum Team

• Causing the removal of impediments to the Scrum Team’s progress; and,

Combine those two and it seems that you and the individual fulfilling the Scrum Master role need to escalate this to your organizational leadership so that the impediment can be addressed.   I am also going to assume that there is a Development Manager involved because very few organizations have eliminated that organizational structure.  That individual should also be made aware of the impact this is having on the Scrum Team's ability to deliver.  If someone was to step in and provide the technical leadership the Developers are needing, I would expect that the Development Manager would be the one to step in. Not Scrum framework specific but it is realistic.

Fromt a SM view : I think Ian Mitchell is right : in what way does your lone programmer gone makes your team 'not competent' ?   it will slow down the velocity of the team, of course, but that's about it. 



it seems like your team have a 'hero developper' complex. the 'hero' leads and decided everything, shows everyone how it's done. Now he's gone, and your team don't know what to do, because they are just waiting for the answers, or are looking for a new 'hero'. You are 100% right in not stepping into that role.



I would use the 'fake-it till you make-it' strategy ... keep on working normally, re-learn to work as a team, and take team decisions, and not having a 'hero' deciding everything.  If I was the SM ... I would say to the team  ' I know Bob is gone, and he was the tech lead ... but now we have to step up as a team into his role'.  



have the TEAM take decision (even if they are the wrong decision) and adjust expectations from stakeholders while the team gets back on track, grooming session might be needed to go longer, and planning/poking sessions might be needed to be a bit longer, and less PBI inspected, but you need only 2 or 3 dev able to learn and 'embracing' the challeng to push it around in a whole new (positive) direction. 

 

Fromt a SM view : I think Ian Mitchell is right : in what way does your lone programmer gone makes your team 'not competent' ?   it will slow down the velocity of the team, of course, but that's about it. 

I don't think Ian Mitchell was making specifically that point.

Depending on the answer to that question, different arguments could be made. For instance, if the only person who understood how to write and update automated tests, or how to track and remove technical debt, has left the team, then there's a risk that the team will continue, without understanding what hidden problems they are causing.

This impediment can be deeper than a mere adjustment of velocity.