AI has the potential to revolutionize the way software is developed, tested, and maintained, bringing a new level of automation and efficiency that...
Storming, Norming, and (Performing) the Business Analyst
Today, software development has become a widely used term. But how many of us have wondered how software ends up on our computers?
There is no simple answer to this question, instead, we can look closely at how a goup of a group of people tipically interact and understand each step of the process. Finally, we can discover the importance of the Business Analyst within a software development team.
What are we theoretically talking about?
The beginning of any project involves going through certain stage. First, we allocate time to get to know each other within the team. Some of us may be more hesitant at first, but over time, we start to become more vocal and engage in interactions, participating in constructive discussions that may be contradictory initially. Eventuallly, we find our rhythm, and everyone feels like a part of the team, knowing what needs to be done.
This process was initially outlined by Bruce Tuckman, an American psychology researcher. In 1965, he formulated the "forming-storming-norming-performing" model. Tuckman believed that each stage had its own characteristics. He referred to the initial stage as "Forming", which is a period of getting to know each other, familiarizing with the project, and starting to assign initial tasks. At the same time, he mentioned that during this stage, team members tend to work more individually, and everyone showcases their qualities.
After the initial stages, the next phase is what Tuckman referred to as "Storming," the second stage of team formation. At this point, disagreements and conflicting opinions among team members often arise. Each individual has already formed their own opinions about their teammates and begins to voice their thoughts, attempting to establish an informal hierarchy within the team. Tuckman considered the "Storming" period to be the most challenging because people may feel judged, tensions may arise, and there can be exchanges of ideas that lead to a hostile working environment.
The third stage, "Norming," describes a state of harmony within the team. At this stage, all the team members have managed to resolve their interpersonal conflicts as well as differences in opinions, and everything starts to flow naturally with a sense of familiarity. The team members develop interpersonal connections and bonds of trust, allowing everyone to focus on achieving the common goal: project delivery.
However, there is yet another stage after "Norming," called "Performing." This step describes an above-average state of normality, where everyone is working at the highest level, and the project is progressing at a faster rate than anticipated. Most teams eventually reach this stage, sooner or later depending on leadership, but there is often a risk of regressing to "Storming" if major team components or even team leadership changes.
How does a Business Analyst contribute to project delivery?
The Business Analyst is the person who has the closest connection to the customer. They understand and guide the client, documenting their requirements in order to deliver customized software and best meet their business needs. With their knowledge and experience, the Business Analyst can help the client fully understand their needs within the project. As a result, they break down the requirements into smaller parts that can be addressed incrementally through user stories by the team. Additionally, the Business Analyst must prioritize and organize these user stories to follow the plan that will lead to project delivery according to the client's desires. Moreover, they ensure ongoing communication with the client at every step to achieve the final proposed goal.
In a team consisting of Developers, QA, Project Managers, Scrum Masters, Team Leaders, or other roles which we will refer to as leadership, we can observe that the Business Analyst has, in fact, multiple dimensions to consider in addition to keeping in touch with the client and shaping requirements through User stories. Therefore, it is worth taking a closer look at how a Business Analyst can contribute to the team formation process throughout the project.
What does a Business Analyst actually do?
Each stage of the project involves a different level of team fromation, so we can consider that the involvement of the Business Analyst varies depending on the stage.
First and foremost, the Business Analyst needs to maintain constant communication with key individuals involved in project leadership, such as the Project Manager, Team Lead, or Scrum Master. These individuals have a significant influence on the team and play an important role in addressing and resolving conflicts. It is important for the Business Analyst to maintain regular one-on-one communication with the leadership team members, as well as group-level communication with other team members. This helps establish a group "policy" regarding the team's approach, taking into consideration both the business needs of the client and the input from the team. The Business Analyst's communication with the leadership team is essential for two reasons: firstly, the Business Analyst needs to be aware of the team's capabilities and any changes within the team that may impact the project's progress, in order to accurately anticipate the future needs and types of tasks (information obtained from the leadership team). Secondly, the leadership team needs to be constantly aware of the client's business needs (information best known by the Business Analyst, who can analyze and document these needs).
As mentioned, the involvement of the Business Analyst needs to be proportionate to the stage of the project.
In the early stages, particularly during the "Forming" phase, including the initial introductions, the Business Analyst needs to support communication and demonstrate neutrality in expressing opinions. According to Tuckman, during the "Forming" phase, people tend to be more timid, which calls for easy and open communication. At this point, the project leadership should organize "get-to-know" sessions among team members, and the Business Analyst should show willingness to get to know new people, share experiences, and create a friendly environment to encourage other colleagues to be open in their communication. Additionally, without mutual support between the leadership and the Business Analyst, the team may perceive an environment that is less conducive to development, perhaps even chaotic.
The "Storming" phase is indeed often the most challenging stage for a team. By this point, the team has learned to communicate effectively, members feel comfortable with each other, and conflicting opinions are bound to arise. In this stage, one of the most important aspects is for the Business Analyst - who has the best understanding of the next steps in project implementation or the existence of already implemented applications - to demonstrate their availability to the team and provide guidance where necessary.
The Business Analyst can defuse a tense conversation by making a decision that serves the ultimate business need. Whenever a misunderstanding arises, the Business Analyst should act as the mediator, leveraging their knowledge of the client's business needs. However, making a decision can only alleviate the tension if the Business Analyst has listened to all parties involved, provided clear and transparent arguments for choosing a particular option. Similar to the first phase, there needs to be mutual support between the Business Analyst and the leadership, as the absence of such support can create an environment that is hostile and chaotic.
Moving beyond the "Storming" phase, during the "Norming" stage, the role of the Business Analyst as a mediator typically diminishes. Team members already know they can rely on the Business Analyst to address any project-related questions or concerns.
Similar to the "Norming" stage, in the "Performing" phase, the Business Analyst no longer serves as a mediator but rather becomes an encourager for the team. In this phase, individuals have already learned that they can make decisions that contribute to the project's success and work together as a high-performing team. At this point, the Business Analyst's role is to instill further confidence in the team, encourage the progress of the project, and ensure that the final outcome aligns with the client's business needs.
So, what should you expect from a Business Analyst?
As described earlier, a Business Analyst needs to be a dynamic element within the team because the team is constantly evolving. The Business Analyst should act as a mediator between the business objective, the interpersonal dynamics of team members in various stages of the Tuckman model, and the project's leadership policies. By adapting to these elements can the Business Analyst have a positive and significant impact, ensuring that the project efficiently achieves its business goals with team that consistently demonstrates a performance-driven mindset.
Speaking from personal experience as a Business Analyst at PitechPlus, I have witnessed firsthand the importance of the attitude I bring to a project. Starting from the forming stage of a project, I noticed that the team tends to complicate certain topics, and I'm not referring to constructive conflicting discussions. By offering to mediate, having one-on-one conversations with team members, and consistently fostering a calm and constructive environment, we were able to deliver a high-performing project that left our clients extremely satisfied.
Therefore, regardless of the role you have in the project team or the experience you bring, always consider the big picture and be open to asking questions and seeking guidance. You will receive answers and be part of a successful team.
Read original article here.