Company profile: Retail company with over 1000 stores in 10 countries with over 50000 employees.
Mission: Structuring Product Management team to align with the agile development practices and improve ways of working for the e-commerce platform development teams.
First day I met the product manager who I had a call with before. She is super smart and knows every detail of the product. Not only the product actually, the whole journey of an item sold, starting from ordering to getting the supply from the vendor and also shipping it from the warehouse. She asked me to join the planning meeting with the platform teams. I was excited to meet with the team, happy days. However, turned out to be not so happy. The scrum master opened to-do list, a spreadsheet of hundreds of lines. She asked the product manager which of these she wants to get done in the next sprint. Well... what is going on here, is that how planning works? They are using Scrum but planning is just asking the product manager "what should we put in the next sprint". Oh besides that, there are already 20 something items they are carrying over from the previous sprint. While having all this sort of thoughts, I decided to stay calm but only ask a very simple question; "do you not use tools like JIRA or TFS". The response from the Scrum Master was hellish, "you don't know this organisation...do you think you know everything... we are different... these tools won't work for us, excel spreadsheet is working well for us..." Wait a minute, what's going on here, I've just asked a simple question... and it is my first day, why does she want to kill me already? I remembered the conversation we had with the Product Manager on the first call, she asked if I've dealt with difficult people, I think I knew then who she was talking about.
After the planning meeting (still the first day), I had a session with the head of omni-channel. Luckily she was very positive and easy-going. She wanted me to start thinking about how they should structure the product team for agility.
At the end of the first day, I had two objectives. First, fix how the platform teams are run. Second, suggest an organisation for product teams that would fit into existing organisation rather than designing the whole company from scratch. I decided to tackle the first because it was the burning issue, also you can't scale things before making the basics right.
First 2 weeks I documented all the problems I've seen in the existing ways how the teams operated. It wasn't that difficult because the teams were not doing even the basics of Scrum. For example, Sprint Planning was done together with the Product Manager, only the team leads and a few stakeholders. Why is the team not attending to the Planning? Why do we have the stakeholders in the planning? There was no such thing as velocity and capacity was decided by the educated guess of the Scrum Master. There was no such thing as Sprint Review... However, these were the minor problems. The main problem was that the Scrum Master didn't have proper experience. I had to train her first.
Rule number one for you if you are planning to work as a consultant, don't blame anyone in the team. Just earn their trust, show them what the problems are and give them examples of an ideal operating model. They will do the rest for you.
After the first month the team started complaining about existing ways of working and they starting coming with change proposals. We also hired a new super-duper Scrum Master who had years and years of experience in leading proper Scrum teams. What we first did was to divide the e-commerce team into 4 squads, 2 squads worked with the new Scrum Master, the other 2 worked with the existing Scrum Master. The new Scrum Master showed the whole organisation how Scrum should run, he was doing great with the team. This made the other Scrum Master acting more hostile towards peers which in the end costed her her job. Her lack of experience and knowledge was acceptable as long as she was open to change but hostility towards peers was not welcome in that organisation.
This is something I've experienced in all successful enterprise companies. Experience, knowledge, mistakes... these all can be forgiven but bad manners towards peers, is not. I see some start-ups making a big mistake allowing bad mannered people ruining their culture for the sake of their skills and experience. In the long run this will ruin your culture and cause your start-up to fail.
Then, we've hired another Scrum Master. For this hire we focused more on facilitation skills and a positive attitude, top level communication skills. After all this change happening in the teams, they needed someone to bring them together with positive attitude and facilitation skills. We had a second Scrum Master joining the platform teams who kept his smile and positive attitude for months and months, no matter what happened. In total, we had 4 squads with 2 Scrum Masters. 2 of the squads running Scrum and working on new big feature development. The other 2 using Kanban and working on smaller changes and bug fixes. We started proper planning using velocity, we started having sprint review meetings which provided transparency to the stakeholders, we started having regular refinement meetings... One of the scrum masters was strong on knowledge and experience in scrum and agile best practices, the other one a great facilitator and motivator. They shared their skills experience during Scrum of Scrums which created a very good balance. All going by the book, so, I could start working on the second objective; product management structure.
The first problem was easy to solve because it only required basics of Scrum. However, the product management structure is more challenging. I decided to keep it to basics at first. I suggested to make the changes in responsibilities and ways of working rather than directly drawing an organisational structure that would only work on the paper. Once we define the responsibilities and ways of working, the requirement for an organisational change will come anyway. First change; product managers to move from top floor to ground floor to sit together with their Scrum Teams. They were co-located, yet there was lack of communication between the teams and Product Managers. They should start being a part of Scrum and become actual Product Owners. Secondly, they should start communicating more frequently with stakeholders to increase transparency about what the team is doing and will be doing in the next 1-2 sprints. These two changes enabled a very important element of the Agile Manifesto; "customer collaboration over contract negotiation".
After the product managers started working within proper Scrum Framework, issues revealed themselves. Some Product Managers actually didn't want to work as Product Owners. They wanted to stay only on the marketing side of the role. For some Product Owners, they didn't have line managers who were interested in the e-commerce platform but more focused on things like inventory management, stocks... In order to fix such issues, we had to make it clear how the product owners placed in the organisation. The main principles were as follows;
Separation between subject matter experts and Product Owners. Systems Thinking explained in SAFe is a key skill that a Product Owner and their line managers should have. Not all subject matter experts have to be Product Owners.
Product Owners should not report to someone who has little interest in the product but responsible for the operations only. Product Team should be in the same organisational structure. For example, the senior accountant at Finance should not also work as a Product Owner of payments in e-commerce team. I based my design on the basics of Less Organisational Structure. In the end we came up with something as below (a small snapshot of the whole);
This was a good example of a quick win to fix a burning issue; organising 4 squads around a specific goal and long term guidance for the company for the next steps. Consultants will always face this challenge to deliver something quick to earn trust but also make sure long term vision is there.
The result of this contract provided the client with happier teams, less defects in delivery, better estimation and transparency, enabling expert feature teams as well as enabling short term project teams with contractors (same day delivery example above). This last bit is going to be controversial because for most agile experts, there is no such thing as project teams. However, life is not ideal and the dynamics of the organisations (budgeting, skills, human resources, targets...) will not always let you live the dream but as a consultant you will be expected to come up with solutions.
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 let me know in the comments section below and I will send you a free registration link. You can check all our Udemy courses from this link;