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.

The Business Model Canvas is a common method to build a business plan in very large and small companies because it is both structured and very simple to understand. The Business Model Canvas is also very Customer-Driven. Yet, there has not been in the past an easy way to plan a detailed Business Architecture model starting from a Business Model Canvas to enable marketing and operation planning. In this article, we will demonstrate how to easily bridge a Business Model Canvas to a Business Architecture model to optimize with agility your marketing and operating modeling.

"I’ve observed a disconnect between stakeholders from the Pentagon and the engineers building the system. I’d like to show you a new technique called Behaviour Driven Development (BDD), which can help us explore how software will behave BEFORE it’s built”.

An analyst must frequently contend with structure-less environments and relentless rejection, and the character of Alice highlights many desirable characteristics that constitute the makeup of a good business analyst. Having identified the value of the Mad Tea Party as a learning ground in the previous episode of this series, we will now examine some of the key lessons learned and how they are applicable to the work of the business analyst.

A list of business analysis techniques is pretty extensive and from year to year new techniques appear, or become more formalised, and are adopted by business analysts all over the world. Some techniques become more popular and are widely used and some are used rare or only when a specific need arises. But definitely there are techniques that became very popular and are used on a daily basis and even become buzz words for some people. These techniques are mainly used to create solution design and they are business process maps, use cases, user stories, wireframes and business rules. Sometimes even business analysts are confused how they should create solution design and what techniques they should use.

By signing up to go through this process, you will be doing yourself a huge favor – a favor that you will never regret especially when people will look at you as the ‘wow’ person who completely transformed his or her life, achieving something that was not even vaguely possible otherwise.