Congratulations! You have been asked to act as the lead Business Analyst (LBA) on an important project. It is more than likely someone recognizes the good work that you have done in the past and their hope is that your past success can be replicated with multiple Business Analysts on this new initiative. Like any new experience, you may have some anxiety or nervousness regarding this new role. It is important to you that what happens turns out to be a future success story and not an experience that stays in the closet.

Consider an agile project on the other hand. Agile projects do not require massive documentation in advance. Moreover, in agile projects, the business owner might communicate directly with the agile team (developers) and sometimes the agile teams are even co-located, which makes the communication between business owner and agile team easier.

So, there is no role of a Business Analyst in agile projects you say!

There’s a high premium on knowing how to craft great definitions. Every business analyst should know how. To get you started, here are some basic criteria for great business definitions:

• It should be easy to give examples for the thing defined, but there should be no counterexamples.
• Each definition should communicate the essence of what a thing is, not what it does, how it’s used, or why it’s important.
• The definition of a thing should focus on its unique characteristics.
• Each thing you define should be distinguishable from every other thing you define using the definition alone.
• Each definition should be concise and as short as possible without loss of meaning. A definition should be readable.

This is the time for the BA community to expand its capabilities and provide critical value to the organization. With a massive 86% of global CEOs reporting a lack of time to think strategically about the forces of disruption and innovation shaping their company’s future, businesses leaders must lean on the evolving capabilities of the business analysis community.

The causes of chaos are unpredictable behaviors that arise from individuals, teams, or systems. Behaviors portrayed by the mentioned three components affect how an organization is able to handle challenges and problems. By allowing individuals and teams to portray their own behaviors in the working environment, different components of an organization may either work properly or experience failure. In the subsequent sections, we will elaborate on some mechanisms that trigger chaos in an organizational context.

I always see people go gaga over agile development methodologies. While I agree that agile has its own advantages, I disagree on the fact agile is an all-powerful and does it all kind of methodology. However, if executed right, agile does have the capability to be an all-powerful methodology. Although the advantages outweigh the perils of agile, the perils if not properly addressed can put the business value and relevance of the solution at risk.

Let’s face it, there are just some conversations that you don’t want to have. There are some people you simply don’t want to talk to, but what happens when we don’t have these conversations? Everyone loses! It is perfectly natural for us to avoid difficult conversations. We fear rejection, retaliation, emotional outbreaks, the dismissal of our ideas, and of course those incredibly awkward moments where everyone around you stares at their feet thinking “God I am glad that’s not me.” However, these conversations need to be had and the Badass Business Analyst will have them. If we want healthy, productive teams and projects, crucial conversations must be had frequently. You can’t just keep ranting, raving, complaining and avoiding, you need to start having meaningful, persuasive conversations that make an impact. You need your ideas to be heard, and more importantly you need behaviors to change. Don’t you think its time you and I have a crucial conversation? Suddenly I feel like I have turned into my father. Sigh. For the record, all of his crucial conversations were always too late, which is maybe why I am so passionate about this particular chapter in my book (the longest chapter by far - okay, moving away from from therapy now).

Is your team struggling with the transition to modern requirements practices? As many teams explore and experiment with modern practices and agile, they often jump to apply tactical methods and techniques. But does anything really change?

 

Most teams work really hard and don’t see results. Or they find a few early benefits, but get stuck on a low plateau. They often give up and slide back into their old habits. Why? Because they’ve modified surface-level tactics, but haven’t modified mindsets.

Every organization has some degree of “chaotic” culture. Some of them breed chaos and unconsciously operate in chaos. Project management is designed to operate with structure. However, reality has always contained a dose of “Wonderland” as well. Projects find themselves at odds with the environment that they operate within when the underlying organizational culture tends to be chaotic and less disciplinary and operates randomly. Project management methodologies and execution processes’ logic and convention are contradicted by the chaotic, shape-shifting setting of “Wonderland.” This conflict threatens a successful outcome for a project. The uncertainty that projects are confronted with throughout the execution process can be fatal. Chaos, by its very nature, is impossible to control completely, and so projects struggle to deliver as they fail to manage the conflict they find themselves in with the organization’s way of life.

Many business analysts fail to achieve top performance while starting to work on a new domain simply because of their fear of making mistakes. I’ve heard analysts freely admit that looking less than competent is what they fear most. “I don’t know what I don’t know” they will tell me, “and in particular in a domain I’m not very familiar with, I’m always afraid I will miss an assumption or an avenue I must address.”

A story is defined as a narrative or tale, true or imaginary. Each story has a moral hidden in it. A story writer won't directly say that hard work and patience is the key to success. Instead the writer came up with a story of Hare and Tortoise. And if we observe carefully, stories are everywhere; we ask a friend about her love story, we watch a prime time news story, we ask a new friend about his life's story, the movie I watched the other day had a good story. 

When my older son graduated from college, he worked as an intern for a professional sports team. At the end of his very first day of work he called me, puzzled. "I asked them what my responsibilities were," he related, "and they said, 'We need you to know what we are supposed to be doing'." After a long pause he went on, "I wanted to ask them why they didn't already know what they were supposed to be doing, but I didn't think that would be such a great idea my very first day there."

Moving on, we will investigate the importance of the business analyst’s often delicate relationship with individual stakeholders.   A business analyst is a facilitator of change, and in affecting these changes within a company, the analyst must interact with multiple stakeholders of varying personalities. When identifying and delivering the necessary changes within a business, the analyst must develop and maintain a relationship with each individual stakeholder.  Each stakeholder will wield a different level of authority within the company and hold a certain amount of power over those changes that are coming into effect. Noting this, the analyst must take part in a careful balancing act, juggling these relationships in order to facilitate change with minimal difficulty.

This short paper series, “Deep Dive Models in Agile”, provides valuable information for the Product Owner community to use additional good practices in their projects. In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.