Learning 6: Make use of your cross-functional talents, make it real team collaboration
This article is part of my learning journal. If you are interested to read them all, jump to my main index page "What I have learnt about product management, agile, and personal development at a big bank".
PART 1: 9 learnings on the process of developing a product from discovery phase to delivery phase
Learning 1: The mindset of DVF, and take ownership to explore DVF, at scale.
Learning 2: Understand your problem statement, and create a clear and long lasting vision
Learning 3: Trust the experts and empower the team
Learning 4: Know the rules before you break the rules (understand current state of your solution)
Learning 5: Clear roles and responsibilities = Clear accountabilities and actions
Learning 6: Make use of your cross-functional talents, make it real team collaboration
Learning 7: Create an actionable roadmap. Convert the experience into coherent user stories. Focus on less, to deliver more
Learning 8: Tactical solution vs Strategic solution, whichever you chose, make sure it's shared understanding
Learning 9: Engage with your stakeholders
It's great you brought people with different skill sets across a big company together, and good on you adopting agile methodology and applying stand up, sprint planning and retro. However, don't stop there.
Get out of your comfort zone and be genuinely interested to understand other people's role, so you can see how everyone's effort are put together to meet the goal. Set up workshops instead of individual meetings and bring PO, BA, UX and technologists together. Discuss the tasks together, and understand the dependencies between each other tasks, so it helps to remove unnecessary handover, and allow some work to start 1 sprint beforehand to sequence the work. And even if you are a seasoned PO who knows the usual dependencies, make sure you don't go to the extreme of setting up the sequences of tasks without discussing with the team first, it usually didn't go too well, you know, who wants to be a robot. Or when the sequence of tasks go out of the sync, the team probably wouldn't care why other parts of the team isn't completed or confused about what went wrong.
I have to say, not fully understand the dependencies is my another pet peeve, on top of unvalidated assumptions. When you see people moving tickets to done at stand up while it is depending on other people's ticket to move forward, you know this isn't true team collaboration. A good scrum master would be able to facilitate this discussion, and make it a team view instead of individual view of tasks. Yes you can break down the task to multiple tickets, but by creating version 1, 2, 3 of the same task, so you have a ticket to move every day is not helping bringing the focus of why the ticket is not completed.
Eg: instead of creating tickets of business requirement draft 1, draft 2, and final. It's better to create 1 ticket of business requirement. and if you cannot move the ticket by the due date, because it keeps on changing by architecture, design or other elements, then it highlights to the team there is a dependency/sequencing issue, and it's better to focus on removing the uncertainty of architecture etc in order to move forward together. Also, it means the BA may be freed up to help researchers on customer interview and synthesis, while waiting for the blocker to be removed.
The other thing worth to note here is to understand why such an behaviour exist. Is it because people don't really understand how agile works? Or they don't feel safe and hate to be deemed as the one who drags everyone behind?
One of the methods that would work quite well is to visualise the dependencies of tasks by creating story board. I will extend it a bit more on the next learning point: create an actionable roadmap.
Read my previous learning point : Learning 5: Clear roles and responsibilities = Clear accountabilities and actions
Read my next learning point : Learning 7: Create an actionable roadmap. Convert the experience into coherent user stories. Focus on less, to deliver more
Back to my main index page: "What I have learnt about product management, agile, and personal development at a big bank".