loading...

re: I spent 30 years coding full-time, then I switched to full-time management and leadership. Ask me anything. VIEW POST

FULL DISCUSSION
 

Hey Lorenzo,

it looks like you have good experience on Scrum as well...
Can you talk on responsibilities of a PO vs team/technical lead ?

Background is, that i feel my current team setup is far from reaching its potential.
A while back i was driving a lot of things for a new project... i liked it, most important it felt like flow. E.g. the ticket ordering felt like 'Yeah, thats the good next step', thing were building on each other.., etc..

Since PM/PO slowly took over most of the ticketing, planning workflow i'm now at a point the flow experience is most of the times lost, sense of priorities is decreased, meetings are boring and it feels like 'Yeah i can work for the next two weeks or take PTO, doesn't really matter for the company'.

Now i'm almost too tired to work on better responsibility structuring, but i would like to get your input on this!

I feel a little bit like 'Please care about the high level things you want to have, talk to customer's etc.. convey everything to me and/or the team and let us figure out the rest. Also in prior teams i sometimes had the impression the team lead is suggesting every step to the PO so that the PO can repeat it and make things official that way... which feels like wasted time...

 

So, did you use Scrum before when you were driving the projects? Or is Scrum something that was introduced recently?

I like to have 3 persons. A Scrum Master, a Product Owner, and a Project Lead.
The Scrum Master deals with the process. They schedule meetings, keep the teams on track during the meetings, remove impediments, drive plannings, demos, retrospectives, etc.
The Product Owner is the business owner of the project. They are able to answer questions or go find answers to the questions.
The Project Lead is a technical leader, who understands the details of the project.
I wrote some notes on this model in an article on my company's tech blog. You can find it here ; take a look, and let me know what you think and/or if I can clarify it. I wrote this a long while ago, but I think it is still valid and I have had very good luck with it.

In general, I recommend bringing problems related to the process at the retrospective, and not hold any punches. That is what retrospectives are for. Scrum is very flexible, and if the people involved understand it, you can change it to satisfy your team's needs.

code of conduct - report abuse