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.