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.

#crossfunctionalteam #teamcollaboration

0 views

Quinnie86@gmail.com  |  Melbourne, Australia