Abdul, the lead developer was one of the co-founders of the company along with Pervez, the CEO and Suzanne, the head of sales. They had built a product from scratch to rival the biggest players in the industry and were getting to the point where they absolutely had to expand. So far they had got away with just Abdul and another developer building the product and due to the small nature of the team, when there was a trade off between user experience and functionality, the choice had always been to add functionality at the expense of user experience.
Recently Pervez had appointed a Product Owner, Manish, to the team to focus the product from a user’s perspective as a clunky product just wouldn’t fly in the market. Unfortunately Manish was not playing the Product Owner role full-time and was also handling the design responsibilities as there was no design role within the development team.
At their first sprint planning session Manish came along as Product Owner with a user story for the highest priority product backlog item that contained a screen grab of how the functionality should look, what tables and fields were required where, how the user would use the feature (drop down lists) and even the colour coding.
Manish felt he had done his job really well and so was surprised when Abdul and the team were upset. Pervez, who was playing the role of ScrumMaster tried to work through the issues.
A lot of teams would be really happy with the Product Owner providing a lot of information about the highest priority product backlog item in the Sprint Planning Meeting as one of the biggest complaints I hear from Scrum teams is the lack of clarity around Product Backlog items. One of the responsibilities of the Product Owner is to make sure the Product Backlog is in a ‘good enough’ state for the next level of planning. This usually means making sure the highest priority items have enough detail in them to make planning them into a sprint achieveable.
However, another principle of Scrum is that the Product Owner limit themselves to worrying about WHAT needs to be done while allowing the self-organising Scrum development team to work out HOW it will be implemented. We trust the development team to use their skills and experience to come up with the most appropriate design and solution. I often say that ‘a Product Owner with a little technical knowledge is a dangerous thing’ as they cannot resist the temptation to state the solution they want rather than the business problem or user need that is to be solved. This often leads to what we call ‘technical successes’ where the development team deliver exactly what has been asked for but miss what the user actually really needed. This allows the development team to claim the delivery a success but from a business point of view, it is far from successful.
This was a difficult situation because Manish was also a member of the development team so would naturally be involved in that design process anyway. However Abdul’s argument was that this smacked of up-front design similar to that of a waterfall process, the designer turning up to the development team and saying “implement this”.
Pervez attempted to determine what the issues were and found out that Abdul felt that once a design was put in front of the team, they felt less able to think of alternatives; all they could see was the presented option and they thus felt stifled and un-empowered. Manish felt that, unless he paid attention to the user experience in the user story, it would be forgotten and more “clunky” functionality would be added leading to an unmarketable product.
Pervez asked Manish if he would be happy if the team picked his design apart to which Manish replied that that was what he was expecting. It was only meant to be a starting point but Abdul was still concerned that the team would still only be focussing on the option in front of them instead of considering alternatives. Pervez then asked the team if they would be happier if Manish came to the Sprint Planning Meeting with his idea about the design in his “back pocket” and to let the team have a first attempt not influenced by Manish’s ideas but the reaction from the rest of the team was “why can’t we come up with the design together in the sprint planning session?”.
What was especially interesting was how this dysfunctionality, while causing conflict within the team, was fairly easily steered toward some very natural agile outcomes. Pervez’s first question was to ask whether Manish should “hide” his idea so as to avoid compromising the creativity of the development team. This led to a suggestion of collaborative design and a call for Manish to focus his Product Owner time on adding acceptance criteria to the user story rather than the design of the solution. While Manish was still a little uncomfortable by this the team agreed it was better than the alternative of tightening up the requirements even more in advance. As it was, this was taking up Manish’s time pre-Sprint and effectively turning the Sprints into mini-waterfall phases.
One suggestion that the team came up with was to actually make visible a few team agreements i.e. the team will collaboratively uncover the design in Sprint Planning and during the Sprint, everyone can contribute to the design discussion but all ideas are open to change/approval/rejection. Manish also decided it would be helpful to clarify what he should and should not be doing when he is in the role of Product Owner and what he should and should not be doing when he is in the role of team member. He also asked Pervez to help remind him when he is crossing the boundaries.
This was an interesting situation because all the players were on the same side but this was potentially a source of great conflict and disharmony. There was an obvious tension between Abdul, the lead developer, who was looking to get as much functionality into the product as possible at the acknowledged expense of it looking great and Manish, the Product Owner, who was openly putting more of a focus on things being usable soon. Equally Manish was struggling with his dual role and separating out the time he should be focussing on being a Product Owner and the time he should be focussing on being a designer while the fact that he was now wearing two hats (designer and Product Owner) was already leading to him being considered less of one of the team by the rest of the development team.
Dual roles (people in the team taking on two Scrum roles simultaneously) always causes conflicts in the team and brings extra risk to the project. It is not impossible to handle, and sometimes it is necessary but there are some things to consider. Namely whether this is absolutely necessary – often it is not as necessary as we first think – and part of the role of the ScrumMaster is to challenge current conventions rather than compromise Scrum. Certain dual roles are easier to handle than others but I would argue that if you have a dual role you need an even stronger ScrumMaster than you might otherwise need to help identify and facilitate the team through the conflicts.
It is usually a good idea as a team to understand who is bringing what to the party (as it were) and to what degree the Product Owner is going to define the design. In this particular case, a big risk is that the product moves from the extreme of “not so pretty” but lots of functionality to a really polished but functionality-sparse product. The ScrumMaster is often the fulcrum between product management and product development. Pervez will probably find himself even more in the spotlight in this regard here, making it very visible when either side is potentially dominating the other.