Monday, December 21, 2015

An effective process of definition (I)

During my recent talk in the Conference Agile Spain 2015 I addressed the issues that Product Owners at corporations face when they are challenged to join a development team and adopt an Agile methodology.

Based on my experience, the product definition is probably the most painful change for the business guys adopting Agile, since it requires not only a U-turn in attitude and a dose of open mind, but also a boost in skills. I mean, it’s just not a matter of unlearning, discarding and throwing away the traditional models: the whole bunch of requirements upfront, a textual and linear format (ppt, doc…), etc. It also requires a significant effort to develop a new mindset: essentially, the ability to slice the product into features or epics and user stories. An ability which may look natural when you haven’t come into contact with the definition of requirements using traditional methodologies, but that entails an important training to unlearn the old style and learn the new model.

My recommendation here is to advise the Product Owner to adhere as much as possible to a process whose first phase should be a Design Research.

I have no doubt that the guys in the Business Development units of our corporations usally rely on techniques to come up with ideas for the new products and services, but I am pretty sure that those techniques usually belong to the discipline of Market Research, with focus set on creating value for the organization.

In contrast, Design Research focus on creating value for the end user, providing with a powerful opportunity to shape those new products and services to the needs and expectations of the clients, in a "customer-centric" approach. Knowing the clients and even co-creating with them is crucial if we want to fix a viable market goal. Outputs such as insights, customer journeys with opportunities and pain points, conceptual designs like wireframes and so on are all invaluable resources for the Product Owner to define the product.

That's said, what are my advices with respect to this point? First, never skip this phase: it usually accounts for a small percentage of the entire budget the project will expend during the phase of development. And secondly (and most important did it not require number one): make the professionals in charge of the Research to share the results not only with the business guys during the early stages of definition, but also with the Development Team once the Scrum has been formed. You will hardly find a guy in the BusDev unit of a corporation able to beat with her/his numbers and figures the story-telling of genuine, passionate researchers and designers. The goal? Your DevTeam will immediately feel on board at the same level than the PO, removing potential barriers in the communication among all of them during their future discussions about the value provided by each funcionality.

No comments :

Post a Comment