Agile On The Beach: my first time

During 2017 and 2018 I got several interesting references at eagileonthebeachvents like Scale Summit and pipelineconf about an interesting event in the south-west of England about lean, agile and continuous delivery that got my attention. I decided that I could not miss it in 2019.

2019 edition of Agile On The Beach was the 9th one. The event has gain a good reputation among agilists for being a good mix of great content and relaxed atmosphere in a beautiful environment. This is not surprising for somebody coming from the Open Source space but is not a so common combination within the lean/agile/CD world.

I bought the tickets and reserved the accommodation on time (months before the event). As you know, I started in MBition in June. My employer was kind enough to make it easy for me to attend. So on July 10th I headed to Falmouth, Cornwall, UK to participate in Agile On The Beach during the following two days, coming back to Málaga on Saturday July 13th.

I liked the event. I felt like home. Like if I was at Akademy, for instance. There were some outstanding talks, a great atmosphere, talented and experienced attendees, reputed speakers, good organization and nice social activities.  Yes, the trip to get there was long but I had no delays in any of the several planes and trains I had to take (who said British trains are awful?) which allowed me to invest a few hours working on each way.

The videos has not been published yet. I will add as comments those I recommend you to check.

Update: please find the videos here.

Next year the event celebrates the 10th edition. They promised to do something special. If you are in the UK or are willing to invest several hours traveling to a good Lean/Agile/CD event, Agile On The Beach is a great one. But stay tuned, the number of tickets is limited and they are gone several months before the event starts.

Bitacora: impact mapping

Introduction

This is the fourth 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.
  3. Bitacora: personas 

Why Impact Mapping?

The steps taken so far are standard for me since long time ago. At this point though, depending on the nature of the product, I did not have a fixed procedure to follow until the creation of user stories. At some point I ended up creating use cases and relating them through mind maps.

A few months ago I read Impact Mapping, from Gojko Adzic, a reputed Agile consultant and writer. He proposes a method to go from business model to Epic/stories description that I found interesting. It fills my gap with a systematic approach using a tool I love, mind maps.

It also helps deprecating a common challenge with use cases. When you get dirty with them, it is easy to write many that are not key for the main goal of the tool. Once you have many of them, it might become tough to relate and prioritize them.

Gojko propose to get rid of use cases and go directly from impact mapping to describing the epics/user stories. I have not been able to do so. It might be that I am simply too hooked to use cases and it is only a matter of time before I follow exactly the new process. It can be also that impact mapping is rigid compared to use cases so you can only get rid of them in a second/third iteration of the impact mapping process…

In any case, for Bitacora I started with an impact mapping. Once it was mature enough, I started from scratch doing the use cases. My impact mapping ended up containing 75% percent of the use cases…. and already structured. I assume that, in a collaborative design process, this percentage will be greater. I assume also I can get better with practice. So I am confident to adopt Impact Mapping exclusively. I might loose some use cases but I gain structure. Relevant but at this point ignored use cases will probably pop up later in the design process or during development. Mistakes in the prioritization due to structure deficiencies has a bigger (negative) impact along the product life cycle.


What is an Impact Mapping?


Mr. Adzic describes in his book Impact Mapping as “a mind-map grown during a discussion facilitated by answering the following four questions: Why?, Who?, How?, What?”
  1. Why: centre of the map, represent the goal of our application. It should include the desired achievemnt based on a key metric.
  2. Who: first level of the mind map, it refers to actors who can influence the outcome. These are the personas. At this point of the process, it is not mandatory to describe them in detail
  3. How: second level of the mind map, it refers to impact we are trying to create on the actors, that is, how the product change their behaviours.
  4. What: third level of the mind map, it refers to the scope, that is, what can we do to achieve the desired impact. Depending on the dimension and complexity of your product/service, this third level will be close or far away from a user story. You can either extend the What section into sub-levels (product approach) or define epics (scrum of scrums). 
You can get further information and diagrams in the website impactmapping.org I am still unsure about the direct relation between the What section and what engineers understand as a derivable. I prefer to reserve derivable as concept to a later stage (user stories) so they are analysed in detail by the product team, together with acceptance criteria. I find this arguable though.

Bitacora Impact mapping

Once you:
you should be able to understand the coming Bitacora Impact Map.

If not, I have probably done something wrong, which wouldn’t surprise me 🙂 or you are not familiar with the problem to solve. Some of the ideas like “tag page” will be described in the user stories, so don’t panic, we will get there.

Since these graphs has gone through several review processes, it might happen that the partial pics are not 100% up to date. The general impact map should be though.

Center and Level 1: Why? and Who?


The center lacks the quantitative goal. Since this is an ideal exercise, I will ignore it for now. We will go down to metrics and measuring impact at the very end.

At the end of the previous article, about personas, I wrote that for a introductory analysis, we could reduce them to 5. Since I went further, I considered groups and described personas for each group since we will use them at some point.

Level 2: How?

This is the second level that defines the impact for the product team members.


 This is the second level that defines the impact for the other personas.



 As you can see, the impact is described in the following areas:

  • Participation: the tool should promote an increase of interactions based on what each persona did.
  • Team/project follow up: bitacora should make following up a team or project activity easier.
  • Analysis: analize what the team is doing or has done should be easier with Bitacora. Self analysis is as important.
  • Report: Bitacora is designed to improve reporting in bothe, vertical and horizontal direction (matrix).
  • For Team Member, Bitacora should work as the central point for everyday (short term)  information.

Level 3: What?

For a easier visualization I have divided this level in three different images. The first one correspond to Product Team:


This is the third level for the Scrum Master persona:



 And this is the third image, corresponding to the other three groups:

Complete Impact Map

Here you have the complete map.

You might be wondering what are the icons for.

I mentioned earlier that one of the advantages of using Impact mappings is the structure. As a consequence, you can start to assign priorities to the different scopes which is very useful before writing down the User stories. 

Note:

The result of this process should in general be features, but in certain circumstances, at this point it could also be processes. I used the “help” icon to reflect them. his concept is arguable. I am at this point unsure if it will survive the story description.

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 article will describe the use cases I worked with so you can compare both approaches.

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.

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.

The diary (aka bitácora): towards alignment in distributed environments

Introduction

There is a virtuous circle that many think is key for any organization to achieve success:


I want to focus on autonomy and its relation with alignment.
I do not know any single smart person that do not like autonomy. Definitely I want it and most of the managers and developers I have worked with too. There is no doubt that we achieve the best results for ourselves and the organization we are involved with with great doses of autonomy.
Autonomy though, as usual, requires high levels of coordination in order to be sustainable over time. It requires mechanisms of check and balance against a plan. Take a look at Scrum, for instance. It proposes to do checks and balances against the backlog every 2 to 6 weeks aprox., at the beginning/end of every sprint And it forces also to stablish a daily check and balance against the micro plan every day. That is a lot but it is the price to pay for getting autonomy.
And this is because the success of a group completely depends on the alignment of its members. Our tendency of “taking our own way” (entropy) is so high that organizations need people and many processes just to make sure everybody fight hard against it.

Definition and a little bit of history

I think it was 2004 when I started my relation with Fotón S.I. crew. Fotón is an open source company from Gran Canaria, founded in 1998, lead by Mike Vazquez and, back then, also by Gonzalo Aller.

Working with Fotón SI had a huge impact on the way I perceive management. It worked as a catalyst. I learned with them in a few months what takes ages for others.
Fotón was formed by a group of very talented and young hackers. The decision processes were very participative and transparent. Let me put you one single example: the basic accounting of the company was open to every employee, including salaries.
In their peak times they were around 20 people but it was strange to see more than 5/6 in the office. Most fotonians worked from home most of the time. They were based in Gran Canaria and my little company was in Tenerife. It was a distributed environment.
Going back to Foton, a key variable that balanced autonomy and alignment  in that distributed environment was THE DIARY, a simple concept but very effective.
Most people right now are probably thinking about that little notebook that needed a key to be opened where some boys or girls write their thoughts at early ages. Obviously that idea has little to do with what I am talking about. The term bitácora, a short way in Spanish to refer to the ship’s log, is closer to what I am talking about.
A bitácora is a log chronologically organized, written by the ship’s captain, kept in a wel define place where the most relevant events related with the ship, the crew and the journey where described. It had two main goals:
  • Analysis.
  • Report.
By writing on regular basis what happened in the ship, captains were creating a tool that allowed them to learn from past experiences. It was a very precious treasure, so preious that needed to be destroyed in case the ship got into the wrong hands. It was way more than the Black box of a plane. It captures the most important knowledge. If the captain got sick, for instance, or died in combat, his replacement used the bitácora to analyse the past history. Many of you are familiar with this concept since it is popular among scientists, archaeologists, etc.
The bitácora worked also as a reporting tool. After a few months sailing, it was impossible for any captain or officer to remember details about the trip if they were not written in real time. Providing a report about the trip was impossible without the bitácora. One interesting point was that, once written, no entry could be modified. If the captain made a mistake, he needed to create a new entry correcting the mistake, like in a check-book.
Fotón was a pret-a-porter development company organized per project. Each project had its own diary/bitácora. Following its culture, everybody had +xrw permissions in every bitácora. Agreed labels were used for different purposes: identify each user, assign relevance a specific entry through colours, etc. This idea was implemented in a hacked Twiki, integrated with Request Tracker and a mail service for notifications. A very smart, geeky, simple and efficient implementation for the time. Like all the wikies back then, UX was not the main feature but for console lovers…..that was no issue.
So Fotón extended the concept of the bitácora to a new level, going from an individual oriented tool to a group one, that is, they took a collaborative approach with a great result.
I still remember the day they explained and showed it to me. I was amazed, excited and cautious about its scalability. I was already used to write regularly what I was doing so the main hurdle did not applied to me: I had the habit. The collaborative approach was new to me though, together with the implementation.
How come something so simple has such a high impact? What makes reading what others do, think or feel so valuable? What is the relation of writing what you do and being efficient as a team? What a diary has to do with alignment? And here is the question that most people that face this tool/process for the first time ask: isn’t it the diary a tool to control me?
Let me start with the last one. The bitácora is a tool to control yourself. If you think you do not need to regularly check and balance your actions against your plans, your colleagues expectations and your company goals is simply because you are not senior enough, period. The diary is just a way to achieve that, like the stand up meetings or the burn down chart.
You decide what kind of information you should include in the bitácora. Here is the main rule. Knowing that is open to those you work with, add what you think is :
  • Relevant to you.
  • Relevant to your peers.
  • Relevant to those you interact with like, managers, other teams, customers, etc.
Do not add information that only one person should know about or that you would not say in a team meeting. Simply use your common sense. For instance, if I am frustrated about something…. I add it in the diary if I want to share it.
Fotón used to open the diary about a specific project to customers and third parties involved on it and it worked beautifully. Of course once in a while somebody wrote something inappropriate, but the benefits of these diaries were so high that assuming the damage was out of question. It became an outstanding engagement tool, as good as the best sprint planning meeting.
Very soon I experienced myself the benefits of getting the habit of writing regularly in those project diaries I was involved with, reading what others wrote and interacting with them through the diary. I got a sense of control of my day to day work and, even better, of what everybody else was doing. Control in a good way. Sync meetings were reduced, asking for weekly reports made no sense,… we were a more efficient, coordinated… better aligned organization, even in our distributed environment, despite working in several projects at the same time, with different customers, third party companies or different working schedule.

Conclusion

In many ways Fotón diaries laid upon two ideas that today are very popular: semantic and social (in a twitter way). I believe that the diary is a key complement to agile methodologies, specially in distributed environments.
In my next article I will describe in detail the concept and what the perfect implementation should look like, based on my experience since I have used it widely since then.

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.