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.

Wednesday, December 2, 2015

Thanks, Three Amigos!

One of my key learnings from my experience as SM if how hard the definition of a user story may become, as it requires an effective communication from the initial intent of the business staff to the final understanding by the DevTeam. A lot of literature can be found around this subject, but I want to share with you an experiment conducted with/by my team in the quest of the "nirvana" for the DoR.

The approach was derived from a fantastic idea by Ryan Thomas Hewitt, named Three Amigos; I guess you need no traslation to this... The idea is pretty simple, but effective: let's pair, if you allow me the expression, the Business Analyst with the Tester and the Developer. Starting from a proposal of description produced by the BA, they iterate to improve such description with a higher level of detail until they all have the same understanding and agree the story is ready for development.

In our own trial, that was sponsored by the guild or system team of Quality Enablement, our initial goal was to ensure a complete alignment between the Business Analyst and the Tester by assigning the first one the task of writing the test scenarios in the BDD format of Given/When/Then. But we took the trial to the extreme of asking the BA to use kind of Gherkin language and to operate a repositoy of scenarios, so that their definition was almost directly applicable to .feature files. Even a website application was built to assist the BAs in manipulating those .feature files, but in a guided environment and insulated from the complexity of purely technical tools such as eclipse.

Our experiment failed, but that was as good as it would have been, had it succeded. We learned a couple of things: you will hardly obtain productive outcomes in the technical side when you ask the business guys to do it.

The second learning was that we were missing the other crucial piece: the Developer. An agreement reached only between the BA and the Tester does not ensure the alignment of the developed feature with its acceptance criteria.

So, we changed our mind with respect to the tool, but also found a simpler way to the ThreeAmigos approach:

  • first, the BA defines the acceptance criteria, describing scenarios, events and outputs but in plain spanish
  • secondly, the BA joins the Tester and the Developer so that they navigate through the full set of requirements and reach a common understanding
  • third, the Tester defines the acceptance tests using Gherkin

I would say this approach is completely compatible with the idea of the 3Cs (card, conversation and confirmation), since all three actions are activated here, but it makes very clear the responsabilities of each role, and furthermore, the accountability of all of them as a team.