Paradigma Digital Technology for business Mon, 19 Mar 2018 15:20:58 +0000 en-US hourly 1 Technology for business Paradigma Digital Technology for business Paradigma Digital Being digital has to do with attitude, not knowledge Mon, 19 Mar 2018 15:20:58 +0000 2017 ended with new years resolutions from Spanish companies to improve and adapt to the new digital environment.

However, these resolutions are still far from becoming a reality. Mainly because some positions of responsibility act under the bias of their previous experience in a radically different environment.

“We can not solve problems using the same reasoning that we used when we created them”, Albert Einstein.

To better understand this situation, let’s look at five mistakes, each one associated with a role or team that we have found  to be recurrent in many large Spanish companies.

The CEO: everything is fixed with a strategic report

Any self-respecting transformation process begins with a traditional life-long consulting analysis. It’s like a kind of kick-start with a cost of 6 figures that reaffirms how important it is to transform if you want to remain competitive in your sector, that you start working in Agile, that you bet on Big Data technologies …

A series of very expensive facts, that serve only to convince some stragglers who still think that their sector is not affected by digital transformation, but little else. This study usually initiates a small organizational change, but it is useless in the face of real change, which requires more actions and less PowerPoints.

The CTO: everything is fixed with tools

The vision of a CTO of all life is that each problem is fixed with a tool. If you want to be agile, Jira is implanted; to lower the time to market we installed Jenkins; and if there are distributed teams, Git solves it.

But the reality is that the tools are useless if the principles are not internalized. Part of the problem lies in the temptation of software manufacturers who, like miracle peddlers from the Far West try by all means to place their products without actually diagnosing the problem, or internalizing the root of the change.

What CTO hasn’t suffered having a BMP? But let’s be realistic, you can work as a team without Git as you can be agile without Jira, because in the end, the tools do not stop being nothing more than support.

HR: everything is fixed with trainings

The vision of human resources is that the digital environment requires a series of new capabilities in people and those skills are acquired with training. To start working with agility, the first thing is to receive a training, probably taught by the usual provider, who works in a traditional way and prepares the training quickly for the occasion.

But neither the longest and most complete of trainings is comparable to participating in a real sprint and experiencing it in first person. So what you have to do after learning the basics, is to choose a driver and start testing as soon as possible.

The most advantaged ones go from training to an Agile Coach or even an Agile Coach horde if the thing does not advance. But to transform the way you make software you need a multidisciplinary team, because the method is as important as the associated engineering practices, and for that you need sharp engineers as well as coaches.

Legal department: everything is fixed with a “no”

The human being does not want messes and less so in hierarchical companies where the most important thing is not to make mistakes in order to maintain your position. For this reason, the legal department tends to carry out its work very strictly.

It is not that they are not right, probably “it can not be done” on paper, but you have to want to do it. Success is for the brave, so remember that the law is open to interpretation and always goes slower than technology.

Almost all successful startups have brought innovations that others dismissed as impossible. We even know a case in which innovation was able to force legal change, it just had to be requested.

Would Uber, Airbnb or Spotify exist if they had stopped at the least legal impediment?

Purchasing Department: everything is fixed with contracts

Another one of those issues that shows that you do not really understand everything that is happening is to let your purchasing department continue to act in the same way as it did 10 years ago.

This way of acting, with project specifications with a closed scope, scores by sections (the price that highest scores, of course) and penalties for non-compliance, are obviously incompatible with a relationship of trust.

These spreads prioritize hard relationships, if your provider is “your provider” it will never be “your partner” and, therefore, you will never be a team.

Why do you think startups with 10 people tend to get more than huge departments from hundreds of people? Because they are a team. Technology is not a cost center, but a fundamental part of your business.

The digital transformation is a profound renewal in companies, with an impact comparable to the industrial revolution of the eighteenth century. And a change of this magnitude is not solved with trainings, neither with tools nor with consulting reports, it is solved by “doing”.

You have to start transforming small groups or departments from start to finish, from the organizational model to the tools to be used, emphasizing the important thing: the necessary change of thinking.

Just as we have already thrown away (or hopefully so) the shirts with shoulder pads and bell-bottoms of the 80s, the roles with certain responsibility of the company must get rid of the old paradigms before initiating the change, because being digital is more to do with attitude than  knowledge.

]]> 0
How will machines understand us in the future? Wed, 14 Mar 2018 14:07:17 +0000 The concept of communication between humans and machines is a classic of science fiction, albeit a science fiction that seems to be almost within reach, with Siri, Alexa and other voice aides. But how did we get here?

There is a branch of Artificial Intelligence that has long studied how to make machines able to extract information from human language. This area is called Natural Language Processing or NLP.

In this post we will rely on the experience we have in Paradigma in Sentiment Analysis and we will illustrate the evolution of these technologies.

Sentiment Analysis

Within NLP there are many subareas, each of them trying to respond to a specific task of extracting information from natural language, since we are still far from achieving true cognitive intelligence.

Examples of these areas may be the Comprehension of Natural Language (NLU) that, along with Speech Transcription are the technologies that use the popular conversation bots recently.

Other examples of NLP can be the detection of topics in a text, entity detection (NER), and others of lower level such as the semantic analysis of the words of a text or the morphosyntactic analysis of sentences.

However, sentiment analysis tries to discern whether the connotation of a phrase is positive, negative or neutral. Normally the objective is to find and classify opinions with respect to a brand or product, but it can also be oriented more generally, simply to study the evolution of sentiment within a group.

On the other hand, it is also a wider area that tries to extract information from the language according to the meaning of the words used, for example, classify texts according to themes.

Finally, the extraction of emotions seeks to find the expressed or implicit emotions in communication,whether it be written or through audiovisual. It is, in a way, an evolution of the analysis of sentiment in which more dimensions than polarity are taken into account.

This can be done by categorizing the emotions by categories (joy, sadness, anger …) or by representing the emotions in a multidimensional space.

The beginnings of Data Analysis in Paradigma

The first Paradigma projects for sentiment analysis began to develop around 2010 and were based on the morphosyntactic analysis of words. Using the Freeling library , the morphological function of the words and their motto or root form was obtained. From this, rules were constructed and the words were classified into different types to create dictionaries.

With the combination of words and rules, the related text was analyzed in a specific entity. This analysis was oriented to medium texts, such as blog posts and forums.

Part of the effort was aimed at detecting when the entity was being talked about and locating spam messages. In addition, a dictionary was created for each project, so behind each project there was a great human work at play.

But let’s see how the evolution of Sentiment Analysis has been from that time to the present and what possibilities there will be in the future.

The irruption of social networks and the beginning of Big Data

The projects based on that model worked for a while, but soon new factors would appear that would forever alter the landscape of the reputation projects. On the one hand, the adoption of Twitter as a communication platform and, on the other, the appearance of processed Big Data.

Twitter became the main way to air opinions on the Internet and also in a user support channel. This caused many companies to start worrying about their reputation in this social network.

The limited length of the tweets and the volume of them forced to rethink the model of data analysis. Thanks to being finite texts, it was not necessary to make sure that all the opinions expressed in the text referred to the brand in question, nor did we have to worry about the cohesion of a text or anaphoras and cathaforas. In return, the volume of information to be analyzed grew steadily.

By being able to process the tweets individually, Hadoop MapReduce could soon be adopted as the technology with which to process the opinions, which also made it possible to deal with the increasing volume of tweets collected.

Among the projects that were based on this technology we can mention project MagnetMarket-as-a-service (both cofinanced by the CDTI), Eurosentiment Project, set within the financing framework of the EU’s FP7 as well as ad hoc solutions for projects.

MixedEmotions: Spark and emotion extraction in multimedia

Sentiment analysis has many applications, but sometimes it is not enough to draw good conclusions when dealing with huge amounts of data. Sometimes, something is needed in more detail.

One solution may be the extraction of emotions. In May 2015, MixedEmotions took off, a Project from Horizon2020 with Paradigma as the expert partner in Big Data.

The aim was very ambitious: to get a platform for the extraction of emotions from audio, text and video image. The consortium consisted of nine companies with different profiles.

The platform also had other NLP capabilities, such as sentiment analysis or entity extraction, but its main focus was the characterization and extraction of emotions.

The emotions extracted could be represented as categories (joy, sadness, anger, disgust and fear) or three-dimensional in the line of the PAD (Pleasure, Arousal, Dominance) model . Sentiment analysis modules are no longer based on lists and manual rules, but on techniques of  Machine Learning, mainly neuronal system networks.

Fort he distributed analysis we used Spark over Mesos, experiencing an improvement in many areas with respect to the development in the old Hadoop 1.x. Other technologies such as HDFS, Docker and Marathon were also used to manage microservices. The  MixedEmotions plaform is mostly open source and available to any user.

The future

Since we began to use sentiment analysis in Paradigma, it has evolved a lot. It has gone from being based on more or less complex rules to being based on Machine Learning techniques.

This evolution also goes from being a set of slow and costly processes to be deployed in distributed processing environments to analyzing large volumes of data. On the other hand, there are increasingly more tools for extracting information from texts that respond to the need for finer analysis than a simple good or bad interpretation.

All this makes it increasingly less profitable to create a solution for language analysis from scratch from libraries. In recent times, solutions from Internet giants for Natural Language Analysis in the cloud have appeared, for example in Google Cloud Platform, in Amazon Web Services, in Microsoft Azure and in IBM.

Google Cloud Platform offers the Cloud Natural Language service, with sentiment analysis and entity extraction capabilities in eight languages and detection of topics in English. It also has speech transcription technology with Speech API and conversational bots with Dialogflow.

In November 2017 Amazon launched Amazon Comprehend, with features of sentiment analysis, entity extraction and theme detection among others. Amazon also has Amazon Transcribe for voice-to-text conversion. Without forgetting about Amazon Lex, the conversational bot technology on which Amazon Alexa is based.

IBM’s natural language processing service is called Watson and has a service of Natural Language Understanding with ability to analyze sentiment and extract emotions, transcription of voice and conversational bots, among others.

Microsoft Azure has an artificial intelligence services section called Microsoft Cognitive Services, among which the Text Analytics service offer sentiment analysis.


Natural Language Analysis has evolved a lot since its origins. It seems clear that it is with the power of Machine Learning techniques where you can get more reliability in these processes, which makes it more attractive to use services in the cloud from giants like Amazon and Google.

But of course they are not the solution to every problem. There will be many cases where these tools are not appropriate and something more specific is needed.

In any case, it seems certain that the ways in which the machines understand us will continue to evolve and that we will see new tools go out to the market, possibly in the cloud, thanks to the processing power that Big Data techniques can bring to the Machine Learning area.

]]> 0
Please, stand down from that digital directors’ seat Mon, 05 Mar 2018 15:33:50 +0000 I just called my bank, but it has not been any odd call. I pick up the phone, it is not a strange or hidden number, it seems to be a normal mobile line. In spite of being the one who receives the call, on the other side, a pre-recorded voice tells me: “Hello, we will attend to you right away”, a second later: “Do not hang up, we will be with you immediately”.

This happens a couple of times more, but I endure as an interested observer, just for the pleasure of discovering new forms of mistreatment to the client.
Finally the machine seems to “connect” with someone on the other side, I hear a loud ambient noise with people talking in the background. I wait a couple of seconds, as nobody talks to me, I throw a couple of “hello?”. Nothing, two seconds later, I hang up.

Were we not in the customer era? All the Powerpoints of the world on digital transformation say so

I know who they are, they’ll call again. It is a digital bank, “son” of one of the traditional banks that denied everything digital for years and now disguises itself as a young person. One of those delayed attempts of digitalization that fulfills everything expected according to the manual of ‘Fixation’: it has cool colors as my partner Javi would say, a modern naming and their branding comes with a ‘Hello!’ Instead of a ‘Dear Customer’. Under their logo, a claim that seems to have understood the disruption that was already of the type: ‘we make it easy’, ‘with people’, ‘the new way of doing banking’ …

I have been called many times with offers of financial products totally out of line with my needs, depersonalized offers sent to “the entire database”, without any procedure to improve it even if I indicated to them that I was not interested in that offer or similar, for excluding reasons.

Neither personalization, nor Big Data or anything at all. They preferred to dynamite their resources and the possibilities of initial brand engagement based on interruption .

In addition, the only way to stop receiving calls is to send a letter to their headquarters, requesting to stop receiving offers (yes, a physical letter). Redesign of processes? What are you talking about?

In my work, I spend time talking and convincing clients about the importance of investing in design. In recent years, I have raised the intensity around the concept of Customer Experience and the design of services.

I try to elevate the word “design” and make it see that it covers aspects that go beyond a discipline focused on beautifying interfaces, to understand that this new and brilliant digital product is one more gear within a service that can be disastrous, such as what that bank is giving me.

To many I still manage to surprise them, precisely because we all hear these experiences. Even so, in the last months, as a result of so many events, talks, courses, meetups, and conferences it is already perceived with certain exhaustion, like that they have already heard it and it sounds like sirens chanting.

I am worried that we will start to suffer this – I call it – postdigital syndrome without having completely transformed, not even partially, seeing situations like the ones I have described and certainly you have lived too.

Some have so internalized the theory, that they believe that by adopting digital ways everything is done. Following this reasoning, to get fit the important thing is that one talks a lot about running.

And so, we find digital experts tired of being told about the digital transformation while still seeing the Baldwin-style customer funnel at Glengarry Glen Ross.

What a mess we have made! If the professionals knew what the transformation is, how is it possible to find tenders titled: “New customer area 100% Customer centric”, then on page 7 find the clause that tells me that functional decisions will be determined by API capabilities. Listen then, was it Customer Centric or API Centric?

We also have projects already located within an existing “digital transformation” process, whose renewal proposal must be delivered printed in hand in the client’s office in a sealed envelope. This is not a joke.

And what about that big bank that asks me to go to the branch to sign 5 pages of paper and get a simple change of card limits, or that the same bank last year sends me a letter to encourage me to use digital banking when I had been doing it regularly for a decade.

I guess they consider that Customer Experience is nothing more than the old “the customer is always right”. What is the difference? The main difference is that “The customer is always right” is not Customer Experience, but Customer Service; but also in its worst version, in reactive and antiquated servility: when the client complains, I attend to him, especially if he does it in the store and pretends to be a well-dressed man.

The proof that this style continues, is that today your complaints continue to be treated much better if you do it through social networks like Twitter (visible to others, like in a store), and your level of interest will be greater if you have more than 3000 followers.

To me, thinking quickly about it, I have been left unanswered by email many times: wine cellars that served me defective bottles, airlines that did not answer an email with doubts on the bill, etc.

On the other hand, a satisfactory customer experience is the result of proactive methods of service design, whose objective is to reduce friction in its provision. A fact that is achieved by designing them around the needs of people and also completely rethinking the processes with the new digital possibilities in mind.

Actually, the problem is not about not knowing what CX or UX is, the problem is not understanding how digital has changed our lives forever, the productive processes and of course, our consumption habits.

The Internet is not about marketing, but about redesigning processes. Of all the processes. From the very exploited payment method, to questioning if we want to continue serving our customers through a switchboard.

Whenever I detect people who have not understood, I recommend Genis Roca’s video about the digital society, now a classic. Normally they are usually people from outside the sector, but you always learn something after seeing it, even if you already dedicate yourself to “digitize”.

Realizing all this is not just “knowing” it, it’s like an epiphany that has happened to you or not. There are people who realized it 20 years ago, others 10, others 5, and there are people who have not understood it yet.

Let’s not dedicate more talks or more posts for this last group, let’s start giving space to brave organizations capable of ending expired processes. Either you have lived the epiphany or not, if you have not lived it, nothing happens, but please step down from that directors’ chair.

P.D .: If you have experienced any shocking, anachronistic or very “antidigital” experiences, I would love for you to write them in a comment.

]]> 0
Metrics in Agile: your opinion is interesting, but… I have data Mon, 26 Feb 2018 15:14:32 +0000 If you had data to predict what the winning number of the lottery would be, would you still choose a number because it looks pretty or ugly? In your projects you have data to predict and decide how to act based on empirical data, so flee from intuition.

Still today you hear phrases like “Scrum… isn’t that a hippy invention?”. These comments usually come from people accustomed to working according to traditional methods of software development, creating huge specification documents and intuitive planning, accustomed to seeing how those plans fail, to try to equate software development with the construction of a car or a building.

In an environment characterized by high uncertainty and constant and unpredictable changes, an empirical method must be used that, through constant deliveries, allows us to obtain the information and knowledge necessary to make decisions. This knowledge arises from the comparison between a hypothesis and the actual result obtained after delivery.

Therefore, the product strategy to be followed in Agile is to define an MVP (Minimum Viable Product), compare the results according to the pre-established strategic metrics (KPI’s), with the assumptions we have applied, correct them and re-iterate with the increase of knowledge obtained.

Types of metrics

Comparing it with the approach, the strategic metrics of which we spoke earlier, we could call them direct metrics, since they have a direct application on the value that we want to generate: economic benefit, social benefit, improvement of the company’s valuation…

These metrics inform us of the status of the strategic objectives of the company, but by themselves they do not give us enough information to know where we should put the focus to improve them. To do this, we must rely on circumstantial metrics, which are metrics that only add value through their aggregation and balancing.

When we compare the direct metrics with the circumstantial ones which come from every possible aspect of the development process… you will no longer require a fortune teller to know what to do.

You can even make measurements of aspects forgotten by the companies, such as the benefits of investments in training, sponsorships or improvements in the work environment.

We are going to name some metrics grouped following Jason Tice’s approach:

  1. Metrics on the health of the process. Focused on evaluating the activities required for delivery and the changes that occur during the entire development process: cumulative flow chart (allows us to see and compare at a glance the lead time, cycle time, WIP, size of the backlog…), control diagram, efficiency flow, time in progress vs time in process, block time per item…
  2. Metrics on deployments. Focused on the continuous delivery process: detected errors and resolution time, deployment time, successful deployment rate, stabilization time of a release, time between deployments with new functionality, cost per release, adoption ratio of a release/installation ratio.
  3. Metrics on the development of the product. They help to measure the alignment between the new functionalities developed with the real needs of the users: delivered business value, NPS, burndown risk, push/pull costs, product forecast, user use analytics.
  4. Metrics on the code. To measure the quality of the architecture and the code: unit test coverage rate, time needed to create the package, failure density, code complexity, unavailability ratio…
  5. Metrics on the equipment. Metrics on human factors, work environment, team commitment: humor/happiness/morality of the team, Gallup Q12, learning log, team seniority, transparency (customer access, data, how learning is shared, successes and failures)…

How to apply them

It depends a lot on the nature of the business. The same numbers of a metric can be positive in one specific business and negative in another.

Some tips:

  • Choose only those circumstantial metrics that help you get a direct metric. What change do you expect to cause? How could it be misinterpreted or perverted?
  • Choose the correct frequency with which you must take the data and the expiration of the experiment. How will you know that you no longer need it?
  • Always use them as trends, not as isolated numbers.
  • Never use a single metric. The team will comply with it, disregarding other aspects of the project. New defects that previously did not occur will be created.
  • Avoid useless metrics (vanity metrics): in general, those that focus on measuring the individual instead of the global team (lines of code per individual, individual points…) that lose focus on real value (number of new functionalities) deployed).
  • Maintain a holistic vision, reviewing the data as a whole.
  • Take into account your context, do not compare metrics applied on tasks with those applied on user stories, epics or bugs. Much less make comparisons between teams.
  • Choose the metrics by consensus with the team, which are not imposed.
  • Share information with stakeholders as soon as possible.

From they propose the Evidence-Based Management for Software Organizations (EBMSO), where they establish a specific framework of metrics that an organization dedicated to offering services through software should follow.

According to their point of view, the survival and success of an organization depends on 3 direct metrics or Key Value Measures (KVMs) that, in turn, rely on other circumstantial metrics:

  1. Current value: It indicates the current value of the organization in your market. It gives us a context, but it is not valid to know its value in the future..
    1. Income per employee: total income / number of employees.
    2.  Product cost ratio: Expenses in improvements (tools, coaching, events…).
    3.  Employee satisfaction:% of satisfied/dissatisfied employees.
    4.  Customer satisfaction:% of satisfied/dissatisfied customers.
  2. Time to market: Time it takes the organization to launch new features, services and products…
    1. Frequency of deployments: time between deployments that provide new functionalities.
    2. Stabilization of deployments: the use of bad development practices causes the need for time to make corrections, which also increases over time.
    3. Cycle time: time that passes until a functionality is delivered to the end user, including stabilization.
  3. Innovation capacity: It is considered a luxury in some organizations, but it is the opposite. Maintaining features that are not used requires spending a large part of the budget to maintain them instead of looking for new ones:
    1. Index of installed versions: How many users use the latest version compared to those who still use the maintenance versions.
    2. Usage index: % use of each functionality.
    3. Ratio of innovation:% of budget dedicated to innovation.
    4. Errors: % of bugs compared to the previous version.

We have reviewed the type of metrics, tips for applying them and even a specific application strategy. Your company is perfectly designed for the results you are getting.

If you want to improve them, do not expect things to just happen, you have everything you need to design the system. Set your goals and start measuring now!

]]> 0
The big lie of the Bimodal IT Mon, 19 Feb 2018 15:07:17 +0000 The term Bimodal IT was created by Gartner and MckInsey at the end of 2014, to refer to the idea that companies which aren’t born in the digital world must be able to work in two complementary work modes, which allow them to compete on equal terms with digital native companies.

Mode 1 provides a traditional operation for the most predictable areas of the company, where robustness and reliability prevail. Mode 2, however, is a much more agile operation for areas with a greater degree of uncertainty, where speed and adaptation to the new demands of the Internet prevail.

Encouraged by this idea, many large Spanish companies have been structured around these two modes, building IT organizations of two speeds: a first speed with mainframe technologies and waterfall methodologies to take charge of the core business of the company that, supposedly, is hardly modified over time; and the second speed with open-source technologies and agile methodologies, focused on the development of mobile and front-end Web applications, under the direction of the new CDO’s.

But, to what extent has this system worked?

Personally, this idea of two speeds within the same company has never convinced me. I think it is wrong for those who think that the core of their business will not change in the next 10 years, with the only justification that in the last decade it has not changed.

I also believe that it is impossible to create a group that works agilely within a company that works in a traditional way. It is very difficult for this agile group to work autonomously, and sooner or later it will be affected by dependencies with the traditional part of the company.

My opinion is unimportant next to Garner or MckInsey, but after several years working on processes of digital transformation, encouraged by some discordant opinions like Martin Fowler and also by some internal talk, today I dare say more confidently that  idea of Bimodal IT does not fit, much less under the proposal that both modes should coexist in time in the same company.

I was fortunate to participate in the beginning of 2015 the creation of this famous mode 2 in one of the great Spanish banks. A small innovation team was created within the bank, supported by scrum and open-source technologies. The result was several pilot projects with good ideas in a few weeks, but when integrating these pilots into the bank … That’s where the problem came! We were hit by the reality of a bank.

Only small adaptations were needed in the core to be able to implement the projects in the market, but many of these projects did not pass that test. To try to eliminate frictions between the two work modes we try to implement the concept of the cultural bubble of Michael Sahota. Creating some figures that would act as a proxy between both worlds, so that the bureaucracy of the traditional world will not affect the agility of the new working group. A patch that did not solve the real problem.

I also had the opportunity to participate at the end of 2015 in a project to define the way of working in the new digital area of ​​a major Spanish insurer. The decision of this company was to give this digital area responsibility for the front Web, using this new way of working: with new technologies, scrum, cloud, new tools, etc.

While the current departments would be responsible for the backend, maintaining the mainframe, the current hosting and waterfall methodologies of always. In this way, they covered the entire backend with an API so that these two work modes coexisted in perfect harmony. But after a few months we have seen that this does not work.


It is true that the front developments are much better, but the reality is that if the front is supported on a back that is not scalable or can be modified in an agile way, this front ends up infecting these problems. That is why this company has now gone a step further and we are helping them in an ambitious project: redoing thier mainframe with new technologies.

Finally, although I have not worked directly on the project, I know from my colleagues at Paradigma the experience of Lowi, the Vodafone virtual operator that was born at the end of 2014. In this project, an autonomous team was created within Vodafone that built the project as if it were a startup within the brand, with scrum, new technologies and everything hosted in Amazon Web Services.

In this case the division was not made by the type of software, but by business model, and it is this reason that has made the difference with the two previous examples. Lowi works as an independent company, a 100% digital company that was launched successfully after only 4 months of development and that continues to expand its offer in an agile manner.

My conclusions after these three experiences is clear: the digital transformation is not a department nor is it a technological update, it is a profound change, a revolution that affects the entire company from the CEO to the last call center operator.

From this point of view, the CDO is not the new person in charge of the websites of the companies or of the mobile applications as it is being understood in Spain, the CDO must be the catalyst that extends the germ of the digitalization throughout the company.

The big companies have seen in the Bimodal IT the perfect excuse not to make a deep change, not to lose their stagnant hierarchical structures and, above all, not to get their hands on the mainframe, their core business.

A kind of monster that is very scary, that has been growing larger for the last 20 years and that only a couple of people have seen from the inside. But today this situation is no longer sustainable or justifiable, the only possible alternative to survive on the Internet is to slowly flee from this monster, one step at a time.


A company cannot operate with two speeds in a permanent way. Mode 2 should be understood only as a first step for companies with years of history to begin a path that should inevitably lead to the whole company adopting the practices and technologies that come from the digital world.

During this transition period, which is essential in most cases, you should not create a two-speed company based on the type of software you manage, but it should be divided according to business criteria, otherwise mode 2 will always be ballasted by its dependencies with mode 1.

The correct way to approach the digital transformation is to draw up an execution plan that will transform vertical business lines, endowed with the necessary independence to digitize them from front to back, and thus gradually change the whole company.

]]> 0
Conversion Rate Optimization in eCommerce Tue, 13 Feb 2018 08:56:57 +0000 If you ever sit at a meeting of e-tailers, you will hear the words “conversion rate” sooner than later, followed by percentages, all invariably with two decimal positions. E-tailers brag about their conversion rates like fishermen about their catches: “My conversion rate is 2.89%” or “My category [sic] of pet food converts at a 4.23%” followed by appreciative nods.

eCommerce is transparent in real time

Imagine that you are in charge of the e-commerce division of a retailer with thousands of euros of total revenue. A new version of your website is ready to launch in a few hours after many months of work.

Admittedly the current online turnover is nothing to write home about, but boy, the monthly growth of the online business is by far the best of all the areas of the retailer.

The investment of the new version is significant: “It is our future“, your CEO reminded you earlier today. One of the beauties of e-commerce is that the data of sales are available in real time, so you are a few days away from knowing whether all this endeavour will pay off or otherwise.

Nobody can blame you for feeling a bit twitchy just before pressing the button “Enter” that releases the new version.

The curse of the new versions

When McLaren joined forces with Honda and Fernando Alonso in 20176, many expected that the best builder of cars, the -potentially- best engine manufacturer and -arguably- the best F1 pilot would create an instant winning combination. The resulting epic fail is history… and the halo of the picture of the 2017 prototype added insult to injury.

Have you resisted to try the new version of your online bank or, say, the more recent Google Calendar? And when you have used the new one, have you come back to the previous version if the website allowed you to? I have, and it is only natural. Changes of a familiar interface increase the cognitive load.

Many online services are cautious about introducing new versions of their interfaces. In this example Typeform makes it easy for users to try the new version and how and when to revert to the old one.

New versions of an online shop that significantly change the front or back end of the website change, more often than not, the conversion rate. The reasons for this change are a mix of:

  • User Experience.
  • Search-engine optimization.
  • Technical performance.

It is easy and cheap to get hard, actionable data about SEO and performance metrics like page speed. Fresh data and insights lead to adjustments and improvements of the new version with measurable impact.

User experience, however, is a matter of perceptions that are harder to measure meaningfully. Behavioural science is a fascinating topic that, for an e-tailer, is summarised into a single metric, again, the conversion rate.

Web analytics

The first step in your CRO process consists of asking your data analysts as many questions as you can imagine: how are visitors behaving before and after the new version? Which are the flow of navigation that presents the most remarkable changes in bounce rate, depth of the visit and conversion rates? Are the conversion of branded searches a good control group before and after the launch?

A rule of thumb with CRO is to invest 3 times as much in research than in coming up with ideas to try to improve the conversion rate. Know yourself before you decide to change.

Conversion Rate Optimization CRO

How can we drive the user experience to improve our conversion rate?

The expertise and sensibility of UX experts are invaluable. UX practitioners are particularly familiar with the mental models that people have about how websites work based on their past experiences visiting other sites, so consulting with them is a second step in the process of optimising your conversion rate.

For instance, the burger nav element of responsive websites is detested by many designers and UX consultants. They claim that many users do not understand the icon and what it is for.

Designers hate these three parallel lines. They are the icon known as side menu, navigation drawer, or a hamburger, that hides the elements of a desktop menu. Such designers are insensitive to the fact that the character on which the nav burger is based, Unicode U+2630 is called the Trigram for Heaven.

A dilemma: product pages vs category pages

Category pages usually capture less organic traffic than product pages… and they tend to convert worse.

The table below contains real figures of an e-commerce website capturing more than one million visits monthly. Product pages capture more than twice the number of visits of organic traffic of category pages. Product pages convert 50% better than category pages. In this example, Product pages are 3 times more valuable than category pages.

Landing pages Capture organic % over total % Conversion Rate orders / visits
Category pages 23.72% 0.63%
Product pages 49.65% 0.93%

Category pages are great to present the products in the ranking that maximises sales. The most common rankers of category pages are price, relevance and the score that the store decides. The latter is usually an algorithm weighting operative margin per reference and factors pertaining the business like users’ preference, providers rank, etc.

We know that some users have a search intent in organic for which category pages fit better than product ones. Examples of this can be “Lego” which is so generic that it probably is about browsing the catalogue of tens of sets of the brand. A search containing the keywords “First Order Heavy Assault Walker” expects a product page.

A user searching “First Order Heavy Assault Walker” expects a result of a product page of the reference, not a category one about other sets of Lego.

Category pages are thus relevant in some instances and they do eventually convert nevertheless. In fact, marketers present recommendations on product pages because the behaviour flow of users includes

The search engine

Search engine technology is usually very important in e-commerce. We found that sessions with search involved at some point were 80% of the total visits to a large e-commerce website. The searches converted seven times better than sessions without them. Logged-in customers did also use search as intensively despite being familiar with the navigation and the inventory.

An e-tailer wants to: improve the performance of the search engine and make the search functionality accessible, clear and easy to use.

]]> 0
Oh no, I hired a Scrum Master and thought it was something else! Thu, 08 Feb 2018 13:18:46 +0000 In a recent post I explained the role of the Scrum Master and many of the tasks the role carries out. However, reflecting on what I wrote, I realized that, at times, this role is misunderstood and misused within companies.

Perhaps it is because we come from an overly hierarchical conception of the working world where we have inheritances from the past and a need to find leaders and one-person responsibilities.

This inherited culture broth is, among other factors, one of the reasons why, around the figure of the Scrum Master, false myths which are difficult to dismantle have arisen with force. In this post we explain what are the most frequent misunderstandings while trying to correct them.

Error 1: the tyrant

Before, in the computer science prior to the Agile Manifesto, we had project managers, who were in charge of coordinating and, above all, managing the different roles that they had in their development team: analysts, developers, testers, etc.

These developed “the project” through a  Waterfall/RUP in which everything “flowed” through requirements, eternal analysis documents, developments that went on in time and endless test cycles.

The project manager was a semi-God, a tyrant (of course there were good bosses, the problem was that the method they used wasn’t) that he knew everything and that he orchestrated by means of precious Gantt diagrams that were never fulfilled.

When the client had a problem, there was the project manager, to whip up the team in the resolution of incidents via the whip or in the development of new features: “How much do you have left? How are you going? Do you already have it?”. As if by repeating it many times the software developed faster.

When the Agile Manifesto came and frameworks such as Scrum, which were born since then, we began to speak in “another” language: leadership, multifunctional teams, product instead of project, early delivery of value…

But not the whole company adapted. It remained a trend of “the computer people” when in fact it had to go further, as a change of organizational mentality (Digital Transformation), because if not… you do not know it, but you are dead.

When an organization is not adapted to this change of culture, the most normal thing is to do the conversion of the project manager to the Scrum Master in a natural way. After all, he sees himself as a team leader, project leader, unit leader, etc.

Error 2: the sweeper

Another common misunderstanding of this figure is the Scrum Master sweeper. I have heard the comment of those who think that the Scrum Master has “free time”, which may also have its origin in the ignorance of the figure both in the development teams and in the people who play this role.

Then, the sweeper, mistakenly, tends to occupy that time in pursuing the tasks that nobody wants to perform because they are tedious or motivate the team a little:

  • The one who schedules the meetings of the Scrum events, takes notes and makes minutes as secretary.
  • The one who every day unsuccessfully remembers the good practices of Scrum.
  • The one who looks at logs or code of a very urgent incident that nobody attends.
  • The one in charge of collecting the post-it or updating boards.

This point of being the one that is sweeping what nobody doesn’t do fits very well with this framework.

It is true that we are a team (although the Scrum Master is not a member of the development team, this is important) and it is good that we all help each other, but we must not fall into this bad practice, but rather encourage co-responsibility and collaboration between everybody.

Error 3: the fire extinguisher

Following the above, and raised to the maximum power, we would have the fire extinguisher that is “the sweeper” but also must solve all the problems that arise, ie, the famous impediments.

It is said that the Scrum Master “solves” impediments, but not everything fits into this definition: should it be the one that if a developer lacks a monitor asks for it? Can not he do it himself? Is not our organization sufficiently agile to solve that demand? Is it still true that in these times we need valid interlocutors, intermediaries, people who give approvals or signatures, and chinese whispers?

When I arrived at Paradigma I needed a monitor and put a post-it on a board with my need and mail. After receiving the supplies, I had it at my table in less than a week, that’s Agile!

From my experience, something that we have to work on perseveringly is self-organization. It is very easy to define how we want to work, but it is very difficult to work in practice in that way, with perseverance and responsibility, in order to achieve results.

Does anyone still think that Scrum is a lax and lazy framework for work? Some said this about XP in its day. For me, it is the opposite, it is demanding and keeps each person on the team tense.

However, there are people who need help, since they are not used to that self-organization. Sometimes, in my teams, before the magical question of “what do I do now?” Formulated by some member of the team directly towards me as a Scrum Master, I turned back and asked: “Who are you talking to?”.

It is necessary to find a way for people, who have previously been treated as servile sheep and have become accustomed to asking for permission, to be given the initiative and to act with responsibility and purpose. The third time I’ve made that joke to someone on the team, he has stopped looking at me, to look at himself and his team.

Error 4: the representative

And it is that the Scrum Master is not the representative of the team on Earth either, so if someone has to take responsibility for the actions of the Development team, be their spokesperson. Also, if someone wants to talk to the team, act as the intermediary Scrum Master or if I have a problem with someone I tell Papa Scrum.

Also within this misunderstood role we could have the reverse side of the coin: the Scrum Master protector who takes care of his owlets until one day, which may never arrive, they leave his nest.

Error 5: the Sprint Police

In addition to all those who have been influenced or on their own initiative have finished in the previous (tyrant, broom, fire-extinguisher, representative…), are those who voluntarily decide to play the role of the Sprint policeman: yes, I know what is Scrum , I know what it promotes, so I’m going to dedicate my Sprint time to evaluate how you do as a team “the Scrum”. But yes, do not count on me to solve any problem, or throw a cable when you need it… my job here is Scrum, do you want me to spell it out?

It is one thing to be the Jiminy Cricket of Scrum, which we all have had to do at some point with some clueless, and another is to reach this extreme.

If you start thinking about your work environments, thousands of examples will come to your mind too, of course this does not pretend to be a closed list. I encourage you in the comments also to put your experiences.

Is there anything positive about all this?

Now comes the moment of the positive part… Yes, there is. Little by little and more and more, all this is better understood and things are getting better and better.

Each time the clients understand better that they can not live without transforming themselves. Each time the teams think more often “it’s cool to commit! that it’s cool to have a boss!”. Every time the professionals in the computer industry are better trained. Every time saying “oh no, I hired a Scrum Master and thought it was something else!” happens less often.

]]> 0
Estimates, reality or fiction? Mon, 29 Jan 2018 08:13:32 +0000 Estimates, that great devil that sneaks into our day to day and marks us. Some of the questions that most people who are starting in the Agile world have asked me are “how do you estimate  in Agile?” or “how do you do to tell the customer how long it will take?”.

In Agile, the estimation phase has matured. We start from the fact that the software is complex and, therefore, there is uncertainty. It is impossible to know what will happen. Software professionals discover it project after project. It is something that only experience can tell us.

Let’s review the different estimation techniques and see a small analysis of each of them to better understand this phase of Agile.

1. Estimation in hours

The estimate based on hours is the most common. Basically it is to indicate the time that we are going to take in carrying out a task. With the estimate in hours we usually make several mistakes. The first thing we commit is that they ask us for a time estimate and… we give some time!

Let’s give an example, imagine that they ask you “how long do you take to go from Madrid to Barcelona by car?”. The first thing we do is think and quickly say “about 6 hours”.

Imagine that now they say “Perfect! Well, you leave tomorrow, Friday at 2:00 p.m., with 2 babies in the car, with a Renault 5 and without being able to use tolls”. Typically, our reaction is the following: “No! With those conditions it would be more time”.

We see this particular case very often, we estimate a time based on an idea without knowing the risks associated with the task. Normally we solve it with the so-called “mattressing”.

The “mattressing” is to make the following reflection: “We have estimated this project in 1,000 hours, we are going to say 1,300 in case something happens”.

The problem of the “mattress” is that it is not transparent, it is not honest, deep down you are cheating. This type of practice occurs because, many times, we focus on negotiating instead of producing software with value.

In the traditional world, this is solved with the Risk Plan, which includes everything we believe could happen and the cost that it would entail if it occurred. In this way we try to make as few mistakes as possible.

The problem of estimating in hours with a Risk Plan is that, in complex environments where it is not possible to predict what is going to happen, it does not work. Unfortunately, for us, the software is complex and in these environments the only way to work is “try-feel-respond”.

2. Estimation in points or “history points”

A “story point” represents a quantity of work that we have to perform. There are teams that confuse the technique of estimation by hours and the estimation in points because they associate time with points: “a point is a day of work”. Obviously, if we make that analogy we are really estimating in time.

Let’s see it through an example. Imagine that we have to paint a room of 100 square meters. An expert painter, who paints 50 meters a day, will take much less than a painter who does 10 meters a day. But for both, it’s the same job! In this example, 1 square meter would be 1 point. This is the advantage of point system, it is easier to reach a consensus as a team.

The point estimate is a relative estimate. This means that tasks are estimated by comparing them with those already estimated. If we say that a task is 3 points with respect to another of 1 point, what we are transmitting is that it will take 3 times more work.

The planning poker technique is used to estimate points. It is very useful because it allows us to have conversations about how to do the backlog items.

The best advice I can give for the estimation in points, is that they are only estimated at the level of User History or Product Backlog Item.

The ideal is that we take an item and divide it into the tasks that we believe we must do. Then, together, we estimate the total work of that item, even though each one of us does a part.

3. Estimate in sizes

Given that many teams have difficulty spending hours on points because they end up associating time with the points, there is an intermediate technique: associate T-shirt sizes with the backlog items: XS, S, M, L, XL.

Since you cannot compare some sizes with others at the numerical level, there are those who count the sizes afterwards. Each size is associated with a number following the Fibonacci series. Once the team matures, it’s time to switch to the points system.

There is something that we cannot lose sight of in this technique. If an item is marked with a certain size, the same item (after time) must be marked with the same size, although now we have more expertise.

The reason is the same as with the example of the painter, the room will always be the same, regardless of whether we paint faster now.

4. Estimation in PBIs

Here comes the star estimate! A long time ago we learned this technique through Jerónimo Palacios and it is the most scientific bet. Remember that Scrum is based on empiricism: as we gain experience, we can gain in predictability.

The estimation technique in PBIs measures the amount of Product Backlog Items (PBIs) that we are capable of doing in a Sprint. The first thing we tend to think about is it depends on the size of each GDP!

Imagine that all the PBIs had a similar size, this technique would be ideal, it would tell us with an interval our ability to work in a Sprint.

For example, after several Sprints we can ensure that our team makes [7-11] PBIs per Sprint. With this data our Product Owner can make projections about the future of the product.

Let’s go to the worst case: all the PBIs are different. What will happen is that our speed would be measured in a much larger interval, for example [4-14] PBIs by Sprint. In this case we are much less predictable.

If we want to improve our predictability, our Product Owner will have to focus on grouping small PBIs and dividing large ones to achieve that homogeneity (and thus improving the data).

Here is the key! Our Product Owner should determine how predictable he or she wants to be. If you want to be more reliable you will have to homogenize. Many may think “if my team has been doing between [7-11] PBIs and suddenly the Product Owner introduces very large PBIs, the team will not give them time”.

Remember that in Scrum estimates are made and are not commitments. If suddenly we are asked for very large PBIs, what will happen is that this Sprint will be less than anticipated and our data will be updated to the new reality.

The great advantage of this method is that it prevents us from “throwing ourselves into the abyss” without writing a line of code. Being a method based on experience, you need Sprints to start running.

Really the points and the hours too, but it is more probable that we give data too soon and that we generate frustration when not fulfilling it.


The conclusion we can draw is simple: you can estimate, but use the estimate as an indicator of happiness in which if you meet what you said you get a reward and, otherwise,  punishment if it does not work. Estimating is good for many things, but not to grade the success of a project. What’s more, you can fulfil your estimate and still nobody wants the software.

We can say that estimates are important in controlled environments. In complex environments investing a lot of time estimating things that are going to change, that are not defined or that we do not know, generates a lot of unhappiness. Let’s focus on taking product and, more than estimating, let’s use our experience and not our imagination.

]]> 0
Agile & Scrum in Digital Transformation Tue, 23 Jan 2018 15:47:05 +0000 If we search Google for “digital transformation” we find endless meanings and interpretations. It is curious that, at this point where the term is already so overused, there is no clear definition.

At Paradigma we realized the importance of the concept of digital transformation 10 years ago. We were born as a digital company and now, a decade later, after having helped multiple companies on their way to becoming digital, we dare to give our own “version” about what Digital Transformation is for us.

Technology, Business and Culture

Business, Technology and Culture are the three concepts (the three pillars) where we support any project that wants to start the journey towards digital transformation. For this, in the first place, we must understand the Business and understand the importance of exploiting it on a digital level.

Second, we have Technology, which helps us move our business to the Internet. Finally, we must have Culture, the modus operandi of how to make software using the best technology to improve the business.

Here comes my first reflection. There are large companies that already have their business on the Internet and the technology they need they buy it. Why do not we consider them transformed? The main reason is because their way of making software has not changed.

Watch out! If we think that the fault is the development of software then everything will point towards the IT area. And what really fails is the way to deliver value to customers. Everyone participates in the delivery of value, so everyone fails!

What is delivering value?

In this case I like to highlight the example of Jeff Patton on the concept of “value”. Imagine that we have to deliver 20€ to our customer. In the traditional model we would have a ticket cut into twenty parts and our job would be to recompose that ticket on a specific date.

The drawback is that it is likely that when the date arrives we do not have the full ticket and, therefore, the value delivered is zero. In the Agile model what we would do would be to collect 1 € coins and deliver them as soon as possible to the user, so that, even though we do not have € 20 on the date, we have delivered value along the way and the user has been able to use it. .

Therefore, if you are not able to deliver fast value you will not be transformed. Or change your processes based on plans that are never met or you can not compete on the Internet, even in the offline environment.

Flow efficiency VS Resource efficiency

An important debate that every company must address is the efficiency of flow faced with the efficiency of resources. In the traditional model the objective has always been to keep people busy all the time; while the Internet model the priority is to give the best possible service, without obsessing over time (in terms of occupancy).

We can see the best example we can find in the hands of Jerónimo Palacios. Palacios puts us in situation: imagine that you wake up one night with a lump in the neck. The scare is important and you decide to go quickly to the doctor.

After waiting three days for you to attend, the doctor sends you to the specialist (a step that you already intuited); After two months, the specialist asks you for tests and, after another two months, he gives you a diagnosis: “You do not have anything, you can go home quietly”. And what about those four months of anguish? The model of public health seeks the efficiency of resources where everyone is busy.

Now we contrast the example with a private hospital. In that hospital they have many specialists with “time” waiting to take care of patients. If you arrive in the morning with your lump in your neck, during the day several doctors will treat you, they will do the tests in the day and they will give you your diagnosis. The drawback in this model is that it is more expensive but… what experience does the user take?

Here is the key, the optimization of the flow helps us to improve the experience and satisfaction of the users, but it has a higher cost. That cost more does not mean that it is not profitable, on the contrary, if I get to the market first I can make the investment profitable.

Pokémon Go is a very graphic example. The game came to light in the summer of 2016 and already at Christmas of the same year, just 6 months later, it had lost millions of followers and had “gone out of style”.

A digital company could, from the first moment, take advantage of the “wave” to obtain benefits. For this you will have “unoccupied” people waiting to take advantage of these opportunities.

A traditional company would first have to identify the opportunity, then generate a business case to study the viability to later join a committee that approved the “project”. Then, make a bid with suppliers, choose the best bidder and start. This provider would have to assemble the equipment, take requirements and start building. By the time they are finished, nobody will play the Pokémon!

Perfect, we already know why we have to change our organization and our culture. How do we do it? For me the best answer is to incorporate Agile in all areas of the organization.

Agile incorporates flow efficiency, incorporates self-organization of equipment and incorporates competitiveness in the market. Within Agile, the most widespread framework is Scrum although you could bet on others like Kanban.

Because of this, Agile & Scrum have a lot to say about Digital Transformation,  by not incorporating Scrum Master, Product Owner or Agile Coach figures into your teams, you will hardly get a lasting Transformation.

Some general advice we can give to address this organizational and cultural change (remember that each company has different contexts):

  • Having a sponsor: The person who supports this initiative must be the highest possible within the prevailing hierarchy, it is essential.
  • Mark the rhythm: Transforming is like losing weight, no matter how good the nutritionist is, you have to decide at what pace you want to do it.
  • Transformation Strategy: Normally there are two paths, bottom-up or top-down. In the first we usually get value before, while in the second we will obtain the necessary support from the management (or the famous sponsor). The best thing is to do it in parallel and always bet on the people most open to the changes.
  • Transformation Backlog: Instead of “planning the transformation”, try to have a backlog with all the initiatives you want to carry out, prioritize and order with your sponsor and do not try to go faster than you can.
  • Deliver value: Learn to deliver fast value and maintain it over time.
  • Urgency Feeling: Transformations occur if there is a sense of “haste” on the part of the organization.
  • Choose people well: When there is a big change there is always someone who is in favor, who is neutral and who is against. Detect and bet on the first to be the “leaders” of the change.
  • Extension by virus: Changes will occur by contagion, if people observe the team next to change, it is likely that they will also be encouraged to change.
  • Avoid mistakes: Learn from your failures, implement inspection and adaptation moments that allow you to analyze your failures to avoid them.
  • Beware of critical projects: Addressing major changes in critical areas can lead to crashes. Choose very well which battles to fight and always building a strong change that does not fall apart.

We know that Digital Transformation has become a fashionable concept. For agilistas it goes much further, it is a wonderful opportunity that opens a wide range of opportunities to change the world.

All the companies that believe it, that bet hard on it will surely reach places they did not expect.

]]> 0
30 things you should know about the Product Owner Mon, 15 Jan 2018 14:58:20 +0000 A while ago, while debating with a teammate about the roles, artifacts and events that exist within Scrum, we realized that there are many doubts about the role of the Product Owner.

As a result of this debate, I have decided to shed some light on this profile and highlight 30 realities about the role of the Product Owner in Scrum.

With respect to the Scrum Team

1. The Product Owner is another member of the Scrum Team. Perhaps the clearest and most obvious, but best not to take anything for granted.

2. It is not the same as a traditional Project Manager.

3. The Product Owner must be a single person, under no circumstances multiple people will share this role or it will be played by a committee. This helps us not only to simplify and streamline communications, but when prioritizing the backlog, no conflicts will be generated.

4. They are not responsible for the progress status of the development during the Sprint, this is the responsibility of the Development Team.

5. They must work together with the Development Team to develop a Sprint Goal. This is carried out in the Sprint Planning and it is likely that the Product Owner comes with a defined business objective but that it must be adjusted along with the Development Team throughout the event.

6. If they work together with multiple teams for the same product, they will only have one Product Backlog, in no case one per team. This will help to have a unique and global vision of the entire product, and also anticipate dependencies.

With respect to artifacts

7. They can not modify the Sprint Backlog, since this is an artifact that belongs to the Development Team.

8. They are the owner of the Product Backlog, nobody, absolutely nobody else can manage this artifact, and they can not delegate its management.

9. Must be the one to monitor and share the progress of the Product Backlog.

10. Is responsible for creating, maintaining and ordering the Product Backlog. They can ask for help from the rest of the Scrum Team. For example, they can ask the Development Team for help writing the Stories and the Scrum Master can help with the best techniques to maintain and sort it.

11. They can update the Product Backlog when they consider. Remember that the Product Backlog is an artifact that is alive therefore it can change continuously (as much as the Product Owner considers).

12. They must ensure that the Product Backlog maximizes the value of the product and represents the needs of the stakeholders. For this, they must encourage feedback not only from stakeholders, but also from the market.

13. They can rely on the Development Team to refine the Product Backlog. This work is very important, because it helps us to anticipate situations, to detail more those PBIs that can be addressed in the next Sprint Planning, identify dependencies …

14. Must collaborate with stakeholders, user groups and product managers to get them involved and extract ideas to incorporate in the Product Backlog.

15. They can add a catalog by “points of value” to the PBI and order it based on the value that each item contributes to the product. In addition, they must take into account the dependencies among other products, backlog items, areas … for the ordering of the Product Backlog.

16. They can delegate the User Stories script to the Development Team.

17. They will be in charge of clarifying the requirements of the Product Backlog if the Development Team needs it.

18. They are not responsible for making the effort estimates of the Product Backlog items, but can provide more detail on the definition of the items, helping the Development Team to refine the estimate.

With regard to events

19. They must attend the Sprint Retrospective, as this is the perfect opportunity to inspect and create an improvement plan about the Scrum Team.

20. They must summon the stakeholders to the Sprint Review.

21. They must provide the Sprint Review and in it they must (and can count on the help of the rest of the Scrum Team):

  • Review the current status of the Product Backlog.
  • Inspect the product increase.
  • Ensure that the items delivered comply with the Definition of Done (DoD).
  • Inspect, together with stakeholders, market changes and the potential use of the product.
  • Update the Product Backlog.
  • They could also make projections about probable release dates based on the speed of the Development Team.

22. They can not change the start or end date of a Sprint. The duration of the Sprint is something that defines the Development Team and must be fixed in time. The Product Owner can not influence this aspect.

23. They can cancel a Sprint as long as the Sprint Goal is obsolete. This situation is extremely abnormal, but it could be the case.

Regarding the product

24. They are responsible for the entire life cycle of the product.

25. They are in charge of monitoring the TCO (Total Cost of Ownership) and this entails contemplating all the investments (conception, development, operation and maintenance) to be made in the product

26. They should try to receive feedback from the market by frequently releasing product increments. Something that we constantly repeat is “inspect and adapt” and this is something that can be applied not only to the method of work, but to the product.

27. Must be the one who knows the most about the progress towards the business objective or the launch (of an increase) of the product.

28. Decide when an increase of product to production is released. The Development Team must ensure that this increase meets the needs to be released to production.

Of general scope

29. Must have the ability to decide, to influence the organization and have time. In many occasions we can find that the Product Owner occupies a high position in organizations and this can have a double reading: the positive one is that they will have the capacity to influence the organization and the negative that consequently they will have a complicated agenda and little time.

30. The Product Owner does not choose who or how. It is the Development Team that performs the tasks and chooses how to do it, while the Product Owner indicates what (to do), reflecting it in the Product Backlog with items.

]]> 0