Writing: A great way to learn from your experiences.

“I write not because I know but because I want to know.”

Julio Serrano- Guatemalan Writer

Julio Serrano is a Guatemalan writer I met in a course about poetry. These words lingered in my mind for quite some time. After a while, I understood what it meant to me, and the reflection surprised me. I started writing articles to practice my written English. My initial thought was to get better by doing: the best way was to write about something I already knew. Thus, I started writing about my experiences at work. I thought the outcome would be about the writing, not the content. But something happened during the process. The ideas were there but needed order, structure, purpose, and a message. First, I had to think about the message: What am I trying to convey? Then the second question came up: What is the message? Is there even a message? I decided to tell stories, like when you find a friend you have not seen in a long time and tell them about what happened to you. That would be my tone, a friendly conversation with a dear friend. So there it was my first decision: who would be my audience.


Then, I thought I must be thorough about what I was saying or writing. Although I would treat my writing as a conversation, this conversation needed to be explained with facts. So every sentence I wrote needed to be a fact of my experience, shared knowledge, or verifiable information. The last statement was the most challenging because if I wanted to write about a topic, I had to review all my concepts to avoid saying something wrong. Thus, every piece of writing became a research subject: I was in trouble now. I told stories and backed them with what I had learned or researched. By researching and comparing my actions with actual concepts, I could compare what I have done wrong and right and make conclusions, assessments, and commitments to improve the outcomes.

The realization

After three or four articles, I realized that I was learning from my own experiences by writing and telling my stories. Julio compellingly explained this process: “Words are powerful; they give order to the Universe.” Oscar Wilde showed the same way of thinking when he wrote about words in his novel The Picture of Dorian Gray: “They seem to be able to give a plastic form to formless things… Was there anything so real as words?” When you put your ideas into words and try to explain to others what you feel, what you have lived, and what you have learned: you create certainty. A notion becomes a concept that others can understand, explain, and even translate into actions that deliver some result. Words are magic wands; they can convert ideas and thoughts into tangible results.

In the article “Three Observations on Leading Through Writing” by Gene Kim, author of The Phoenix Project and The Unicorn Project, he describes how leaders like Admiral John Richardson and Jeff Bezos rely on writing to deliver their message to their peers. However, this message is not a long report but a conscious process of providing ideas in the proper format. Kim also says that writing “clarifies thinking you need to reason about complex decisions.” That seems quite logical. Suppose you can translate a concept into words with sentences that everybody understands. In that case, you can deliver a well-constructed message. Then you can also deliver these words in the form of speaking. You use words in meaningful sentences that can reach most of your audience.

Learning to write

However, this process has been a five-year journey for me. English is not my first language, and the process of communicating ideas varies from culture to culture. The culture influences how sentences are constructed and how words are delivered. In Spanish, my mother language, we prefer longer sentences and more elaborate paragraphs, whereas English is more to the facts. The ideas are abstract concepts, and they translate differently in various languages. Thus, language is not easy to master, and even then, the writing process has a set of rules that a writer has to master: the audience, the tone, the style, the rhetoric, grammar, and so on.

Writing is a craft that needs practice but requires some practical knowledge. This knowledge needs to be acquired in some form. I have a technical background, so I usually use tutorials and self-paced classes to obtain new material, but writing has been a real challenge. The process is not logical as in a technical field. Language results from rules and conventions that groups of people create in a living environment. New words are formed on the fly due to new technology or other facts of life. New terms like “teleworking,” “emojis,” and “internet,” for example, have been created in the last few years. The rules of communicating are different between informal environments and business settings. Thus, we as professionals should acquire this craft through formal learning and commitment.

After five years, I can say that It has paid off. The time involved has been a real commitment, much more than the monetary investment, but I see the difference. I needed to make this investment for my personal and professional needs, but I recommend getting involved in writing. When we communicate better, we perform better and get better results. And by translating our thoughts, ideas, and stories, we can make sense of our experiences, understand better who we are, and then plan better and learn from the past to have a better future.

Words Have Power

Winston Churchill is an excellent example of what writing can accomplish; he made words an essential part of history. President Kennedy said, “He mobilized the English language and sent it into battle. The incandescent quality of his words illuminated the courage of his countrymen.” He is widely known for his memorable speeches in the House of Commons and to the British people in one of the darkest times in human history. However, I did not realize that before Churchill became Prime Minister, he made a living by writing about war and continued to do so after his tenure.

Churchill wrote more than forty books during his life. Most of his writings are about historical war events. He also was a journalist who reported war events for The Daily Telegraph and The Daily Graphic while serving in India. Thus, he was knowledgeable about war themes before even the Great War had begun. His first book was published in 1898, and it was “The Story of Malakand Field Force,” a recount of war events in India.

Churchill made a living out of describing war to the British citizens, and by explaining these events to others, by observing, analyzing, and translating these events to the ordinary people of the British empire, he became a master of words that moved a nation to hope and to fight for its values. Long before World War II started, he made sense of war events and the effects on people; as a journalist and book writer, he had to put some order and make sentences readable to all about what he taught, what he saw, what he understood about war.

Many quotes from this man are well known, but this one describes a moment in which the British had lost a lot, and the Japanese had won a lot:

The whole future of mankind may depend upon our action and upon our conduct…We shall not fail now. Let us move forward steadfastly together into the storm and through the storm.”

From his speech to the British called Tonight the Japanese are triumphant, February 15, 1942, upon the fall of Singapore to the Japanese forces.

What I like about this speech is that Churchill spoke the hard truth to his fellow citizens, but also he spoke about hope, the alliance with the United States, the hardship to come, about the place in history that the British people had. He moved all those people with powerful words that speak to the core of the human heart. So, how could he give hope in such dark times? Let us remember that the British fought almost alone from the fall of France in 1939 until Pearl Harbor in 1941. The German forces bombarded London, and still, the British fought with everything they had. The citizens in London sent their children far away; the hardships were enormous. But, he inspired hope with words because he knew how to deliver a message, how people reacted to these messages, how to say the bad and the good when to say it, and let’s say that he mainly spoke the truth.

Words are powerful indeed if they can convey a message that is understood. Some can deliver these messages to the masses, but most people can speak with meaningful words to those close to them. If they take the time to prepare, if people work on this unique skill, they could accomplish a great deal if people commit to the idea that it is essential to be understood. Indeed, together people can achieve big things if they understand each other. That is what Churchill did with his words. He united his country against a threat. This accomplishment was a humongous one.

There is a lot more that I can say about Churchill’s words, but I would take pages and pages, so I recommend reading “Churchill: The power of words” by Martin Gilbert. It is an excellent book that depicts some of the most memorable Churchill speeches. It is a must-read book if you are interested in history, words, and this man’s extraordinary life. Winston Churchill was bestowed with the Nobel prize in literature in 1953. According to the Academy, this honor was given “for his mastery of historical and biographical description as well as for brilliant oratory in defending exalted human values.”

The End

Winston Churchill is a unique man; most people are here to live their lives relevant to a much smaller circle of action. But, we can learn from this powerful example how a craft like writing can help us to reach our goals and to invest in communicating better. Maybe not everybody can be enrolled in a writing program, but we can all invest time now and then and get more involved in crafting an excellent story to tell. In the end, maybe we will discover a hidden talent that had not been seen before because we were not looking enough into our personal history.

I started with a quote, so it is fair that I finish with one to make us think about how putting order into the past can help us lead our future, and writing can help us to do so.

It is my earnest hope that pondering upon the past may give guidance in days to come, enable a new generation to repair some of the errors of former years and thus govern, in accordance with the needs and glory of man.

Wiston Churchill, 1948, The Gathering Storm

People over Process, Process over Tools

I recently read a recommendation about a tool about Data Governance and how this tool would solve every data governance problem in an organization. Then, I went back in time, and I remembered how the CEO of a software company told me that a client that we had in common would have plenty of cash to buy costly software from his company by using the tool that he just sold them. I was very skeptical about his prediction, but I couldn’t precisely pinpoint the problem at that moment. So I gave it much thought, and I finally found the explanation I was looking for.

The False Premise

The tool was a business intelligence software that depicted the inventory status of all stores in the company. With this intelligence, the supply chain manager could replenish the available inventory and the inventory by store. However, each store had its own profile, the type of clients was very different from store to store. Furthermore, most of the products were imported; thus, replenishment to the main inventory was tricky. Everybody that works with supply chain management is aware that dead inventory is the main enemy of a company: it is money sitting there that any day can become a liability. Therefore, moving the inventory as fast as possible should be the rule, and detecting sitting-duck products in the stores and the warehouses is a priority.

However, this kind of work requires, first of all, people. Detecting the products is not the main problem: it is moving the products. This type of activity requires collaboration, communication, and leadership. For example, moving the inventory needed the list of products that needed moving and the knowledge of the clients that every store served. Of course, an intelligence tool makes this work easier and better, but the process and commitment to perform the activities come from the people involved. The process is born from the intrinsic knowledge of the people that perform the action. A manager or someone who knows the theory very much can devise an approach. Still, only the people involved in the everyday activity know those little details that make the difference between a wish and a goal. This company lacked synergy amongst its employees; the management worked top-down, and a policy always came from above without considering the feedback from the people who did the work. 

The vendor explained the technicalities, the beautiful dashboards and described a good picture of how the inventory would move and generate the cash needed to solve all the company’s problems. A very nice summary and review about supply chain management complemented with pictures were presented, and the sale was made. But, unfortunately, ten years later, they still didn’t have enough cash to buy the expensive software.

People over Process

When an organization needs to implement a process or solve a significant problem, the best way is to involve all the people in the process and devise a prototype solution. It may work or not, and in the best cases, it would be a good start that would generate information to improve the process as with any prototype. The starting point is solving a subset of the problem: the simplest is the best approach. However, the company should have a culture of change and a managerial staff ready to hear any suggestion, good or bad. Good advice may come from very unexpected places. Most people feel motivated just by being listened to and recognized; being part of something is, most of the time one of the best rewards. If there is no culture of listening, it is challenging to implement changes that impact an outcome.

Process over Tools

If the company has had this virtue, the next step would have been to create a process to replenish one store using the new procedures. Maybe a good start could have been to choose just a group of sitting-duck products. The company wouldn’t need to purchase a tool for that, and the inventory manager could have got the products that were not moving in the last six months, for example. The selection of the products is related to the cost, season, and store. Then, the sales department, the sales store manager, the supply chain manager, and the inventory manager could have devised a process.

Again, there was no need for a tool; the process could have been implemented using what the company had at that moment that included an IT department. Then the next step was to research and then getting the process in better shape using the results, or the worst-case scenario: to start again. But this time, they could have created the new method using the knowledge gathered during the experimentation stage. The updated process could have included more stores to further the analysis. This fact is critical because each store had a different type of client. Once the process was developed and yielding good outcomes, they could have started looking for tools.

Organizations may be of significant scale; thus, a prototype may not be able to be upgraded to full scale unless there is software in place. However, investing in a tool without a thorough understanding and a plausible solution is a waste of good money. Furthermore, it can cause disappointment amongst the employees who are asked to implement the tool, knowing that it will not work.

Some History

The concept “people over process, process over tools” was first introduced in Scrum and included in the values of DevOps. It is interesting to note that both frameworks were developed by practitioners who researched their organizations. They named the values using their own experiences and realized that the problems were the same among peers. Sure, they did thorough research, and they also made their prototypes, but they also implemented these new frameworks in their companies. Both frameworks are in constant review, and both frameworks started with people getting together to solve a big common problem in the IT field. People first. Nice!!!

I like to look for good historical examples to discover patterns and realize how people have changed so little over time. In my search, I found that The Battle of Thermopylae contains elements that depict what “people first” is trying to convey. In the year 480 BC, an army of about a quarter of a million from the Achaemenid Empire of Xerxes I, according to Herodotus, fought against 7,000 Greeks lead by Leonidas I, King of Sparta. The battle lasted three days; the Greeks successfully resisted the Xerxes’ army for the first two days.

They used the narrowest part of the path to confront the enemy and cause the most damage with scarce resources. The Greeks were highly outnumbered, but using their famous phalanx formation, they could have resisted the invasion for a long time; this battle was not a suicidal mission. However, the Greeks were betrayed by Ephialtes, who showed the Persians a small pathway to avoid the pass on the third day. The Persian forces flanked the Greeks, who fought to the last man to defend the position. When King Leonidas got the news about the trespassing, he sent the allied forces to retreat, but he and the Spartan forces stayed with 2,000 allied soldiers. The Persians finally got into Athens and destroyed the city. Still, there was enough time to gather and organize the troops, and the Greek coalition defeated the Xerxes’ army in the Battle of Salamis and the Battle of Plataea. In both battles, the Greek and allied forces used the battle cry “Thermopylae, Thermopylae!!!” It is said that the forces were infused with patriotism by the sacrifice of the 300 hundred and their King.

People over process and tools, as mentioned before, relate to leadership, collaboration, and empowerment: people working together towards finding a common goal or solve a complex problem. A clear example of leadership is King Leonidas’ actions. Leonidas sent an army of 7,000 soldiers to the Thermopylae, pass along with 300 Spartans against an army of a quarter of a million Persians. That is too much to ask if we see it from a distance as we are doing it right now. However, he went and fought along with their peers; that is leadership. He didn’t ask his fellow soldiers anything more that he would do to defend his country. 

Collaboration comes with the combined knowledge of the allied forces and the Spartan soldiers. For example, the phalanx formation was a highly effective war tool to fight the enemy; however, it required a close collaboration amongst the soldiers to accomplish the impenetrable block formation. Herodotus described how the Spartans were bombarded with so many arrows that the sky was obscured by the attack’s shadow, and even then, the phalanx was ironclad; none of the Spartan soldiers were harmed.

Empowerment can be seen when Leonidas commanded the soldiers to leave after realizing that they were about to be flanked by the Persians using the secret road behind them. Nevertheless, the Spartan soldiers stayed, and 2,000 allied soldiers also chose to be there; It was better to die fighting for the freedom of their country instead of falling under the slavery of Xerxes I. It is essential to notice that the Immortals, a 10,000 elite division with an avalanche of resources in the form of arrows, elephants, war carriages, and so many more war tools, couldn’t defeat the Grecian coalition during the first two days.

They finally lost not because of the enormous resources invested by the Persians but because the Greeks were betrayed. We can fantasize that if this treason would not have happened, the small Grecian army could have held the position using the values instilled in the Spartan way of life and their enormous force of will first, and then by well-defined methods of war. Thus, we can see that people made this impossible tale of courage possible, and their sacrifice inspired the rest of the Grecian coalition to finally defeat Xerxes’ army.

Further Reading

Going fast forward, 2,500 years at least, right into this century, I recommend the book “The Unicorn Project” by G. Kim, who describes how an elite team got together to overthrow the overlord of bureaucracy to modernize an entire business and technological operation in a company with overwhelming challenges to stay on top of the competence. Maybe it is not a story as romantic and poetic as the 300 Spartans who died along with their king to defend their country. Still, it is a comprehensive tale of what can happen when people get together to solve a highly complex problem. I can attest to the integrity of the problems, failures, and dramas presented in the book: I lived a smaller version of them. For me, it was a vivid experience. It was so real that I had to stop reading chapter six to take Advil because the narrative reminded me of many dramas in my professional life that I relived. For example, I can remember updating an error in the production version of the software and paralyzing the whole company’s operation for a couple of hours. It was horrific to remember that, but, as any good horror story, I kept reading, and the book had a happy ending: Van Helsing killed Dracula in the end.

Finally, I know how to answer the happy CEO who sold his tool to his client, but next time, I would rather help the client put in place a comprehensive solution designed by their own people before buying any tool. But only if they are willing to listen to everybody’s suggestions no matter how good or bad the suggestions could be.

Resources

The Battle of Thermopylae is a summarization from Wikipedia, Battle of Thermopylae – Wikipedia

Interesting article about People in the Scrum world, When it comes to agility, people come before process | PA Consulting  by Amy Finn

Genba: See for Yourself a Better Way to Define Software Requirements.

“Gemba” is a Japanese word that means “go see by yourself” and is used in Kaizen. According to Investopedia, Kaizen is a Japanese business philosophy regarding the processes that continuously improve operations and involve all employees. Kaizen is used to implement Lean Manufacturing and was highly popularized in Japan by Toyota and its continuous improvement model. Gemba is one of the principles that are used to implement this methodology. But what does the term Gemba mean exactly? The translation from Japanese, which is “go see for yourself,” doesn’t explain very well the true meaning of this word. I think the best way to describe it is by using clear examples.

The Malayan Invasion

One of my favorite and more dramatic examples would be the Malayan British Peninsula take-over in December of 1941 by the Japanese Army using bicycles. Colonel Masanobu Tsuji was in charge of planning this invasion. It is worth mentioning that the Japanese already had plenty of spies in the peninsula that informed the Japanese command of every movement and resource of the British Army. However, Coronel Tsuji decided to look by himself the terrain, so in October of 1941, he made a recognizance trip. He observed that the Malayan roads were well pavemented; there were also many bridges along the invasion pathway. This last fact made vehicles a problem because they could not have been moved if the British Army destroyed the bridges as they retreated. The disembarking site was quite far away from the target, which meant they needed to move fast to avoid a rapid response.

Tsuji also observed something else, the abundance of bicycles in the area, which prompted the idea of using this type of transportation during the invasion. The roads were well suited for the bicycles. If the bridges were destroyed, the soldiers could easily transport the bikes on their shoulders. Finally, they didn’t need to take the bicycles all the way from Japan because they were already there. The soldiers just needed to steal the bicycles from the Malayans. Needless to say, the invasion was a complete success. When Churchill received the news, he stated,

“It was the worst disaster and the largest capitulation in British history… In all the war, I never received a more direct shock.”

And that is how a dramatic story ends. But then a question arises from this tale: “What would have happened if Tsuji had not seen with his own eyes the enemy’s territory?” 

Genba at work

How this story relates to our intended purpose of gathering information for software requirements? In the business of gathering information, the main problem is to deliver the feature as needed. There is always a gap between what the user needs and what the software development team delivers. Here is where Agile helps by allowing us to talk directly with our stakeholders to inquire and resolve any question. However, the gathering of information goes beyond asking for the feature from our target user or stakeholder. There is a high probability of making a wrong interpretation between our understanding of the problem and our end-users reality. One of my first bosses used to ask me before I started any feature development: “Did you see it for yourself?” This question is exactly what Colonel Tsuji had in his mind when he went to visit the Malayan Peninsula. He needed to see the terrain, the bridges, the bicycles, the problems, and the possible solutions in his case. In my case, the question meant that if I were going to create a report for the poultry inventory to load trucks, I should go to the warehouse and actually see the people loading the trucks with my own eyes. The trucks were loaded in the delivery order, starting from the back with the last orders to be delivered and finishing with the front with the first orders. The report had to be printed in exactly this order using the clients’ addresses as reference. Problems and solutions may arise from visits to the actual site, but this knowledge must be assessed from a closer look at the terrain, just like Tsuji did. 

I learned two lessons from these experiences. The first one: The processes may differ from what you imagine and what they actually are when you see them in action. The second: Never use nice shoes when researching your features in a production plant because the floor may be flooded with water and poultry blood. It might not be nearly as dramatic as the British army defeat, but I still remember the passing of my favorite shoes with some pain.

Here We go Again

Over the years, these kinds of experiences have happened to me several times. I became highly aware of the necessity of researching directly from the people who were using the features. The instructions that were followed for everybody on the teams that I worked with were to research the feature as if you were the person to execute the function when this person was going on vacation. If you can do it as this person does it, you can define the feature. Some people would say that this kind of research takes a lot of time; however, the cost of not doing it may be much higher. If Colonel Tsuji wouldn’t have visited the site, what would have happened with the invasion? We can speculate many theories; however, the bicycle solution wouldn´t have been a solution, which was cost-effective and indeed logistically very clever. In our case, the development of a feature from their concept to the final delivery is costly, and delivering a function that does not do the job is a complete loss, not only of money but also of credibility. When the stakeholders lose credibility, the whole process becomes endangered. Thus, “go see by yourself” –Gemba, it is really the safest way to go.

This concept is widely used in lean management, not only in lean manufacturing. I’ve seen, with my own eyes, three companies that implemented this concept to train their executives. A month or so training consisted of visiting all the company areas, even the delivery process, which meant that the trainee had to see how the trucks were loaded; how the product was delivered; they talked with clients; the asked for orders; from there they went all the way back to the warehouse. Once the new-minted executives learned and saw what the company meant for every employee, for every client, for every middle manager, then they were ready to apply their knowledge and implement successful policies and make wise decisions. 

The last time I actually made software from scratch to implement a meaningful feature was for a physical inventory process using barcodes. Before I started designing the features, I did the inventory with the audit department. I asked to be in the process not as an observer but as an active participant, and I was given a small part of the store to count. The result from the exercise was nothing of what I had pictured in my mind. I realized that the size of the products mattered; I saw the products, and for me, all looked the same, but no, they were different by half an inch or so, labeling was critical; another problem was products on transit: the warehouses may have delivered product that was on the way to other stores. This product would take a day or so to go into the warehouses to be counted.

By doing this exercise, I became aware of many details that I would have not otherwise realized: people would not have told me, not on purpose, of course. When people perform a task repeatedly, some details become common knowledge, so when someone else asks these details, they just get hidden somewhere behind people’s brains along with what they had for breakfast a week ago.

To Sum Up    

But going and seeing with your own eyes does not solve the problem by itself. The functionality and the applications can be overwhelmingly huge; the person that is doing the research is not the one that is creating the apps. Here is where good user stories come into play: a good user story is the one that clearly states the definition of done and the one that clearly defines the type of test that should be performed over the features. Product owners and their teams become the cornerstone to a good application. This person will define the epics, the stories, and tests that can be implemented to have a minimum viable product. Thus, it starts with good research and follows with a good definition of user stories. The path to success continues, these are just the first two steps, but that is another chapter in the Agile way of life’s book. It is important to mention that Colonel Tsuji did not execute the plan for the Malayan Peninsula invasion. General Tomoyuki Yamashita invaded and created the final strategy using the intelligence and ideas proposed by Tsuji and some more from his own assessments. Here we have a perfect example of what teamwork means between a good product owner and scrum master, and here is where our story ends and with the following quote.

“Reality Wins” –by Dan Rawsthorn, as he wrote on my copy of his book “Exploring Scrum: The Fundamentals”

OnLine Training, A Few Tips

When I arrived in the US, I could not work in the country because I had a non-immigrant visa for NAFTA workers’ spouses. But I couldn’t just stay at home, so I helped with some training in my home country and other activities online. When you are not used to it, teleworking can be challenging, and training people online can be even more complicated. Everybody can relate to the first time they did online training and asked their first question: most likely, a mortal silence came back to them like an echo from the underworld.

There are several types of online training, but today, I would like to talk about synchronous training, a live presentation with an audience, and real-time questions, since it is the concern for most trainers with a new order in the world. When we migrate from a classroom with walls, seats, and a projector to an online setting, we need to adjust to this new environment. Many technical trainers and teachers may rely on the class’s mood to make sudden changes to the presentation or integrate new material. Others may rely on group work like a study case discussed and generates insights and excellent feedback in the class. I prefer this method to teach because I can rely on other sources of knowledge to build up an interesting discussion. And the list can be long and with many items; each teacher or trainer has worked very hard to develop their superpowers in the classroom. Thus, what can we do when we got stripped of our superpowers? Well, I found out that two factors are significant when you are teaching online: engagement (please, student don’t go to sleep because you decided to receive your class on your bed); and insights ( please, somebody out there ask something so we can make this a litter bit more interesting.)

We have to learn new ways to create exciting classes, and we have to dedicate more time to prepare for the course. At first, it may seem much work, but it was also the first time we taught a class: it is an investment. I am a true believer in education, and this world that we live in requires much knowledge if we don’t want to end up in the line of unemployment. The more time passes, the more education a young mind will need to acquire to tackle the present’s good jobs. Notice that I am talking about good jobs, not any job. Let’s invest in the future generations, and it is also an excellent opportunity to add to our resume a new skill: an excellent online trainer. The path that so far has given me good results is as follows: first the introduction to the class, a good start generates the mood; second, keep the attention of the student as much as possible, that gives continuity to the discussion; and lastly, a proper closure so we can state that the goals of the class or training have been met.

Engagement

The introduction is the most important part. What has worked for me is to have some homework done, generally, a reading if it is a conceptual class or a piece of code or activity that has to be done on the tool we are learning. Then, I usually introduce at the first five or ten minutes a pop-up quiz. The quizzes are not for everybody; I am the worst at them. For example, if you ask me what’s the result of two plus two and then multiply the result by two, I would probably flunk it, but as a student, they keep me alive because I know that the first activity is going to be a quiz and need to prepare and be ready. If the technical course doesn’t allow extra work, the exam can summarize the last class, so the students have to review the material. The elaboration of the quizzes means extra work from the professional trainer. The quiz should be web-based. I am used to working with Gototraining, which has excellent tools for online evaluations, and I will use it as a reference from now on, but I am not promoting the app. It is just because this is what I have been using so far.

The online quizzes allow me to have an immediate result, and I usually see what answers have the most problems, so I spend the next minutes resolving the issues with those questions. They also help the students because they know that something is coming up, so they need to pay attention. The quiz results also allow me to make direct questions to those who answered right or wrong, depending on the type of feedback that I am expecting. This activity sets the mood: everybody is alert and engaged. The first class is always the difficult one, but after that, the students become more motivated because they know that preparation is key to this first activity; they will be expecting questions and the format of the questions. Remember that people are good at recognizing patterns, and once the trainer sets their teaching pattern, the students will follow along.

Generate Insights

Now that we have our start, then comes the rest of the class; how do we keep the engagement? Well, the same way. If I am presenting a conceptual class, I usually give some reading beforehand to discuss the topic at hand; however, as every trainer has experienced, most of the time, the same persons will ask or participate. What I usually do to generate participation from different persons is to introduce polls during the class. I typically program polls with three or four questions. They are not quizzes, just polls, simple questions, and easy answers like yes or no. The results show me immediately if the new material is presented the right way, and I can make corrections directly and correct the wrong concepts. Depending on the content, I usually submit a poll every twenty minutes, and yes, I am substituting most of the questions to students with polls, so I avoid the awkward silence.

The final part of the class is the closure that summarizes the results, and if I am going to use this summary as a base for the next quiz, I make sure that every concept is very well explained. However, the most important activity is to design your classes and present them to a focus group. The questions in the quiz must be understood and well designed for your audience; if the exams do not comply with their primary purpose, the students will rest value to the activity, and it may be frustrating for them, so having a focus group for the quizzes it is always the best way to go. As I stated at the beginning, creating an online synchronous class is hard work, but in the end, you will have a very well-formatted course template that you can recreate in every class that you have. You will find your mojo again as a trainer.

Additional Tips

Another question that can come up is how to conduct technical training? Well, that is harder work but doable. When I started with technical online training, it wasn’t straightforward. Still, now many tools can help to set the technical environments without the burden of having every student with their computers ready. The trainer can create a virtual machine with all the environment ready and the labs, and they either can be downloaded by the student, or the trainer can install it in a server with an account for each student. There are also tools like GoToAssist, where you can see several computers on your screen and help every student from your seat. I am mentioning GoToAssist because this is the tool that I had used, but many apps can help you access your class computers. These apps help to supervise the workshops almost the same way as if you were with them in the computer lab.

Finally, I am listing a set of tools for online training that you can use to set your polls, quizzes, and labs. This is only a small list of what is out there for those who have not checkout before what tools can complement online training, but definitely, there is a lot. In the future, I shall dedicate some time to getting up to date on what is new, but I would welcome suggestions in the comments; I would really appreciate it.

  • Gototraining has a lot of functionality. You can upload material and sent it to your class previously. You can also program your course and set the quizzes and polls. The feature that I like the most is the immediate response with statistics for answers; these results make my day because I can act immediately based on this information.
  • Skype has interesting features like share presentations and polls; if we combine skype with a quiz tool, then we have excellent functionality for our course.
  • Classmaker is a tool for quizzes and exams. I have used it before, and it has all the necessary elements to make a good exam.
  • Webex is a good tool for presentations, but It lacks the exams and quizzes, but if you include skype or Classmaker to create your quizzes, you can create the right format for your class.
  • VirtualBox to create virtual machines, you can set a virtual machine and send it to your students with all the development environments you need. However, always check out licenses; even if it is a virtual machine, there’s always a license agreement to fulfill.
  • Repl.it is an online environment ready to use for several programming languages like python, R, Java, Node.js, and many more. The students just need to create an account.

The message is that there are many tools out there, depending on what you are teaching. But believe me, nowadays you can find what you need if you are really interested. I found what I needed ten years ago when I started doing online training: now there is much more. I am a computer science-oriented trainer; however, there are online labs for other courses; you just need to do a good search. Be positive and creative, and like every profession you need to practice: practice makes perfect!

What I learned about Data Governance working in Central America

Recently I took a data warehousing class, and one of the themes was Data Governance, which is vital to design an information system. Until then, I didn’t pay a lot of attention to the term; I have worked with data all my professional life, so it comes naturally for me to organize, classify, process and give results. However, standardizing the process helps everybody get the best results in the shortest amount of time, and explaining this concept with the right words to the stakeholders helps empower any project implementation. After the class, I reflected on my experience, and here is the result of these insights. I worked as an ERP (Enterprise Resource Planning)consultant for many years, and I worked for several companies spread through Central America. Data Governance was the first activity to be executed after planning a project. When you are implementing an ERP or new technology at any company, the first question is what information will be needed to present results. The second would be how we will prepare and log the data into the systems to get the expected results. As with almost everything that has to do with systems, several organizations explain these matters to us, and a good one is the Data Governance Institute which gives us the following definition:

Data Governance is a system of decision rights and accountabilities for information-related processes, executed according to agreed-upon models, which describe who can take what actions with what information and when, under what circumstances, using what methods.

However, it is easier to say it than to make it happen. Throughout the years, I found that configuring a sound information system has more to do with getting to know the company’s operations and working with a team that possesses a thorough knowledge of their areas than the software per se. However, an external consultant will not do the job; the people executing the everyday operations with guidance will do the task at hand.  Working in Central America allowed me to see how companies worked and performed their transactions in different settings. Because each country in Central America is small, the companies are not humongous. However, they have the complexity of any big company in a smaller setting. It is like working in your lab. I learned in this lab that getting to know the type of organization is the first step to organize the information. But you don’t have to learn from scratch. There is much documentation available on how a company is organized. A company can be a factory, a distribution company, a retailer, and so on. However, no matter what the company does, three factors influence implementing useful system information and a sound governance data system. These factors are the company’s depth, the breadth of the company, and the onboarding process.

The depth of the company refers to the diversity of operations that a company or corporation addresses. A company in the business of food, vegetables to be more specific, can have its farms to cultivate the produce. Then, the company may have its trucks to transport the produce and its stores to sell it, and also they can export the produce to other countries. The variety of operations could be wide. Each operation unit should be addressed independently so that every bit of information will converge into one information system that will provide results to different stakeholders. The depth of the company will determine the complexity of the data model.

Then comes the breadth of the company: how many branches does it have? Let’s say that the stores are located in three different states, and part of the exports to other countries are also sold in stores that belong to the company. The breadth can be extensive, and the information system should reflect the challenges that the company faces with these types of operations. Taxes can be different in different states, and of course, they are different in other countries. There are laws about which products should be sold in the countries. For example, you cannot send products manufactured using parts from countries that do not comply with international commerce agreements. When a company exports goods, there are rules to be followed. For instance, the company needs to send a certificate of origin that ensures that the laws comply. For me, the company’s breadth means paying special attention to the details because the law gets in the way, and an error in how the information is registered can lead to humongous penalties.

Lastly, the onboarding process refers to how the recording of all the data should be done. Each case needs to be documented, explained, and understood for each person involved in each process. The onboarding is a two-way highway because it suits informing and gathering information to update the process. Any information system is alive and changes. New products can come along with different types of operations related to them. New laws can emerge, and others may be eliminated. A company hired me to separate one of the units in the information system, legally they would be two separate entities, but the board needed the information to be shown as one entity. Some years later, this company hired me again to put together the companies in the information system. Everything moves and evolves and needs the means to grow and maintain like a living entity; here is where a sound Data Governance system helps keep things going smooth.

Like I said before, it is easier to say it than do it, so I would like to get into some detail about depth, bread, and onboarding by addressing each factor with real-life cases.

Depth

One of my most memorable projects started with a financial report on one page. This report’s sole purpose was to present earnings by-product and the expenses by each cost unit, the product could be a whole company, and the unit cost could be an entire factory. The board oversaw an entire vertical operation that included factories, distribution systems, and finally, a chain of restaurants in Central America that sold different menus types during the day. The verbalization of the requirement was kind of simple: “We just want to know the overall gains of the corporation in this report that we review each 10th of the month.” My mind was racing at this time. As a subject matter expert on the ERP software, my job would be implemented to achieve this goal. My first thinking was on creating the codification for the different operations in different companies and departments. Like everything big, first, you have to work with a team, and second, you divide the problem into smaller parts. The company made some sagacious decisions before they even start shopping around for software. One of these decisions was to choose a team of executives that had a thorough knowledge of the company. The people that they selected were the Chief Information Officer and the Financial Comptroller. Even though they already knew the company, they lacked some knowledge about the finest details in the operations, so they were separated from their daily activities and embarked on a one-year quest to get to know every company’s process at its smallest detail. They even made some trips as copilots in the trucks that made the deliveries to the restaurants. That reminded me of a question that one of my first bosses used to ask me: “Did you see it with your eyes?” and then he always finalized with: “You cannot create software for processes that you don’t know how to execute; without a computer.”

After they finalized their quest, they led a team that would include the main stakeholders in the different operations, and together they choose the software to be implemented. At this stage, I came along with the software. I became part of the team. We spent four months in a conference room designing the information system, basically all the codification that was going to be used throughout the corporation to comply with the legal and financial issues and present the one-page report. After two years, we finalized the project, and the most valuable lesson that I learned here was that a thorough understanding of the operation is essential. This understanding comes from the people in the company, not from outsiders. An external consultant’s job is to organize, moderate, and create an environment for positive outcomes.

Breadth

To exemplify a corporation’s breadth, I will cite the implementation of an accounting system for a regional bank. The depth of the project wasn’t profound since it only included financial products and service units. However, the breadth was extensive. The bank extended its operations from Guatemala to Panama. In each country, they had several branches. Here, the challenge was to address all the legal issues associated with each bank in each country, with different currencies in each one, while still maintaining the information system to inform the board of directors in Guatemala’s corporate offices. The bank comprised six countries with four different currencies in an unstable political environment. The government highly controls the bank system in Central America. There are many rules that each bank has to follow. The banks have to follow a codification that is standard for all the banks in the country. This codification aims to report operations like balance sheets, cash flow, and others into an audit system in the Central Bank. Then, a series of tasks are performed in the Central Bank, which includes, amongst others, auditing of the information and quota calculations. The banks have to follow many rules. For example, a bank has to maintain a certain amount of cash; a percentage of the savings has to be transferred into the Central Bank to protect the clients’ assets; the banks are not allowed to invest in risky operations. Indeed, there is a lot of control, which makes the lending of money highly expensive for Central Americans. Panama is the exception, and the Central Bank has a more libertarian approach to put it in some way.

To sum up, it was a very complicated situation because every rule, every asset, every operation must be reflected in the accounting system as the Central Bank commands. If the bank is local, it is not that big of a problem because the operations are reported to the board of directors using this arrangement. Still, when working with a regional bank, the operation’s codification becomes a big challenge, but not impossible. We found out that using and an intermediate codification would do the job, and of course, the conversion of all the operations to a single currency, which is usually the US dollar. The fixed assets are a huge problem because a bank has valuable assets, assets like building offices, and these assets are usually collected as payment for a defaulting loan. There are special rules that must be followed to convert these assets. An asset may have a different value when it was registered for the first time than when reported to the board, which means that reevaluation should be made. The big question here was, how do we organize six teams, in six countries, with six different legal scenarios? Again the answer continued to be the same; first, you work with a team within the company; then, you divide the problem into small pieces to be solved one at a time. In this case, we had a meeting with the financial comptrollers of each bank. We agreed upon an intermediate codification, and finally, we divided the implementation by country.

We started with one country, and once we proved our codification and processes, we continued with the rest of the countries. From this experience, I learned that stringent laws constrain creativity in the creation of processes. The implementation was lengthy, and it took several consultants to finalize it because the rules changed from country to country. We had a baseline, but a local application had to adapt the systems to each Central Bank’s requirements. The company’s breadth may add a considerable amount of complexity, so it is important not to underestimate the challenges of a horizontal operation that spans different scenarios. The challenges are not only legal or process-related but also culturally. The way people communicate, act and behave changes from country to country, even if they speak the same language.

Onboarding

No matter how much work you do to accomplish the perfect information system; or how well you devise the perfect report, if there is not a process to manage the communication of the rules of engagement to all the stakeholders, then the work done to design the information system is a waste of time. The project that showed me how data governance should be handle was the longest project that I have managed so far. Now I see it as one, but in truth, they were two different projects, and that is the beauty of the experience. In the end, I realized that it was only one project that lasted more than three years, which I called in my diary, the blue book project.

In most of the projects that I worked for, part of the job was the design of codification for each operation in a company: the bill of accounts, the products in inventory, the codification of the different departments in the company, and so on. The goal was to create a system of information that could later be easily translated to a data warehouse for business analysis, and at the same time to be able to integrate any summary of information and be able to audit the numbers presented to the board for accuracy. I do like patterns and order, so that job suit me very well. But it came the time when I went to a small company in Guatemala, which was a branch of a Salvadorean corporation. This company only had 15 employees at the most, which were the administrative and warehouse personnel. This brand’s purpose was to distribute a product made in El Salvador to the different supermarkets in Guatemala. The operation seemed very simple, which it was. But when I came to talk with the financial comptroller, he showed me a blue book and told me: “What we need is to for you to help us configure the system to comply with these sets of codification and processes.” The blue book described the codification of the products, the warehouses, the operation of a distribution branch, and the format of the reporting needed to present to the different stakeholders. The blue book also gave rules on how to adapt the codification so each branch could comply with the country’s laws. That indeed was an easy project. I went in and out in a very short time. 

I also went to a matrix corporation in El Salvador. The company had the distribution operation plus a factory that manufactured the product to be sold in Central America and Mexico. The CEO of the company was Mexican. When I went to elicit the company’s requirements, they showed me the blue book again, and the request was similar, “we need to implement this codification and these reports to our main matrix company in Mexico.” But this time, it included all the operations of the factory, plus processes related to exporting goods to several countries. Again, my job was to show them how to implement the codification and create the reports to help them do the job. The implementation took me to the branch of this corporation in Costa Rica. Even though it was a little more complicated than Guatemala’s operation, the methods and codification were the same, all guided by the blue book; the only issue that I had to pay special attention to was the country’s legal requirements.

One year passed, and then the software was sold to a sister company of this corporation in Panama, so I went with the software. There I found was a distribution branch of a different type of product manufactured in several factories in Asia. This distribution company sold the products to all Central America, Caribe, and some Miami and Colombia stores. Again I went to elicit the CEO’s requirements, and he opened a drawer in his desk and showed me again the blue book. Well, I reread the blue book, but this time, only the sections that corresponded to the products sold in this branch, plus all the requirements to comply with exporting of goods. Panama is a particular country; the legal system is more relaxed than any other country in the region because of the Panama Canal. Many companies have distribution units there to take advantage of the fiscal incentives. The banks are relaxed and very protective of their client’s information, so it is a perfect place to do business. Again, I had to learn about the legal requirements and implement the blue book. The CEO was a temporary CEO. He was what they called an international executive, and his job was to open companies on behalf of this vast European corporation with operations worldwide. He had worked in Latin America extensively and received periodic training in Europe. He stayed just a few years in each country. He explained all the operations of the company and the purpose of the information systems, which was also described in the blue book. For me, this was one of the most rewarding experiences. It helped me realize how important it is the documentation and the preparation of people to implement a sound Data Governance system. We do not need a blue book, several software products accomplish this purpose, but the software does not make magic. The people in a team, discipline, and a thorough understanding of the necessities of a company are the elements that, when managed well, will create this magic.

I have worked in many companies as an external consultant. From this pool of experiences, I can say that these three examples are the ones that helped me the most to understand the purpose of an information system and the difficulties in implementing it. However, the challenges can be overcome by forming a team with the most knowledgeable people that the company has, a good moderator, and the understanding of the company’s depth and breadth along with the complexities that these factors add to the process of implementing a sound Data Governance System. Finally, the last lesson that I learned was that well-documented processes and data structures can ease the challenges of implementing any technology project by dictating a baseline to follow and still have room for improvement. To sum up, when you start a new project that has to do data, start by learning this information’s scope. The important elements that will help you with this task are understanding the operations’ breadth, how horizontal the organization is, and the depth of the operations, or how vertical the organization is. Once you understand your data and your organization, you can implement a Data Governance system. You can’t manage something that you don’t understand, thus, first, acquire the knowledge, and then you start governing the rules of engagement of this information.

Instruments to Generate Conversation and Obtain a Working Software Product

One of the first systems that I designed was about distributing chicken to different markets in the city of Guatemala. Markets in Latin American countries are the primary source of food for families, and they have a unique dynamic. They start to operate around 5:00 am. Most of the products are delivered at this time, so the vendors have the time to settle everything to start selling around 6:30 or 7:00 in the morning. This kind of schedule required that trucks are loaded between 1:00 am, and 3:00 am to deliver the product on time to each market around the city. The logistics to accomplish all of this is very demanding. It requires a very tight schedule from the orders’ posting, weighting the product, printing the invoices, loading the trucks, and delivering the product to each customer. Understanding the process was very daunting, and it took around one year and a half to design all of the features. I worked with a senior analyst that knew the process, but, in the end, the final product had many flaws. There were many teeny, tiny little tweaks that took at least another year to fix. It was the longest year of my life, with so little sleep. I remember; clearly, this one process we did not know existed that allowed an extra sale between 3:00 am and 4:00 am, and with the new system, there was not an option to report this extra sale. My boss asked me then why I did not ask for this process, which I answered candidly, well boss, I ask what occurs to me, but if nobody tells me I don’t have enough imagination to guess these things can happen, I cannot come up with a question. Eliciting requirements is indeed a tough job. Thus, how do we accomplish this task with the best results without risking the company’s operation by implementing software that doesn’t fully do the job?

One of the principles behind the agile manifesto states that “The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.” However, these conversations should have a specific method on how they should be performed; otherwise, they could become long rambling meetings with little outcome. The first step is to have a thorough understanding of our capabilities and expertise on the matter. Let’s say that we are experts in dogs, and the user needs an elephant. If the user describes an animal with four legs, a long snout, and big ears, we may be drawing Pluto’s picture in gray color. The context may vary amongst different stakeholders. The knowledge that we acquire during our life is shaped and modified by our culture, previous experiences, and sentiments. These experiences and stereotypes that we have acquired during our work life may create noise in requirements communication. Words and concepts may have different meanings amongst our peers; thus, how do we align various contexts to create a single feature upon which everybody agrees? Many techniques have been developed throughout the years, such as context diagrams, user stories, UML (Unified Modeling Language), etc. Still, for me, it comes to one solution: present an instrument to generate conversation about what it is important to achieve and how to do it.

The Instrument

It is well known that a picture is worth a thousand words. When it comes to context, a picture is the best way to align the concepts amongst the different stakeholders. If we go back to the example of the elephant, when the words are translated into a picture and presented to the users, they will say, “No, we do not want a grey Pluto.” Now the conversation starts. But, how do we build these pictures or visual presentations of reality in the actual job setting? The first step is to survey requirements. As a business process analyst or product owner, you will make a rough gathering of information about what is needed. The primary purpose of this activity is to listen and gather what everybody is requiring. The questions would be about understanding or clarification of ideas. Then the second step is to present a rough solution to the problem in a graphic presentation. The demonstration of the suggested solution can be a home run or a big flop; either way is fine. Remember, the purpose of the meeting is to align what you understood with the reality of what is needed, and this purpose should be clearly presented at the beginning of the session because some people will expect solutions right away. Depending on the personalities of each one, they could undermine the process if a big flop is presented. Here is where agile methodologies become an excellent tool to achieve results because you will not give the solution of the entire product, just the minimum amount of work that will be required for the next sprint. If you ultimately got it wrong, it is only a small part of the product that is being developed. Taking a step back and doing it all over again should not be a big loss, on the contrary, it would a learning experience.

However, we should define the concept of graphic presentation. This instrument may vary during the different stages of designing a feature for the product. The first step of developing a feature is brainstorming; the second is a first draft of the feature; the third is a tentative release; ultimately, the last step is the final release. I try to maintain these four steps; however, when I am not familiar with what I am designing, I may take an extra step between the first draft and the tentative release. It gets worse when the stakeholders are experimenting with the product or don’t know what they are looking for exactly. We can call this process an experimentation phase that may happen with new products. If this is the case, additional steps may be needed. These extra steps may require a focus group to evaluate the final release, and the feature may suffer significant changes at this stage. Steps can be added and deleted depending on the scope of the feature and the nature of the product. The instrument that is used in each stage will also vary. For the initial steps, I usually use mockups and flow diagrams explaining the feature. These mockups convey the inputs, flow, and outputs. You can create these mockups with a familiar tool like Excel or more sophisticated programs like Adobe UI Creator. This type of instrument serves two purposes, the generation of ideas and alignment of the message. The message to the audience is, “This is what I understood, confirm or reject.” When we are confident that we have all the necessary elements, we create the user story to be included in the next sprint for the developer’s team, the definition of done is reviewed with the stakeholders, and we wait for the result of the requirements. This result requires a demo, the demo is presented to the stakeholders, and the definition of done is reviewed again, but this time with the working software from the developer’s team. The instrument continues to be graphical because we can see it, and we can confirm or reject the results. The product owner or business analyst will present the demo to the stakeholders and be open to changes because this demo is still a draft, a working draft, but again, it is a work in process. All the observations are made, annotated, and translated into technical requirements for the developer’s team to be included in the next sprint. The definition of done will consist of these changes. When we get the results, a new demo is scheduled, and the observations are addressed. The cycle can conclude here or continue a couple of times. In my experience, when a team starts working, in this case, business process analysts and stakeholders, the cycles are longer, but when they get acquainted with the process of delivering a feature, and they find the way to communicate differences, the cycles become shorter. That is why agile methodologies are so successful because they allow learning experiences throughout the process and enable teams to integrate organically.

The conversation

We may have a perfect visual instrument and knowledge of the feature that we are trying to create. However, if we do not generate a good flow in communication when we are presenting our instruments in the different stages of producing a feature -gathering information, displaying the demos, and releases-, the product may not be as successful as it would be expected. The Merriam-Webster dictionary defines communication as “a talk, especially an informal one, between two or more people, in which news and ideas are exchanged.” If we say that the tone of the meetings around the presentations of the instruments is conversational, we are implying a relaxed environment where everybody’s opinion is essential. A product owner is responsible for the product; the product serves an audience; hence, the main job here is to direct the meetings towards serving the intended audience. Conducting successful meetings to gather information requires preparation and an excellent method for keeping a record of critical matters. I usually trust in visual aids to keep a record of the important subjects. I typically divide the board into three sections: the wish list, the things that matter the most, and the things that can technically be done. This arrangement may seem like the backlog in the Scrum methodology. But, refining issues is necessary throughout all the process of making a product. For me, the creation of the wish list is the most critical part of the process. Asking everybody what they need generates credibility. It also avoids animosity towards the process. And most important, excellent ideas may come up since there is no limit to the imagination. After the wish list is finished, the process of choosing amongst the ideas starts. The product owner’s intervention in this stage is to direct the conversation towards choosing what adds value to the product.

As a product owner, I always find difficulties finding the right moment to intervene in the conversation. Over the years, I discovered that making questions has been one of the most successful tools to direct the conversation towards the desired end. The other device is to arrange the information that everybody puts on the table into meaningful blocks; this way, we can eliminate ideas by repetition or make an idea out of fragments of several thoughts. By arranging and completing concepts, we create features that are grouped by their similarities. When we manage our board correctly, conveying and organizing the information, we create a visual context upon which everybody can read and agree or disagree. Ideas that contradict themselves are discarded, and incomplete thoughts are put together to generate great features. But we have to keep in mind that this exercise is done around our visual instrument. The instrument is the anchor that will keep our focus on the purpose of the meeting. There may be situations where thoughts pertaining to related topics may come up in the exercise; however, as tempting as it is to follow up this new feature, the product owner must set aside the topic to be discussed in another meeting. To describe how the process of presenting an instrument and creating a conversation around, let’s go back to our initial example of the grey Pluto. As a product owner, you will be presenting this wrong idea of the initial requirements -the elephant, and by creating a positive environment where everybody has an opinion and thoughts are complemented and organized, we will see the gray Pluto transforming into a beautiful elephant. Somebody will say the snout is not right, and he or she will give a complete description that someone else will complement. Maybe another member of the team will stand up and will draw the snout on the board. The product owner will manage the conversation by saying that the features should be addressed in a particular order; for example, he or she will suggest that it should be better to start with the snout, then the ears, then body, and so on. The process has been described to the team’s members. The tone of the meeting has been established. At the end of the session, we will have a better understanding of what an elephant is. Then the product owner will have the information ready to create user stories for the technical team.

To Sum Up

I can say that through the years, the best way that I succeeded in getting a software product ready for production has been, in part, by getting a good understanding of the features. This awareness comes directly from the intended audience of the product, and the way that I have found most reliable to elicit this knowledge has been using the right visual instruments that conveys the understanding of the product features. Visual communication is a powerful tool that enables all the people in the team to align different contexts towards a universal concept. This visual instrument may vary in the various stages of developing a feature, from brainstorming, to the first demo, up to the final release. The conversation generated around these visuals is vital to address all the misunderstandings. The conversation should also generate new ideas that add value to the product. The product owner or business analyst will serve as a positive moderator whose primary function is to command the flow of ideas and observations towards meaningful pieces of knowledge. The best ideas will be used to create user stories for the technical team. A product owner with experience in the industry may get results with fewer steps; however, the constant communication with the team using a methodology to elicit information will also generate positive results. The team will learn to interact, and with time, it will become more and more efficient, producing excellent features and definitions of done for the product.

Planning Top-Down, Executing Bottom-Up, The Agile Approach

Someone once asked me, “How do you handle a missed deadline?” We have to own the problem and inform using the appropriate channels on time, not days before the deadline. However, this outcome is preventable by using Scrum or any Agile method. I started working with agile methods some time ago when I was desperate to comply with my deadlines, and everything seemed out of place. The first technique that I used was workcells. Workcells are used in lean manufacturing; one workcell combines resources to execute a process, and several workcells create cellular manufacturing. According to Investopedia: “The goal of cellular manufacturing is to move as quickly as possible, make a wide variety of similar products while making as little waste as possible.”

One of the main characteristics of this methodology is the short cycles of manufacturing implemented in the workcell. I started with this technique by accident. I studied using workcells in supply chain management because I had to deal a lot with warehouses’ replenishment. One of the arguments presented was that short cycles were essential to assess performance and instill confidence in the workcells team. In the end, a team that sees positive results from its work becomes highly motivated. Another argument presented was that the process of following up short cycles becomes easier and promotes accountability. The faster we get results, good or bad, the quickest we can act to move on to the next task or to resolve the issue at hand. This assessment resonated with me in a big way. I used to implement ERP’s, which may take at least a year, and most of my projects lasted about two years. As an outsider to the companies that I worked for, I knew that my first task was to gain credibility.

I accomplish this first task by breaking up the project into smaller projects based on processes—one process is equivalent to one sub-project. Then I chose the project that had the highest likelihood of success in the shortest time. The next step was to sell this project as priority number one to the different stakeholders. I sold the idea using the following arguments: the team will learn the implementation process; the team will also learn how to communicate, and who the decision-makers are (in practice, decision-makers may appear in the most unusual places); finally I contended that a quick result in one area would boost the credibility of the process in all the other ones. In most cases, if we got this small project done on time and with positive results, the rest of the implementation generally would go as planned. Thus, the concept of short cycles seemed the solution that I was looking for.

However, using short cycles does not mean that planning for the long run becomes invalid. Over the years, I experienced that a clear roadmap with rough estimates of time sets the final destination journey. The stakeholders should clearly state this road, and it should have deadlines and milestones, and the details of how to reach each milestone may vary over time. If I had a two-year project at hand, I could not address a detailed plan on achieving the goals for the next year. The only fact that I knew for sure was what I could do for the next three or four months, so I planned for the processes that I could implement in that period. Even if I planned for three or four months, I focused only on what could be done in a month. The month concluded with a meeting with the stakeholders to deliver a sub-product. The primary purpose was to show progress. I would hold a weekly meeting with the team; the purpose was to address the week’s deadlines and the week’s problems before. Those who have worked on Scrum can recognize the agile framework in this approach. For me, being agile means short cycles of one or two weeks of work (the sprint), a clear long term goal (the vision), monthly deliverables to show progress to different stakeholders (the release), and milestones to accomplish to get to my goal (the roadmap).

I translate the agile mindset into one phrase: plan top-down, execute bottom-up and be prepared to change your plans without losing perspective of what the main goal is. The most challenging part of this approach is learning to deal with change and plan with big empty boxes that will be filled later. This planning must be done with some experience at hand because only if the planner has plenty of experience, he or she will know how to draw a rough estimate. That’s why the stakeholders should perform this critical activity. The combined experience of the team will deliver an informed estimate of the plan. Each subject matter expert will estimate without delving too much into the details. The plan should address everybody’s concerns. For example, the technical team’s subject matter expert may say that implementing a reliable database in AWS for the project at hand could take up to two months. Planning is always risky, but as a rule of thumb, the team should consider three scenarios: the worst-case scenario, the probable-case scenario, and the best-case scenario. The team should decide which one should be taken for the plan or parts of the plan. However, the best-case situation is usually used as a starting point. Choosing this scenario is not recommended. How does the team choose? Well, that is a complicated question that every book that I read about management answered with this phrase: “it depends.” Indeed, it depends on the circumstances: Is the project critical? Are the available resources sufficient for the project? Is there a need to hire people, and how long would it take to hire them? What are the levels of expertise of the team members implementing the project? Is there a team already formed, or is it a new one, and how long would it take to be fully functional? As many as they can address, the stakeholders should make many questions to create a reasonable plan. The final result of this activity that may take several meetings, is a plan that resonates with all the parties. Now that we have our project, with a vision, a roadmap, and milestones, no details, and fully approved, we can start with the next three months.

The work done in the first three months is the most important because the results from this work will set the rhythm of the project. This period will contain the preparation stages of the project. The product owner and the business analysts will prepare the stories for the first stage of the product. The technical team will have its own technical stories to execute, like servers, databases, and languages to be used. The product owners will focus all their attention on the first sprint’s details, the first release, the first retrospective, and of course, the first celebration. The end of the first sprint should be a motive to celebrate, and I would recommend doing it in a simple yet meaningful way. This kind of activity generates goodwill in the team and creates a commitment towards the goal. I do celebrate the first sprint, the releases, and of course, the realization of the vision. The last one is a major celebration, a well-deserved congratulation, and a good excuse to introduce the new vision to be executed next.

We have discussed how to do agile, but doing agile is not the same as being agile. Being agile is a mindset that enables you to plan for big things and still stay focused on the next sprint in everything that you do. Being an agile practitioner is hard, and it is harder for people that have been involved in the technical fields for some time. Programmers and good software architects tend to be detail-oriented and need to know how everything is going to fold. The anxiety that comes with uncertainty is hard to overcome, but it is doable with practice. First, start small and simple. The creation of the agile mind is what makes a good agile team successful. If the team believes in the methodology, then a big part of the work is already done. I heard someone saying that he had a board with all the chores and projects needed at home. He picked the tasks that could be done over the weekend. If he could do some work on weekdays, he chose something that he could do in a couple of hours. This description is the simplest way of depicting an agile mind. Another example is using agile to get a college degree. The vision is a four-year degree, the milestones are eight semesters, the sprint and the focus is what we can do with the best possible results in the next week ( tests, homework, and projects), and the retrospectives can be done after each major project or midterms, what we could do best next time and how are we going to do to get on track with the grades. The most important part of this exercise is to keep focus in the sprint. Do the best, with the resources at hand, to execute the work for this week. One week at a time, and then all over again. Believe it or not, it is working with my first-year college daughter.

To sum up, being agile means having a vision with a roadmap to be followed, marked by milestones and expected changes –planning top-down. The secret to finishing the road is to know how you will do the next couple of yards. Something may appear in this short distance that will change how you will approach the next ones. Stay focused in this sprint, do not worry about the next one, wait for change, and don’t forget where the road is going, the vision –executing bottom-up. Practice makes perfect; thus, try to get an agile mind in every project, personal and professional, that you do and keep it simple. Adapt to your circumstances, and some ceremonies may need some change for your particular needs, be agile, stay agile, do your retrospectives and start all over again.

References

Kenton, W. (2019 Jun 30). Work Cells. Investopedia. Retrieved from https://www.investopedia.com/terms/w/work-cell.asphttps://www.investopedia.com/terms/w/work-cell.asp

Reduction of Communication Bias in Project Management

I have worked as a project manager for several years, and communication has always been the main issue. Being a project manager can be challenging since the project manager is responsible for the results without owning the resources used to implement them. Most of the team members may belong to different departments with different bosses. These members may even work in different companies. Therefore, the team members may have different points of view on how things must be done, and the company values may also change amongst various departments. Thus, it is fair to say that those differences become more significant if people belong to different companies, which may lead to a failure in the implementation.

Communication is key to a project’s success, and cognitive bias plays a vital role in the communication process. So, what is bias? According to Psychology Today, “bias is a tendency, inclination, or prejudice toward or against something or someone” (Psy,2019). Some biases are good, like eating greens; they will help your health. Others are bad, like stereotypes. Biases are cognitive shortcuts that can lead us to make a rash decision without a thorough understanding of a problem. Then comes the second question: how can we reduce bias during the communication process when executing a project? Indeed, there are many techniques and documentation about communication in project management. However, here we will concentrate on what has been more helpful for me over the years. First, clearly define the goals of the project with the team. Second, trust the word of each member of the team. Third, review the project from each member’s perspective; this is called a 360º overview. Fourth, act upon concerns, which means that you should eliminate impediments and resolve concerns.

Let’s start with the definition of the purpose of the project. An excellent way to do this is using the SMART technique to create the goals; SMART stands for specific, measurable, attainable, relevant, and time-bound. Everybody needs to know what is expected from them and the time frame. This activity should deliver a document signed by each team member, which will be the manifesto of the project. I have learned that if people disapprove of the manifesto, they are not reading and understanding the goals. Creating shared goals will reduce bias in the project’s expectations; everybody will be on the same page. However, this is just the start.

Several problems might arise during the execution of the project, The difficulties can span over different time frames, departments, and processes. These problems will be solved if and only if the team members can assess the real scope of the problem. One common issue is that the team member who is addressing the issue will be undermined or misunderstood; this type of bias is due to perception. Everybody has a different understanding of facts. This difference in perception occurs because the information is stored in the brain with modifications made by previous experiences and sentiments. There is also the fact that the communication process has flaws, and we tend to fill in the gaps with the modified knowledge that we have stored in our brains. To address this problem, the project manager should work as a moderator, and they should create an environment where every team member trusts to speak candidly.

Another way to reduce perception bias is by using data to support facts. The correct approach should address the problem and describe it with valid documentation and numbers drawn from the project. This approach will tend to eliminate the necessity to fill in the gaps and wait for information before making any decision. Speaking candidly and showing information from every team member will cover the 360º overview of the project. Each member of the team will have an equal opportunity to show their concerns. We can see a project like an apple; if we see it from the front, we cannot see if there is a worm eating the apple in the back. However, if we turn it, we will see the bad part of the apple. We will have the 360º overview of apple only if we allow each team member to give their point of view of the situation: trust your team.

Last but not least, act upon concerns. Each concern should be address even to be dismissed by consensus. The team members will trust the communication process since every concern is addressed, and every problem is given a path of action. A problem that is small at the beginning can be solved before it can derail a project. At the end of this exercise, the team should generate a document of compromises with a time frame, responsibilities, and actions to be taken. The path of action should address clearly the questions: what, who, when, and how. This list should be task-oriented, simple in language, and with dates and one owner for each task. An activity without an owner is nobody’s business: the problem won’t be resolved. I shall stress the word “one”; more than one owner will also create confusion. Ownership occurs when one person is responsible for the task. The owner will not necessarily execute the activity, but he or she will be responsible for it.

There are more issues to be addressed to have excellent communication in a project. According to the Project Management Institute: “55% of the project manager is spent on communication” (PMI,2013). There are many documents and techniques to learn related to this topic. In fact, there are many types of communication in a project: to ask for requirements from a client, to give feedback to clients, to inform the main stakeholders, to inform external stakeholders, and others. However, the communication that happens among the team members is one of the most important ones. The communication to inform the different stakeholders will originate from the team once the project has started. The good execution of the project will also depend on this type of communication to address issues. The tools described here have worked for me to reduce bias in the communicating process; they are a good starting point: SMART goals, trust the team, 360º review of the project, and act upon concerns. Practice makes perfect, and these techniques, when being implemented and used frequently, will become good habits in the everyday life of a project manager.