I’ve just finished reading this article http://www.leadingagile.com/2015/04/making-sure-they-do-it-the-right-way/.
The article is about how difficult it can be for people transitioning into a product owner role to accept that they only need to specify what they want solved, not how to solve it.
The conclusion is that they need to trust the team to find the ‘correct’ solution, as the team are the best people to do this for a number of reasons. The article is well worth a read as it makes you think about one of the fundamental principles underlying the way we work.
This really got me thinking so I’ve added a few things below that I thought were important as well…
Not trusting the team is a lost opportunity: This isn’t about empowering teams because that’s what the process says to do. This is about giving the team the blank slate and seeing what happens. It could be something brilliant and the business wins. It’s really hard to go back to that blank slate once a solution has been suggested as we tend to get locked into a single way of thinking.
This doesn’t always come from the direction of the product owner: Anyone in the business can end up in a place where they feel that they’ve got the only right way in mind for a particular job.
Sometimes they might have additional information, requirements, or restrictions in mind (people are really bad at explaining these once they have a solution in mind), or maybe they have been thinking about this for years and they’re emotionally invested. They might see this as their chance to get their solution done. There are a huge number of directions this symptom can come from and an infinite number of reasons why. ScrumMasters can help a lot in these cases. Most the time we really need to try and be a neutral party (rather than evangelize), to try and figure out what’s really going on, to make sure the team has all the information, to aid everyone in communicating clearly and to help the team decide how to act.
Ideally we all work together to create a level of trust running in all directions so that once everyone has had some space to think we can all make suggestions, and that’s how they’re taken, as suggestions rather than orders.
This isn’t just a top down problem: Teams can have a hard time transitioning to designing solutions themselves. The switch can feel like there is suddenly a lack of guidance or clarity (some people think they quite like being told what to build and how to build it). Designing solutions can also feel like taking on a lot of responsibility which not everyone wants. Again as a ScrumMaster we’d take a look at the reasons why this is happening and try to get those fixed first: Is there a blame culture? Are stakeholders used to experimental or evolving solutions? Are there smaller places to start to build trust? etc.
The team has to be genuinely cross-functional: The team can only come up with the right way of doing something if the team has the right skills; a cross-functional team has all these skills.
When a team is formed people generally have in mind the sort of skills needed, in the case of web development that might be, UX, Design, Front-end developers, Back-end developers and QA. If work comes along that’s very different, or we suddenly start doing things in a new way we might find we’re missing something. Again the ScrumMaster might help the team recognize this and aid the team in getting outside help, training, more people or something else.
I hope this made you think as well!
Originally published on my internal blog at Macmillan.com