Sunday, January 24, 2016

The language barrier

Once again, I will try to summarize here my view on another key aspect to be carefully considered during the transition from traditional to Agile methodologies in the context of a corporation: the sudden exposure of the business guys to the technical language, an inconvenience they may have avoided so far thanks to the shelter created by IT structures like the “IT Reps”.

The relocation of the business members to a site shared with the testers and developers gives rise to the main barrier in the process of their adaptation to living together with the technical tribes. Without their missed “translator” (the former IT Representative), terms as obvious as “backend” or “service” will sound hollow in the heads of the business team the first times, but soon will turn into a concern as they become commonplace in their conversations with the technical guys.

Here, our goal should be to point out the similarities in both perspectives, the business and the technical stuff alike. What do I mean by similarities? While the business guys may take the complexity of the engineering language for granted, the technical guys may well have the same perception of the business jargon; so, let’s highlight this fact, and let the Product Owners and Business Analysts know that the business language may be very frightening for the software engineers. The effort to understand a new language is reciprocal.

On top of that, Scrum Masters must not forget to add a drop of empathy to the formula: all Scrum Masters have an educational and professional backgrounds, but they do not necessarily have to overlap either the computer science or the corresponding business field. That’s to say, to some extent the SM is condemned to be inmersed in (and eventually to command) both languages. His and hers is the highest penalty of all!

Saturday, January 2, 2016

An effective process of definition (II)

Hi, let's keep on going through my recommendations about a health product definition: based on the outcomes of the Design Research, you will want to outline your product by means of a Story Mapping.

Over time this technique has almost become a methodological standard for any Agile approach, as it helps the Product Owner to break the system into epics, features and, utimately, user stories. And when it comes to a corporative context, in my opinion this activity, that can take one or more working sessions, should gather together all relevant stakeholders, which usually represent a good collection of departments: from marketing to legal, from customer segments to operations, from business processes to customer service. Thus, we will come up with a comprehensive, though high-level, picture of the new product being defined, through a process-oriented approach that entails the demands of all the end-users involved.

Now it's the time for the backlog prioritization and the selection of the features that will account for the MVP or Minimum Viable Product. From my experience, this is a crucial milestone in the process of setting the foundations for the Agile project to be kicked off. And it's crucial because prioritization is a practice the business team are not accostumed to; their previous experience is just an all or nothing approach.

My tip here: have on hand facts and figures that show the proportion of functionalities that are commonly underused, or even not used at all, in previously delivered products at the company. Remember that in the context of a corporation, typically dozens of sw development projects are ongoing concurrently, and hundreds of applications are available at the desktops, tablets and smartphones of the end-users (I mean, employees as well as customers). I am sure you are already familiar with the commonplaces of those figures (they range from 64% rarely or never used in a 2002 study, to 80% in studies about the Microsoft Word processor); well, you will hardly find more about this on internet, but you do not need magic to come up with the figures of your own company.

That's said, you may not imagine how disturbing they are for the business units when they are confronted with them, because they may haven't been told about them before. We all know that "less is more" but, please, be kind and empathetic: it's hard for the Product Owner to assume the fact that some of the features identified during the previous phases might never be implemented. On the contrary, show her the advantage in managing stakeholders: she can always explain "those extremely important features" will be implemented in the upcoming versions to be released soon.

Of course, during the coming iterations we will have the opportunity to repeat the refinement and reprioritization of the product backlog again and again, and to strengthen this practice. Nonetheless, the first instance of this exercise will teach the Product Owner a lesson about the necessity of handling her product as a living being, that must evolve from elementary to complex no more than what is demanded by the end-user and the market.

Thanks for your reading, and by the way, enjoy a Happy New Year 2016!