Bitacora: personas

Introduction

This is the third of a series of articles about Bitacora. Please read the previous ones to get full context:
  1. The diary (aka bitácora): towards alignment in distributed environment.
  2. Bitacora: environment definition.

The environment description is incomplete without the personas. I like this concept for many reasons but the main one is because I get extremely annoyed by the use of the word user.

When designing a product/service, it is hard to agree on what a user is, specially in engineering environments. In marketing/product environments, in general is in the DNA of those involved in product design to differentiate buyers from consumers (users). Market segmentation is understood by default. In my experience, this is not always the case in engineering environments.

I must admit that I do not use this concept every time since again, in my experience, engineers tend to show a high resistance to this concept, specially those who have direct contact to users, that is, those who work in open and collaborative environments. They tend to consider it mainly a simplification not of a representation.

Groups

We will assume there are 4 groups/roles involved in our scenario. Each group will be represented/formed by one or several personas. To label the groups, I will use names associated with roles you probably are familiar with, which is not a good practice since it limits their potential translation to a different scenarios. I do it so it becomes easier for you to identify them. The groups, based on its interaction with Bitacora are:

  1. Product team: professionals included in the team that will develop the product.
  2. Customer representative: professionals in charge of the requirements/backlog. Responsible for the product.
  3. Senior manager: professional in charge of the above groups.
  4. Supporting actors: people that interact with the team and are needed to develop/launch the product. They can be part of the company, the open source community that develops the technology the product is based upon or the sponsor.

If this blog series would try to reflect the Bitacora design process sequentially, the number of personas, even groups, should be lower, increasing them when necessary during the design or development process.

Product team

 I have considered 4 personas:
  •  Junior developer (jdev)
  • Senior Developer (sdev)
  • Artist (art)
  • Scrum master (smast)
persona_kareem
persona_james
persona_lisa
persona_byron

Artist represent non-technical profiles technical teams might include like domain experts, communication experts, etc. At this stage, defining 4 personas is not the right thing to do. Two (scrum master and the rest) would have been enough. only when going into details, the four personas will make sense.

Customer representative

I have considered two personas:
  • Product owner (pdm)
  • Sponsor (spon)
persona_earvin
persona_ac
Like in the previous case, one persona is enough for most of the bitacora design process.

Senior manager

I have considered a single persona, the engineering Vice President, which is the most common non-executive senior manager (EVP).

persona_michael

Contributor

I have considered three personas:
  • Marketeer (mark)
  • FLOSS community member (cmem)
  • HR representative (hrep)
persona_candece
persona_kurt
persona_tina

The Marketeer could also be any other professional within the company that interacts with the team. The FLOSS community member could also be an external consultant/domain expert contracted to help the team.

As in the previous cases, for most initial stages of the process we will follow, the first two personas could be considered as one. The third one has a very specific and limited role in this design, based on my experience, so it could be ignored or somehow included in the senior manager persona. I will refer to it in very few (but relevant) cases.

For a close follow up you might want to download the slides.

The cliparts has been taken from clker.com and 1001freedownloads.com If

Conclusion

As you can see, I have considered 11 personas, which is a lot at this point. But I started with 5 which must be considered the main ones:

  1. Engineer
  2. Scrum master
  3. Product owner
  4. EVP
  5. FLOSS community member.

So from now own I will refer to them by their names or roles. Based on your input and the process design development I might refine them.

Series of articles

  1. The diary (aka bitácora): towards alignment in distributed environment.
  2. Bitacora: environment definition.
  3. Bitacora: personas
  4. Bitacora: Impact mapping

The following one will describe the impact mapping. This section will be updated with the coming articles.

Agustin Benito Bethencourt (Toscalix)
@toscalix
Linkedin profile: http://linkedin.com/in/toscalix

Bitacora: environment definition

Introduction

This is the second of a series of articles about Bitacora. Please read the first one to get full context.

In order to understand the perfect implementation of a Bitacora we need to go down the road of a product definition. One of the first steps is to define the environment.

Bitacora is specially designed, although not exclusively, to distributed teams. So we need to first understand what do we mean by a distributed team.

Technically speaking, we need to define the environment in which our product will live. At this point, we will take it as a hypotheses, which should be the result of studying and defining our business model. But that is out of my scope so I will use as starting point an abstraction of the different environments in which I have worked. In most of them I have worked with imperfect/limited/working versions of (the ideal) Bitacora.

Description of the environment

We will assume the Bitacora is designed to be used in a professional environment, a company that has four offices:

  • The headquarters are in Silicon Valley (UTC-8).
  • The main engineering office is in New York, US (UTC-5).
  • QA and services dept. are based in Hyderabad, India (UTC+5:30).
  • The fastest growing office is the London, UK (UTC).

Three years ago, the company changed its growth strategy due to the difficulties they were facing to attract talent. The increasing relation with some Open Source communities acted as catalyst for this change. So now, instead of relocating people, they hire the talent wherever is available, becoming what I refer to as a distributed environment.

50% of the people hired (not including sales and customer support) the last three years are home based. They expect to increase this number up to 75% in the coming three years.

The company was originally conceived as an agile company. Every product/service has been developed following Kanban or Scrum. One of the challenges they are currently facing is how to adapt those methodologies to:

  • The increasing relation with open collaborative environments.
  • The distributed nature of the teams.

At the same time, the company need to face an increase of the services associated to the products they are developing. This is creating a friction between processes associated to product development and services.

Due to the increasing interaction with open source communities, it is expected that this challenge will get more complicate due to the R&D nature of the work done in these communities, that incorporates new and different processes that the company do not has control upon.

But above all, the main challenge brought by the new distributed nature detected by senior managers is the the reduction of alignment within the company which has two clear symptoms:

  1. Appearance of silos.
  2. Complains by senior engineers and first level managers of lack of big picture and reduced horizontal communication among teams.

A new team has been formed within the company to develop a new product, which is an evolution of a former one, based on a technology developed by an open source community. The new product is sponsored by a reputed German company that is building a complete solution for a vehicle industry leader.

This team is multidisciplinary and, following the nature of the company, heavily distributed.  It will have direct relation with the open source community the product is based on, the sponsor and several key stakeholders within the company.

Finally, since this is product considered key for the future of the company, senior management want to evaluate the work done on a regular basis.

You, reader, and I, are in charge of, using this team as test case, designing a tool that improve alignment keeping high levels of autonomy, using agile principles while reducing the impact on existing company processes to the minimum.

That tool is Bitacora.

Why this environment?

I see the above environment as the maximum common denominator of the key ones I have worked in, that is:
  • Team distributed in several offices in the same time zone
  • Team centralized in one office with a significant % of remote (home) work with a remote product manager, all in the same time zone.
  • Team distributed in two offices and several remote team members in different time zones.
  • Team completely distributed (no office) on two correlative time zones.
  • Team completely distributed across the globe in several time zones.

The possible combinations increase if we introduce culture/origin/native language/profile of the team members or sponsors, the nature of the company/product/service being developed, my role in the team and the relation of the product with collaborative environments.

I also wanted to choose an environment that might sound familiar to my blog readers. This scenario is probably not the one where Bitacora would have the highest impact, but again, my main goal is explaining the ideal solution, not creating the best business plan.

Series of articles

  1. The diary (aka bitácora): towards alignment in distributed environment.
  2. Bitacora: environment definition.
  3. Bitacora: personas
  4. Bitacora: Impact mapping

The following one will define the personas. This section will be updated with the coming articles.

Agustin Benito Bethencourt (Toscalix)
@toscalix
Linkedin profile: http://linkedin.com/in/toscalix