Improving the flow and focus of financial product innovation teams by getting transparency about problems and their duration
Introduction
Financial product innovations are often connected with hard challenges such as organizational, technological as well as personal dimensions of teams, the team's stakeholders, and the team's individuals. Many teams do not know their biggest blocks regarding a good stakeholders interaction and do not measure their problem time. The Management 3.0 practice “Problem Time” can help to foster the team's ability to collaborate and focus.
The practice: Short explained
First, transparency about the necessary problems must be created. This can be done e.g. by team brainstorming or by the team facilitator so that an improvement backlog is created with problems was the additional time is clear and an estimated problem time. Important is to focus on the case of financial product innovations, also the thinking of customer-centricity. This means the problem should especially also consider stakeholder blocks — therefore e.g. the voice of the product owner can be very valuable. Then, calculate the average problem time together so that the result can be communicated to the team and monitored in a regular way. This improvement backlog should be inspected and adapted every week so that it is in an actual state. Then, this improvement backlog can be used in a regular way to ask the stakeholders what can be done in a better way / where to focus next to improvement.
Why did I decide to use this practice?
My team had hard problems interacting with the stakeholders and I felt during the Sprint Review a kind of untrust rising. The stakeholders were not happy with the results and also they did not give good feedback in the context of the product owner's collaboration. There seem to be some not transparent problems in the air. I wanted to create more transparency to foster trust and enable an inspection and adapt the process in my financial product innovation team.
How did I use this practice?
I made an experiment in the coming Sprint Retrospective where all team members were together. We made a brainstorm on an online whiteboard about the current problems of our team and especially with our stakeholders. then we add the problems to an issue tracking tool (Jira) to create an improvement backlog and remember when the problems are added. We estimated the problem time for each. Then I as the facilitator was able to calculate the average time for the entire board so that I was able to create transparency about the overall problem time in front of the team. Afterward, I created for myself a repeating task every week to inspect and adapt the improvement backlog. It Important was to ask the stakeholders of our product innovation what we as a team can do better and raise transparency and trust.
My learnings as a facilitator
The problem time was for me now one of the most effective methods to foster focus and collaboration with our stakeholders and inside our team.
How did the team feel about implementing the tool?
The team had at first doubts if the new level of transparency will help or damage the work together with our stakeholders. Therefore it was helpful that I explained a short success story from my past working experience of another team where I was a team member. I explained to the team that the level of trust and productivity raised up after we introduced measuring the problem time. This own experienced helped a lot to break the ice on this new approach for my current team.
As an experiment, what went right and what went wrong?
We learned that it was reasonable to foster regular refinements events with the stakeholders to speak openly and improve the clarity of the documented problems. This cadence and synchronization enabled us also to split the problems into better handleable and understandable chunks — before it was sometimes hard to be able to hold an overview about just roughly described bigger problems.
What was the feedback from people?
My team gave me as a facilitator very good feedback and the stakeholder's trust in our way of working improved in a significant way. The flow increased and the delays were reduced.
What could you do better or differently next time?
I can advise starting from the beginning of the first Sprint retrospective to start to measure the problem time and inspect and adapt the improvement backlog. As another experiment, I will introduce this technique in the next four weeks to one of our Kanban teams during their next lessons learned and Inspect & Adapt event because it was working overall already very well as described above.
