Knowledge isn’t like other commodities. If I have three dollars and give you one of them, now I have only two dollars. Money is zero-sum in the sense that I must lose some of it for you to gain something in this transaction. In contrast, if I give you some of my knowledge, I still possess all the knowledge myself. I can share it with other people, as can you. Everyone touched by this expanding circle of knowledge benefits.  Everyone has something to teach—and to learn. You don’t need to be the world’s expert on some topic to be helpful. You just need some useful block of knowledge and the willingness to share it. In the world of technology, if you’re one week ahead of the next person in some area, you’re a wizard. Someone else will doubtless be ahead of you in other areas, so take advantage of their trailblazing. People in a healthy learning culture share what they know and also acknowledge that someone else might know a better way.

One of the most empowering aspects of the agile mindset is that fact that agile teams are generally self-organized verses the traditional command and control protocols of traditional project management. While there are several benefits to self-organizing teams, it can lead to failure if the team misses some key planning aspects during team formation. Agile chartering is key to executing successful agile initiatives. In general, agile charters consist of the project charter and a team charter. The project charter defines the project vision and objectives, while the team charter establishes how the team will work together and how they can incorporate agile values as the team collaborates. A team charter is especially critical when organizations are new to the process of incorporating agile frameworks into the organization as it will facilitate knowledge transfer and identify key learning opportunities. With that said, here are some key reasons agile teams need team charters.

Business knowledge is simply knowing your business—its facets, strengths, weaknesses, competition, challenges, positioning within the market, and readily available solutions to its daily problems. Strong business knowledge should inform everything you do.  So, what you learn and hear in discovery should be filtered through your business knowledge. What you define in your requirements should also be informed by your business knowledge. As one business analysis writer puts it, “I’ve always been of the opinion that I’d like to know as much as I can about whatever I can because you never know when something you learned may come in handy.”^[2] The following four areas are the ones, specifically, according to BABOK, that you’ll want to apply yourself to.

The quality of any data analysis created to inform business decisions will ultimately be constrained by the quality of the underlying data. If the data is faulty, then the analysis will be faulty too. This is why data wrangling–the transformation of raw data into a format that is appropriate for use–has become such a ubiquitous task in most organizations. Unfortunately, the significance of data wrangling is still often overlooked. And this is where data-savvy business analysts can help save the day.

Thanks to infrastructure as a service (IaaS) and software as a service (SaaS) architectures, the utility of and business case for model-driven, no-code and low-code platforms have become more compelling than ever. More and more enterprises are entrusting their digital transformation, regulatory compliance, and business process management objectives to model-driven, no-code or low-code business application platforms.  These model driven platforms also raise the bar for the business process modeling skills of the business analysts, systems analysts and process owners who use them.

Many BAs struggle to produce ‘normalized’, function-independent data models (or don’t produce them at all). Very few business stakeholders can appreciate such models as “… a picture worth a thousand words.” This article describes an easy-to-create, simple-to-understand view data model. The view is of just those records involved in an information system capability supporting a specific business activity.

NOTE: This article uses the business-friendly terms record and field rather than the usual data modeling terms entity (or class) and attribute.

A crisis always highlights the need for specific managerial and leadership Behaviors (Behavioral School of Leadership). These behaviors of course are triggered by specific personal characteristics of the leader (Leadership Trait Paradigm), by the specific conditions (Leadership Contingency Theory) and by the willingness and devote of individual in continues practicing these behaviors any possible occasion. Although it is my intention to approach the leadership from a behavioral point of view, a synthesizing and integrating logic is more than necessary to have a holistic view that can lead to insightful conclusions.

In this fun piece, Ron examines the connection between rules and counts, such as KPIs. Ever wonder why different people can count the very same things and come up with different answers? Fear the numbers you’re going by aren’t telling exactly the right stories? In viewing a measure, how far the truth might have been stretched? Come along on this short travel story and let’s explore the matter together.

Learning how to become an effective people manager can be difficult. Becoming a manager of business analysis resources has some unique challenges, but I hope to make it easier for you by sharing some advice based on my experience managing three different business analysis teams in three different organizations.  There are two ways people become business analysis managers; from having a lot of business analysis experience or being a people manager and transitioning to leading a business analysis team.  

In my experience while working for different companies, I have seen that some organisations are learning to be agile while some pretend to be agile and others are not agile at all. While we are not here to talk about the last category (assuming they have a very good reason for not wanting to go agile), I would like to put down some challenges for organisations who are on their journey to becoming agile and for those who think they are agile but are possibly not. In this article, I am going to talk about my understanding of the plausible reasons why some organisations struggle to make it.

The practical applications of data science are multiplying. From predicting if a delivery will arrive late to recommending how much herbicide to use to save money and protect the ecosystem, there are endless examples of organizations harnessing data science solutions to improve the efficiency and quality of business decisions.

Is there something called as Agile BA or DevOps BA? Or is there a dedicated role such as ‘BA in DevOps’? How are Agile and DevOps related? How does BA role change or goes through metamorphosis, when it comes to DevOps?

One day, I got a corporate training enquiry and that is when I heard the term ‘Agile BA’ for the first time. At that time, I had already worked on Agile projects yet nobody had referred to my role particularly as Agile BA. A thought came to my mind, what if there was a job post saying “looking for a ‘Waterfall BA’?” I even heard once: “With DevOps there is hardly any role a need for BA or PM”.

As BA's our fundamental job is to understand the business problems proactively, determine the consequences of not solving them, and then define a solution that eliminates or alleviates the problem. When given our directives: (i) a problem exists- define it (ii) provide a solution to that problem- describe it (iii) a change is required in the business to solve the problem- realise it. We must have effective tools in our arsenal, and a sure way to see beyond the bars on the window is to understand the fundamental truth of the situation and reason up from there. A first principles mindset could be that dominant tool to understand the seed to reap the fruits, enabling us to be the change agents that improve business processes and add value.

In a previous organization I worked for, I formed a Business Analysis team by bringing 7 business analysis professionals together for the first time.  There were no templates, no standards, everyone was doing work their own way.  I don’t believe in standards for the sake of everyone doing work the same way, but I do believe in embracing what works best in an organization and striving to use that to achieve repeatable success.  I introduced the concept of a Business Analysis Center of Excellence (CoE) to the organization. 

Several years ago, I had the opportunity to manage a group of project managers and business analysts. This article reminisces about what shaped my thoughts on managing such a group and hopefully gives you some considerations given the opportunity.

Past Experience

Perhaps negative experiences impress us more than positive ones. What does not kill you, makes you stronger. In the area of managing a group of project managers and business analysts, two negative experiences stand out for me. I was a project manager engaged in a conversation with my boss on my development. I had worked for this person several years. I asked him if he had heard about a group called the “Project Management Institute.” He said “yes” and maybe he should expose the organization to the group. Maybe? I asked the question since I had been working as a project manager without guidance and frankly was a bit upset over the lack of leadership and development. I told myself, “isn’t that the role of management - to develop people.”