PITA 019
TOPIC 1: What’s (one of) the most ridiculous WTF moments you’ve faced with stakeholders or developers as a PM?
‘This goes against everything we stand for, as we believe dev teams should not work together. Or talk to each other.’
‘Enough analysis paralysis - when are you going to stand up and shoot?’ (when presenting that something isn’t yet ready for public consumption.)
10 minutes of feedback on the fonts and presentation format. None on the content.
TOPIC 2: Tech debt and how to create incentives for tech leads towards maintainability
Creating more tech debt by addressing something at the wrong time - oops!
Openly addressing what the underlying problems are - taking time away from product work to discuss what you could do in an ideal world
Be clear on what the end goal of the functionality is - focus on both short and long term at all times
Bake in self-time to pay down debt in alternating sprints
Any pre-holiday sprint - when planning is screwy anyway - is given over to debt
Setting up principles at the start as to when you should take on debt, or how much is too much
Put it in economic terms - establish a contract with your counterparts
Gitprime & similar do code analysis to look at quality - does this need to be done?
best practice metrics tools around cycle times, return rates, number of production and other issues (e.g. Plandek) - and make these metrics part of the regular catch up and priorities, lots of them are dependent on tech debt
Get Dev on support calls to really identify with the real problems
Pull in the team and allow them to come up with a plan of attack - so they own ittr
Redefine Velocity away from story points and towards value realised. If that slows, address the issues that stop you from delivering value
TOPIC 3: I start a new job Monday - Head of Product and inheriting multiple teams that came from acquisition - what is the best way to bring them all together and think as one product not many?
Start with goals
Start small, then scale to the bigger team
Start by listening, then induce change. Watch the reaction. Deal with that. Rip the band-aid off.
I’d speak to people separately too, gather input on what works well and what doesn’t according to them. Also identify the strong influential personalities and focus on working with them.
And we’ve said this before - the fact that you’re the new person can be a benefit too, use the advantage to ask more questions and bring a new perspective
Identify everyone’s competencies - get a benchmark, as well as their styles
Look at end users - what is the experience that they need? What’s working and not working?
Get your metrics straight: what is the problem that needs to be prioritised?
Do a leadership retro
People, processes, prioritisation and perception ; Briefing & back-briefing
Take them out of the work environment one on one. I find people open up more when they are outside of a working setting. If you cannot meet face to face then do a walking zoom call.
Futurecasting
User Story Mapping workshop
TOPIC 4: I have been thinking a lot about boundaries recently. Do you have experiences where you have seen great examples of setting or maintaining boundaries in or across teams?
Christina Wodtke, The Team that Managed Itself: A Story of Leadership
Alternate take: Be a dictator. Set the mission and expectations clearly. Set responsibility: you have to make *this* decision - i.e., Dev makes the architecture decision, but on a tight schedule
Team retros, followed by mini 1:1 retros
Ways of working sessions
Understand the history - why is it working this way?