Company profile: B2B Product Company, offices in USA and UK, around 1000 employees.
Mission: Structuring Agile ways of working in Product Management and improve collaboration between different departments.
First day with the development team was amazing. They are all modest, highly skilled and experienced engineers. They seem like working in harmony without any drawbacks. So, why did they bring me on board? I hope I can add some value. I explained to them that it would take some time for me to understand what they are doing. First week I will only listen and have lots of questions. Head of engineering tried to explain everything to me in 20 minutes and at the end asked me if I knew everything about the product now. My answer was clear, "of course not, you kept talking about such minute details, I still don't know what the product actually does", he burst out a laughing. Then, I had my 1-1 with the head of products. He is the nicest senior manager I've ever worked with. Now, I know a little more about what the product is doing. My question remains, why did they need a consultant on board for that mission? Does that problem really exist at all?
First 2 weeks is over. I've attended a Sprint Review, all daily calls, refinement sessions... Things appear to be not as perfect as I thought they were. There is a constant blame culture between countries. UK teams blaming US teams about not knowing the product and ruining the releases. US teams blaming UK teams about not being innovative and being a pain in the a... I decided to monitor this behavior and find the root cause.
I started having 1-1s with everyone to understand what they do, what their pains are, what they think should change. I made a list of things that;
need to get better and things that;
are already good and don't need much of my attention
This helped to channel my time and energy on the issues that need my attention. Finding out what is going bad was only the beginning because there is always a hidden root cause behind these problems. Lowering down the cause to personal characteristics of people is the easy way of getting away with it. Without any exception, I've always seen that it is never the case that the problem is caused by a specific individual's or a team's behaviour but usually it is the lack of required process and management.
In the next few weeks I started collecting the facts that might cause each of these problems. I am an engineer, I like having lists with check boxes. First of all, I needed to get everyone's trust and make sure they think of me as someone who is there to help. I will skip how I achieved this for now. I will write an article later for that and add the link here. After earning that trust from teams, I started working on solving the real problems.
US and UK teams can't get along well
This was the easiest one because I realised that;
They have never seen each other before and all the communication was done only over emails.
The design team in US is not included in any Scrum ceremonies but rather placed in the process as a waterfall service provider.
When you spot the problems the solution comes automatically. I set up a video conference and asked everyone to talk about;
What they do in the company, what is difficult about their job, what they like about their job
Their hobbies
Family and friends
This wasn't very easy for everyone, especially for people who are not used to sharing much with colleagues. However, I took people out of their comfort zone and I started talking myself with 100% transparency. I even started talking about my life goals, my retirement plans... Me being so open about everything, encouraged everyone to speak out. After this session, the tone of communication changed drastically in a positive way. People started asking how the other person is getting along with another project they are working at, they started talking about their shared hobbies. I started finding myself ending these sorts of conversations to focus on the real subject of the meeting. This was a good sign but not enough. The second step was to start a process to make this an on-going practice. Thanks to good alignment of senior management, we could arrange the budget for quarterly offshore trips where we take people from different teams to work abroad to get a better grasp of how it feels like to be working with the time difference, how it is like being have to stay in the evening for the meetings or having to wake up at 6 am to join a call.
The second issue was about inclusion of the UX and Design teams. Again, once you see what the problem is, the solution comes easily. We decided to have a dedicated designer for each Scrum Team. The designers were shared resources but we knew who the designer is for a team and we knew how much of their time they have to dedicate to that team only. For example if a designer is dedicating 30% of their time and we measured that it is around 10 story points per sprint, then, we were making sure the designer is getting that much work in a sprint. We started including the UX experts to Scrum ceremonies so that they understand the difficulties in implementing the design and the engineering teams can understand what might happen as a result of badly implemented UX design. Having these discussions in daily calls and refinement meetings aligned the engineering and design teams. It also improved the iterative and incremental approach in product delivery.
Support and delivery teams dispute all the time
By the end of 2 months, results were looking good. However, the problem between support and delivery was still there. According to the head of support, delivery teams did not care about fixing production issues but prefer to work on new feature development because it was easier and more fun. Engineering team, of course, claimed that this is imaginary and support was blaming the delivery because they were not capable of doing their job. Not a very nice situation to be in for the head of products because he was between these two. I started investigating the issue and came up with some historical statistics. According to statistics of the last 2 years, 20% of the delivery teams' effort were spent on support issues. However, sometimes the teams did not fix issues for consequent 2-3 sprints. With all this information in mind, we decided to start by increasing the issue bandwidth to 25% and also dedicate this bandwidth to support for every sprint. There comes the second question, how will we decide which issue to include in that bandwidth. Everyone who has taken a Scrum course and worked as a Product Owner for a few months would have said, it is the Product Owner who decides. However, we work with humans, not robots. So, I had to be more flexible than this. I've started open meetings for the Product Owner to open the issue list and works on prioritization where anyone from engineering team and support team can join and give suggestions. The Product Owner was acting like a Prime Minister of a country, saying the last word but committed to making a democratic decision. After running these 2 meetings for 2 months and sharing the statistics with everyone, the subject of the meetings between the head of engineering, the product people and the head of support changed. Rather than being aggressive, they were talking about how much effort they should dedicate on support issues, what is the cost of delay for new features and for unfixed issues.
This was an intense task for the Product Owner and I could see how consuming it is. But, who said being Product Owner was easy? Choosing not to listen to anyone and block any communication channel is the easy way but not the right way. Using the Scrum definition of a Product Owner as an excuse to escape this difficulty is very common and should be avoided.
Engineering teams general response is to push back
After a several months being in the organisation, I checked my notes and my list again. I realised that the last issue that I have spotted at the beginning wasn't happening anymore. This was interesting because I hadn't done anything and the team members haven't changed. So, what had happened for the problem to now be gone. Was it simply that if you wait enough things will fix themselves? It was near the end of my contract as a consultant and I did what I've always done, I sent an evaluation survey for my services, not only to senior managers but also to every person I've worked with even if it was only a single email correspondence. The answers I got from the engineering team revealed how this last issue was resolved. Most of them mentioned the same thing, the product team stopped being bossy and started to respect our experience and knowledge. Apparently, the constant push back from the engineering team was actually about them trying to be heard. This was an important lesson learned on my side for my Product Owner courses and mentoring sessions. Product Owners give so much focus on "As a Product Owner I am solely responsible to tell WHAT needs to get done", they forget about the "Scrum Values" and how they should collaborate with others. Without the necessary soft skills, the mechanical part of Agile Frameworks will fail. After that experience, now I am always emphasizing the importance of collaboration to Product Owners.
At the end of my consultancy contract, they took me out for a lunch and it was an emotional leaving event. I guess after getting through struggles together, you bond more with the team. I am still in touch with the teams, they have been acquired by another company. All is going in favour of them now and this result is one of the things I’m most proud of during my consultancy career.
Please share your comments below if you have experienced anything similar or if you have any questions.
Also, we have some online courses in Udemy and if you are interested in any of them please ping me and I will send you a free registration link (I don't want to add it here because it gets shared everywhere). You can check our Udemy courses from this link;